Impact Score reference

This reference provides details on how the Impact scores are calculated.

1E Patch Insights DEXPacks reference

Reference information for Patch Insights feature-related DEXPacks. These DEXPacks are required to support various features of Patch Insights.

Patch Insights DEXPacks reference — Classic DEXPack used to create the 1E Patch Insights instruction set in 1E, required by the following Patch Insights features:

Impact Score reference

The Impact Score

How Patch Insights calculates the Impact score. To compare patch deployments, a metric score needs to be defined that allows users to quickly distinguish the priority and impact of patch deployments on their environments.

As vulnerabilities also define a standards based scoring mechanism, similar concepts can be extended to construct a scoring algorithm for patches.

Scoring

By borrowing concepts from CVSS scoring construct we can define:

Base score of a patch that includes patch specific properties
Temporal score of a patch deployment which would include removing of unknown factors
Environmental score of a patch deployment based on the applicability of patches and impact of unpatched devices based on device criticality

Final score can then be defined as:

Note that we have chosen scores that multiply out where base score is diminished by both temporal and environmental scores. It is therefore assumed that:

Base score is in range of 0 to 100
Temporal score is in range of 0 to 1
Environmental score in range of 0 to 1

Base score

Base score for patches are based on:

Patch classification
Patch publish date
OS install date

Where the base score is defined as:

Patch criticality

Patch criticality can be based on classification of patches:

Patch classification	Patch criticality value	Notes
Security Updates	1.0	Security updates also define severity value however we are unable to reliably capture patch severity and therefore severity is not included in the scoring. It is also important to note that most recent cumulative security update patches take the highest severity of any of it's patches within the cumulative update and therefore most severities are "Critical" and therefore we are assuming that severity will have little impact on the base score.
Definition Updates	0.8	Definition updates are the second most critical type of updates and are therefore given a higher criticality over the other types of patches.
Other patch types: Applications Critical Updates Drivers Feature Packs Service Packs Tools Update Rollups Updates	0.2	Other types of patches are not security based including "Critical updates" which do not impact security. The overall score for these patches are significantly lower in order to highlight security critical patches first.

Patch classification

Patch criticality value

Notes

Security Updates

1.0

Security updates also define severity value however we are unable to reliably capture patch severity and therefore severity is not included in the scoring. It is also important to note that most recent cumulative security update patches take the highest severity of any of it's patches within the cumulative update and therefore most severities are "Critical" and therefore we are assuming that severity will have little impact on the base score.

Definition Updates

0.8

Definition updates are the second most critical type of updates and are therefore given a higher criticality over the other types of patches.

Other patch types:

Applications
Critical Updates
Drivers
Feature Packs
Service Packs
Tools
Update Rollups
Updates

0.2

Other types of patches are not security based including "Critical updates" which do not impact security. The overall score for these patches are significantly lower in order to highlight security critical patches first.

Priority

Priority of a patch deployment is defined as follows:

Where:

Now is the today in days
Day published is when the patch was published. As this data is not available on the end point, the publish date will have to be approximated with a date when the patch was first seen by Patch Inventory.
Day OS installed is when the OS of a device was installed. This makes sure to truncate older publish days as such device has not been unpatched before the OS was installed.

Days to deploy

Each classification type has a pre defined (configurable) number of days allowed to deploy a type of a patch.

Patch classification	Days to deploy	Notes
Security updates	7	If there is no distinction between SLA for different types of updates then setting this value to 30 would remove the priority for security updates.
Definition updates	30	This value is left as 30, however if higher priority is required for definition updates the number can be decreased.
Other	30

Where priority is defined as:

Logarithm is used to flatten out long running unpatched updates as the longer the patch is unpatched the less of a relevance it has in the environment, however it's score is still relatively high.

Temporal score

In order to reduce the unknown factors in the environment the patching system must:

Be operational
Be in sync and up to date

Assuming we can measure scanning cycles then the higher percentage of the estate scanned the less unknown and risk for a patch deployment. Similarly if the patching system is not in good health the risk to a patching process is higher.

A proposed values can be:

% scanned estate	Score
< 25%	1.0
25% - 75%	0.9
> 75%	0.8
0%	1.0

Similarly with a patch system health:

Patch system health	Score	Notes
Not running	1.0	Patching agents are not installed, configured or running.
Offline	0.9	Device is offline for a long periods of time e.g. 7 days+
Operational	0.8
Undefined	1.0

Further analysis would be required to incorporate these scores and adjust the scoring accordingly.

At the moment these values are not being measured and therefore the temporal score is:

Environmental score

The impact of the environment on the score is based on:

Device patch status
Impact

Where the environmental score is defined as:

Device criticality

Assuming criticality is normalised into finite states, the following values can be used:

Device criticality	Value	Notes
Critical	1.0	If at least one device of Critical criticality is applicable for patching then the value for "Critical" is used.
High	0.9	If at least one device of High criticality is applicable for patching and no "Critical" devices are affected then the value for "High" is used.
Medium	0.8	Similarly for "Medium"
Low	0.5	Similarly for "Low"
Non-critical	0.2	Similarly for "Non-critical"
Undefined	0.8	Where criticality is not defined we are assuming "Medium" criticality.

Device patch status

Device patch status	Value	Notes
Failed	1.0	If at least one of the devices for a particular patch has failed this metric is flagged as "Failed".
Requires patching	0.8	If at least one of the devices for a particular patch is unpatched and there are no failed patches, this metric is flagged as "Requires patching".
Requires rebooting	0.5	If at least one of the devices for a particular patch is pending a reboot and there are no failed nor unpatched patches, this metric is flagged as "Requires rebooting".
Fully patched	0.0	The score for a fully patched environment for a particular patch assumes the overall score to be zero.

Impact

Where the impact is defined as:

Where:

Device count is a total number of devices in the environment
Applicability is a count of patches that are applicable and not yet installed e.g. Failed, Missing and Pending reboot combined.

Note that applicability is flattened out against the total number of devices to include high impact patches with a small footprint, but still highlighting a high footprint patches in the environment.