Policy Set Scores

Policy Set Scores

The Elisity Cloud Control Center (CCC) provides two scoring metrics that quantify and visualize policy enforcement effectiveness within each Policy Set: the Policy Score and the Device Score.

  • The Policy Score measures how completely policies are defined across all Policy Group pairs in the Policy Matrix. Each cell with an enforced policy counts as full coverage; each cell with a simulated policy counts as 10% coverage.
  • The Device Score evaluates the same matrix but weights each Policy Group pair by Security Level and the number of devices classified into each Policy Group, revealing whether the majority of actual assets benefit from enforcement.

Both scores differentiate between Enforced, Simulated, and External Control policies, exclude UnassignedPG and InternetPG groups, and are calculated per Policy Set. External Control policies are treated as enforced (full weight) in both score calculations.


Core Concepts

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, enabling alignment with the IEC 62443 framework. This labeling approach supports organizations in identifying and prioritizing critical assets, as required by industry standards.

While Security Levels can be applied across a wide range of verticals and industry standards, they align specifically with the requirements outlined in the IEC 62443 framework. IEC 62443 defines security levels based on the criticality and risk associated with specific assets or zones. In CCC, PG Security Levels offer a clear mapping to this framework:

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

Assigning PG Security Levels

In the Edit Policy Group window, the Security Level can be found at the top, above the Policy Group Name field. Select the drop-down menu to assign the appropriate Security Level based on your organization's assessment. After selecting the appropriate Security Level, click Save Changes.

Policy Group Security Levels can also be viewed and assigned in the Policy Group Table view. If a Policy Group uses a Policy Group Template with a higher Security Level assigned, this SL takes precedence. This is indicated by an information icon with the Effective Security Level where applicable. See the article on Policy Group Templates for details.


Policy Score

The Policy Score measures straightforward policy coverage across the Policy Matrix. It answers the question: what percentage of the matrix has policies defined? Security Levels and device counts do not affect the Policy Score.

How the Policy Score Is Calculated

1. Determine Total Possible Pairs

Count every eligible source–destination Policy Group pair in the matrix. Each pair represents one cell. Every cell has equal weight.

2. Score Each Cell

  • Enforced policy: 1.0 point (full coverage)
  • External Control policy: 1.0 point (treated as enforced)
  • Simulated policy: 0.1 points (10% coverage)
  • No policy: 0 points

3. Calculate the Score

Policy Score = (Sum of Cell Points / Total Eligible Cells) × 100

If every cell has an enforced policy, the Policy Score is 100. If every cell has a simulated policy, the Policy Score is 10. If half the cells have enforced policies and the rest have no policy, the Policy Score is 50.


Device Score

The Device Score measures policy enforcement coverage weighted by the number of devices affected. While the Policy Score treats every matrix cell equally, the Device Score weights each cell by the Security Level and device count of the source and destination Policy Groups. This reveals whether the majority of actual assets benefit from enforcement — not just whether policies exist.

How the Device Score Is Calculated

For each source–destination Policy Group pair in the matrix, calculate the cell weight using the formula:

weight = (src_SL × src_devices + dst_SL × dst_devices) / 2

Where:

  • src_SL / dst_SL = Security Level of the source / destination Policy Group
  • src_devices / dst_devices = number of devices classified into the source / destination Policy Group

This weight is the cell's maximum possible contribution. The achieved contribution depends on policy state:

  • Enforced policy: full weight
  • External Control policy: full weight (treated as enforced)
  • Simulated policy: weight × 0.1 (10%)
  • No policy: 0

The Device Score is then:

Device Score = (Sum of Achieved Weights / Sum of All Possible Weights) × 100

As a result:

  • Policy Group pairs involving more devices carry greater weight
  • Policy Group pairs involving higher Security Levels carry greater weight
  • A missing policy between two large, high-criticality Policy Groups has a significant impact on the Device Score, even if the Policy Score appears healthy

Configurable Security Level Weights

The Security Level weights used in the Device Score are configurable, providing flexibility to tailor the scoring to your organization's priorities. All Policy Groups are included in the Device Score calculation, including those with no Security Level assigned (SL 0). The default weights are:

Security Level Description Default Weight
Level 0 No Security Level Assigned 1
Level 1 Low Impact 2
Level 2 Medium Impact 3
Level 3 High Impact 4
Level 4 Critical Impact 5

Administrators can configure weights using the scoring API endpoints:

  • GET /api/policy/v1/enforcement-score/settings — Retrieve current weight configuration
  • PUT /api/policy/v1/enforcement-score/settings — Update weight values
  • GET /api/policy/v1/enforcement-score/{policySetId} — Retrieve scores with calculation details for a Policy Set

NOTE: Weight configurations apply globally across all Policy Sets. Changes immediately recalculate the Device Score for every Policy Set. The Policy Score is not affected by weight changes.


Calculation Examples

The following examples demonstrate both scores calculated for a Policy Set containing two Policy Groups:

Policy Group Security Level (SL) Device Count
PG-1 1 (Low Impact) 1
PG-2 2 (Medium Impact) 3

The Policy Matrix contains four possible source–destination pairs. Three have policies configured:

  • PG-1 → PG-1: Enforced policy
  • PG-1 → PG-2: Enforced policy
  • PG-2 → PG-2: Simulated policy
  • PG-2 → PG-1: No policy (gap)

Policy Score

Every cell is weighted equally. Score each based on policy state:

PG-1 → PG-1: 1.0 (enforced) PG-1 → PG-2: 1.0 (enforced) PG-2 → PG-2: 0.1 (simulated, 10%) PG-2 → PG-1: 0.0 (no policy) ─── Points = 2.1 out of 4.0 possible

Policy Score = (2.1 / 4.0) × 100 = 52.5

Device Score

Each cell is weighted by (src_SL_weight × src_devices + dst_SL_weight × dst_devices) / 2. With the new default weights (SL 1 = weight 2, SL 2 = weight 3), the full matrix at maximum weight:

PG-1 → PG-1: (2×1 + 2×1) / 2 = 2.0 PG-1 → PG-2: (2×1 + 3×3) / 2 = 5.5 PG-2 → PG-1: (3×3 + 2×1) / 2 = 5.5 PG-2 → PG-2: (3×3 + 3×3) / 2 = 9.0 Total = 22.0

Then the achieved points based on policy state:

PG-1 → PG-1: 2.0 (enforced, full weight) PG-1 → PG-2: 5.5 (enforced, full weight) PG-2 → PG-2: 0.9 (simulated: 9.0 × 0.1) PG-2 → PG-1: 0.0 (no policy) ─── Points = 8.4 out of 22.0 possible

Device Score = (8.4 / 22.0) × 100 = 38.2

Why the Scores Differ

The Policy Score (52.5) is higher because it sees two out of four cells fully covered and one simulated — decent coverage by cell count. The Device Score (38.2) is lower because PG-2 pairs carry much more weight due to PG-2's higher device count and Security Level weight. The missing PG-2 → PG-1 policy and the simulated PG-2 → PG-2 policy drag the Device Score down significantly.

The divergence grows as device populations become more uneven. If PG-2 contained 300 devices instead of 3, the missing PG-2 → PG-1 policy would barely affect the Policy Score (still one empty cell out of four) but would dramatically lower the Device Score because it represents a gap covering hundreds of devices.

NOTE: When a Policy Set has no devices assigned to its Policy Groups, the Device Score calculation falls back to using Security Level weights only.


Comparing the Scores

Attribute Policy Score Device Score
Description Cells that have an action applied Weighted score to account for device quantity
Weight Formula Each cell = 1.0 (enforced) or 0.1 (simulated). All cells weighted equally. (src_SL × src_devices + dst_SL × dst_devices) / 2
Security Level Not a factor Higher Security Levels increase cell weight
Device Count Not a factor More devices increase cell weight
Best Used For Assessing overall matrix completion and policy coverage breadth Identifying gaps where high-population or high-criticality Policy Groups lack enforcement
Location Policy Matrix header bar and Policy Set list view Policy Matrix header bar

Score Ranges and Color Coding

Both scores use the same 0–100 scale, categorized into four ranges with corresponding color codes:

Range Color Interpretation
0–10 Red Poor policy coverage; critical improvement needed.
11–50 Orange Moderate policy coverage; requires attention.
51–75 Yellow Adequate coverage; opportunities for improvement.
76–100 Green High policy coverage; robust policy enforcement.

Common Score Patterns

  • Policy Score is high, Device Score is low: Policies exist across the matrix, but the Policy Groups with the most devices lack sufficient enforcement. Prioritize policy creation or transition from simulation to enforcement for high-population Policy Groups.
  • Policy Score is low, Device Score is high: The Policy Groups containing the most devices have good enforcement, but smaller Policy Groups lack coverage. Review coverage for critical, low-device-count Policy Groups to address this gap.
  • Both scores are similar: Enforcement coverage is distributed proportionally across device populations. The policy posture is consistent regardless of Policy Group size.
  • Both scores are low: Significant enforcement gaps exist across the Policy Set. Prioritize enforcement for high-population, high-Security-Level Policy Groups to improve both scores simultaneously.

Use Cases

1. Visibility and Assessment

The Policy Score provides an at-a-glance view of matrix completion, while the Device Score reveals whether enforcement coverage reaches the majority of actual devices. Together, they enable security teams to identify gaps and make proactive adjustments.

2. Prioritization of Resources

Compare the two scores to determine where to focus effort. A healthy Policy Score with a low Device Score indicates that high-population Policy Groups need enforcement attention. Use both scores to prioritize the transition of policies from simulation to enforcement.

3. Compliance and Audit Readiness

Enabling alignment with frameworks like IEC 62443 requires structured segmentation and consistent policy enforcement. The scores simplify compliance tracking by visually representing coverage across critical assets, and auditors can quickly assess whether network segmentation meets benchmarks.

4. Continuous Improvement

By factoring simulated policies into both scores at 10% weight, the system supports iterative policy development. Organizations can test policies in simulation mode before full enforcement, track score improvements over time, and refine segmentation strategies.

5. Risk Communication

The scores provide a quantitative, color-coded representation of security posture that can be communicated to non-technical stakeholders, supporting budget justification and executive visibility into network security status.

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