The CVSS or Common Vulnerability Scoring System, in its most basic form is a framework used to assign a numeric score 0 – 10 to severity of vulnerabilities, 10 being the most severe. The score is based on vendor neutral qualitative estimates of risk, in combination with end user input depending on environmental specific considerations. It is designed in a manner to be scalable enough for rating vulnerabilities on all levels from Operating Systems to Web Applications to Protocols.
Current version of CVSS is 3.1, however the CVSS SIG (Special Interest Group) is currently working on the update to 4.0. Those potential improvements can be found here.
Scoring is measured in 3 categories:
Base Metrics: Base factors are those that will not change over time and are not dependent on other factors. It will be scored on Exploitability, Scope and Impact
Temporal Metrics: Opposite of Base Metrics, Temporal factors are those that will change as exploit code matures over time. Availability of remediation actions (vendor patches) are also taken in to consideration when calculating the Temporal Metric Score.
Environmental Metrics: Environment Factors take criticality of Assets in to consideration. If the Asset is mission critical a higher score will be assigned. So if the vulnerability deals with authentication to a Domain Controller, that score will be much higher than a low level vulnerability on a standard user laptop. The other consideration the Environment Factor allows for is mitigations applied to the asset, Air Gapping is an example here.
The three Metrics above are calculated based on weight for the final Qualitative product. One note on that calculation is that the Base Metric is mandatory, however the Temporal Metric is optional, both of those scores are provided by the vendor when the vulnerability information is released. Lastly the Environmental Metric is entered by the product end user and is also optional. So as you can see there is room for a fair amount of score manipulation which is somewhat of a short fall of CVSS.
|CVSS Score||Qualitative Rating|
|0.1 – 3.9||Low|
|4.0 – 6.9||Medium|
|7.0 – 8.9||High|
|9.0 – 10.0||Critical|
Now we have a general idea of how scores are calculated, so what does that all mean for me as an administrator patching a system?
With everything related to CVSS, it depends. There are general guidelines of patch priority based on score but your specific environment as well as your personal risk acceptance comfort level threshold need to be taken in to consideration.
Here are two examples of different organizations, use them as a guide but remember as a Security Professional you must decide whats best for you.
NIST sets their scores slightly different than the recommendation above, then incorporates a patch decision tree to help decide what action to take and how soon. More info can be found here on the NIST process: https://us-cert.cisa.gov/sites/default/files/recommended_practices/RP_Patch_Management_S508C.pdf
Microsoft uses the following recommendation for patching.
If you are going to take one piece of advice away from here, execute the following:
– Talk to Asset owners and have a patch plan in place that works for your organization
– Know your risk tolerance level and that of your C level sponsor (They don’t have to match, probably won’t)
– Stay on top of patch notifications for the systems in your Organization
Questions that will help along the way when figuring it all out:
– What is the Asset exposure, Internally available only or Externally available ?
– What defense in depth security controls do you have in place ?
– Is the vulnerability being exploited already in the wild ?
– Is the attack vector Network based or Local ?
– Does the attack require user interaction ?
– How complex is it to exploit, can it be done by a script kiddie with metasploit ?
– Is the exploit code still a Proof of Concept or has it been validated ?
– Is there a workaround available that can buy you time until a Maintenance window opens ?
Take CVSS with a grain of salt, if its a 9.8 or 10, jump on that and patch, don’t wait. If its coming in at a 7, the questions listed above are going to be a lot more helpful in deciding whether to stop operations and pull the trigger early, or waiting a week or two for a patch window.
Lastly if you are a security analyst, admin, engineer whatever your title is and you bring a recommendation to patch now to your C Level Exec who is willing to push off the patch and accept the risk, Document that decision. Its your job to make the recommendation and push for what is best on the security side, some times that gets trumped by needs of the business. If Risk Tolerance is higher on the C Suite that’s okay, that’s what they get paid the big bucks for, but just make sure to document that decision for later reference.
Patching is a non stop war – Have a battle plan ready
Weister Creek Information Security – 2/11/2021