Maximizing ROI on Vulnerability

Management Programs
September 2015
Table of Contents

Vulnerability Management........................................................................................................................................................... 3
Typical Problems in Vulnerability Management Programs ............................................................................................ 3
Lack of Corporate Direction ....................................................................................................................................................................................... 3
Lack of Resources ........................................................................................................................................................................................................... 4
Ineffective Scanning ...................................................................................................................................................................................................... 4
Misleading Patch Audits .............................................................................................................................................................................................. 4
Not Using Credentials................................................................................................................................................................................................... 4
Making Vulnerability Management Pay Off ......................................................................................................................... 4
Perform Risk Analysis ................................................................................................................................................................................................... 5
Identify Assets ................................................................................................................................................................................................................. 5
Classify Data..................................................................................................................................................................................................................... 5
Define Requirements .................................................................................................................................................................................................... 5
Create a Vulnerability Program Blueprint ............................................................................................................................................................ 5

Analyze Solutions ............................................................................................................................................................................. 7

Patch Management ........................................................................................................................................................................................................ 7
Configuration Management ....................................................................................................................................................................................... 7
Incident Response .......................................................................................................................................................................................................... 7
Software Development ................................................................................................................................................................................................ 7
IT Support .......................................................................................................................................................................................................................... 8
Deploying a Vulnerability Management Solution ............................................................................................................... 8
Establish a Baseline........................................................................................................................................................................................................ 8
Tune Scanning Parameters ......................................................................................................................................................................................... 8
Scan Scheduling ............................................................................................................................................................................................................... 8
Correlate Results ............................................................................................................................................................................................................ 9
Analyze Results ............................................................................................................................................................................................................... 9
Communicate Results ................................................................................................................................................................................................... 9
Mitigation and Remediation ....................................................................................................................................................................................... 9
Develop Trending Reports .......................................................................................................................................................................................... 9
Status Metrics vs. Risk Metrics................................................................................................................................................................................10

Conclusion ........................................................................................................................................................................................ 10
About Tenable Network Security ........................................................................................................................................... 10

Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc.
2
Vulnerability Management
Vulnerabilities are exposures that can be exploited. A vulnerability can be a software defect, configuration error, presence of
malware, or basic human error. Vulnerability management programs attempt to identify and prioritize vulnerabilities:
systems are scanned, requests are made for various people to patch vulnerable systems, and therefore everything is as
secure as it can be.

Or is it? There are many reasons why some vulnerability management programs are unsuccessful, and there are many others
why some programs are successful. In this whitepaper, we’ll discuss how to make your program fall into the “extremely
successful” bucket so that you maximize the return on investment you’re spending on this very important resource.

Typical Problems in Vulnerability Management Programs

If simply having a vulnerability management program were enough to keep systems secure, we would not be hearing about
data breaches so frequently. There are many reasons such programs fail to work, but one of fundamental reasons is the lack
of a clear goal for the program. If the organization is initiating a vulnerability management program simply because they
“have to” or for unclear reasons, it’s more likely to fail.

Common reasons why vulnerability management programs fail include:

 Lack of corporate direction

 Lack of resources
 Ineffective scanning
 Misleading patch audits
 Not using credentials

Lack of Corporate Direction

The primary problem with most vulnerability management programs is that management hasn’t defined a clear program
goal. Clear goals are things like:

 Demonstrate compliance with regulations or industry standards or the fulfillment of contractual obligations
 Secure your systems and reduce risk
 Increase your security intelligence
 Apply patches to systems faster and/or on a more frequent basis

Programs without a goal are often very reactive, such as responding to an executive’s panicked email about a worm he or she
read about on a blog. A reactive approach will always be behind the curve.

Without a clear goal and direction, it’s challenging for the person responsible for the vulnerability management program to
get buy-in and cooperation with IT, business units, and executive management. Without a consensus on the approach, it is
doomed to failure. For example, a set of systems for a particular business unit may have risks interpreted in several different
ways. The business unit will attach significance to the type of data stored on the servers, while the IT department may be
focused on risks to the operating system itself. Auditors will have a different view and may consider a reported vulnerability
to be of high importance since they are not considering the significance of the data and server it resides on. A “surprise” audit
may make sense to an auditor but is horribly disruptive to IT and the business units.

These are all problems management needs to solve at the executive level. Unfortunately, the frequent cop-out is to blame
the security team for exposures when they haven’t been empowered with a process that works.

Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc.
3
Lack of Resources
Compliance regulations and guidelines do not specify the resources that must be committed to a vulnerability management
program, leaving this up to interpretation – always a bad move when budgets are involved. This leads management to focus
commitment on the purchase of tools or a service, with little regard for developing a process for its use and committing
people to supporting the process. Tools are only effective if they are used by staff trained in their use and following an
established process governing how they are used.

Ineffective Scanning
Vulnerability management is considered a cost center – a necessary process to pass compliance audits that often gets in the
way of business. This attitude results in a lukewarm support for the program so that components are weakened to the point
of minimal effectiveness.

As part of the process to cut corners on the vulnerability management program, many organizations are only concerned with
scanning for vulnerabilities and nothing more. “If it ain’t broke, I don’t want to know about it” is an expression that sums up
their attitude. This reactive attitude results in missing many issues that a more proactive approach would detect. Many
scanners have the ability to use credentials to log in to a system and get information that is not available on a network scan.
This information is crucial to ensuring systems are secured, but management does not want to know about it since it would
ruffle too many feathers. Even system administrators sometimes shy away from authenticated scans so they do not have to
analyze and mitigate as much data.

Misleading Patch Audits

Vulnerability scanners can detect missing patches, but don’t know what the official corporate policy is regarding patching.

A configuration audit can be useful to ensure that it is part of the patching process.

Using a network scan to determine if a patch was applied is misleading. Just because the patch process was initiated does not
mean the patch was applied. There are many reasons a scanner may report a system as patched when it really isn’t; lack of
disk space, buggy patches, security settings, loss of power during patch application, incorrect backup methods, systems not
being rebooted, and many other reasons can contribute to a patch that appears to be installed, but did not complete.

Another issue with patch audits involves older operating systems that no longer have patches available. If no patches are
available, scanning for nothing will reveal nothing. For organizations that find need to use manually compiled programs,
patch audits appear to paint a grim picture when in reality, the situation may not be bad at all.

Ignorance is bliss – until something happens.

Not Using Credentials

Scanners that support the use of credentials to log in to a system can provide information about configuration settings that
would not be visible from the network. For example, a credentialed scan can get information about the type of hardware that
is running. Hardware drivers have life cycles just like any other type of software, and are subject to the same security issues.
The Center for Internet Security (CIS) provides consensus benchmarks that set security hardening standards. A credentialed
scan can verify that systems are configured in accordance with a known “gold standard”. Often, configuration standards are
not established, which impacts uptime and reliability.

Making Vulnerability Management Pay Off

If you want to get the most out of your vulnerability management program, you need to take a proactive approach. This
requires planning, but once the process is in place it will be much more effective and save you time responding to compliance
requests – not to mention saving the cost of a data breach.

Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc.
4
Perform Risk Analysis
A vulnerability rated as “critical” by a scanner does not have the same importance on all systems. Throwaway systems, such
as a test box that is isolated from critical systems, can easily be reloaded and probably do not store any important data. The
same cannot be said for a system that stores a customer database.

Identify Assets
It is important to identify what you need to protect. For large organizations, this can be a huge challenge. It is often helpful to
group assets by common functions and features, such as OS platform or business function. This facilitates vulnerability
scanning and remediation by ensuring that scans are configured to probe for common weaknesses in the platform or
application. Systems may be classified in multiple asset lists. For example, a Linux web server on the DMZ may be listed
under “Linux Systems”, “Web Servers”, and “DMZ Systems”. This ensures that scans are targeted appropriately. Create asset
lists that logically group assets, such as:

 Critical business servers

 Critical infrastructure devices
 Managed servers
 User / Desktop
 Off-site (VPN, Managed)
 Production servers
 Development servers
 Test systems

Classify Data
Data leakage is a growing problem that gets considerable media attention. Organizations have a lot of data flowing through
their network and not all of it is of equal importance. Technology does not have ESP. Unless the data has been identified and
classified, the system administrator has no idea of the significance of the data. This requires some effort from the business
owner. Once the data has been classified, the network and security devices can be designed to segregate data flows and
monitor for data patterns. Some typical classifications are as follows:

 Patient Health Information

 Credit Card Data
 Client Financial Data
 Intellectual Property
 Material Non-public
 Business Critical Data

Define Requirements
What do you want from your vulnerability management program? This question is not as easy to answer as you might think.
You need to consider a number of factors such as compliance requirements, business objectives, and contractual obligations.

Define an effective process for gathering information, performing scans, and creating meaningful reports before deploying
tools.

Create a Vulnerability Program Blueprint

Create a blueprint document for the vulnerability management program before purchasing or test driving vulnerability
scanning tools. The advantage of a blueprint is that all aspects of the program will be clearly documented and vetted. A
comprehensive blueprint allows the organization to put the program through peer and executive management review to

Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc.
5
identify critical assets and build consensus on the direction of the program. This aids greatly in setting expectations for the
impact of vulnerability scanning and identifies potential risks of scanning before it becomes an issue.

A vulnerability program blueprint may contain the following items:

Area Description

Business Requirements The drivers behind the creation of the program, such as:
• Compliance
• Policy
• Contracts
• Standards
• Business Initiatives

Technical Requirements Some examples of requirements are:

• Features and functionality
• Reporting (internal vs. exportable)
• User Interface (yes, look and feel does matter)
• Costs (including ongoing operations and maintenance)
• Automatic and manual scanning capabilities

Vulnerability Research Review reported vulnerabilities and correlate them with patches. The types of
vulnerabilities reported can determine the course of action taken to remediate the
issues.

Scanning and Reporting Process Develop a comprehensive process to do the following:

• Information gathering for scans
• Scheduling and performance of scans
• Conversion of scan reports to risk assessment reports
• Delivery of reports to business owners
• Establishment of an SLA for remediation and mitigation
• External reporting (e.g., customers)

Administration and Operations Large IT organizations typically require a detailed list of what is required of them to
Requirements manage the devices. Among the requirements are:
• Network
• System
• Data Center
• Support

Change Management Some companies require a change request to run a scan.

Roles and Responsibilities Clearly identify who is responsible for what.

Audit Verify technology solutions are being operated as required.

Budget Equipment, software, personnel – tell them how many hours are required for
installation and ongoing monthly support.

Service Level Agreements (SLAs) Scanning, remediation, mitigation timelines.

Metrics Risk metrics show many vulnerable applications you have, the level of vulnerability,
and the remediation status. Status metrics show how far the program has spread
through the company.

Resources Process diagrams, descriptions of reports, etc.

Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc.
6
Analyze Solutions
Be objective in your analysis of possible solutions. They all have strengths and weaknesses. Most important is to not try to fit
your program to a specific tool. Find a solution that works with your program and processes.

Since there are multiple vulnerability management solution options, perform a “bake-off” between qualified parties to better
judge their capabilities. Some of your evaluation criteria could include:

 Is it supported on/can it scan multiple platforms?

 How well does it scale?
 Do the features align with technical and business requirements?
 What are the costs (both one time and recurring)?
 What is the long-term viability of the product?
 What is the update process?
 What is the learning curve?
 What could it break?
 How effective and flexible is the reporting?
 Who else uses it?

Do not just look at the short-term costs. Some solutions may be a bit more expensive up front, but are more inexpensive over
time. In addition, look for solutions that you can leverage for other areas of the organization. For example, can the
vulnerability management solution integrate with your patch management solution? Go beyond just looking for
vulnerabilities.

Areas where integration with the vulnerability management program is helpful include:

Patch Management
Identify the priority of deploying patches during a normal schedule or in an emergency based on the threat level defined in
the vulnerability research part of the program. Use the tools to provide verification that patches have been fully applied to
the systems they are supposed to be applied to.

Configuration Management
Establish “gold” standards and then perform credentialed audits against those standards. Make sure they are your
standards! Use the vulnerability management tools to provide independent verification of any patches or security issues and
adherence to configuration standards in accordance with an established security and configuration management plan.

Incident Response
Monitor networks for potential security incidents. Correlate events over time to detect anomalies that can indicate a
pending attack or the presence of an attacker who already has a foothold in the door.

A Security Incident and Event Management (SIEM) system simplifies incident reporting by gathering IDS and NetFlow data,
operating system logs, and many other disparate pieces of information into one place.

Organizations that have an effective vulnerability management program can quickly provide a global picture of system
activity to those responding to an incident.

Software Development
In organizations that develop applications, it is typical to find the same types of vulnerabilities across many application
segments, begging the following questions:

Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc.
7
  Why do they keep occurring?
 Who is responsible for detecting and preventing?
 What steps can be taken to change programming behavior to reduce vulnerabilities in applications?

Integrate scanning into the Software Development Life Cycle (SDLC) (source code audits, vulnerability scans of development
builds) during development. This will help reduce the number of QA cycles and allow developers to fix problems earlier.
Detecting vulnerabilities early in the development cycle saves costly efforts to mitigate a problem after the software has
been released.

Organizations that create Security Application Coding standards and train their developers on secure coding practices can
use the vulnerability scan metrics to show trends in vulnerabilities to measure the effectiveness of the program.

IT Support
A nice side effect of vulnerability scanning is that it can help identify bugs or problems in the network, which aids system and
network administrators in troubleshooting problems. A passive scanner can identify new devices on the network that
otherwise may go unnoticed, except for a sudden spike in network traffic. A close relationship between the IT support and IT
security teams can greatly improve efficiency.

Deploying a Vulnerability Management Solution

Once you’ve identified your vulnerability management goals, avoided common problems, designed your blueprint, and
selected the best technology solution for your organization, it’s time to deploy it.

Here are some measures that will help you maximize the return on the investment you’ve made in a solution:

Establish a Baseline
How will you know if you’re improving if you don’t know where you started? Establish and share a baseline vulnerability
analysis report at the start of the program. Don’t worry if it paints a dismal picture of the organization’s security posture –
you can only go up from there. The baseline provides the foundation for demonstrating progress.

Tune Scanning Parameters

Any vulnerability scan – manual or automated – needs to be tuned. Tuning scans makes them more efficient, faster to
accomplish, and generates more accurate results (less false positives). Some points to get the most from your scanning:

 Tune the scan to the target: a thousand database checks against a web server with no database are about as
effective as banging your head against the wall.
 Figure out false positives: one hundred findings sounds bad, until you figure out only 30% are valid.
 Audit companies and scanners assign risk levels to vulnerabilities based on their standards/experience. Weigh the
risks reported, adjust according to your organization, and then act on them.

Scan Scheduling
Avoid ad hoc scanning as it is typically very disruptive and difficult to manage. Set a schedule for scanning systems and stick
to it. Work with your IT organization so that scans are not disruptive to operations. Ad hoc scans should generally be used
only to test administrative response to an unplanned test. However, unscheduled tests often lead to bad things, including
resentful administrators, unnecessary escalation, and law enforcement are a few of your least favorite things.

Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc.
8
Correlate Results
Large organizations often do not communicate well across departments or divisions. This creates redundancy in software,
personnel, scanning, and remediation. Sharing information, at all levels and processes, benefits everyone. Sharing includes,
but is not limited to:

 Solutions in place (e.g., AV, FW, IDS, IPS, SIEM)

 Players involved (e.g., management, auditors)
 Schedules for testing
 Scanning results
 Logs (daily, during testing, correlated, and monitored)
 Network data (you are sniffing your network, right?)

Analyze Results
Use standard report templates for the vulnerability reports, detailed risk reports and summary risk reports. Standard
templates provide a mechanism for consistent reporting of vulnerabilities and risks. They help establish a level of efficiency
in understanding risks.

Anyone can read a vulnerability report, not everyone can understand one.

 Analyze and research the results! Many scanners provide a brief description and suggested remediation of the
detected vulnerability, but don’t take this at face value. Remember, they are giving the “best” recommendation for
the masses, not the recommendation that may be most suitable for your company.
 Follow-up on the issue. Did it really get patched? Or did it get addressed through other means without fixing the
underlying issue?
 Create risk reports based on vulnerability reports and nature of the data.

Communicate Results
Once all of the reports have been created, make sure they are communicated to the appropriate parties. More importantly,
ensure that they are drafted in a format that is readable to the intended audience. Most importantly, ensure that they will be
read by the audience. Length and technical scope must be tailored for all levels of the organization. Executive management
does not understand what a “fingerd” vulnerability is or its impact to the organization. Make sure the report is worded in
terms they can understand.

Mitigation and Remediation

Share risk reports with business owners and gain consensus on remediation and mitigation efforts. Establish Service Level
Agreements with business owners and enforce them. Gain buy-in from senior management to meet these objectives.
Remember, finding issues are not “gotchas”. Lay out an objective report describing the risk if these vulnerabilities are left
unmitigated. If management is held accountable and understands the facts, they are more likely to make the right decisions.
Developers are interested in technical details. Business owners are interested in the risk to their livelihood.

Develop Trending Reports

Define status and risk metrics to show the progress of the program and the amount of risk to the organization. Ensure that
everyone involved in the process is aware of progress, not just executives.

Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc.
9
Status Metrics vs. Risk Metrics
Status metrics demonstrate the state of the program and are organized in the following categories:

 Information gathering
 Vulnerability scanning
 Remediation and mitigation efforts

Risk based metrics demonstrate the overall posture of the risk to applications and are organized as follows:

 High, medium, and low vulnerabilities

 Critical, high, medium, and low risks
 Compliance issue
 Score between vulnerability and criticality of the data

There are several risk scoring systems available (e.g., Microsoft STRIDE and DREAD rating systems, CVSS2, etc.) that can be
used as a template. Develop a consistent scoring system that is in line with business objectives and stick to it. This helps
demonstrate improvements that save money and demonstrates ROI.

Conclusion
Compliance requirements can provide useful checklists to ensure you’ve addressed specific security concerns, but it is
dangerous to base a vulnerability management program solely on a checklist. A proactive vulnerability management program
that addresses specific business needs of the organization will do far more to provide real value to the organization. Planning
requires effort, but poor planning results in wasted resources.

About Tenable Network Security

Tenable Network Security provides continuous network monitoring to identify vulnerabilities, reduce risk, and ensure
compliance. Our family of products includes SecurityCenter Continuous View™, which provides the most comprehensive and
®
integrated view of network health, and Nessus , the global standard in detecting and assessing network data. Tenable is
relied upon by many of the world’s largest corporations, not-for-profit organizations and public sector agencies, including the
entire U.S. Department of Defense. For more information, visit tenable.com.

Copyright © 2015. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc.
10