Policy Groups

Policy Groups are the building blocks of Elisity microsegmentation and are used to dynamically or statically assign assets into groups that receive the same level of cybersecurity treatment. 


Policy Groups

A Policy Group is a core building block of the Elisity policy architecture and allows an administrator to group together multiple users, devices or applications based on match criteria. Policy Groups can also be used to define custom IP ranges to be treated as policy endpoints. The policy group can then be referenced during policy creation as a source or destination entry, effectively simplifying and avoiding policy sprawl. 


Default Policy Groups

Cloud Control Center is delivered with several pre-built Policy Groups, including Unassigned and InternetPG.

Unassigned is a catch-all Policy Group for any user, device or application that does not match to any explicit customer-defined Policy Group. This allows customers to secure any asset on the network that is unidentified, or does not yet have a policy group defined. 

NOTE: Unassigned Policy Group applies to any device not classified by Elisity. This includes upstream devices north of the policy enforcement point. Use caution when deploying DENY policies to the unassigned Policy Group. This can block critical functions like DNS if used improperly. 

InternetPG is a modifiable Static Policy Group that defines external subnets as a policy endpoint, effectively controlling any traffic destined for network addresses in those defined subnets with policy.


Types of Policy Groups

There are two types of Policy Groups that are used to meet two specific use cases:

Dynamic Policy Groups

These Policy Groups dynamically group assets (users and devices) using identity to be used as policy endpoints. Dynamic means that as assets are discovered and evaluated by our policy engine, they are assigned to these policy groups using a holistic view of the policy group structure you have built including context of Policy Group order (precedence), match criteria using a variety of attributes, and if an asset is known by your AD or CMDB.

Static Policy Groups

Statically define IP addresses or subnets to be used as policy endpoints. Define subnets from /1 all the way to individual hosts at /32. These Policy Groups always take lower precedence than dynamic Policy Groups during policy evaluation. 

NOTE: Because assets are assigned to Static Policy Groups based on IP address, if a device goes offline (loses it's IP address) it's Policy Group association will be changed to the "Unassigned Policy Group" until an IP address can again be associated with the said device. This is not the case for devices classified into Dynamic Policy Groups since classification is based on identity attributes and not IP address. 

Baseline Policy Groups

There are a handful of Policy Groups that we ship with Cloud Control Center as standard or "baseline" Policy Groups for IT and IoT devices. These are completely modifiable and serve to group the most common IT and IoT devices that we find in customer environments into Policy Groups. This provides customers the ability to see assets auto-classify into Policy Groups upon discovery when deploying Elisity in their environments. Custom Policy Groups need to be built for all IoMT, OT, or unique IT/IoT devices that are expected on the network.


Creating Policy Groups 

Creating Dynamic Policy Groups

In the following example a policy group is being created that matches users that are a part of the Physicians AD group AND are connecting to the network using a laptop. This policy group will later be referenced as a source or destination on the Policy Matrix when creating a policy.

To create this policy group, navigate to the Policy section on the left pane in Cloud Control Center, select Policy Groups on the top menu bar and then select Add Policy Group. You will then select which type of POLICY Group you want to create: Dynamic or Static. Here we will select "Dynamic Policy Group.'


We will give our Policy Group a name that aligns with the rest of our naming conventions, insert a brief description, and we can begin to select our match criteria.

Policy Groups offer a flexible AND/OR logic for matching assets. Lets briefly run through this AND/OR logic and how it can be used to create powerful match criteria to ensure that no asset is misclassified.


Dynamic Policy Group AND/OR Logic

Dynamic Policy Groups are essential for the targeted application of security policies in networked environments, leveraging AND/OR logic to create sophisticated and custom-fit groups based on distinct criteria.

"OR" logic enables the inclusion of devices that satisfy any one of several criteria within a given category. By selecting a category like "Device Type," administrators have the ability to form a Policy Group comprised of diverse devices that share similar security requirements, such as IP Cameras, Security Systems, or Doorbells. Here, OR logic means that any device classified under these types is eligible for inclusion in the Policy Group.

You can further refine these groups by using AND logic, overlaying additional criteria onto the previously defined match criteria. For example, an administrator may first group devices by type with OR logic and then apply an AND condition to further specify that only devices from 'Ring Solutions' should be included. Consequently, the Policy Group is narrowed down to devices that are either IP Cameras, Security Systems, or Doorbells, provided they also match the vendor criterion.

Alternatively, the second-tier application of OR logic serves to widen the match criteria further. By strategically combining AND and OR logic, administrators can define Policy Groups that are either narrowly targeted for specific device configurations, or broadly inclusive to cover a wide array of devices, thereby ensuring flexible and precise security policy enforcement. Below is an example of combining multiple match criteria using "OR" logic to broaden what devices will fall into this Policy Group - Assets can match on Device Type OR Vendor, and both criterion DO NOT need to be met for an asset to be assigned to this Policy Group.


Note: You cannot delete a Policy Group until you have first deleted all policies associated with that Policy Group. It you have not yet deployed a policy, this will make more sense in the next section.

Note: Matching on AD User Groups requires entering at least three characters to query existing AD groups for use as match criteria.

Creating New Match Criteria in Policy Groups

Direct Addition of New Criteria

When setting up a policy group, you can directly add new values for Device Type and Operating System. This capability is useful for preparing your network to seamlessly integrate and manage new devices that are not currently present or visible.

Proactive Network Security

By leveraging this feature, administrators can ensure that as soon as new devices are detected and their attributes are learned, they are immediately covered under the appropriate policy groups. This proactive approach reduces the time and effort required to update policy groups in response to network changes. This ensures that all devices, regardless of when they are introduced to the network, adhere to your organization’s security policies and compliance standards from the moment they are discovered.

Utilizing the Feature
Navigate to Policy Group Creation: Select the option to create a new policy group.
Input New Match Criteria: For Device Type or Operating System, select the option to add a new value. Input the criteria for device types or operating systems you anticipate integrating into your network.
Apply and Save the Policy Group: With your new criteria added, finalize your policy group. It’s now set to automatically apply to future devices matching these newly created criteria, ensuring comprehensive coverage.


Creating Static (Network) Policy Groups

In the scope of network policy management, Elisity's Network (Static) Policy Groups provide precise asset control that's indispensable in various scenarios. This section delves into the significance of Static Policy Groups, offering an in-depth look at their importance, particularly in the context of Operational Technology (OT) environments and traditional networking methodologies. For those new to Elisity constructs, understanding the role and value of Static Policy Groups is key to refining your segmentation strategy.

The Stability Your Network Needs

Static Policy Groups stand out in environments where assets demand a steadfast classification methodology. They excel in situations where customers would prefer to use IP addresses and subnet ranges rather than dynamic asset classification, or in scenarios where dynamic asset classification is not possible.  These groups ensure that your assets remain consistently categorized by their networking address, aligning with the established segmentation strategies in certain environments.

Applied Wisdom: OT Environments

Operational Technology (OT) environments, often characterized by industrial control systems and critical infrastructure, present unique challenges that require equally unique solutions. Here's how Static Policy Groups fit into this picture:

  1. Securing Upstream Private Subnets: In scenarios where you need to secure upstream private subnets, such as data centers, Static Policy Groups offer an elegant solution. They enable you to establish precise policies that control access to these critical zones, ensuring the utmost security for your data center resources.

  2. Fortifying Access to Public Cloud Resources: As organizations increasingly migrate to the cloud, securing access to public cloud resources becomes paramount. Static Policy Groups provide a robust mechanism to define and enforce policies that safeguard your cloud infrastructure, protecting it from unauthorized access and potential threats.

  3. Protecting Specific Network Subnets: Your network might encompass diverse subnets like OT Zones, Guest Wireless, and more. Each of these subnets carries unique security requirements. Static Policy Groups allow you to tailor policies for each subnet, creating distinct access controls that enhance security without compromising operational efficiency.

To create a Static Policy Group, go to Policies on the left hand side, click Policy Groups in the top bar, and + Create Policy Group. Give your Policy Group a name, and choose "Static Assets" as the type. You can enter IP addresses or subnets one at a time to the list, or copy/paste multiple IPs/Subnets in a single comma separated line. Note that host IP addresses require a /32 subnet declaration. After submitting the subnets you will notice that a "Matched Assets" count is displayed to the right, denoting how many known assets will be matched on creation of the Static PG. 

When you have added all the necessary IP addresses, click Save.


NOTE: By default, Static Policy Groups have lower precedence than Dynamic Policy Groups and the most specific prefix match will always win when it comes to Static Policy Groups. However, selecting the Prioritize over Dynamic Policy Group assignment option changes this behavior and moves the Static Policy Group to the top of the list. Again, the most specific prefix match will always win when it comes to Static Policy Groups, even if they are prioritized over Dynamic Policy Groups. 

Policy Group Reordering Mode - Establishing Order of Precedence

In some cases, assets can match to multiple Policy Groups. You may have created a broad Policy Group that matches on Device Genre = IoT. If you then create other IoT Policy Groups that are narrower and more granular matching on Device Type, or any other match criteria, you may be questioning which Policy Group takes precedence. We have made this simple with our Policy Group Reordering Mode. 

Policy Group Reordering only applies to dynamic Policy Groups


Default Order of Precedence = Order of Policy Group Creation

When you begin creating Policy Groups, the order in which they were created is the order of precedence by default. This means if a classified asset can match multiple Policy Groups, it will match to whichever Policy Group was created first. The left hand column gives a numbered Policy Group order.



You can re-order this list by clicking REORDERING MODE in the top right of the Policy Group dashboard. You can then drag and drop using the (6 dot) handles on the left, or you can manually specify the order by selecting which Policy Groups you want to re-order and clicking the "Specify Order" button.



After clicking specify order, you can select a Policy Group and click the up or down arrow. You can also select the number field and type in a unique number to re-order the Policy Group.

Note that if you attempt to move a Policy Group to a different slot such as '3', you will have to re-order whatever Policy Group is located in slot 3.



After creating a new Policy Group or re-ordering, the matched assets category will show 'processing' on all affected Policy Groups while assets are re-assigned based on match criteria and Policy Group order.



Inserting a new Policy Group between existing ones

Normally, when creating a new Policy Group it get placed at the bottom of the list, meaning it has the lowest priority from a match logic perspective. This is good practice since initially, you may not want the Policy Group to take priority over all of your existing Policy Groups causing assets to potentially be re-classified. However, if you know exactly where in the list you want the new Policy Group to be placed, you can select the line in the list where you want the new Policy Group to be placed after creation. 

Hover over the line where you want to insert the new Policy Group and click the symbol. 


Deleting Policy Groups

You can delete Policy Groups in a couple of ways. 

Policy Groups can be deleted as a group by selecting the check boxes to the left of each Policy Group, then clicking delete at the top of the list. You will be asked to confirm if you would like to delete.

Policy Groups can also be deleted individually from the editing view as seen below.

Was this article helpful?
0 out of 0 found this helpful