How do we manage and prioritize the security software vulnerabilities we find?
First let's look at prioritizing vulnerabilities. There are two primary questions for prioritizing vulnerabilities for remediation: How serious is the vulnerability and how hard will it be to fix? The answers to these let security and development teams decide what can be remediated and when.
Managing vulnerabilities is not fun, but it is something organizations must do to reduce their exposure.
Tools often give a single-dimensional critical/high/medium/low ranking to vulnerabilities they identify. These are often based on partial information and can thus be misleading. Fortunately, other structured models can help better characterize vulnerability severities.
Microsoft released the DREAD risk assessment model for classifying security vulnerabilities. The DREAD model asks analysts to classify the severity of vulnerabilities along these five dimensions:
- Damage potential: What is the raw potential for damage if the vulnerability is successfully exploited?
- Reproducibility: How reliably can the vulnerability be exploited?
- Exploitability: How much work would be required to successfully exploit the vulnerability?
- Affected users: How many users would be impacted if the vulnerability were exploited?
- Discoverability: How easy is it to discover the vulnerability?
Each dimension is given a rank from one to three. Analysts can average the values if needed in order to roll up to a single critical/high/medium/low score, but the different dimensions can also be used independently. For example, you can look at all vulnerabilities that have a large damage potential, independent of other factors.
NIST also has the Common Vulnerability Scoring System Version 2.0 (CVSS2). Similar to the DREAD model, CVSS2 expands the scoring of a vulnerability to encompass multiple dimensions so that analysts can take into account a variety of factors when making decisions about a given vulnerability's severity.
Determining level of effort
For many infrastructure-level vulnerabilities, fixing the vulnerability requires applying a vendor-supplied patch or changing a configuration setting. Unfortunately, most application vulnerabilities require software developers to make code changes to fix them. Because of this, application security remediation projects are actually software maintenance projects and should be estimated as such.
Estimation requires a determination of the level of effort required to actually fix the vulnerable code. It also requires consideration of time needed for other ancillary tasks, such as setting up development environments, confirming fixes were effective and if it introduces new bugs into the code. Deploying code into production and other overhead tasks inevitably creep into software maintenance efforts.
A critical point to remember is that these projects should be estimated from the bottom up by enumerating the various tasks and adding up the total required time. A common mistake is to estimate these efforts from the top down -- making the assumption that the project team "ought to be able" to accomplish some high-level tasks in an arbitrary amount of time.
I have previously released some data publicly discussing the time it takes to fix vulnerable code as well as the percentage of projects that will be spent on different types of activities. Using data like this, development teams can start to create a model for estimating remediation projects.
Making a plan
First, security and development teams must build an understanding of the exposure that stems from a given set of identified software vulnerabilities. Then they need to negotiate what gets fixed, what doesn't get fixed and in what order to implement the fixes.
Every organization is going to have a different set of priorities and circumstances that will shape this discussion. How mature are the development practices? What are the internal priorities? Does IT have service-level agreements (SLAs) or other commitments to customers or third parties?
Negotiations can be tense, but having a defined risk model as well as level-of-effort estimates will help keep conversations quantitative and fact-based. A typical goal is to address the most serious vulnerabilities as quickly as possible.
Once a plan is developed, it is beneficial to treat the vulnerability remediation tasks as software defects and manage them in the development team's defect tracking system. As mentioned above, application remediation projects are really software maintenance projects, so tracking the tasks associated with these efforts should be done in the tools the development team uses to manage its everyday workloads.
Managing software vulnerabilities is not fun, but it is something organizations must do to reduce their exposure. By creating a plan based on a defined risk model and bottom-up level of effort estimates and by executing this plan using tools the development team is already using, these efforts can be made less painful and less expensive.
Have a question about managing security vulnerabilities? Let us know and we'll pass your question on to one of our experts.
Dig Deeper on Topics Archive
Related Q&A from Dan Cornell
Is it safe to move from on-premises application lifecycle management tools to cloud-based tools? Read this expert answer to find out. Continue Reading
Can security impact application performance? What security vulnerabilities might be slowing us down? Continue Reading
As our developers incorporate more and more third-party software components and partner APIs that we don't have direct control over, how do we test ... Continue Reading