Misplaced Pages

#12987

27-781: The current version of CVSS (CVSSv4.0) was released in November 2023. CVSS is not intended to be used as a method for patch management prioritization, but is used like that regardless. Research by the National Infrastructure Advisory Council (NIAC) in 2003/2004 led to the launch of CVSS version 1 (CVSSv1) in February 2005, with the goal of being "designed to provide open and universally standard severity ratings of software vulnerabilities". This initial draft had not been subject to peer review or review by other organizations. In April 2005, NIAC selected

54-473: A net productivity boost for the organization. Up-to-date systems often perform more efficiently, less expensively, with less errors, less security risks , and better user workflow . Additionally, compliance with changing local and federal regulations are more likely to be satisfied. Patches can be used to defend against and eliminate potential vulnerabilities of a system, so that no threats may exploit them; therefore, patch management can be considered

81-441: A sub-discipline of vulnerability management. Every patchable device in a system presents an attack surface that must be secured. There are a multitude of problems that can arise during patch management. A common issue is buggy patches, which either fail to fix their problem or introduce new issues. Another issue is deployment synchronization, since various subsystems may receive instructions to update at different times. Similarly,

108-621: A system, so that no threats may exploit them. Problems that can arise during patch management, including buggy patches that either fail to fix their problem or introduce new issues. Patch management tools can help orchestrate all of the procedures involved in patch management. Patch management is defined as a sub-practice of various disciplines including vulnerability management (part of security management ), lifecycle management (with further possible sub-classification into application lifecycle management and release management ), change management , and systems management . The practice

135-459: A user are considered more severe. PR can take the values None, Low, or High; similarly, attacks requiring fewer privileges are more severe. Patch management Patch management is concerned with the identification, acquisition, distribution, and installation of patches to systems . Proper patch management can be a net productivity boost for the organization. Patches can be used to defend against and eliminate potential vulnerabilities of

162-427: A vulnerability allows the temporal score of a vulnerability to decrease as mitigations and official fixes are made available. The report confidence (RC) of a vulnerability measures the level of confidence in the existence of the vulnerability and also the credibility of the technical details of the vulnerability. These three metrics are used in conjunction with the base score that has already been calculated to produce

189-414: Is broadly concerned with the identification, acquisition, distribution, and installation of patches to systems . Some definitions of patch management are as a software-level practice, while others are as a systems-level process: software , drivers , and firmware . While reserving time for patching takes up enterprise resources, there are balancing factors which can make proper patch management into

216-523: Is generated for each of these metric groups. A vector string (or simply "vector" in CVSSv2) represents the values of all the metrics as a block of text. Complete documentation for CVSSv2 is available from FIRST. A summary is provided below. The access vector (AV) shows how a vulnerability may be exploited. The access complexity (AC) metric describes how easy or difficult it is to exploit the discovered vulnerability. The authentication (Au) metric describes

243-537: The CVSS Vector for the vulnerability. A buffer overflow vulnerability affects web server software that allows a remote user to gain partial control of the system, including the ability to cause it to shut down: This would give an exploitability sub-score of 10, and an impact sub-score of 8.5, giving an overall base score of 9.0. The vector for the base score in this case would be AV:N/AC:L/Au:N/C:P/I:P/A:C. The score and vector are normally presented together to allow

270-703: The Forum of Incident Response and Security Teams ( FIRST ) to become the custodian of CVSS for future development. Feedback from vendors using CVSSv1 in production suggested there were "significant issues with the initial draft of CVSS". Work on CVSS version 2 (CVSSv2) began in April 2005 with the final specification being launched in June 2007. Further feedback resulted in work beginning on CVSS version 3 in 2012, ending with CVSSv3.0 being released in June 2015. The CVSS assessment measures three areas of concern: A numerical score

297-401: The aforementioned vulnerable web server were used by a bank to provide online banking services, and a temporary fix was available from the vendor, then the environmental score could be assessed as: This would give an environmental score of 8.2, and an environmental vector of CDP:MH/TD:H/CR:H/IR:H/AR:L. This score is within the range 7.0-10.0, and therefore constitutes a critical vulnerability in

SECTION 10

#1732782911013

324-567: The categories NVD defined for CVSSv2 that were not part of that standard. In the Base vector, the new metrics User Interaction (UI) and Privileges Required (PR) were added to help distinguish vulnerabilities that required user interaction or user or administrator privileges to be exploited. Previously, these concepts were part of the Access Vector metric of CVSSv2. UI can take the values None or Required; attacks that do not require logging in as

351-755: The context of the affected bank's business. Several vendors and organizations expressed dissatisfaction with CVSSv2. Risk Based Security, which manages the Open Source Vulnerability Database , and the Open Security Foundation jointly published a public letter to FIRST regarding the shortcomings and failures of CVSSv2. The authors cited a lack of granularity in several metrics, which results in CVSS vectors and scores that do not properly distinguish vulnerabilities of different type and risk profiles. The CVSS scoring system

378-490: The difficulty of patch management across many devices may grow at an uncontrollable rate depending on organizational size. One prominent demonstration of the challenges facing proper patch management was the buggy Falcon Sensor patch by CrowdStrike which caused one of the worst IT outages of all time. A patch management tool (alternatively patch manager , patch management system , patch management software , or centralized patch management ) help orchestrate all of

405-409: The example above, if the vendor was first informed of the vulnerability by a posting of proof-of-concept code to a mailing list, the initial temporal score would be calculated using the values shown below: This would give a temporal score of 7.3, with a temporal vector of E:P/RL:U/RC:UC (or a full vector of AV:N/AC:L/Au:N/C:P/I:P/A:C/E:P/RL:U/RC:UC). If the vendor then confirms the vulnerability, then

432-469: The financial impact upon the affected organisation if the vulnerability is exploited. The target distribution (TD) metric measures the proportion of vulnerable systems in the environment. Three further metrics assess the specific security requirements for confidentiality (CR), integrity (IR) and availability (AR), allowing the environmental score to be fine-tuned according to the users' environment. The five environmental metrics are used in conjunction with

459-419: The number of times that an attacker must authenticate to a target to exploit it. It does not include (for example) authentication to a network in order to gain access. For locally exploitable vulnerabilities, this value should only be set to Single or Multiple if further authentication is required after initial access. The confidentiality (C) metric describes the impact on the confidentiality of data processed by

486-1150: The previously assessed base and temporal metrics to calculate the environmental score and to produce the associated environmental vector. AdjustedImpact = min ( 10 , 10.41 × ( 1 − ( 1 − ConfImpact × ConfReq ) × ( 1 − IntegImpact × IntegReq ) × ( 1 − AvailImpact × AvailReq ) ) ) {\displaystyle {\textsf {AdjustedImpact}}=\min(10,10.41\times (1-(1-{\textsf {ConfImpact}}\times {\textsf {ConfReq}})\times (1-{\textsf {IntegImpact}}\times {\textsf {IntegReq}})\times (1-{\textsf {AvailImpact}}\times {\textsf {AvailReq}})))} AdjustedTemporal = TemporalScore  recomputed with the  BaseScore s  Impact  sub-equation replaced with the  AdjustedImpact  equation {\displaystyle {\textsf {AdjustedTemporal}}={\textsf {TemporalScore}}{\text{ recomputed with

513-456: The recipient to fully understand the nature of the vulnerability and to calculate their own environmental score if necessary. The value of temporal metrics change over the lifetime of the vulnerability, as exploits are developed, disclosed and automated and as mitigations and fixes are made available. The exploitability (E) metric describes the current state of exploitation techniques or automated exploitation code. The remediation level (RL) of

540-442: The score rises to 8.1, with a temporal vector of E:P/RL:U/RC:C A temporary fix from the vendor would reduce the score back to 7.3 (E:P/RL:T/RC:C), while an official fix would reduce it further to 7.0 (E:P/RL:O/RC:C). As it is not possible to be confident that every affected system has been fixed or patched, the temporal score cannot reduce below a certain level based on the vendor's actions, and may increase if an automated exploit for

567-406: The system. The Integrity (I) metric describes the impact on the integrity of the exploited system. The availability (A) metric describes the impact on the availability of the target system. Attacks that consume network bandwidth, processor cycles, memory, or any other resources affect the availability of a system. These six metrics are used to calculate the exploitability and impact sub-scores of

SECTION 20

#1732782911013

594-572: The temporal score for the vulnerability with its associated vector. The formula used to calculate the temporal score is: TemporalScore = roundTo1Decimal ( BaseScore × Exploitability × RemediationLevel × ReportConfidence ) {\displaystyle {\textsf {TemporalScore}}={\textsf {roundTo1Decimal}}({\textsf {BaseScore}}\times {\textsf {Exploitability}}\times {\textsf {RemediationLevel}}\times {\textsf {ReportConfidence}})} To continue with

621-437: The vulnerability is developed. The environmental metrics use the base and current temporal score to assess the severity of a vulnerability in the context of the way that the vulnerable product or software is deployed. This measure is calculated subjectively, typically by affected parties. The collateral damage potential (CDP) metric measures the potential loss or impact on either physical assets such as equipment (and lives), or

648-1666: The vulnerability. These sub-scores are used to calculate the overall base score. Exploitability = 20 × AccessVector × AccessComplexity × Authentication {\displaystyle {\textsf {Exploitability}}=20\times {\textsf {AccessVector}}\times {\textsf {AccessComplexity}}\times {\textsf {Authentication}}} Impact = 10.41 × ( 1 − ( 1 − ConfImpact ) × ( 1 − IntegImpact ) × ( 1 − AvailImpact ) ) {\displaystyle {\textsf {Impact}}=10.41\times (1-(1-{\textsf {ConfImpact}})\times (1-{\textsf {IntegImpact}})\times (1-{\textsf {AvailImpact}}))} f ( Impact ) = { 0 , if  Impact  = 0 1.176 , otherwise  {\displaystyle f({\textsf {Impact}})={\begin{cases}0,&{\text{if }}{\textsf {Impact}}{\text{ = 0}}\\1.176,&{\text{otherwise }}\end{cases}}} BaseScore = roundTo1Decimal ( ( ( 0.6 × Impact ) + ( 0.4 × Exploitability ) − 1.5 ) × f ( Impact ) ) {\displaystyle {\textsf {BaseScore}}={\textsf {roundTo1Decimal}}(((0.6\times {\textsf {Impact}})+(0.4\times {\textsf {Exploitability}})-1.5)\times f({\textsf {Impact}}))} The metrics are concatenated to produce

675-667: The }}{\textsf {BaseScore}}{\text{s }}{\textsf {Impact}}{\text{ sub-equation replaced with the }}{\textsf {AdjustedImpact}}{\text{ equation}}} EnvironmentalScore = roundTo1Decimal ( ( AdjustedTemporal + ( 10 − AdjustedTemporal ) × CollateralDamagePotential ) × TargetDistribution ) {\displaystyle {\textsf {EnvironmentalScore}}={\textsf {roundTo1Decimal}}(({\textsf {AdjustedTemporal}}+(10-{\textsf {AdjustedTemporal}})\times {\textsf {CollateralDamagePotential}})\times {\textsf {TargetDistribution}})} If

702-417: Was also noted as requiring too much knowledge of the exact impact of the vulnerability. Oracle introduced the new metric value of "Partial+" for Confidentiality, Integrity, and Availability, to fill perceived gaps in the description between Partial and Complete in the official CVSS specifications. To address some of these criticisms, development of CVSS version 3 was started in 2012. The final specification

729-448: Was named CVSSv3.0 and released in June 2015. In addition to a Specification Document, a User Guide and Examples document were also released. Several metrics were changed, added, and removed. The numerical formulas were updated to incorporate the new metrics while retaining the existing scoring range of 0-10. Textual severity ratings of None (0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), and Critical (9.0-10.0) were defined, similar to

#12987