Gathering Information about Automatable
Automatable (ssvc:A:2.0.0)
Can an attacker reliably automate creating exploitation events for this vulnerability?
Value | Key | Definition |
---|---|---|
No | N | Attackers cannot reliably automate steps 1-4 of the kill chain for this vulnerability. These steps are (1) reconnaissance, (2) weaponization, (3) delivery, and (4) exploitation. |
Yes | Y | Attackers can reliably automate steps 1-4 of the kill chain. |
Automatable (ssvc:A:2.0.0) JSON Example
{
"namespace": "ssvc",
"key": "A",
"version": "2.0.0",
"name": "Automatable",
"definition": "Can an attacker reliably automate creating exploitation events for this vulnerability?",
"schemaVersion": "2.0.0",
"values": [
{
"key": "N",
"name": "No",
"definition": "Attackers cannot reliably automate steps 1-4 of the kill chain for this vulnerability. These steps are (1) reconnaissance, (2) weaponization, (3) delivery, and (4) exploitation."
},
{
"key": "Y",
"name": "Yes",
"definition": "Attackers can reliably automate steps 1-4 of the kill chain."
}
]
}
An analyst should be able to sketch the automation scenario and how it either does or does not satisfy each of the four kill chain steps. Once one step is not satisfied, the analyst can stop and select no. Code that demonstrably automates all four kill chain steps certainly satisfies as a sketch. We say sketch to indicate that plausible arguments, such as convincing psuedocode of an automation pathway for each step, are also adequate evidence in favor of a yes to Automatable.
Like all SSVC decision points, Automatable should capture the analyst's best understanding of plausible scenarios at the time of the analysis. An answer of no does not mean that it is absolutely inconceivable to automate exploitation in any scenario. It means the analyst is not able to sketch a plausible path through all four kill chain steps. “Plausible” sketches should account for widely deployed network and host-based defenses. Liveness of Internet-connected services means quite a few overlapping things 1. For most vulnerabilities, an open port does not automatically mean that reconnaissance, weaponization, and delivery are automatable. Furthermore, discovery of a vulnerable service is not automatable in a situation where only two hosts are misconfigured to expose the service out of 2 million hosts that are properly configured. As discussed in in Reasoning Steps Forward, the analyst should consider credible effects based on known use cases of the software system to be pragmatic about scope and providing values to decision points.
-
Shehar Bano, Philipp Richter, Mobin Javed, Srikanth Sundaresan, Zakir Durumeric, Steven J Murdoch, Richard Mortier, and Vern Paxson. Scanning the internet for liveness. SIGCOMM Computer Communication Review, 48(2):2–9, 2018. ↩