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. 

 

Policy Groups are the primary tool used in the Elisity platform to segment your network into smaller chunks by grouping assets into Policy endpoints. These segments can be as broad or as granular as needed by your organization, meaning you can split your network into microsegments using granular, specific identifying match criteria, or using broader match criteria such as "Device Genre = OT." You can further improve the manageability and granularity of these Policy Groups by site using Local Policy Groups. Below is an overview of the different types of Policy Groups and how they are leveraged to achieve microsegmentation at scale.

 

Types of Policy Groups

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. 

 

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.

 

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 Create 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: All AD Groups are available as match criteria regardless of the number of users in each group.

For a complete understanding of the types of attributes that can be leveraged as match criteria, we recommend reading our IdentityGraph™ article.

 

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

Overview

Elisity's Network (Static) Policy Groups offer precise asset control that is indispensable in various scenarios. This section explores the significance of Static Policy Groups, highlighting their importance, especially in Operational Technology (OT) environments and traditional networking methodologies. For those new to Elisity constructs, understanding the role and value of Static Policy Groups is crucial for refining your segmentation strategy.

Offering Stability in Sensitive Environments

Static Policy Groups excel in situations where IP addresses and subnet ranges are preferred for asset classification. They ensure that assets remain consistently categorized by their networking address, aligning with established segmentation strategies. This is particularly beneficial in environments where dynamic classification is not suitable or desired.

Applied Wisdom: OT Environments

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

Securing Upstream Private Subnets

In scenarios requiring the security of upstream private subnets, such as data centers, Static Policy Groups offer an elegant solution. They enable the establishment of precise policies that control access to these critical zones, ensuring maximum security for your data center resources.

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.

Protecting Specific Network Subnets

Your network might encompass diverse subnets like OT Zones, Guest Wireless, and more, each with 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.

 

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.

 

 

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. 

 

Custom Filters for the Policy Groups Page

Overview

Custom filters on the Policy Groups page allow administrators to streamline policy management by tailoring views to specific criteria, enhancing efficiency in navigating and managing large sets of policy data.

Creating Custom Filters

To create a custom filter, navigate to the "Policy Groups" section in the Cloud Control Center. Click on the filter icon to open the filter settings.

Select the column you want to filter by from the dropdown list, such as "Policy Sets," "Assets," "Order," "Name," "Policy Group Labels," "Type," "Locked Assets," "Group Tag Value," "Created On," "Created By," "Modified On," or "Modified By." Then, choose the appropriate operator (e.g., "contains," ">=") and enter the value for the filter. For instance, you might filter for policy sets containing "Incident Response" or assets greater than or equal to a specific number.

 

Once you have set your filter criteria, click "Save Filter" to apply and save it. Saved filters can be accessed under the "Saved Filters" tab for future use. You can manage these filters by editing or deleting them using the respective icons next to each filter name.

This process simplifies the task of locating and managing specific policy groups based on defined criteria.

 

Actions Menu in Policy Groups

In the Policy Groups section of the Elisity platform, users can access a set of actions by clicking the three vertical dots on the far right of each Policy Group entry. This action reveals a dropdown menu with several options:

1. View Policy Group: This option allows you to see the details of the selected Policy Group, including its associated policies, assets, and other configuration settings. It is useful for reviewing the current setup and ensuring that the Policy Group aligns with your security needs.

2. Edit Policy Group: Selecting this option lets you modify the details of the chosen Policy Group. You can update the name, adjust the labels, or reconfigure other parameters. This is essential for keeping your Policy Groups up to date with changes in your security posture or organizational structure.

3. Duplicate Policy Group: This feature allows you to create a copy of an existing Policy Group. When duplicating, the Create button will remain greyed out until the Policy Group name is changed, as the platform requires each Policy Group to have a unique name. This is particularly useful for quickly setting up new groups that share similar configurations with an existing one but need to be distinguished for different purposes.

4. Delete Policy Group: If a Policy Group is no longer needed, this option allows you to remove it. However, it's important to note that a Policy Group cannot be deleted until all associated policies are first deleted. This safeguard ensures that you do not inadvertently disrupt existing security rules by removing a Policy Group that is still in use.

Each of these options is designed to give you flexible control over your Policy Groups, making it easier to manage and adjust your security configurations as needed.

Bulk Actions for Policy Groups

Cloud Control Center provides the tools for managing policy groups efficiently through bulk actions. Utilizing these bulk actions allow administrators to make changes to multiple policy groups at once, streamlining the management process. Here are the key bulk actions available:

 

 

Specifying Order for Policy Groups

The "Specify Order" feature enables administrators to set the priority of policy groups, ensuring that the most important policies are evaluated first when devices are matched to policy groups. This is yet another method to specify the order for a number of PGs, in addition to reordering mode, that allows administrators the ability to focus in on just a number of PGs in large environments.

Steps to specify order:

1. Navigate to the Policy Groups section.
2. Select the desired policy groups using the checkboxes on the left side.
3. Click on the "Bulk Actions" dropdown and select "Specify Order."
4. Assign the order for the selected policy groups as needed.

 

Assigning Policy Group Labels

Assigning labels to policy groups helps in organizing and managing them efficiently. This bulk action allows you to apply labels to multiple policy groups simultaneously.

Steps to assign labels:

1. Navigate to the Policy Groups section.
2. Select the policy groups you want to label.
3. Click on the "Bulk Actions" dropdown and choose "Assign Policy Group Label(s)."
4. Select or create labels and apply them to the selected policy groups by clicking "Assign."

 

Bulk Deleting Policy Groups

The bulk delete feature allows administrators to remove multiple policy groups at once, making it easier to clean up and manage the policy group list.

Steps to delete policy groups:

1. Navigate to the Policy Groups section.
2. Select the policy groups you wish to delete.
3. Click on the "Bulk Actions" dropdown and select "Delete Policy Groups."
4. Confirm the deletion to remove the selected policy groups.

These bulk actions enhance the efficiency of policy group management, allowing administrators to implement and maintain policies more effectively across their network.

 

Asset Locking in Policy Groups

Overview

Elisity Cloud Control Center now offers an enhanced "Asset Locking" feature within Policy Groups. This feature allows administrators to lock specific assets to a policy group, ensuring strict governance over asset-policy associations and preventing unintended changes. The functionality is designed to enhance security and operational integrity by maintaining consistent policy enforcement for critical assets.

 

Significance of Asset Locking

Asset Locking is particularly valuable as it protects against various issues that can arise in network policy management. These include:

1. Prevention of Unintended Changes: Asset Locking ensures that changes in match criteria or priority within a Policy Group do not inadvertently remove a device from the group. This stability is key to maintaining consistent policy enforcement for critical assets.
2. Secure Policy Enforcement: By locking an asset to a Policy Group, you guarantee that the asset remains under the intended security policies, even if changes occur in the identity, location, or policy group match criteria for a device. 
3. Operational Integrity: Locking assets prevents accidental or unauthorized alterations, ensuring that devices critical to operations continue to adhere to predefined policies. This consistency helps in maintaining a secure and compliant network environment.

 

Adding Asset Locking to a Policy Group

1. Navigate to the Policies section in the Elisity Cloud Control Center.
2. Select the Policy Group you wish to configure.
3. In the Policy Group details page under the Assets tab, you will find an option for Asset Locking for each device. You can search for a device or filter devices to assist in selecting the correct assets.

 

Locking a Device

1. Click on the Lock Asset action in the Actions column.
2. The asset will be immediately locked into the current Policy Group. A confirmation message will appear indicating the asset has been successfully locked.

 

Unlocking a Device

1. Unlocking an asset is as simple as clicking Unlock Asset in the Actions column.
2. If any reclassification into another Policy Group will occur upon unlocking the asset from the current PG, a notification will appear with the reclassification details. Use this information to determine if this is desired and how it will impact the assets policies. 

 

Device Details Enhancement

The Device Details page now includes an indicator showing whether a device is locked to a Policy Group. This is displayed next to the name of the Policy Group to which it is locked.

 

Summary of Benefits

1. Operational Integrity: Ensures assets remain under the governance of intended policies, preserving operational consistency and compliance.
2. Streamlined Administration: A clear, intuitive interface for locking and unlocking assets saves time and reduces potential errors.
3. Enhanced Security: Prevents accidental or unauthorized changes to asset-policy group associations, bolstering overall security posture.

The Asset Locking feature provides precise control over policy applications, enhancing both security and efficiency in managing device policies within Elisity Cloud Control Center.

 

Global and Local Policy Groups

Local Policy Groups are a crucial enhancement in the Elisity microsegmentation solution, designed to provide granular control over network security policies within specific sites. Unlike Global Policy Groups, which apply broadly across the network, Local Policy Groups are confined to individual sites, ensuring that local security needs are prioritized and managed independently. This segregation allows administrators to implement site-specific dynamic policy groups that cannot be overridden by broader, more general policy groups. By including a static Site Label in the match criteria, Local Policy Groups offer a robust framework for precise and targeted security enforcement, significantly improving the overall flexibility and safety of policy management in complex network environments. Local Policy Groups must be enabled in advanced settings within Cloud Control Center before they can be used. The following section contains details on how to enable and leverage Local Policy Groups.

 

Global Policy Groups vs Local Policy Groups

Global Policy Groups:

• Include Priority Static PGs, Dynamic PGs, and Static PGs.
• Apply broadly across the entire network.
• Follow a fixed order of precedence: Priority Static → Dynamic → Static.

Local Policy Groups:

• Dedicated to Dynamic PGs and require a mandatory, non-editable Site Label.
• Apply specifically within designated sites.
• Have higher precedence over Global Policy Groups within their respective sites.

This distinction is only relevant if Local Policy Groups are enabled. Without enabling this setting, all assets fall into what we refer to as "Global Policy Groups" or simply "Policy Groups."

 

Enabling Local Policy Groups

Local Policy Groups allow administrators to create site-specific Policy Groups with higher precedence within a Site Label, providing a streamlined way to apply customized policies across large environments. These groups take precedence over Global Policy Groups within their designated sites, allowing for precise control at the local level.

 

To enable Local Policy Groups, follow these steps:

1. Navigate to the Settings Menu
   • On the left-hand side of the Cloud Control Center interface, click on the Settings option.
2. Access the System Settings
   • At the top menu bar, click on System to reveal a dropdown menu.
3. Open Advanced Settings
   • From the dropdown menu, select Advanced. This will bring up the advanced system settings page.
4. Locate the Local Policy Groups Section
   • Scroll down to find the Local Policy Groups section within the advanced settings.
5. Enable Local Policy Groups
   • Toggle the switch next to Enable Local Policy Groups to activate this feature.
6. Confirm Activation
   • Once activated, this feature allows you to create site-specific Policy Groups with higher precedence within their Site Label, ensuring that local needs and global standards are effectively aligned.
   • Note: To disable this feature, you must first delete all existing Local Policy Groups.

Important Note

When enabling Local Policy Groups, you will see the following message:

"Existing Policy Groups that include Site Labels will be automatically changed to Local Policy Groups and will be attached to an appropriate Site Group."

This means:

• Automatic Conversion: Any existing Policy Groups that already include Site Labels will be automatically converted into Local Policy Groups.
• Site Group Attachment: These converted Policy Groups will be attached to the appropriate Site Group based on their Site Labels.
• Impact on Policy Management: This ensures that the transition to using Local Policy Groups is seamless, with existing configurations being adapted to the new structure without the need for manual intervention.

Creating and Managing Local Policy Groups

 

Follow the virtual tour of creating and managing Local Policy Groups below

 

 

 

Role-Based Access Control (RBAC) for Local Policy Groups

Role-Based Access Control (RBAC) can be leveraged to manage RW or RO access to Local Policy Groups in Cloud Control Center and via API access. This effectively enables granular Identity Access Management for Cloud Control Center users to restrict their access to only relevant sites, minimizing the risks for those select users to make configuration changes that can potentially impact other sites. For more information, please see our Role Based Access Control (RBAC) article.