CVD Roles and Their Influence

Vendors

System Owners

Security Researchers

Coordinators

Governments

This page is not normative

This page is not considered a core part of the Vultron Protocol as proposed in the main documentation. Although within the page we might provide guidance in terms of SHOULD, MUST, etc., the content here is not normative.

CVD stakeholders include vendors, system owners, the security research community, coordinators, and governments. Of primary interest here are the main roles defined in the CERT Guide to CVD: finder/reporter, vendor, deployer, and coordinator. Each of the roles corresponds to a set of transitions they can cause. For example, a coordinator can notify the vendor (V) but not create the fix (F), whereas a vendor can create the fix but not notify itself (although a vendor with an in-house vulnerability discovery capability might also play the role of a finder/reporter as well). A mapping of CVD Roles to the transitions they can control can be found in the table below. Roles can be combined (vendor + deployer, finder + coordinator, etc.). We also included a role of adversary just to cover the A transition.

Different stakeholders might want different things, although most benevolent parties will likely seek some subset of \(\mathbb{D}\). Because \(\mathcal{H}\) is the same for all stakeholders, the expected frequencies shown in Event Order Frequency will be consistent across any such variations in desiderata.

A discussion of some stakeholder preferences is given below, while a summary can be found in the following table.

Stakeholder Preferences for Event Ordering

The table below summarizes the expected preferences of different stakeholders for the order of events in a CVD process. We notate these variations of the set of desiderata \(\mathbb{D}\) with subscripts: \(\mathbb{D}_v\) for vendors, \(\mathbb{D}_s\) for system owners, \(\mathbb{D}_c\) for coordinators, and \(\mathbb{D}_g\) for governments. (Government stakeholders are omitted from the table because they are expected to have similar preferences to coordinators.)

Desideratum \(d \in \mathbb{D}\)	Vendor (\(\mathbb{D}_v\))	System Owner (\(\mathbb{D}_s\))	Coordinator (\(\mathbb{D}_c\))
V \(\prec\) P	yes	maybe⁴	yes
V \(\prec\) X	yes	maybe⁴	yes
V \(\prec\) A	yes	maybe⁴	yes
F \(\prec\) P	yes	maybe⁵	yes
F \(\prec\) X	yes	yes	yes
F \(\prec\) A	yes	yes	yes
D \(\prec\) P	maybe¹	maybe¹	yes
D \(\prec\) X	maybe²	maybe⁵	yes
D \(\prec\) A	maybe²	yes	yes
P \(\prec\) X	yes	yes	yes
P \(\prec\) A	yes	yes	yes
X \(\prec\) A	maybe³	maybe³	maybe³

Table Notes

When vendors control deployment, both vendors and system owners likely prefer D \(\prec\) P. When system owners control deployment, D \(\prec\) P is impossible.
Vendors should care about orderings involving D when they control deployment, but might be less concerned if deployment responsibility is left to system owners.
Exploit publication can be controversial. To some, it enables defenders to test deployed systems for vulnerabilities or detect attempted exploitation. To others, it provides unnecessary adversary advantage.
System owners may only be concerned with orderings involving V insofar as it is a prerequisite for F.
System owners might be indifferent to F \(\prec\) P and D \(\prec\) X depending on their risk tolerance.

In Desirable Histories, we defined a preference ordering between every possible pairing of events, therefore \(\mathbb{D}\) is the largest possible set of desiderata. We thus expect the desiderata of benevolent stakeholders to be a subset of \(\mathbb{D}\) in most cases. That said, we note a few exceptions in the text that follows.

As shown in the table above, we expect vendors' desiderata \(\mathbb{D}_v\) to be a subset of \(\mathbb{D}\). It seems reasonable to expect vendors to prefer that a fix is ready before either exploit publication or attacks (F \(\prec\) X and F \(\prec\) A, respectively). Fix availability implies vendor awareness (V \(\prec\) F), so we would expect vendors' desiderata to include those orderings as well (V \(\prec\) X and V \(\prec\) A, respectively).

Vendors typically want to have a fix ready before the public finds out about a vulnerability (F \(\prec\) P). We surmise that a vendor's preference for this item could be driven by at least two factors: the vendor's tolerance for potentially increased support costs (e.g., fielding customer support calls while the fix is being prepared), and the perception that public awareness without an available fix leads to a higher risk of attacks. As above, vendor preference for F \(\prec\) P implies a preference for V \(\prec\) P as well.

When a vendor has control over fix deployment (D), it will likely prefer that deployment precede public awareness, exploit publication, and attacks (D \(\prec\) P, D \(\prec\) X, and D \(\prec\) A, respectively).

Some vendors might prefer public awareness before deployment anyway

On the other hand, some vendors might actually prefer public awareness before fix deployment even if they have the ability to deploy fixes, for example in support of transparency or trust building. In that case, \(\mathbb{D_V} \not\subseteq \mathbb{D}\), and some portions of the analysis presented here may not apply.

However, when fix deployment depends on system owners to take action, the feasibility of D \(\prec\) P is limited.

Silent Patches

"Silent patches" can obviously occur when vendors fix a vulnerability but do not make that fact known. In principle, silent patches could achieve \(\mathbf{D} \prec \mathbf{P}\) even in traditional COTS or OSS distribution models. However, in practice silent patches result in poor deployment rates precisely because they lack an explicit imperative to deploy the fix.

Regardless of the vendor's ability to deploy fixes or influence their deployment, it would not be unreasonable for them to prefer that public awareness precedes both public exploits and attacks (P \(\prec\) X and P \(\prec\) A, respectively).

Ensuring the ease of patch deployment by system owners remains a likely concern for vendors. Conscientious vendors might still prefer D \(\prec\) X and D \(\prec\) A even if they have no direct control over those factors. However, vendors may be indifferent to X \(\prec\) A.

Related ISO/IEC Standards

The ISO/IEC 30111 and 29147 standards provide guidance to vendors on how to handle vulnerability reports and coordinate with security researchers. These standards are intended to improve the efficiency and effectiveness of the CVD process by providing a common framework for vendors and security researchers to work together. The standards do not explicitly address the ordering of events, but they do provide guidance on how to improve CVD outcomes by encouraging vendors to be responsive to vulnerability reports and security researchers to be cooperative with vendors.

See also our detailed crosswalk between the ISO/IEC standards and the Vultron CVD model.

Although our model only addresses event ordering, not timing, a few comments about timing of events are relevant since they reflect the underlying state transition process from which \(\mathcal{H}\) arises. Vendors have significant influence over the speed of V to F based on their vulnerability handling, remediation, and development processes. They can also influence how early V happens based on promoting a cooperative atmosphere with the security researcher community. Vendor architecture and business decisions affect the speed of F to D. Cloud-based services and automated patch delivery can shorten the lag between F and D. Vendors that leave deployment contingent on system owner action can be expected to have longer lags, making it harder to achieve the D \(\prec\) P, D \(\prec\) X, and D \(\prec\) A objectives, respectively.

System owners ultimately determine the lag from F to D based on their processes for system inventory, scanning, prioritization, patch testing, and deployment---in other words, their VM practices. In cases where the vendor and system owner are distinct entities, system owners should optimize to minimize the lag between F and D in order to improve the chances of meeting the D \(\prec\) X and D \(\prec\) A objectives, respectively. Enabling automatic updates for security patches is one way to improve F to D performance, although not all system owners find the resulting risk of operational impact to be acceptable to their change management process.

System owners might select a different desiderata subset than vendors \(\mathbb{D}_s \subseteq \mathbb{D}\), \(\mathbb{D}_s \neq \mathbb{D}_v\). In general, system owners are primarily concerned with the F and D events relative to X and A. Therefore, we expect system owners to be concerned about F \(\prec\) X, F \(\prec\) A, D \(\prec\) X, and D \(\prec\) A. As discussed above, D \(\prec\) P is only possible when the vendor controls D. Depending on the system owner's risk tolerance, F \(\prec\) P and D \(\prec\) X may or may not be preferred. Some system owners may find X \(\prec\) A useful for testing their infrastructure, others might prefer that no public exploits be available.

The "friendly" offensive security community (i.e., those who research vulnerabilities, report them to vendors, and sometimes release proof-of-concept exploits for system security evaluation purposes) can do their part to ensure that vendors are aware of vulnerabilities as early as possible prior to public disclosure

Early Vendor Notification Improves Outcomes

Because vendors can only develop fixes for vulnerabilities they know about, we expect that security researchers would prefer that vendors are aware of vulnerabilities before the public (V \(\prec\) P), and especially before exploits are publicly available (V \(\prec\) X) or attacks are observed (V \(\prec\) A).

\[vfdpxa \xrightarrow{\mathbf{V}} Vfdpxa \implies \mathbf{V} \prec \mathbf{P} \textrm{, } \mathbf{V} \prec \mathbf{X} \textrm{ and } \mathbf{V} \prec \mathbf{A}\]

Also note that many of the other desiderata are impossible to achieve without V. For example, F \(\prec\) P is impossible without V \(\prec\) P because the vendor cannot create a fix for a vulnerability it does not know about. The same applies to F \(\prec\) X and F \(\prec\) A. Likewise, D \(\prec\) P, X, or A is similarly impossible without both V \(\prec\) P, X, or A and F \(\prec\) P, X, or A for the reasons discussed above.

Security researchers can also delay the publication of exploits until after fixes exist, are public, and possibly even until most system owners have deployed the fix.

Exploit Delay Improves Outcomes

Delaying exploit publication until after fixes are available, the public is aware of the vulnerability, and system owners have deployed the fix can also improve outcomes. This is because it gives defenders the opportunity to respond before giving potential attackers a (hopefully unintended) advantage.

\[\begin{aligned} \mathbf{X}|q \in VFdpx &\implies \mathbf{F} \prec \mathbf{X} \\ \mathbf{X}|q \in VFdPx &\implies \mathbf{F} \prec \mathbf{X} \textrm{ and } \mathbf{P} \prec \mathbf{X}\\ \mathbf{X} |q \in VFDPx &\implies \mathbf{F} \prec \mathbf{X} \textrm{, } \mathbf{P} \prec \mathbf{X} \textrm{ and } \mathbf{D} \prec \mathbf{X} \end{aligned}\]

This does not preclude adversaries from doing their own exploit development on the way to A, but it avoids providing them with unnecessary assistance.

Coordinators have been characterized as seeking to balance the social good across both vendors and system owners (See for example Optimal Policy for Software Vulnerability Disclosure by Arora, Telang, and Xu). Thisimplies that they are likely interested in the union of the vendors' and system owners' preferences. In other words, coordinators want the full set of desiderata (\(\mathbb{D}_c = \mathbb{D}\)).

Why not a Coordinator Awareness event?

We pause for a brief aside about the design of the model with respect to the coordination role. We considered adding a Coordinator Awareness (C) event, but this would expand \(|\mathcal{H}|\) from 70 to 452 because it could occur at any point in any \(h\). There is not much for a coordinator to do once the fix is deployed, however, so we could potentially reduce \(|\mathcal{H}|\) to 329 by only including positions in \(\mathcal{H}\) that precede the D event. This is still too large and unwieldy for meaningful analysis within our scope; instead, we simply provide the following comment.

The goal of coordination is this: regardless of which stage a coordinator becomes involved in a case, the objective is to choose actions that make preferred histories more likely and non-preferred histories less likely.

The rules outlined in CVD Action Rules suggest available actions to improve outcomes. Namely, this means focusing coordination efforts as needed on vendor awareness, fix availability, fix deployment, and the appropriately timed public awareness of vulnerabilities and their exploits (V,F,D, P, and X).

Finder/Reporter

Coordinator

In their defensive roles, governments act as a combination of system owners, vendors, and increasingly coordinators. Therefore we might anticipate \(\mathbb{D}_g = \mathbb{D}_c = \mathbb{D}\).

However, governments sometimes also have an adversarial role to play for national security, law enforcement, or other reasons. The model presented here could be adapted to that role by drawing some desiderata from the lower left triangle of the ordered pairs table (reproduced below for convenience). While defining such adversarial desiderata (\(\mathbb{D}_a\)) is out of scope for our purposes, we leave the topic with our expectation that \(\mathbb{D}_a \not\subseteq \mathbb{D}\).

Ordered Pairs of Events

This table displays all 36 possible orderings of paired transitions and whether they are considered impossible, required (as defined by the formalized constraints reproduced below for convenience)

\(\prec\)	\(\mathbf{V}\)	\(\mathbf{F}\)	\(\mathbf{D}\)	\(\mathbf{P}\)	\(\mathbf{X}\)	\(\mathbf{A}\)
\(\mathbf{V}\)	-
\(\mathbf{F}\)		-
\(\mathbf{D}\)			-
\(\mathbf{P}\)				-
\(\mathbf{X}\)					-
\(\mathbf{A}\)						-

Key: = Required, = Desired, = Undesired, = Impossible, = row, = column \(\prec\) = precedes