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. This 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. 
• 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 

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.

 

When creating both Dynamic and Static Policy Groups, there are several universal configurations to consider, covered in this article. Of course, you need to give your Policy Group a name and description, but additional configurations include:

Security Level
Policy Group Label
Default Security Profile and Default Final Action
Audit Comment
Auto-Lock Devices
Policy Group Templates

Notice in the two PG creation windows below the shared configurations between Dynamic and Static PGs (highlighted in blue).

Continue reading to learn about these shared configurations, or skip ahead to learn about adding Dynamic Policy Group Match Criteria and Static Policy Group Match Criteria.

Default Security Profile Inheritance

Policy Groups allow administrators to define a Default Security Profile and Final Policy Action, ensuring that new Policy Groups automatically inherit these settings when added to the Policy Matrix. This streamlines policy management and helps maintain a consistent security posture by reducing the risk of unintended traffic permissions.

Once configured, these defaults apply only to newly created Policy Groups and do not retroactively modify existing groups or policies. Updating a Policy Group does not trigger changes to the Policy Matrix—only new groups added after the configuration is set will inherit the default profile and action.

Configuring Default Security Profile and Final Policy Action

To configure a default Security Profile for a Policy Group:

1. 1. Navigate to the Policy Groups section in the Cloud Control Center.
   2. Select an existing Policy Group or create a new one.
   3. Choose a Default Security Profile from the available options. The options include the system-defined "Deny All" and "Allow All" Security Profiles, as well as any custom Security Profiles previously created by administrators.
   4. Select a Final Policy Action - either Allow All or Deny All. This is how all remaining traffic is handled beyond what is defined in the Custom Security Profile.
   5. Save the changes.

Once set, any new Policy Group added to the Policy Matrix that interacts with this group will automatically apply the defined security profile and action. 

Step-by-Step 

First, add a Default Security Profile and Default Final Action to a new or existing Policy Group.

You can see that no policy is deployed for any existing intersections in the Matrix, as this configuration is only applicable for any new Policy Groups added after configuration.

Next, we will add another Policy Group to this Matrix. We will see that the Default Security Profile from the "Default-Deny-SP-Example" PG is applied to the newly created PG.

Example Use Case: An organization managing IoT devices wants to ensure that all IoT traffic is denied by default. By setting the "Deny All" security profile as the default for the IoT Devices Policy Group, any new Policy Group added to the Policy Matrix that interacts with IoT Devices will automatically apply this restriction. This prevents unauthorized access and maintains network segmentation without requiring manual configuration for each new Policy Group.

Best Practices

• Use Default Security Profiles in environments where segmentation is critical, such as OT, IoT, and Healthcare networks.
• Regularly review Security Profiles to align with evolving security policies.
• Ensure only authorized users have Policy Activation permissions to prevent unauthorized changes.

Audit Comments for Policy Groups

Audit comments in Elisity Cloud Control Center provide a structured way to capture the intent behind changes to Policy Groups. Requiring comments when creating or updating Policy Groups ensures that each modification is documented, supporting compliance, accountability, and easier policy reviews. Read our article on Audit Comments to learn how to enable and use mandatory audit comments.

Dynamic Policy Group Match Criteria and Logic

Match Criteria can be added in a few ways:

• Using Policy Group Templates as the core Match Criteria layered with additional criteria. 
• by selecting existing values from the drop down menu
• by typing in values to filter existing match criteria or create new values (indicated by *New Item* - see the section below)
• by typing or pasting a comma separated list (ie. Fire Alarm Panel, IP Camera, Motion Detector, Security Equipment, Security System) - each of the items in the comma separated list will be selected from the dropdown list (if existing), or a NEW ITEM will be created for each value that does not exist. This only applies to Match Criteria which allows Administrators to create new match criteria.

Copy/Pasting Values: If pasting a list of comma separated values that you expect to match to existing values, it's important to note that these values are case-senstive. Pasting "alarm" will create a New Item rather than matching to the existing value "Alarm."

 

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.

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

 

Dynamic Policy Group Conditional Operators 

Select attributes in IdentityGraph have conditional operators available when selecting them as Match Criteria during Policy Group creation. The list below outlines the conditional operator available, and which attributes can leverage these operators.

Creating New Match Criteria in Dynamic Policy Groups

Direct Addition of New Criteria: When configuring a policy group, administrators can add new values to certain match criteria that allow proactive item creation. This includes Elisity Native: Model, Operating System, Subnet, Type, and VLAN. If a match criteria does not support the creation of new items, only existing values can be selected.

Ensuring Proactive Policy Coverage: By leveraging this feature, administrators can predefine match criteria for policy groups, ensuring that as new devices and attributes are discovered, they are automatically categorized under the appropriate policies. This eliminates the need for frequent manual updates and helps maintain consistent security enforcement as the network evolves.

How to Use This Feature

1. Navigate to Policy Group Creation: Begin by creating a new policy group.
2. Input New Match Criteria:
   • For match criteria that support new item creation (Elisity Native: Model, Operating System, Subnet, Type, VLAN), administrators can enter new values manually or paste a comma-separated list.
   • Each value in the list will either match an existing entry or be added as a New Item if it does not already exist.
   • Since values are case-sensitive, ensure accuracy when entering them to avoid unintended new item creation.
3. Save and Apply the Policy Group: Once new criteria are added, finalize the policy group. Any future devices that match these values will be automatically assigned, ensuring continuous and automated policy enforcement.

This method streamlines policy management, allowing for a proactive approach to Policy Group creation without the need for constant reactive manual updates.

 

Creating Static (Network) Policy Groups

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. 

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

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. 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.

Note: You cannot delete a Policy Group until you have first deleted all policies associated with that Policy Group. 

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:

Bulk Action: 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. 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.

Bulk Action: 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. 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 Action: 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. 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

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 or to enable "auto locking" for an entire 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. Additionally, locked devices will remain in the Device List indefinitely, even if they are offline for an extended period.

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

1. 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.

In the next two sections, we will show the two methods for locking assets into Policy Groups. First, manually locking on a per-device basis, and then auto-locking at the Policy Group level. 

Manually Locking/Unlocking Assets in a Policy Group

As previously mentioned, devices can be locked to a Policy Group individually, for cases where Auto-Locking may not be the preferred behavior. Navigate to the Policies section in the Elisity Cloud Control Center and select the Policy Group you wish to configure. 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. 

1. 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.
   3. Assets can be locked using bulk actions by selecting the assets using the check boxes on the left side of the table, clicking the Bulk Actions dropdown, and clicking "Lock Assets."

 

Unlocking an asset follows the exact same workflow as locking an asset. This is as simple as clicking Unlock Asset in the Actions column, or selecting multiple locked assets and using the Bulk Actions menu.

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. 

 

Auto-Locking Devices into Policy Groups

Auto-Locking allows administrators to automatically lock all devices within a Policy Group (PG), ensuring they remain assigned to the intended security policies without requiring manual intervention. This feature is ideal for critical Policy Groups where match criteria are well-defined, minimizing the risk of misclassification. By automating the locking process, Auto-Lock enhances policy consistency, reduces administrative effort, and prevents unintended device reclassification. Auto-Lock Status is easily visible in the Policy Groups list, alongside the number of locked assets.

 

How to Enable Auto-Locking for a Policy Group

The easiest method of enabling or disabling Auto Locking in a Policy Group is to open the details view of the Policy Group and click the Lock/Unlock Policy Group icon to the left of the Policy Group name. You will be promped with a confirmation to proceed with locking the Policy Group.

 

You can also enable/disable auto-locking in the Policy Group Edit menu as seen below.

Navigate to Policies > Policy Groups in the Elisity Cloud Control Center.
Locate the Policy Group and select Edit Policy Group from the Actions menu.

 

Check the box for "Auto-Lock Devices into Policy Group" and click Save Changes. Note the message that existing and newly assigned devices will be automatically locked into this Policy Group upon saving changes.

Once enabled, existing devices within the Policy Group will be locked automatically. New devices assigned to the group will be immediately locked upon classification. You can see in the screenshot below the new Locked status, as well as the number of Locked Assets, which should now match the total number of assets in this Policy Group.

 

Behavior of Auto-Locked Devices

Devices in an Auto-Locked Policy Group cannot be manually unlocked unless Auto-Lock is first disabled.
The Auto-Lock Status column in the Policy Groups table indicates whether Auto-Lock is enabled or disabled. Disabling Auto-Lock does not automatically unlock devices—administrators must manually unlock assets if needed.

 

Unlocking Devices from an Auto-Locked Policy Group

If Auto-Lock is disabled, all assets will remain locked to the Policy Group and the PG Auto-Lock status is updated, and any new device that is classified into the PG after the setting is changed will not be locked. Of course, when the Auto-Lock is disabled administrators regain control to:

• Unlock individual devices.
• Unlock all assets within the Policy Group using Bulk Actions.
• View a confirmation modal before unlocking, showing potential reclassification details.

 

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.

In the Devices Page, the Lock Status column gives the same indication as to whether the device is locked in it's current Policy Group.

 

Summary of Benefits

1. 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.

 

Policy Group Security Levels

The Policy Group Security Levels (PG Security Levels) feature in Elisity Cloud Control Center (CCC) provides a structured way to label Policy Groups by their criticality, following the IEC 62443 standard. This labeling approach supports organizations, particularly in Operational Technology (OT) environments, in identifying and prioritizing critical assets for security, as required by industry standards.

 

Understanding IEC 62443 Alignment

IEC 62443 defines security levels that align with the criticality and risk associated with specific assets or zones. These levels guide organizations in applying appropriate security measures. In CCC, PG Security Levels provide a straightforward mapping to this standard:

• Level 1 (Low Impact): Minimal security requirements, appropriate for less critical assets where a breach would have low operational impact.
• Level 2 (Medium Impact): Moderate security needs, aimed at assets where disruptions are noticeable but manageable.
• Level 3 (High Impact): High security requirements for assets where a breach could significantly disrupt operations.
• Level 4 (Critical Impact): Highest security designation for the most critical assets, where security failures could have severe or catastrophic consequences.

This setup enables OT and IT administrators to structure Policy Groups that reflect the IEC 62443 requirements, aligning internal cybersecurity practices with established standards. With this visibility feature, administrators can see which Policy Groups are designated as critical, streamlining efforts to monitor and protect these assets.

 

Assigning PG Security Levels

Policy Group Security Levels are primarly used for calculating Policy Set Enforcement Scores - a powerful metric for determining policy coverage and overall security posture across various Policy Sets. However, there are some additional benefits to this tool as seen below.

This feature allows users to:

1. 1. Assess and Prioritize Assets: The SL label highlights each Policy Group's criticality, guiding organizations to prioritize security measures effectively.
   2. Support IEC 62443 Compliance: By labeling Policy Groups with IEC 62443-based SLs, organizations ensure their network segmentation efforts meet industry standards, aiding compliance and risk mitigation.
   3. Improve Security Planning and Resource Allocation: With clear visibility into asset criticality, security teams can allocate resources and apply policies that address the highest risk areas first, strengthening the overall security posture.

In the Edit Policy Group window, the Security Level can be found at the top, above the Policy Group Name field. You can select the drop down menu to assign the appropriate Security Level based on your organizations assessment. After clicking the appropriate Security Level, click Save Changes.