Prioritizing Patch Deployment

Here we describe an example decision model for a Deployer deciding the priority of deploying a patch for a vulnerability in their infrastructure.

Deployer Patch Deployment Priority

As noted in Enumerating Decisions, the root of a decision model's identity is the combination of the stakeholder and the decision being modeled. In this case, the stakeholder is the Deployer and the decision is the priority of deploying a patch.

Deployer Units of Work

Deployer Unit of Work

The unit of work for a Deployer is usually a single deployable patch or patch bundle such as a service pack.

Deployers are usually in the position of receiving remediations or mitigations from their Suppliers for products they have deployed. They must then decide whether to deploy the remediation or mitigation to a particular instance (or not). Whether they have the option of deploying only part of a remediation such as a fix bundle depends on whether the Supplier has engineered their release process to permit that degree of flexibility. For example, if service packs are fix bundles, the Supplier might choose to release individually deployable fixes as well.

The vulnerability management process for deployers has at its core the collation of data including

Relationship to asset management

The relationship between SSVC and asset management is discussed further in SSVC and Asset Management.

• an inventory of deployed instances of product versions
• a mapping of vulnerabilities to remediations or mitigations
• a mapping of remediations and/or mitigations to product versions

The first must be collected by the Deployer, while the latter two most often originate from the product Supplier. Managing this information is generally called asset management.

In turn, Deployers must resolve this information into specific actions in which a remediation or mitigation is slated for deployment to replace or modify a particular instance of the product. The Deployer model described below considers the mission and safety risks inherent to the category of systems to which those deployed instances belong. For this reason, we recommend that the pairing of remediation or mitigation to a product version instance constitutes the unit of work most appropriate for the Deployer.

Deployer Decision Outcomes

A deployer's decision centers on with what priority to deploy a given remediation or mitigation to their infrastructure. Similar to the Supplier case, we consider four categories of priority, as outlined in the table below. While we've used the same priority names, the meaning of the priority may have different implications for the deployer than for the supplier.

Patch Deployer Priority

Deployer Priority	Description
Defer	Do not act at present.
Scheduled	Act during regularly scheduled maintenance time.
Out-of-cycle	Act more quickly than usual to apply the mitigation or remediation out-of-cycle, during the next available opportunity, working overtime if necessary.
Immediate	Act immediately; focus all resources on applying the fix as quickly as possible, including, if necessary, pausing regular organization operations.

When remediation is available, usually the action is to apply it. When remediation is not yet available, the action space is more diverse, but it should involve mitigating the vulnerability (e.g., shutting down services or applying additional security controls) or accepting the risk of not mitigating the vulnerability.

Applying mitigations may change the value of decision points. A mitigation that successfully changes the value of a decision point may shift the priority of further action to a reduced state. If applying a mitigation reduces the priority to defer, the deployer may not need to apply a remediation if it later becomes available.

Mitigation Examples

• An effective firewall or IDS rule coupled with an adequate change control process for rules may change System Exposure from open to controlled. This could be enough to reduce the priority where no further action is necessary.
• In the area of Financial Safety Impact, a better insurance policy may be purchased, providing necessary fraud insurance.
• Physical Safety Impact may be reduced by testing the physical barriers designed to restrict a robot's ability to interact with humans.
• Mission Impact could be reduced by correcting the problems identified in a disaster recover test-run of the alternate business flow.

However, mitigation techniques will not always be adequate to address the risk posed by the vulnerability.

Examples of Inadequate Mitigation

• The implementation of a firewall or IDS rule to mitigate System Exposure from open to controlled is only valid until someone changes the rule.
• In the area of Financial impacts, the caps on the insurance may be too low to act as a mitigation.
• The Physical impact may be increased by incorrect installation of the physical barriers designed to restrict a robot’s ability to interact with humans.
• The Mission Impact could be increased when a disaster recovery test-run identifies problems with an alternate business flow.
• The mitigating action may not be permanent or work as designed.

As opposed to mitigation, applying a remediation finishes an SSVC analysis of a deployed system.

Remediation is not a final state

While specific vulnerabilities in specific systems can be remediated, the vulnerability cannot be 'disposed of' or eliminated from future consideration within an IT environment. Since software and systems are dynamic, a single vulnerability can be re-introduced after initial remediation through updates, software rollbacks, or other systemic actions that change the operating conditions within an environment. It is therefore important to continually monitor remediated environments for vulnerabilities reintroduced by either rollbacks or new deployments of outdated software.

Deployer Decision Points

The Deployer Patch Deployment Priority decision model uses the following decision points:

• Exploitation - A vulnerability with known exploitation is more likely to be given a higher priority.
• System Exposure - The more exposed a system is, the more likely it is to be given a higher priority.
• Utility - The more useful a vulnerability is to an attacker, the more likely it is to be given a higher priority.
• Human Impact - The more severe the human (safety, mission) impact of a vulnerability, the more likely it is to be given a higher priority.

More detail about each of these decision points is provided at the links above, here we provide a brief summary of each.

Exploitation v1.1.0

TextJSON

The present state of exploitation of the vulnerability.

Value	Definition
None	There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability.
Public PoC	One of the following is true: (1) Typical public PoC exists in sources such as Metasploit or websites like ExploitDB; or (2) the vulnerability has a well-known method of exploitation.
Active	Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting.

{
  "namespace": "ssvc",
  "version": "1.1.0",
  "key": "E",
  "name": "Exploitation",
  "description": "The present state of exploitation of the vulnerability.",
  "values": [
    {
      "key": "N",
      "name": "None",
      "description": "There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability."
    },
    {
      "key": "P",
      "name": "Public PoC",
      "description": "One of the following is true: (1) Typical public PoC exists in sources such as Metasploit or websites like ExploitDB; or (2) the vulnerability has a well-known method of exploitation."
    },
    {
      "key": "A",
      "name": "Active",
      "description": "Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting."
    }
  ]
}

System Exposure v1.0.1

TextJSON

The Accessible Attack Surface of the Affected System or Service

Value	Definition
Small	Local service or program; highly controlled network
Controlled	Networked service with some access restrictions or mitigations already in place (whether locally or on the network). A successful mitigation must reliably interrupt the adversary’s attack, which requires the attack is detectable both reliably and quickly enough to respond. Controlled covers the situation in which a vulnerability can be exploited through chaining it with other vulnerabilities. The assumption is that the number of steps in the attack path is relatively low; if the path is long enough that it is implausible for an adversary to reliably execute it, then exposure should be small.
Open	Internet or another widely accessible network where access cannot plausibly be restricted or controlled (e.g., DNS servers, web servers, VOIP servers, email servers)

{
  "namespace": "ssvc",
  "version": "1.0.1",
  "key": "EXP",
  "name": "System Exposure",
  "description": "The Accessible Attack Surface of the Affected System or Service",
  "values": [
    {
      "key": "S",
      "name": "Small",
      "description": "Local service or program; highly controlled network"
    },
    {
      "key": "C",
      "name": "Controlled",
      "description": "Networked service with some access restrictions or mitigations already in place (whether locally or on the network). A successful mitigation must reliably interrupt the adversary\u2019s attack, which requires the attack is detectable both reliably and quickly enough to respond. Controlled covers the situation in which a vulnerability can be exploited through chaining it with other vulnerabilities. The assumption is that the number of steps in the attack path is relatively low; if the path is long enough that it is implausible for an adversary to reliably execute it, then exposure should be small."
    },
    {
      "key": "O",
      "name": "Open",
      "description": "Internet or another widely accessible network where access cannot plausibly be restricted or controlled (e.g., DNS servers, web servers, VOIP servers, email servers)"
    }
  ]
}

Utility v1.0.1

TextJSON

The Usefulness of the Exploit to the Adversary

Value	Definition
Laborious	Automatable:No AND Value Density:Diffuse
Efficient	(Automatable:Yes AND Value Density:Diffuse) OR (Automatable:No AND Value Density:Concentrated)
Super Effective	Automatable:Yes AND Value Density:Concentrated

{
  "namespace": "ssvc",
  "version": "1.0.1",
  "key": "U",
  "name": "Utility",
  "description": "The Usefulness of the Exploit to the Adversary",
  "values": [
    {
      "key": "L",
      "name": "Laborious",
      "description": "Automatable:No AND Value Density:Diffuse"
    },
    {
      "key": "E",
      "name": "Efficient",
      "description": "(Automatable:Yes AND Value Density:Diffuse) OR (Automatable:No AND Value Density:Concentrated)"
    },
    {
      "key": "S",
      "name": "Super Effective",
      "description": "Automatable:Yes AND Value Density:Concentrated"
    }
  ]
}

Human Impact v2.0.1

TextJSON

Human Impact is a combination of Safety and Mission impacts.

Value	Definition
Low	Safety Impact:(Negligible) AND Mission Impact:(None OR Degraded OR Crippled)
Medium	(Safety Impact:Negligible AND Mission Impact:MEF Failure) OR (Safety Impact:Marginal AND Mission Impact:(None OR Degraded OR Crippled))
High	(Safety Impact:Critical AND Mission Impact:(None OR Degraded OR Crippled)) OR (Safety Impact:Marginal AND Mission Impact:MEF Failure)
Very High	Safety Impact:Catastrophic OR Mission Impact:Mission Failure

{
  "namespace": "ssvc",
  "version": "2.0.1",
  "key": "HI",
  "name": "Human Impact",
  "description": "Human Impact is a combination of Safety and Mission impacts.",
  "values": [
    {
      "key": "L",
      "name": "Low",
      "description": "Safety Impact:(Negligible) AND Mission Impact:(None OR Degraded OR Crippled)"
    },
    {
      "key": "M",
      "name": "Medium",
      "description": "(Safety Impact:Negligible AND Mission Impact:MEF Failure) OR (Safety Impact:Marginal AND Mission Impact:(None OR Degraded OR Crippled))"
    },
    {
      "key": "H",
      "name": "High",
      "description": "(Safety Impact:Critical AND Mission Impact:(None OR Degraded OR Crippled)) OR (Safety Impact:Marginal AND Mission Impact:MEF Failure)"
    },
    {
      "key": "VH",
      "name": "Very High",
      "description": "Safety Impact:Catastrophic OR Mission Impact:Mission Failure"
    }
  ]
}

In the Human Impact table above, MEF stands for Mission Essential Function.

Deployer Decision Model

Below we provide an example deployer prioritization policy that maps the decision points just listed to the outcomes described above.

Notes on the Deployer Decision Model Example Policy

In the example policy shown below:

• An active state of Exploitation will never result in a defer priority.
• A none state of Exploitation (no evidence of exploitation) will result in either defer or scheduled priority—unless the state of Human Impact is very high, resulting in an out-of-cycle priority.

Tree Notation

Rectangles are decision points, and triangles represent outcomes. The values for each decision point are different, as described above. Outcomes are priority decisions (defer, scheduled, out-of-cycle, immediate). Outcome triangles are color coded:

• Defer = gray with green outline
• Scheduled = yellow
• Out-of-Cycle = orange
• Immediate = red with black outline

Table of Values

row	Exploitation	Exposure	Automatable	Human Impact	Priority
1	none	small	no	low	defer
2	none	small	no	medium	defer
3	none	small	no	high	scheduled
4	none	small	no	very high	scheduled
5	none	small	yes	low	defer
6	none	small	yes	medium	scheduled
7	none	small	yes	high	scheduled
8	none	small	yes	very high	scheduled
9	none	controlled	no	low	defer
10	none	controlled	no	medium	scheduled
11	none	controlled	no	high	scheduled
12	none	controlled	no	very high	scheduled
13	none	controlled	yes	low	scheduled
14	none	controlled	yes	medium	scheduled
15	none	controlled	yes	high	scheduled
16	none	controlled	yes	very high	scheduled
17	none	open	no	low	defer
18	none	open	no	medium	scheduled
19	none	open	no	high	scheduled
20	none	open	no	very high	scheduled
21	none	open	yes	low	scheduled
22	none	open	yes	medium	scheduled
23	none	open	yes	high	scheduled
24	none	open	yes	very high	out-of-cycle
25	PoC	small	no	low	defer
26	PoC	small	no	medium	scheduled
27	PoC	small	no	high	scheduled
28	PoC	small	no	very high	scheduled
29	PoC	small	yes	low	scheduled
30	PoC	small	yes	medium	scheduled
31	PoC	small	yes	high	scheduled
32	PoC	small	yes	very high	scheduled
33	PoC	controlled	no	low	defer
34	PoC	controlled	no	medium	scheduled
35	PoC	controlled	no	high	scheduled
36	PoC	controlled	no	very high	scheduled
37	PoC	controlled	yes	low	scheduled
38	PoC	controlled	yes	medium	scheduled
39	PoC	controlled	yes	high	scheduled
40	PoC	controlled	yes	very high	out-of-cycle
41	PoC	open	no	low	scheduled
42	PoC	open	no	medium	scheduled
43	PoC	open	no	high	scheduled
44	PoC	open	no	very high	out-of-cycle
45	PoC	open	yes	low	scheduled
46	PoC	open	yes	medium	scheduled
47	PoC	open	yes	high	out-of-cycle
48	PoC	open	yes	very high	out-of-cycle
49	active	small	no	low	scheduled
50	active	small	no	medium	scheduled
51	active	small	no	high	out-of-cycle
52	active	small	no	very high	out-of-cycle
53	active	small	yes	low	scheduled
54	active	small	yes	medium	out-of-cycle
55	active	small	yes	high	out-of-cycle
56	active	small	yes	very high	out-of-cycle
57	active	controlled	no	low	scheduled
58	active	controlled	no	medium	scheduled
59	active	controlled	no	high	out-of-cycle
60	active	controlled	no	very high	out-of-cycle
61	active	controlled	yes	low	out-of-cycle
62	active	controlled	yes	medium	out-of-cycle
63	active	controlled	yes	high	out-of-cycle
64	active	controlled	yes	very high	out-of-cycle
65	active	open	no	low	scheduled
66	active	open	no	medium	out-of-cycle
67	active	open	no	high	out-of-cycle
68	active	open	no	very high	immediate
69	active	open	yes	low	out-of-cycle
70	active	open	yes	medium	out-of-cycle
71	active	open	yes	high	immediate
72	active	open	yes	very high	immediate