Given that 2021 set a record for the number of vulnerabilities disclosed and that threat actors improved their capacity to weaponize vulnerabilities, prompt and intelligent prioritization and repair of vulnerabilities should be a priority for all businesses.

Despite the fact that the US Cybersecurity and Infrastructure Security Agency (CISA) frequently publishes lists of the most exploited vulnerabilities and maintains a frequently updated Known Exploited Vulnerabilities catalog that anyone is welcome to use, organizations frequently have trouble deciding which security flaws should be fixed first.

Stakeholder-Specific Vulnerability Categorization

The purpose of SSVC(Stakeholder-Specific Vulnerability Categorization) is to aid in prioritizing a vulnerability’s correction depending on the effect that exploitation would have on the specific organization (s). The four SSVC score factors that are discussed in this article provide an overview of how CISA indicates patching priority. SSVC may be used by any person or organization to improve their own vulnerability management procedures.

THE SCORING DECISION FOR VULNERABILITY

TRACK: At this moment, nothing has to be done about the vulnerability. The company would keep a check on the vulnerability and reevaluate it if fresh information came to light.

TRACK* :Specific traits of the vulnerability call for possible tighter monitoring for modifications.

ATTEND: Internal, supervisory-level members of the company must pay attention to the vulnerability. Requesting help or information about the vulnerability and releasing a notification—internally or externally—about the vulnerability are both examples of necessary activities.

ACT: The internal, supervisory, and leadership levels of the company must pay attention to the vulnerability. Requesting help or details regarding the vulnerability, as well as disseminating a notification internally and/or internationally, are necessary steps. Internal groups would often gather to decide on the overall reaction before carrying out the decisions made.

CONSIDERATIVE DECISION POINTS

The following decision points and related values are employed to determine how to decide scoring decision for vulnerabilities.

Evidence of Active Vulnerability Exploitation

This metric establishes how the vulnerability is currently being exploited. It recognizes the information that is known at the time of analysis rather than making predictions about future exploitation or measuring the likelihood or simplicity of an adversary developing future exploit code. Answers should be timestamped because the situation of exploitation today frequently changes over time.

NONE: There is no confirmation that the vulnerability has been actively exploited, and there is also no publicly available proof of concept (PoC).

PUBLIC PoC: At least one of the following is accurate: One of two things can happen: either the vulnerability has a widely used technique of exploitation, or there is a typical public PoC in places like Metasploit or websites like ExploitDB.

ACTIVE: Proof that is widely available, visible, and trustworthy that cyber threat actors have actually exploited the exploit in the wild; the public reporting comes from a trusted source.

Technical Impact of the Vulnerability

Technical impact is comparable to the “severity” term used in the Common Vulnerability Scoring System (CVSS) base score. The scope specification is particularly crucial when assessing technical effect. The “Total” decision point refers to the component that is affected by the vulnerability. If an authentication or authorization credential is revealed to the system as a result of a vulnerability, this information exposure should also be rated as “Total” if it gives the adversary complete access over the component.

PARTIAL: One of the following is accurate: The exploit either provides the threat actor a low probability possibility for entire control or restricted control over the behavior of the program that includes the vulnerability, as well as information disclosure about it. Low here refers to the ability of the attacker to legitimately attempt to overcome security- or physical-based barriers and gain complete control. A restricted type of control over the behavior of the susceptible component is a denial-of-service attack.

TOTAL: The exploit offers the attacker total access to the software’s functionality or total exposure of all data on the machine that is vulnerable.

Automatable

Automatable encapsulates how quickly and easily a cyber threat actor may trigger exploitation events.
Can an attacker reliably automate, producing exploitation events for this vulnerability? is the question that Automatable answers. Whether an actor can quickly generate several exploitation events depends on a number of things. These include the difficulty of the attack, the particular code a potential actor would have to create or setup, and the typical network deployment of the susceptible system. Identifying the obstacles that prevent the vulnerability from being exploited by worms is another technique to consider if a vulnerability is automatable.

A No response can be provided with just one efficient barrier. For instance, requiring user authentication and login generally protects a vulnerability from being exploited by worms. The authentication barrier, however, is rendered useless if the susceptible system also has another unpatched vulnerability that permits code injection or remotely and easily grants an attacker access to a guest account. This is the outcome of “chaining” vulnerabilities to enable automated exploitation.

NO: It is not possible to successfully automate reconnaissance, weaponization, delivery, and exploitation steps 1-4 of the kill chain for this flaw. 1 The following are some examples of reasons why each step may not be reliably automatable: (1) the vulnerable component is not searchable or enumerable on the network; (2) weaponization may require human direction for each target; (3) delivery may require channels that are blocked by widely used network security configurations; and (4) exploitation may be thwarted by adequate exploit-prevention techniques enabled by default .

YES: The first four steps of the kill chain can be successfully automated. The answer is probably affirmative if the flaw permits unauthenticated remote code execution (RCE) or command injection.

Impact on Relevant Entities’ Essential Mission Functions

A function that is “directly relevant to executing the organization’s mission as set out in its statutory or executive charter” is referred to as a mission important function (MEF). Planning for business continuity during a crisis includes identifying MEFs. An organization “must conduct a [MEF] during an interruption to regular operations,” in contrast to non-essential tasks. The mission is the reason a company exists, and MEFs are the means by which it is accomplished. Instead of directly supporting the mission, non-essential functions ensure the seamless delivery or success of MEFs. Mission prevalence involves more than only counting the number of present technologies or goods. This criticality is crucial if only a few devices are affected yet they directly perform crucial tasks.

MINIMAL: Neither the terms essential nor support apply. Although the susceptible component may be utilized by the entities, it is not a mission-critical component and does not significantly assist mission-critical operations.

SUPPORT: Only MEFs for two or more entities are supported by the susceptible component.

IMPORTANT: At least one MEF capability is directly provided by the susceptible component. Component failure for at least one entity might, but need not, result in overall failing the mission.

Impacts of Affected System Compromise on Humans

Violations of safety are those that are harmful to wellbeing. The CDC’s broad definition of well-being, which includes physical, social, emotional, and psychological health, is one that SVCC supports.

MINIMUM: For all factors covered in the material, the impact is below the threshold.

MATERIAL: It can cause Physical, Environment, Financial and Psychological harm.

IRREVERSIBLE: It can cause irreversible Physical, Environment, Financial but no Psychological harm.

Status of the Vulnerability’s Available Mitigations, Workarounds, or Fixes

The level of difficulty to promptly mitigate the vulnerability is measured by the mitigation state. Three things need to be taken into account: type, difficulty, and availability.

It makes sense that unavailable is worse than available and that high is worse than low for availability and system change difficulties. Workaround mitigations typically tend to be more difficult or call for specific system owner tasks, but a remedy (patch) frequently has an established and generally simple application procedure. This makes workaround mitigations worse than fixes for the kind of mitigation. Unless one of the factors mentioned as high is satisfied, the complexity of system modification should be minimal.

MINIMAL: It can two values Available or Unavailable. The mitigation is either accessible to the public or not.

SYSTEM CHANGE DIFFICULTY: It can two values Low or High and is decided if any one of the following is accurate:
• There is no integrated updating procedure for the system.
• Significant downtime will be needed to implement the mitigation.
• Following mitigation, system performance will be below what is typically acceptable.
• The regulatory setting could make it impossible to use mitigation.

TYPE: It can two values Fix(An official patch that remediates the vulnerability) or Workaround( Some method of thwarting exploitation that does not fix the underlying problem; this frequently takes the form of reconfiguring the vulnerable point component or its environment.)