Determining suitable controls to effectively mitigate risk is a balancing act. More money can always be spent. More effort can always be put forth. But the right choices are all too often elusive and recognized in hindsight.
To avoid suffering unfortunate repercussions, it is best to practice a flavor of risk management that is at once as business minded as it is technically savvy. Too little or much of one or another most often leads to the realization of risks better otherwise controlled.
Factors in Risk Assessments
Based on the Payment Card Industry (PCI) Data Security Standard (DSS) version 2.0 requirements and the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-40 version 2 Creating a Patch and Vulnerability Management Program, mature vulnerability management processes require careful consideration to appropriately assign risk ranking and mitigation strategies.
An understanding of Common Vulnerability Scoring System (CVSS) version 2 calculation methodologies, established subsequent to the 2005 publication of SP800-40 version 2, directly assist in supporting the reasonable diligence necessary to effectively assess identified vulnerabilities.
CVSS base elements consider vulnerability access vectors, complexity, authentication requirements and the potential impact to confidentiality, integrity and availability. The temporal nature of vulnerabilities further considers exploitability factors affecting the ease with which a vulnerability may be exploited and the difficulty of remediation.
Additionally, environmental aspects of the affected environment including damage related impact, the prevalence of affected systems and established organizational confidentiality, integrity and availability prioritized security requirements are considered.
Security Controls Do Not Equal Invulnerability
With this in mind, it should be understood that though it's true many implemented security controls and supporting processes offer protection for organizations, it can not also be reasonably fathomed that their existence alone consistently mitigates the impact of identified vulnerabilities.
For example, suppose a database server is identified as being prone to one or more SQL injection vulnerabilities. It is isolated to a dedicated network segment with established access controls restricting communications to authorized internal hosts and the entirety of network assets protected by host-based and perimeter security controls including, respectively, both anti-virus protection and an intrusion prevention system. While the probability of exploit is arguably contained, the vulnerability remains.
Further, many if not all of the authorized hosts permitted communication with the server in this scenario are likely granted Internet access in addition to participating in email communications. As a result, despite the implemented security controls, compromise of any one authorized host via phishing or other Internet-born threat may still lead to the exploit of the database server’s vulnerability.
Ask RSA. In the case of their widely reported breach, the source proved to be a phishing attack which ultimately rendered all preventative technical controls moot.
Start with Understanding the Vulnerability
To effectively manage vulnerabilities and their associated risk, the vulnerability itself must first be understood prior to consideration being given to the potential effect of implemented controls and processes. While NIST SP800-53 derived probability and impact factors certainly should prove instrumental in final risk rating, CVSS-based calculation criteria should also be taken into account to better quantify and support the process. The resulting overall risk rating and determined mitigation strategy may only then be substantively applied.
While the method of documenting and monitoring ongoing vulnerability management processes will differ from organization to organization, the selected medium can range from spreadsheets to wiki-based tasking or even still GRC system tracking.
Independent of medium, it is further suggested that at a minimum, the following be detailed: vulnerability name, Common Vulnerabilities and Exposures (CVE) Identifier, National Vulnerability Database (NVD) assigned CVSS score, internally calculated CVSS score should it differ; high, medium or low rated probability, impact and overall risk rating assignment; selected mitigation strategy, identification of assigned resources and status.
Through these efforts, much of the guesswork and arguable biases may be removed to the benefit of organizational information security and business concerns alike. The result may further lead to improved governance processes and control strategies. Taking the time to programmatically identify, manage and monitor vulnerability risk should be an inherent part of any mature risk management program. Given concerns for evolving threat landscapes, increasing privacy and breach regulation and breach-related reputation concerns, it should also undoubtedly be a part of your own.
Image courtesy of udra (Shutterstock)
Editor's Note: To read more from Peter on the topic of risk management: