Skip to content

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

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",
  "schemaVersion": "1-0-1",
  "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

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",
  "schemaVersion": "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

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",
  "schemaVersion": "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

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",
  "schemaVersion": "1-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:

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