Putting Days-of-Risk to Practical Use

Jeffrey R. Jones
Senior Director, Security Business & Technology Unit
Microsoft Corporation

In March, Forrester Research published a recent study titled “Is Linux More Secure Than Windows.” The study brought renewed attention to the concepts of a vulnerability life cycle and a time period of increased security risk, or “days of risk.”

Forrester conducted research covering a 12-month period to get beyond “what everybody knows” with an objective, repeatable, independent methodology for defining and measuring three security metrics that can be applied to software vendors: responsiveness, relative severity, and thoroughness. Each vendor mentioned in the study was given the opportunity (and each took it) to help make sure the research data was accurate.

Using the independent methodology, combined with the verified data you can get from Forrester, you can repeat the study to draw your own conclusions. So, even though the study’s results (Microsoft came out on top) have been disputed by the Linux distributions that participated, the study is a new tool that businesses can use to measure some aspects of their vendor’s software security.

As much as I’d enjoy digging into the details of the Forrester study here, instead I’ll encourage you to read the report and I’ll discuss how you might use the concepts in the report to manage yourself and your vendor to reduce your exposure to illegal or malicious attacks to your networks.

The Vulnerability Life Cycle

Figure 1: Vulnerability Life Cycle

• Vulnerability discovered. This is the first time that an individual or small group of individuals identify a software vulnerability.

• Vulnerability disclosed. This is the milestone where a vulnerability is made broadly public ,typically through newsgroups or the press. Due to widespread distribution of information about the vulnerability, this event increases the likelihood that an exploit will be created to take advantage of the vulnerability. Protective software such as a personal firewall can help mitigate the risk of the vulnerability until a fix is made available.

• Fix available. This is when a tested patch is made available from a software vendor (or distribution vendor like Red Hat). Some vendors are very open and transparent with public security advisories or bulletins, while others have less public notification policies. Users should install available patches immediately to mitigate the risk of the identified vulnerability.

• Exploit code available. This is when a sample exploit is posted publicly, which enables both sophisticated coders and less knowledgeable users known as “script kiddies” to more easily develop malicious attack code. This is a second milestone that increases security risk for customers.

• Fix deployed (or vulnerability mitigated). This is the milestone where software has been updated to neutralize the vulnerability, reducing security risk back to normal levels. The mitigation step could be a separate milestone and in some instances may occur before exploit code is available.

With this life cycle model, we can recognize that the goal for minimizing security risk related to the software vulnerability life cycle is to achieve zero days of risk. A day of risk occurs as soon as a vulnerability is disclosed.

Who Can Affect Days of Risk

With a goal in mind, the next step is to identify what steps can be taken to achieve that goal. In the life cycle model, actions are under the control of three parties: software vendors, software users, and security researchers. In addition, it is good to keep in mind the fourth party that represents the threat during the days of risk: malicious attackers.

The actions we would want to influence that would have an impact on days of risk are the following:

Software Vendors

• Relative severity (Forrester metric) – Products with fewer vulnerabilities and lower severity.

• Responsiveness (Forrester metric) – Fixes available quickly after a vulnerability is disclosed reduce risk.

• Thoroughness (Forrester metric) – All security vulnerabilities fixed.

Security Researchers

• Responsible disclosure – Public disclosure by researchers without a fix starts the clock on days of risk.

Malicious Attackers

• Worms/viruses – Threat. Mobile malicious attacks designed for maximum spread, damage, and notoriety.

• Root attacks – Threat. Stealthy attacks targeted at theft or ensuring future accessibility.

Software Users

• Patch management processes – Fixing a vulnerability ends the risk of attack.

• Security risk mitigation process - Closing a vulnerability (for example, blocking a port or stopping a service) ends the risk of attack.

Putting It All into Practical Use – The Action Plan

As a security subject matter expert or decision maker in your organization, you have the ability to choose which vendor to partner with for your software security solutions and to drive both their behavior and your own. With this in mind, a suggested action plan to manage vulnerability life cycles might involve:

• Adjusting software user processes to reduce days of risk.

• Improving vendor performance in the vulnerability life cycle model.

• Encouraging security researchers to reduce days of risk.

• Motivating malicious attackers to stop their illegal actions.

Your Company – Actions You Can Take

Depending on the size of your organization, the most effective processes will vary, but high-level questions to ask include:

• Network architecture. Are there ways to isolate subsets of your systems from potential threats? Have you established network domains of trust, with well-controlled gateways separating them?

• Hardening and protective software. Have you hardened systems? For example, do database servers have all unnecessary ports blocked? Do your workstations have antivirus and personal firewalls and can you centrally manage them? Can you tell if they are compliant with your policy?

• Software update policies and processes. Do home users and small businesses use AutoUpdate capabilities? Do enterprises have quality update tools for efficient updates? Have you determined the right testing for updates? Do you have a process for determining relevancy to your environment?

• Encourage responsible disclosure (and behavior) in security researchers. Are their marketing and PR actions putting you at unnecessary risk? Are you speaking out to discourage bad behavior?

• Help catch attackers. Are you effectively cooperating with law enforcement and other companies in tracking and catching malicious attackers?

Your Software Vendor – Questions You Should Ask

Forrester has given you a baseline vendor comparison in its report, but, if you see value in the methodology, you can ask your vendor to provide you with current data that is supported by public references for comparison.

• For product X, what is your responsiveness using the vulnerability life cycle model over a given time period?

• For product X, using a recognized third-party rating system like ICAT, how many severe vulnerabilities did your product have over a given time period?

• For product X, how many vulnerabilities remain unfixed over a given time period?

• What details in your software development process help reduce the total number of vulnerabilities?

• What improvements have you made in your software development process to reduce vulnerabilities? When did you make them? Do they apply to all components in product X?

• What protective features do you have that mitigate or neutralize classes of vulnerabilities for product X?

• What update package features and tools do you have to make my update management process easier? Can I uninstall your updates? What will be the impact if I uninstall them?

• Can I selectively approve updates for deployment? Do you provide a consistent update experience? Do I have to reboot (or recompile)? Does your package work with my third-party system management tool?

• What are you doing (vendor) to encourage responsible behavior by security researchers in the industry?

• What are you doing (vendor) to help stop malicious attackers from their illegal actions?

Customers also have begun to recognize that integrated security is a factor in business decisions. Customers are asking hard questions and want solid answers based on objective data.

Since the Forrester study has value to customers, I am predicting that it is only the first of many studies over the next year that will attempt to pierce the veil of “common perception” (which are often misperceptions) with analysis based on extensive fact collection and formal methodologies. And if some readers mistrust the results and initiate their own studies, that will promote security even further.

The customer value to methodologies and metrics like Forrester’s days-of-risk study will ultimately be measured by whether customers and vendors find it useful for driving improvements in their operations and across the industry. I think this study, and the vulnerability life cycle model, stand up well to that test.