Coordinator Publication Decision
Coordinators have to make two decisions about publication of information about a vulnerability. The first is whether to coordinate the vulnerability, which we discuss in Coordination Triage. The second decision is whether to publish information about a vulnerability. While other stakeholders may also have to make a publication decision, here we focus on the coordinator's decision.
Coordinator Publication Decision
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 Coordinator and the decision is whether to publish an advisory about the vulnerability.
Policy Constraints and Publication Decisions
Other Stakeholders' Publication Decisions
Other stakeholders may also have to make a publication decision. For example, a supplier may have to decide whether to publish information about a vulnerability in their product. A deployer may have to decide whether to publish information about a vulnerability in their infrastructure. A vulnerability finder may have to decide whether to publish information about a vulnerability they have discovered. Each of these decisions is likely to be different from the coordinator's decision.
The decision to publish information about a vulnerability is a policy choice, and is likely to differ from organization to organization. Two points where CERT/CC policy clearly influences the publication decision are embargo periods and scope.
Publication and Embargo Periods
As a matter of policy, CERT/CC will support an embargo from the public of information about a vulnerability through its choice not to publish that information while a number of conditions hold:
- A negotiated embargo timer has not expired. The CERT/CC default embargo period is 45 days.
- Other exceptions have not been met, including active exploitation of the vulnerability in the wild or other public discussion of the vulnerability details.
Regardless, the decision described in this section assumes the embargo period is over, one way or another.
Triage Decisions and Publication
The second point is related to the Coordination Triage Decision and the status of the vulnerability. CERT/CC only expects to publish about vulnerabilities with a coordinate status. While an issue that is tracked or declined may be reevaluated at a later date and status changed to coordinate, unless that happens we would not publish about the vulnerability. Other organizations, such as NVD, would have different publication criteria and may want to include decision points or the decision itself from the Coordination Triage Decision in their publication decision.
Coordinator Publication Units of Work
Coordinator Publication Unit of Work
The unit of work for the coordinator publication decision a single publication. For CERT/CC, this corresponds to a CERT Vulnerability Note.
In the CERT/CC's vulnerability coordination practice, a single report leads to a single coordination case which leads to a single publication. Therefore the unit of work for the publication decision is often the same as the unit of work for the coordination triage decision.
That is sometimes not the case, however. For example, there could be multiple reports of multiple vulnerabilities and the coordinator might choose to publish a single advisory covering all of them if the vulnerabilities are variations on a central theme and have a common set of affected products.
Multiple Reports, Single Advisory
There are numerous examples of multiple reported vulnerabilities being consolidated into a single publication in the CERT/CC's history. A few recent cases include:
Another possibility is that a single report could lead to multiple advisories, for example if the product is a library that is used in multiple other products, and the coordinator chooses to publish separate advisories based on some other criteria.
Single Report, Multiple Advisories
Occasionally, a single report leads to multiple advisories. For example
- VU#854306 Multiple vulnerabilities in SNMPv1 request handling
- VU#107186 Multiple vulnerabilities in SNMPv1 trap handling
arrived as a single report and were published as separate vulnerability notes because they affected different aspects of the libraries in question. Although this example pre-dates SSVC by many years, it is illustrative of the situation where a single report leads to multiple advisories.
Coordinator Publication Decision Outcomes
For the CERT/CC, the publication decision is binary: publish or do not publish.
Coordinator Publish Priority
| Publish Priority | Description |
|---|---|
| Do not publish | Do not publish information about the vulnerability. |
| Publish | Publish information about the vulnerability. |
The Publication Decision is Time Sensitive
The publication decision is always a decision at a point in time. As discussed in Guidance on Communicating Results, a SSVC decision may change over time as the inputs to that decision change. A decision to publish cannot be revoked, since the publication is likely to be archived or at least remembered. However, a decision to not publish is a decision not to publish at the time the decision was made. It is not a decision never to publish in the future.
One benefit of encoding the decision process in SSVC is the analysts can all agree on what new information would change the decision and prioritize maintaining awarenss of just those decision points.
CERT/CC Publication Decision Outcomes Over Time
The CERT/CC has a long history of publishing information about vulnerabilities. In the past, the CERT/CC had multiple publication vehicles, including Vulnerability Notes, CERT Advisories, and Current Activity entries. Each of these had different publication criteria. Had we been using SSVC at the time, we might have modeled the publication decision differently for each of these vehicles. Or we might have modeled the decision as a single decision with multiple outcomes, each of which would lead to a different publication vehicle. This is an example of how SSVC can be customized to the needs of the organization using it.
Coordinator Publication Decision Points
The publication decision reuses the Exploitation decision point and adds two new ones (Supplier Involvement and Public Value Added).
- Supplier Involvement - If the supplier is involved and likely to publish already, there is less need for the CERT/CC to publish.
- Exploitation - If the vulnerability is being actively exploited, the CERT/CC is more likely to publish.
- Public Value Added - If there is already significant public discussion of the vulnerability, there might not be much for the CERT/CC to add, making us less likely to publish.
More detail about each of these decision points is provided at the links above, here we provide a brief summary of each.
Supplier Involvement v1.0.0
What is the state of the supplier’s work on addressing the vulnerability?
| Value | Definition |
|---|---|
| Fix Ready | The supplier has provided a patch or fix. |
| Cooperative | The supplier is actively generating a patch or fix; they may or may not have provided a mitigation or work-around in the mean time. |
| Uncooperative/Unresponsive | The supplier has not responded, declined to generate a remediation, or no longer exists. |
{
"namespace": "ssvc",
"version": "1.0.0",
"key": "SI",
"name": "Supplier Involvement",
"description": "What is the state of the supplier\u2019s work on addressing the vulnerability?",
"values": [
{
"key": "FR",
"name": "Fix Ready",
"description": "The supplier has provided a patch or fix."
},
{
"key": "C",
"name": "Cooperative",
"description": "The supplier is actively generating a patch or fix; they may or may not have provided a mitigation or work-around in the mean time."
},
{
"key": "UU",
"name": "Uncooperative/Unresponsive",
"description": "The supplier has not responded, declined to generate a remediation, or no longer exists."
}
]
}
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",
"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."
}
]
}
Public Value Added v1.0.0
How much value would a publication from the coordinator benefit the broader community?
| Value | Definition |
|---|---|
| Limited | Minimal value added to the existing public information because existing information is already high quality and in multiple outlets. |
| Ampliative | Amplifies and/or augments the existing public information about the vulnerability, for example, adds additional detail, addresses or corrects errors in other public information, draws further attention to the vulnerability, etc. |
| Precedence | The publication would be the first publicly available, or be coincident with the first publicly available. |
{
"namespace": "ssvc",
"version": "1.0.0",
"key": "PVA",
"name": "Public Value Added",
"description": "How much value would a publication from the coordinator benefit the broader community?",
"values": [
{
"key": "L",
"name": "Limited",
"description": "Minimal value added to the existing public information because existing information is already high quality and in multiple outlets."
},
{
"key": "A",
"name": "Ampliative",
"description": "Amplifies and/or augments the existing public information about the vulnerability, for example, adds additional detail, addresses or corrects errors in other public information, draws further attention to the vulnerability, etc."
},
{
"key": "P",
"name": "Precedence",
"description": "The publication would be the first publicly available, or be coincident with the first publicly available."
}
]
}
Coordinator Publication Decision Model
An example coordinator publication decision model is shown below. The policy described by the model is based on CERT/CC publication decisions. Other organizations may have different publication criteria and may want to include other decision points in their publication decision model.
Table of Values
| row | Supplier involvement | Exploitation | Value added | Priority |
|---|---|---|---|---|
| 1 | fix ready | none | precedence | publish |
| 2 | fix ready | none | ampliative | don't publish |
| 3 | fix ready | none | limited | don't publish |
| 4 | fix ready | PoC | precedence | publish |
| 5 | fix ready | PoC | ampliative | don't publish |
| 6 | fix ready | PoC | limited | don't publish |
| 7 | fix ready | active | precedence | publish |
| 8 | fix ready | active | ampliative | publish |
| 9 | fix ready | active | limited | don't publish |
| 10 | cooperative | none | precedence | publish |
| 11 | cooperative | none | ampliative | don't publish |
| 12 | cooperative | none | limited | don't publish |
| 13 | cooperative | PoC | precedence | publish |
| 14 | cooperative | PoC | ampliative | don't publish |
| 15 | cooperative | PoC | limited | don't publish |
| 16 | cooperative | active | precedence | publish |
| 17 | cooperative | active | ampliative | publish |
| 18 | cooperative | active | limited | don't publish |
| 19 | uncoop/unresponsive | none | precedence | publish |
| 20 | uncoop/unresponsive | none | ampliative | don't publish |
| 21 | uncoop/unresponsive | none | limited | don't publish |
| 22 | uncoop/unresponsive | PoC | precedence | publish |
| 23 | uncoop/unresponsive | PoC | ampliative | publish |
| 24 | uncoop/unresponsive | PoC | limited | don't publish |
| 25 | uncoop/unresponsive | active | precedence | publish |
| 26 | uncoop/unresponsive | active | ampliative | publish |
| 27 | uncoop/unresponsive | active | limited | publish |