The Elisity Cognitive Trust platform offers the most comprehensive and flexible policy language in the industry while ensuring simplicity and scalability in its deployment and management methodologies.
Policy Objects and Security Profiles
Elisity Policy is comprised of two components: Policy Objects and Security Profile Rules. Policy Objects use identifying data about assets to create referenceable objects. Security Profiles define what traffic is allowed between these policy objects. The article linked at the bottom of this page goes into more detail on these policy constructs.
Identify the Assets You Need to Protect
Our zero trust capabilities are intended to protect your business from the impact of breaches, enabling only trusted users and trusted devices to access your trusted applications, wherever they are.
The starting point for our policies are the business assets you need to protect - for instance, intellectual property, customer or employee data or electronic health records (figure 1). We build comprehensive inventories of the critical assets on your network, and use gleaned identity data to create policy objects based on asset identity rather than constructs like MAC address or IP address.
Figure 1. Example policy summary.
Controlling Access To Critical Business Applications
To represent your critical assets, the things that you most need to protect, we first define policy objects.
The Cognitive Trust policy model is extremely flexible and allows user identities, device and application types to be referenced directly in policies, but to gain the most value from Cognitive Trust we recommend that reusable policy objects called Policy Groups are defined to represent the combinations of trusted users, devices and applications that matter to your organization.
For example, to allow only building control systems to access your building management applications we could create a policy group to denote a variety of control systems that need to communicate with building management systems, but be isolated from many forms of user endpoints (figure 2).
Figure 2. Policy attributes.
In the policy logic used, we use policy groups to describe the business assets in plain language, along with the detail criteria used to map individual endpoints or applications into that policy group.
For a compliance-critical use case like handling credit card data (figure 3), we may form policy groups to describe the PCI-critical apps being protected and the very specific entities that may need to communicate with them:
Figure 3. Policy groups of compliance critical data.
If we consider a healthcare example, where health records may be critically important, policy groups used may define Electronic Medical Records applications and the devices that are required to access them, such as Infusion Pumps and Patient Barcode scanners
Figure 4. Specify specific devices with access to applications.
In these examples we have used group-based policies. For situations where there are exceptions to group-based policies required or specific users require elevated privileges, users and specific devices can be referenced directly in policies without needing additional policy groups to be created.
The next article will walk you through policy objects, constructs, logic, and application.