Successfully Presenting Vulnerability Data To Management

Your organization's network is a never-ending source of vulnerability information. New systems and applications are constantly being added, making the job of consistent vulnerability identification and risk management difficult. Tenable provides several tools to assist in this process. Nessus, combined with the Security Center, can provide detailed information about the vulnerabilities in your environment. The problem that many administrators face is that they are not always successful in getting management to recognize problems and provide resources for remediation. This blog post describes some tactics I have compiled over the years to help expedite this process.

Management Should Be Expecting It

Vulnerability management and assessment programs must have executive management buy-in and support. Executive management must be made aware of the importance of the program to manage risk. As a security professional responsible for establishing this program you need to provide the following information to gain approval:

• Scope - Define the scope of the testing. Will the assessment program scan all ports and services of every device connected to the network each week? Will denial of service testing be permitted, if so when? Will the scans focus on network, applications or both?
• Workflow - You need to clearly define who will see the reports and what actions will be taken. For example, reports must flow to the technical people who are capable of fixing the problems with a summary report sent to management on the progress.

Tip In every vulnerability report I always include a field for "management response". This section is filled in by the people responsible for the security of the systems that were involved in the assessment and include the actions taken to remediate the problems found, or state a plan to fix the problems (e.g. "The software will be replaced with new software in two months").

• Goals - Management must be very clear on the goals of the assessment program. Some goals could include identifying vulnerabilities to ease regulatory compliance audits (such as PCI), and/or help enforce security policies and procedures. The above two goals are tied directly to measurable and quantitative items, which really helps show how security is helping the bottom line.

Be Concise

This is some of the best advice when writing reports, and something that can be challenging for technical staff who tend to focus in on technical details. For example, if you've found several systems on your network that are vulnerable to the Debian OpenSSL key weakness, you may be tempted to write a page or two describing how the vulnerability works, the details of the detection methods, and exploitation methods. However, management only cares about the risk and what they need to do to remediate the problems. Try to explain the problem in short and concise sections, breaking it down into a brief description of the problem, the effect it could have on the organization, and the remediation steps. If management has questions or requests more information, then a more thorough explanation is warranted.

Pictures Help, but...

A picture speaks a thousand words, however you must be certain to put all of those words in the right context, otherwise this can work against you. Let’s look at an example:

The above diagram, without context, leaves the interpretation up to the reader. An executive looking at this picture may think, "Wow, 94% of our vulnerabilities are low risk, we're in great shape! Why does security need so much budget?". Context is important, be certain to describe:

• Time - What time period does this graph cover? Days? Weeks? Months? Years?
• Ratings - In every report, describe what the vulnerability ratings mean to you. How should your organization treat low level alerts and what do they mean with respect to your corporate policy?
• Math - It’s important to describe what the numbers actually mean. For example, 2% of the vulnerabilities were deemed as "High", but is that relative to the vulnerabilities found or the hosts that were vulnerable? For example, if only 2% of the vulnerabilities were critical, but every system in your environment contained at least one, there is a much bigger problem than the graph is telling you.

The graph depicted here is extremely useful for measuring risk and communicating that risk to others in the organization. However, be certain to qualify the details of the data that is being represented.

Relate to Real-World Examples & Policy

It is important to relate your findings to what is happening in the real world, and your corporate policy. This could even be a situation where policy does not exist, and you can use vulnerability data as justification for creating and implementing one. For example, let’s review the following vulnerability data:

The above data comes from a Tenable research site and represents the "High" vulnerabilities detected over several months. This data was collected using the Security Center to run Nessus vulnerability scans on a daily basis. There are three alerts above that I would immediately flag and tie into a policy recommendation. The "Default community names of the SNMP Agent", "Linksys Router Default Password (admin)" and "SMB blank administrator password" are all examples of poor password policy. This is a great example of how to demonstrate to management the need for a policy, or policy enforcement, by stating that these scans were run, and found several critical vulnerabilities that showed weak or default passwords were in use. Relate this to real world events by showing how attackers are able to exploit weak passwords to gain access to critical systems on a regular basis. Then discuss defensive measures and state the resource required to implement them.

The other policy to be be addressed by this organization is the wireless controls. In this case there were two wireless access points found on the network with either default credentials or vulnerabilities ("Apple AirPort Base Station Authentication Credential Encryption Weakness"). Again, this is a great foundation to suggest policy and/or enforcement of an existing policy. There is no shortage of information of the risk of wireless networks, and you can even point to PCI for recent regulatory compliance examples that cover wireless security.

Conclusion

Tenable provides several tools for assessing and reporting on the state of security for your organization. It is up to you to take that information to management and get actionable results. There are several tactics that can contribute to your success, including making sure you have management buy-in, putting context around your results, being concise in your vulnerability reporting and tying in both real-world examples and regulatory compliance.

Resources

• Maximizing ROI on Vulnerability Management

Further Reading

• How to Win at the Compliance and Security Game (Tenable Webinar)
• Reporting Vulnerabilities in an IT Managed Environment
• Successful Security Assessment Programs
• Common Mistakes in Vulnerability and Compliance Reporting
• Differentiating new Vulnerabilities from Change