Get Instant Access
to This Blueprint

Security icon

Implement Risk-Based Vulnerability Management

Get off the patching merry-go-round and start mitigating risk!

  • Vulnerability scanners, industry alerts, and penetration tests are revealing more and more vulnerabilities, and it is unclear how to manage them.
  • Organizations are struggling to prioritize the vulnerabilities for remediation, as there are many factors to consider, including the threat of the vulnerability and the potential remediation option itself.

Our Advice

Critical Insight

  • Patches are often seen as the only answer to vulnerabilities, but these are not always the most suitable solution.
  • Vulnerability management does not equal patch management. It includes identifying and assessing the risk of the vulnerability, and then selecting a remediation option which goes beyond just patching alone.
  • There is more than one way to tackle the problem. Leverage your existing security controls in order to protect the organization.

Impact and Result

  • At the conclusion of this blueprint, you will have created a full vulnerability management program that will allow you to take a risk-based approach to vulnerability remediation.
  • Assessing a vulnerability’s risk will enable you to properly determine the true urgency of a vulnerability within the context of your organization; this ensures you are not just blindly following what the tool is reporting.
  • The risk-based approach will allow you prioritize your discovered vulnerabilities and take immediate action on critical and high vulnerabilities, while allowing your standard remediation cycle to address the medium to low vulnerabilities.
  • With your program defined and developed, you now need to configure your vulnerability scanning tool, or acquire one if you don’t already have a tool in place.
  • Lastly, while vulnerability management will help address your systems and applications, how do you know if you are secure from external malicious actors? Penetration testing will offer visibility, allowing you to plug those holes and attain an environment with a smaller risk surface.

Implement Risk-Based Vulnerability Management Research & Tools

Start here – read the Executive Brief

Read our concise Executive Brief to find out why you should design and implement a vulnerability management program, review Info-Tech’s methodology, and understand the four ways we can support you in completing this project.

1. Identify vulnerability sources

Begin the project by creating a vulnerability management team and determine how vulnerabilities will be identified through scanners, penetration tests, third-party sources, and incidents.

2. Triage vulnerabilities and assign priorities

Determine how vulnerabilities will be triaged and evaluated based on intrinsic qualities and how they may compromise business functions and data sensitivity.

3. Remediate vulnerabilities

Address the vulnerabilities based on their level of risk. Patching isn't the only risk mitigation action; some systems simply cannot be patched, but other options are available. Reduce the risk down to medium/low levels and engage your regular operational processes to deal with the latter.

4. Measure and formalize

Evolve the program continually by developing metrics and formalizing a policy.


Member Testimonials

After each Info-Tech experience, we ask our members to quantify the real-time savings, monetary impact, and project improvements our research helped them achieve. See our top member experiences for this blueprint and what our clients have to say.

9.0/10


Overall Impact

$229,314


Average $ Saved

44


Average Days Saved

Client

Experience

Impact

$ Saved

Days Saved

Farm Credit Southeast Missouri

Guided Implementation

9/10

$2,267

2

Virginia Department of Taxation

Workshop

9/10

$2,393

N/A

Marshall University

Guided Implementation

9/10

$12,599

32

British Columbia Institute of Technology

Guided Implementation

9/10

$900K

110

Franciscan Missionaries of Our Lady Health System

Workshop

9/10

N/A

32

Statistics New Zealand

Guided Implementation

10/10

$8,679

10

State of Michigan

Workshop

7/10

$12,399

10

South Carolina State Ports Authority

Guided Implementation

10/10

$60,319

20

Legal Services Corporation

Guided Implementation

9/10

N/A

N/A

Trihealth

Guided Implementation

9/10

N/A

N/A

STERIS Corporation

Guided Implementation

8/10

$62,999

50

Investors Bank

Guided Implementation

10/10

N/A

N/A

Delta Dental Plan Of Colorado

Guided Implementation

10/10

N/A

29

Trinidad and Tobago Unit Trust Corporation

Guided Implementation

8/10

N/A

N/A

Ocean Spray Cranberries

Guided Implementation

8/10

N/A

N/A


Workshop: Implement Risk-Based Vulnerability Management

Workshops offer an easy way to accelerate your project. If you are unable to do the project yourself, and a Guided Implementation isn't enough, we offer low-cost delivery of our project workshops. We take you through every phase of your project and ensure that you have a roadmap in place to complete your project successfully.

Module 1: Identify Vulnerability Sources

The Purpose

  • Establish a common understanding of vulnerability management, and define the roles, scope, and information sources of vulnerability detection.

Key Benefits Achieved

  • Attain visibility on all of the vulnerability information sources, and a common understanding of vulnerability management and its scope.

Activities

Outputs

1.1

Define the scope & boundary of your organization’s security program.

  • Defined scope and boundaries of the IT security program
1.2

Assign responsibility for vulnerability identification and remediation.

  • Roles and responsibilities defined for member groups
1.3

Develop a monitoring and review process of third-party vulnerability sources.

  • Process for review of third-party vulnerability sources
1.4

Review incident management and vulnerability management

  • Alignment of vulnerability management program with existing incident management processes

Module 2: Triage and Prioritize

The Purpose

  • We will examine the elements that you will use to triage and analyze vulnerabilities, prioritizing using a risk-based approach and prepare for remediation options.

Key Benefits Achieved

  • A consistent, documented process for the evaluation of vulnerabilities in your environment.

Activities

Outputs

2.1

Evaluate your identified vulnerabilities.

  • Adjusted workflow to reflect your current processes
2.2

Determine high-level business criticality.

  • List of business operations and their criticality and impact to the business
2.3

Determine your high-level data classifications.

  • Adjusted workflow to reflect your current processes
2.4

Document your defense-in-depth controls.

  • List of defense-in-depth controls
2.5

Build a classification scheme to consistently assess impact.

  • Vulnerability Management Risk Assessment tool formatted to your organization
2.6

Build a classification scheme to consistently assess likelihood.

  • Vulnerability Management Risk Assessment tool formatted to your organization

Module 3: Remediate Vulnerabilities

The Purpose

  • Identifying potential remediation options.
  • Developing criteria for each option in regard to when to use and when to avoid.
  • Establishing exception procedure for testing and remediation.
  • Documenting the implementation of remediation and verification.

Key Benefits Achieved

  • Identifying and selecting the remediation option to be used
  • Determining what to do when a patch or update is not available
  • Scheduling and executing the remediation activity
  • Planning continuous improvement

Activities

Outputs

3.1

Develop risk and remediation action.

  • List of remediation options sorted into “when to use” and “when to avoid” lists

Module 4: Measure and Formalize

The Purpose

  • You will determine what ought to be measured to track the success of your vulnerability management program.
  • If you lack a scanning tool this phase will help you determine tool selection.
  • Lastly, penetration testing is a good next step to consider once you have your vulnerability management program well underway.

Key Benefits Achieved

  • Outline of metrics that you can then configure your vulnerability scanning tool to report on.
  • Development of an inaugural policy covering vulnerability management.
  • The provisions needed for you to create and deploy an RFP for a vulnerability management tool.
  • An understanding of penetration testing, and guidance on how to get started if there is interest to do so.

Activities

Outputs

4.1

Measure your program with metrics, KPIs, and CSFs.

  • List of relevant metrics to track, and the KPIs, CSFs, and business goals for.
4.2

Update the vulnerability management policy.

  • Completed Vulnerability Management Policy
4.3

Create an RFP for vulnerability scanning tools.

  • Completed Request for Proposal (RFP) document that can be distributed to vendor proponents
4.4

Create an RFP for penetration tests.

  • Completed Request for Proposal (RFP) document that can be distributed to vendor proponents

Implement Risk-Based Vulnerability Management

Get off the patching merry-go-round and start mitigating risk!

Table of Contents

4 Analyst Perspective

5 Executive Summary

6 Common Obstacles

8 Risk-based approach to vulnerability management

16 Step 1.1: Vulnerability management defined

24 Step 1.2: Defining scope and roles

34 Step 1.3: Cloud considerations for vulnerability management

33 Step 1.4: Vulnerability detection

46 Step 2.1: Triage vulnerabilities

51 Step 2.2: Determine high-level business criticality

56 Step 2.3: Consider current security posture

61 Step 2.4: Risk assessment of vulnerabilities

71 Step 3.1: Assessing remediation options

Table of Contents

80 Step 3.2: Scheduling and executing remediation

85 Step 3.3: Continuous improvement

89 Step 4.1: Metrics, KPIs, and CSFs

94 Step 4.2: Vulnerability management policy

97 Step 4.3: Select & implement a scanning tool

107 Step 4.4: Penetration testing

118 Summary of accomplishment

119 Additional Support

120 Bibliography

Analyst Perspective

Vulnerabilities will always be present. Know the unknowns!

In this age of discovery, technology changes at such a rapid pace. New things are discovered, both in new technology and in old. The pace of change can often be very confusing as to where to start and what to do.

The ever-changing nature of technology means that vulnerabilities will always be present. Taking measures to address these completely will consume all your department’s time and resources. That, and your efforts will quickly become stale as new vulnerabilities are uncovered. Besides, what about the systems that simply can’t be patched? The key is to understand the vulnerabilities and the levels of risk they pose to your organization, to prioritize effectively and to look beyond patching.

A risk-based approach to vulnerability management will ensure you are prioritizing appropriately and protecting the business. Reduce the risk surface!

Vulnerability management is more than just systems and application patching. It is a full process that includes patching, compensating controls, segmentation, segregation, and heightened diligence in security monitoring.

Jimmy Tom, Research Advisor – Security, Privacy, Risk, and Compliance, Info-Tech Research Group.Jimmy Tom
Research Advisor – Security, Privacy, Risk, and Compliance
Info-Tech Research Group

Executive Summary

Your Challenge

Vulnerability scanners, industry alerts, and penetration tests are revealing more and more vulnerabilities, and it is unclear how to manage them.

Organizations are struggling to prioritize the vulnerabilities for remediation, as there are many factors to consider, including the threat of the vulnerability and the potential remediation option.

Common Obstacles

Patches are often seen as the answer to vulnerabilities, but these are not always the most suitable solution.

Some systems deemed vulnerable simply cannot be patched or easily replaced.

Companies are unaware of the risk implications that come from leaving the vulnerability open and from the remediation option itself.

Info-Tech’s Approach

Design and implement a vulnerability management program that identifies, prioritizes, and remediates vulnerabilities.

Understand what needs to be considered when implementing remediation options, including patches, configuration changes, and defense-in-depth controls.

Build a process that is easy to understand and allows vulnerabilities to be remediated proactively, instead of in an ad hoc fashion.

Info-Tech Insight

Vulnerability management does not always equal patch management. There is more than one way to tackle the problem, particularly if a system cannot be easily patched or replaced. If a vulnerability cannot be completely remediated, steps to reduce the risk to a tolerable level must be taken.

Common obstacles

These barriers make vulnerability management difficult to address for many organizations:
  • The value of vulnerability management is not well articulated in many organizations. As a result, investment in vulnerability scanning technology is often insufficient.
  • Many organizations feel that a “patch everything” approach is the most effective path.
  • Vulnerability management is commonly misunderstood as being a process that only supports patch management.
  • There is often misalignment between SecOps and ITOps in remediation action and priority, affecting the timeliness of remediation.
CVSS Score Distribution From the National Vulnerability Database: Pie Charts presenting the CVSS Core Distribution for the National Vulnerability Database. The left circle represents 'V3' and the right 'V2', where V3 has an extra option for 'Critical', above 'High', 'Medium', and 'Low', and V2 does not.
(Source: NIST National Vulnerability Database Dashboard)

Leverage risk to sort, triage, and prioritize vulnerabilities

Reduce your risk surface to avoid cost to your business; everything else is table stakes.

Reduce the critical and high vulnerabilities below the risk threshold and operationalize the remediation of medium/low vulnerabilities by following your effective vulnerability management program cycles.

Identify vulnerability sources

An inventory of your scanning tool and vulnerability threat intelligence data sources will help you determine a viable strategy for addressing vulnerabilities. Defining roles and responsibilities ahead of time will ensure you are not left scrambling when dealing with vulnerabilities.

Triage and prioritize

Bring the vulnerabilities into context by assessing vulnerabilities based on your security posture and mechanisms and not just what your data sources report. This will allow you to gauge the true urgency of the vulnerabilities based on risk and determine an effective mitigation plan.

Remediate vulnerabilities

Address the vulnerabilities based on their level of risk. Patching isn't the only risk mitigation action; some systems simply cannot be patched, but other options are available.

Reduce the risk down to medium/low levels and engage your regular operational processes to deal with the latter.

Measure and formalize

Upon implementation of the program, measure with metrics to ensure that the program is successful. Improve the program with each iteration of vulnerability mitigation to ensure continuous improvement.

Tactical Insight 1

All actions to address vulnerabilities should be based on risk and the organization’s established risk tolerance.

Tactical Insight 2

Reduce the risk surface down below the risk threshold.

The industry has shifted to a risk-based approach

Traditional vulnerability management is no longer viable.

“For those of us in the vulnerability management space, ensuring that money, resources, and time are strategically spent is both imperative and difficult. Resources are dwindling fast, but the vulnerability problem sure isn’t.” (Kenna Security)

“Using vulnerability scanners to identify unpatched software is no longer enough. Keeping devices, networks, and digital assets safe takes a much broader, risk-based vulnerability management strategy – one that includes vulnerability assessment and mitigation actions that touch the entire ecosystem.” (Balbix)

“Unlike legacy vulnerability management, risk-based vulnerability management goes beyond just discovering vulnerabilities. It helps you understand vulnerability risks with threat context and insight into potential business impact.” (Tenable)

“A common mistake when prioritizing patching is equating a vulnerability’s Common Vulnerability Scoring System (CVSS) score with risk. Although CVSS scores can provide useful insight into the anatomy of a vulnerability and how it might behave if weaponized, they are standardized and thus don’t reflect either of the highly situational variables — namely, weaponization likelihood and potential impact — that factor into the risk the vulnerability poses to an organization.” (SecurityWeek)

Why a take risk-based approach?

Vulnerabilities, by the numbers

60% — In 2019, 60% of breaches were due to unpatched vulnerabilities.

74% — In the same survey, 74% of survey responses said they cannot take down critical applications and systems to patch them quickly. (Source: SecurityBoulevard, 2019)

Info-Tech Insight

Taking a risk-based approach will allow you to focus on mitigating risk, rather than “just patching” your environment.

The average cost of a breach in 2020 is $3.86 million, and “…the price tag was much less for mature companies and industries and far higher for firms that had lackluster security automation and incident response processes.” (Dark Reading)

Vulnerability Management

A risk-based approach

Reduce the risk surface to avoid cost to your business, everything else is table stakes

Logo for Info-Tech.
Logo for #iTRG.

1

Identify

4

Address

Mitigate the risk surface by reducing the time across the phases ›Mitigate the risk by implementing:
  • patch systems & apps
  • compensating controls
  • systems and apps hardening
  • systems segregation
Chart presenting an example of 'Risk Surface' with the axes 'Risk Level' and 'Time' with lines created by individual risks. The highlighted line begins in 'Critical' and eventually drops to low. The area between the line and your organization's risk tolerance is labelled 'Risk Surface'.

Objective: reduce risk surface by reducing time to address

Your organization's risk tolerance threshold

Identify vulnerability management scanning tools & external threat intel sources (Mitre CVE, US-CERT, vendor alerts, etc.)Vulnerability information feeds:
  • scanning tool
  • external threat intel
  • internal threat intel

2

Analyze

Assign actual risk (impact x urgency) to the organization based on current security posture

Triage based on risk ›

Your organization's risk tolerance threshold

Risk tolerance threshold map with axes 'Impact' and 'Likelihood'. High levels of one and low levels of the other, or medium levels of both, is 'Medium', High level of one and Medium levels of the other is 'High', and High levels of both is 'Critical'.

3

Assess

Plan risk mitigation strategy ›Consider:
  • risk tolerance
  • compensating controls
  • business impact

Info-Tech’s vulnerability management methodology

Focus on developing the most efficient processes.

Vulnerability management isn’t “old school.”

The vulnerability management market is relatively mature; however, vulnerability management remains a very relevant and challenging topic.

Security practitioners are inundated with the advice they need to prioritize their vulnerabilities. Every vulnerability scanning vendor will proclaim their ability to prioritize the identified vulnerabilities.

Third-party prioritization methodology can’t be effectively applied across all organizations. Each organization is too unique with different constraints. No tool or service can account for these variables.

Equation to find 'Vulnerability Priority'.

When patching is not possible, other options exist: configuration changes (hardening), defense-in-depth, compensating controls, and even elevated security monitoring are possible options.

Info-Tech Insight

Vulnerability management is not only patch management. Patching is only one aspect.

Blueprint deliverables

Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals:

Key deliverable:

Vulnerability Management SOP

The Standard operating procedure (SOP) will comprise the end-to-end description of the program: roles & responsibilities, data flow, and expected outcomes of the program.

Sample of the key deliverable, Vulnerability Management SOP.
Vulnerability Management Policy

Template for your vulnerability management policy.

Sample of the Vulnerability Management Policy blueprint.Vulnerability Tracking Tool

This tool offers a template to track vulnerabilities and how they are remedied.

Sample of the Vulnerability Tracking Tool blueprint.
Vulnerability Scanning RFP Template

Request for proposal template for the selection of a vulnerability scanning tool.

Sample of the Vulnerability Scanning RFP Template blueprint.Vulnerability Risk Assessment Tool

Methodology to assess vulnerability risk by determining impact and likelihood.

Sample of the Vulnerability Risk Assessment Tool blueprint.

Blueprint benefits

IT Benefits

  • A standardized, consistent methodology to assess, prioritize, and remediate vulnerabilities.
  • A risk-based approach that aligns with what’s important to the business.
  • A way of dealing with the high volumes of vulnerabilities that your scanning tool is reporting.
  • Identification of “where to start” in terms of vulnerability management.
  • Ability to not lose yourself in the patch madness but rather take a sound approach to scheduling and prioritizing patches and updates.
  • Knowledge of what to do when patching is simply not possible or feasible.

Business Benefits

  • Alignment with IT in ensuring that business processes are only interrupted when absolutely necessary while maintaining a regular cadence of vulnerability remediation.
  • A consistent program that the business can plan around and predict when interruptions will occur.
  • IT’s new approach being integrated with existing IT operations processes, offering the most efficient yet expedient method of dealing with vulnerabilities.

Info-Tech’s process can save significant financial resources

PhaseMeasured Value
Phase 1: Identify vulnerability sources
    Define the process, scope, roles, vulnerability sources, and current state
    • Consultant at $100 an hour for 16 hours = $1,600
Phase 2: Triage vulnerabilities and assign urgencies
    Establish triaging and vulnerability evaluation process
    • Consultant at $100 an hour for 16 hours = $1,600
    Determine high-level business criticality and data classifications
    • Consultant at $100 an hour for 40 hours = $4,000
    Assign urgencies to vulnerabilities
    • Consultant at $100 an hour for 8 hours = $800
Phase 3: Remediate vulnerabilities
    Prepare documentation for the vulnerability process
    • Consultant at $100 an hour for 8 hours = $800
    Establish defense-in-depth modelling
    • Consultant at $100 an hour for 24 hours = $2,400
    Identify remediation options and establish criteria for use
    • Consultant at $100 an hour for 40 hours = $4,000
    Formalize backup and testing procedures, including exceptions
    • Consultant at $100 an hour for 8 hours = $800
    Remediate vulnerabilities and verify
    • Consultant at $100 an hour for 24 hours = $2,400
Phase 4: Continually improve the vulnerability management process
    Establish a metrics program for vulnerability management
    • Consultant at $100 an hour for 16 hours = $1,600
    Update vulnerability management policy
    • Consultant at $100 an hour for 8 hours = $800
    Develop a vulnerability scanning tool RFP
    • Consultant at $100 an hour for 40 hours = $4,000
    Develop a penetration test RFP
    • Consultant at $100 an hour for 40 hours = $4,000
Potential financial savings from using Info-Tech resourcesPhase 1 ($1,600) + Phase 2 ($6,400) + Phase 3 ($10,400) + Phase 4 ($10,400) = $28,800

Guided Implementation

A Guided Implementation (GI) is a series of calls with an Info-Tech analyst to help implement our best practices in your organization.

A typical GI is between 8 to 12 calls over the course of 4 to 6 months.

What does a typical GI on this topic look like?

Phase 1

Phase 2

Phase 3

Phase 4

Call #1: Scope requirements, objectives, and your specific challenges.

Call #2: Discuss current state and vulnerability sources.

Call #3: Identify triage methods and business criticality.

Call #4:Review current defense-in-depth and discuss risk assessment.

Call #5: Discuss remediation options and scheduling.

Call #6: Review release and change management and continuous improvement.

Call #7: Identify metrics, KPIs, and CSFs.

Call #8: Review vulnerability management policy.

Workshop Overview

Contact your account representative for more information.
workshops@infotech.com 1-888-670-8889

Day 1Day 2Day 3Day 4Day 5
Activities
Identify vulnerability sources

1.1 What is vulnerability management?

1.2 Define scope and roles

1.3 Cloud considerations for vulnerability management

1.4 Vulnerability detection

Triage and prioritize

2.1 Triage vulnerabilities

2.2 Determine high-level business criticality

2.3 Consider current security posture

2.4 Risk assessment of vulnerabilities

Remediate vulnerabilities

3.1 Assess remediation options

3.2 Schedule and execute remediation

3.3 Drive continuous improvement

Measure and formalize

4.1 Metrics, KPIs & CSFs

4.2 Vulnerability Management Policy

4.3 Select & implement a scanning tool

4.4 Penetration testing

Next Steps and Wrap-Up (offsite)

5.1 Complete in-progress deliverables from previous four days

5.2 Set up review time for workshop deliverables and to discuss next steps

Deliverables
  1. Scope and boundary definition of vulnerability management program
  2. Responsibility assignment for vulnerability identification and remediation
  3. Monitoring and review process of third-party vulnerability sources
  4. Incident management and vulnerability convergence
  1. Methodology for evaluating identified vulnerabilities
  2. Identification of high-level business criticality
  3. Defined high-level data classifications
  4. Documented defense-in-depth controls
  5. Risk assessment criteria for impact and likelihood
  1. Documented risk assessment methodology and remediation options
  1. Defined metrics, key performance indicators (KPIs), and critical success factors (CSFs)
  2. Initial draft of vulnerability management policy
  3. Scanning tool selection criteria
  4. Introduction to penetration testing
  1. Completed vulnerability management standard operating procedure
  2. Defined vulnerability management risk assessment criteria
  3. Vulnerability management policy draft

Implement Risk-Based Vulnerability Management

Phase 1

Identify Vulnerability Sources

Phase 1

1.1 What is vulnerability management?
1.2 Define scope and roles
1.3 Cloud considerations for vulnerability management
1.4 Vulnerability detection

Phase 2

2.1 Triage vulnerabilities
2.2 Determine high-level business criticality
2.3 Consider current security posture
2.4 Risk assessment of vulnerabilities

Phase 3

3.1 Assessing remediation options
3.2 Scheduling and executing remediation
3.3 Continuous improvement

Phase 4

4.1 Metrics, KPIs & CSFs
4.2 Vulnerability management policy
4.3 Select and implement a scanning tool
4.4 Penetration testing

This phase will walk you through the following activities:

Establish a common understanding of vulnerability management, define the roles, scope, and information sources of vulnerability detection.

This phase involves the following participants:

  • Security operations team
  • IT Security Manager
  • IT Director
  • CISO

Step 1.1

Vulnerability Management Defined

Activities

None for this section

This step will walk you through the following activities:

Establish a common understanding of vulnerability management and its place in the IT organization.

This step involves the following participants:

  • Security operations team
  • IT Security Manager
  • IT Director
  • CISO

Outcomes of this step

Foundational knowledge of vulnerability management in your organization.

Identify vulnerability sources
Step 1.1Step 1.2Step 1.3Step 1.4

What is vulnerability management?

It’s more than just patching.

  • Vulnerability management is the regular and ongoing practice of scanning an operating environment to uncover vulnerabilities. These vulnerabilities can be outdated applications, unpatched operating systems and software, open ports, obsolete hardware, or any combination of these.
  • The scanning and detection of vulnerabilities is the first step. Planning and executing of remediation is next, along with the approach, prioritized sequence of events, and timing.
  • A vendor-supplied software patch or firmware update is often the easy answer, however, this is not always a viable solution. What if you can’t patch in a timely fashion? What if patching is not possible as it will break the application and bring down operations? What if no patch exists due to the age of the application or operating platform?

“Most organizations do not have a formal process for vulnerability management.” (Morey Haber, VP of Technology, BeyondTrust, 2016)

Effective vulnerability management

It’s not easy, but it’s much harder without a process in place.
  • Effective vulnerability management requires a formal process for organizations to follow; without one, vulnerabilities are dealt with in an ad hoc fashion.
  • Patching isn’t the only solution, but it’s the one that often draws focus.
  • Responsibilities for the different aspects of vulnerability management are often unclear, such as for testing, remediation, and implementation.
  • Identifying new threats without proper vulnerability scanning tools can be a near-impossible task.
  • Determining which vulnerabilities are most urgent can be an inconsistent process, increasing the organizational risk.
  • Measuring the effectiveness of your vulnerability remediation activities can help you better manage resources in SecOps and ITOps. Your staff will be spending the appropriate effort on vulnerabilities that warrant that level of attention.

You’re not just doing this for yourself. It’s also for your auditors.

Many compliance and regulatory obligations require organizations to have thorough documentation of their vulnerability management practices.

Vulnerability management revolves around your asset security services

Diagram with 'Asset Security Services' at the center. On either side are 'Network Security Services' and 'Identity Security Services', all three of which flow up into 'Security Analytics | Security Incident Response', and all four share a symbiotic flow with 'Management' below and contribute to 'Mega Trend Mapping' above. Management is supported by 'Governance'.Vulnerabilities can be found primarily within your assets but also connect to your information risk management. These must be effectively managed as part of a holistic security program.

Without management, vulnerabilities left unattended can be easy for attackers to exploit. It becomes difficult to identify the correct remediation option to mitigate against the vulnerabilities.

Vulnerability management works in tandem with SecOps and ITOps

Vulnerability Management Process Inputs/Outputs:
'Vulnerability Management (Process and Tool)' outputs are 'Incident Management', 'Release Management', 'Change Management', 'IT Asset Management', 'Application Security Testing', 'Threat Intelligence', and 'Security Risk Management'; inputs are 'Vulnerability Disclosure', 'Threat Intelligence', and 'Security Risk Management'.

Arrows denote direction of information feed

Vulnerability management serves as the input into a number of processes for remediation, including:
  • Incident management, to deal with issues
  • Release management, for patch management
  • Change management, for change control
  • IT asset management, to track version information, e.g. for patching
  • Application security testing, for the verification of vulnerabilities

A two-way data flow exists between vulnerability management and:

  • Security risk management, for the overall risk posture of the organization
  • Threat intelligence, as vulnerability management reveals only one of several threat vectors

For additional information please refer to Info-Tech’s research for each area:

  • Vulnerability management can leverage your existing processes to gain an operational element for the program.
  • As you strive to mature each of the processes on their own, vulnerability management will benefit accordingly.
  • Review our research for each of these areas and speak to one of our analysts if you wish to improve any of the listed processes.

Info-Tech’s Information Security Program Framework

Vulnerability management is a component of the Infrastructure Security section of Security Management

Information Security Framework with Level 1 and Level 2 capabilities in two main sections, 'Management' and 'Governance'. Level 2 capabilities are grouped within Level 1 capabilities.For more information, review our Build an Information Security Strategy blueprint, or speak to one of our analysts.

Info-Tech Insight

Vulnerability management is but one piece of the information security puzzle. Ensure that you have all the pieces!

Case Study

Logo for Cimpress.
INDUSTRY: Manufacturing
SOURCE: Cimpress, 2016

One organization is seeing immediate benefits by formalizing its vulnerability management program.

Challenge

Cimpress was dealing with many challenges in regards to vulnerability management. Vulnerability scanning tools were used, but the reports that were generated often gave multiple vulnerabilities that were seen as critical or high and required many resources to help address them. Scanning was done primarily in an attempt to adhere to PCI compliance rather than to effectively enable security. After re-running some scans, Cimpress saw that some vulnerabilities had existed for an extended time period but were deemed acceptable.

Solution

The Director of Information Security realized that there was a need to greatly improve this current process. Guidelines and policies were formalized that communicated when scans should occur and what the expectations for remediations should be. Cimpress also built a tiered approach to prioritize vulnerabilities for remediation that is specific to Cimpress instead of relying on scanning tool reports.

Results

Cimpress found better management of the vulnerabilities within its system. There was no pushback to the adoption of the policies, and across the worldwide offices, business units have been proactively trying to understand if there are vulnerabilities. Vulnerability management has been expanded to vendors and is taken into consideration when doing any mergers and acquisitions. Cimpress continues to expand its program for vulnerability management to include application development and vulnerabilities within any existing legacy systems.

Step 1.2

Defining the scope and roles

Activities
  • 1.2.1 Define the scope and boundary of your organization’s security program
  • 1.2.2 Assign responsibility for vulnerability identification and remediation

This step will walk you through the following activities:

Define and understand the scope and boundary of the security program. For example, does it include OT? Define roles and responsibilities for vulnerability identification and remediation

This step involves the following participants:

  • Security operations team
  • IT Security Manager
  • IT Director
  • CISO

Outcomes of this step

Understand how far vulnerability management extends and what role each person in IT plays in the remediation of vulnerabilities

Identify vulnerability sources
Step 1.1Step 1.2Step 1.3Step 1.4

Determine the scope of your security program

This will help you adjust the depth and breadth of your vulnerability management program.
  • Determining the scope will help you decide how much organizational risk the vulnerability management program will oversee.
  • Scope can be defined along four aspects:
    • Data Scope – What data elements in your organization does your security program cover? How is data classified?
    • Physical Scope – What physical scope, such as geographies, does the security program cover?
    • Organizational Scope – How are business units engaged with security initiatives? Does the scope cover all subsidiary organizations?
    • IT Scope – What parts of the organization does IT cover? Does their coverage include operational technology (OT) and industrial control systems (ICS)?
Stock image of figures standing in connected circles.

1.2.1 Define the scope and boundary of your organization’s security program

60 minutes

Input: List of Data Scope, Physical Scope, Organization Scope, and IT Scope

Output: Defined scope and boundaries of the IT security program

Materials: Whiteboard/Flip Charts, Sticky Notes, Markers, Vulnerability Management SOP Template

Participants: Business stakeholders, IT leaders, Security team members

  1. On a whiteboard, write the headers: Data Scope, Physical Scope, Organizational Scope, and IT Scope.
  2. Give each group member a handful of sticky notes. Ask them to write down as many items as possible for the organization that could fall under one of the four scope buckets.
  3. In a group, discuss the sticky notes and the rationale for including them. Discuss your security-related locations, data, people, and technologies, and define their scope and boundaries.

The goal is to identify what your vulnerability management program is responsible for and document it.

Consider the following:

How is data being categorized and classified? How are business units engaged with security initiatives? How are IT systems connected to each other? How are physical locations functioning in terms of information security management?

Download the Vulnerability Management SOP Template

Assets are part of the scope definition

An inventory of IT assets is necessary if there is to be effective vulnerability management.

  • Organizations need an up-to-date and comprehensive asset inventory for vulnerability management. This is due to multiple reasons:
    • When vulnerabilities are announced, they will need to be compared to an inventory to determine if the organization has any relevant systems or versions.
    • It indicates where all IT assets can be found both physically and logically.
    • Asset inventories typically have owners assigned to the assets and systems whose responsibility it is to carry out remediations for vulnerabilities.
  • Furthermore, asset inventories can provide insight into where data can be found within the organization. This is extremely useful within a formal data classification program, which plays a large factor in vulnerability management.
If you need assistance building your asset inventory, review Info-Tech’s Implement Hardware Asset Management and Implement Software Asset Management blueprints.

Info-Tech Insight

Create a formal IT asset inventory before continuing with the rest of this project. Otherwise, you risk being at the mercy of a weak vulnerability management program.

Assign responsibility for vulnerability identification and remediation

Determine who is critical to effectively detecting and managing vulnerabilities.
  • Some of the remediation steps will involve members of IT management to identify the true organizational risk of a vulnerability.
  • Vulnerability remediation comes in different shapes and sizes. In addition to patching, this can include implementing compensating controls, server and application hardening, or the segregating of vulnerable systems.
    • Who carries out each of these activities? Who coordinates the activities and tracks them to ensure completion?
  • The people involved may be members outside of the security team, such as members from IT operations, infrastructure, and applications. The specific roles that each of these groups play should be clearly identified.
Stock image of many connected profile photos in a cloud network.

1.2.2 Assign responsibility for vulnerability identification and remediation

60 minutes

Input: Sample list of vulnerabilities and requisite actions from each group, High-level organizational chart with area functions

Output: Defined set of roles and responsibilities for member groups

Materials: Vulnerability Management SOP Template

Participants: CIO, CISO, IT Management representatives for each area of IT

  1. Display the table of responsibilities that need to be assigned.
  2. List all the positions within the IT security team.
  3. Map these to the positions that require IT security team members.
  4. List all positions that are part of the IT team.
  5. Map these to the positions that require IT team members.

If your organization does not have a dedicated IT security team, you can perform this exercise by mapping the relevant IT staff to the different positions shown on the right.

Download the Vulnerability Management SOP TemplateSample of the Roles and Responsibilities table from the Vulnerability Management SOP Template.

Step 1.3

Cloud considerations for vulnerability management

Activities

None for this section.

This step will walk you through the following activities:

Review cloud considerations for vulnerability management

This step involves the following participants:

  • Security operations team
  • IT Security Manager
  • IT Director
  • CISO

Outcomes of this step

Understand the various types of cloud offerings and the implications (and limitations) of vulnerability management in a cloud environment.

Identify vulnerability sources
Step 1.1Step 1.2Step 1.3Step 1.4

Cloud considerations

Cloud will change your approach to vulnerability management.
  • There will be a heavy dependence on the cloud service provider to ensure that vulnerabilities in their foundational technologies have been addressed.
  • Depending on the level of “as-a-Service,” customers will have varying degrees of control and visibility into the underlying operations.
  • With vendor acquiescence, you can set your tool to scan a given cloud environment, depending on how much visibility you have into their environment based on the service you have purchased.
  • Due to compliance obligations of their customers, there is a growing trend among cloud providers to allow more scanning of cloud environments.
  • In the absence of customer scanning capability, vendors may offer attestation of vulnerability management and remediation.
Table outlining who has control, between the 'Organization' and the 'Vendor', of different cloud capabilities in different cloud strategies.

For more information, see Info-Tech Research Group’s Document Your Cloud Strategy blueprint.

Cloud environment scanning

Cloud scanning is becoming a more common necessity but still requires special consideration.

An organization’s cloud environment is just an extension of its own environment. As such, cloud environments need to be scanned for vulnerabilities.

Private Cloud
If your organization owns a private cloud, these environments can be tested normally.
Public Cloud
Performing vulnerability testing against public, third-party cloud environments is an area experiencing rapid growth and general acceptance, although customer visibility will still be limited.

In many cases, a customer must rely on the vendor’s assurance that vulnerabilities are being addressed in a sufficient manner.

Security standards’ compliance requirements are driving the need for cloud suppliers to validate and assure that they are appropriately scanning for and remediating vulnerabilities.

Infrastructure- or Platform-as-a-Service (IaaS or PaaS) Environments
  • There is a general trend for PaaS and IaaS vendors to allow testing if given due notice.
  • Your contract with the cloud vendor or the vendor’s terms and conditions will outline the permissibility of customer vulnerability scanning. In some cases, a cloud vendor will deny the ability to do vulnerability scanning if they already provide a solution as part of their service.
  • Always ensure that the vendor is aware of your vulnerability scanning activity so that false positives aren’t triggering their security measures as possible denial-of-service (DoS) attacks.
Software-as-a-Service (SaaS) Environments
  • SaaS offers very limited visibility to the services behind the software that the customer sees. You therefore cannot test for patch levels or vulnerabilities.
  • SaaS customers must rely exclusively on the provider for the regular scanning and remediation of vulnerabilities in the back-end technologies supporting the SaaS application.
  • You can only test the connection points to SaaS environments. This involves trying to figure out what you can see, e.g. looking for encrypted traffic.

Certain testing (e.g. DoS or load testing) will be very limited by your cloud vendor. Cloud vendors won’t open themselves to testing that would possibly impact their operations.

Step 1.4

Vulnerability detection

Activities
  • 1.4.1 Develop a monitoring and review process of third-party vulnerability sources
  • 1.4.2 Incident management and vulnerability management

This step will walk you through the following activities:

Create an inventory of your vulnerability monitoring capability and third-party vulnerability information sources.

Determine how incident management and vulnerability management interoperate.

This step involves the following participants:

  • Security operations team
  • IT Security Manager
  • IT Director
  • CISO

Outcomes of this step

Catalog of vulnerability information data sources. Understanding of the intersection of incident management and vulnerability management.

Identify vulnerability sources
Step 1.1Step 1.2Step 1.3Step 1.4

Vulnerability detection

Vulnerabilities can be identified through numerous mediums.

Info-Tech has determined the following to be the four most common ways to identify vulnerabilities.

Vulnerability Assessment and Scanning Tools
  • Computer programs that function to identify and assess security vulnerabilities and weaknesses within computers, computer systems, applications, or networks.
  • Using a known vulnerability database, the tool scans targeted hosts or systems to identify flaws and generate reports and recommendations based on the results.
  • There are four main types of tools under this category: network and operating system vulnerability scanners, application scanning and testing tools, web application scanners, and exploitation tools.
Penetration Tests
  • The act of identifying vulnerabilities on computers, computer systems, applications, or networks followed by testing of the vulnerability to validate the findings.
  • Penetration tests are considered a service that is offered by third-parties in which a variety of products, tools, and methods are used to exploit systems and gain access to data.
Open Source Monitoring
  • New vulnerabilities are detected daily with each vulnerability’s information being uploaded to an information-sharing platform to enable other organizations to be able to identify the same vulnerability on their systems.
  • Open source platforms are used to alert and distribute information on newly discovered vulnerabilities to security professionals.
Security Incidents
  • Any time an incident response plan is called into action to mitigate an incident, there should be formal communication with the vulnerability management team.
  • Any IT incident an organization experiences should provide a feed for analysis into your vulnerability management program.

Automate with a vulnerability scanning tool

Vulnerabilities are too numerous for manual scanning and detection.
  • Vulnerability management is not only the awareness of the existence of vulnerabilities but that they are actively present in your environment.
  • A vulnerability scanner will usually report dozens, if not hundreds, of vulnerabilities on a regular and recurring basis. Typical IT environments have several dozen, if not hundreds, of servers. We haven’t even considered the amount of network equipment or the hundreds of user workstations in an environment.
  • This tool will give you information of the presence of a vulnerability in your environment and the host on which the vulnerability exists. This includes information on the version of software that contains a vulnerability and whether you are running that version. The tool will also report on the criticality of the vulnerability based on industry criticality ratings.
  • The tools are continually updated by the vendor with the latest definition updates for the latest vulnerabilities out there. This ensures you are always scanning for the greatest number of potential vulnerabilities.
Automation requires oversight.
  1. Vulnerability scanners bring great automation to the task of scanning and detecting vulnerabilities in high numbers.
  2. Vulnerability scanners, however, do not have your level of intelligence. Any compensating controls, network segregation, or other risk mitigation features that you have in place will not be known by the tool.
  3. Determining the risk and urgency of a vulnerability within the context of your specific environment will still require internal review by you or your SecOps team.

For guidance on tool selection

Refer to section 4.3 Selecting and Implement a Scanning Tool in this blueprint.

Vulnerability scanning tool considerations

Select a vulnerability scanning tool with the features you need to be effective.
  • Vulnerability scanning tool selection can be an exciting and confusing process. You will need to consider what features you desire in a tool and whether you want the tool to go beyond just scanning and reporting.
  • In addition to vulnerability scanning, some tools will integrate with your IT service management (service desk ticketing system) tool and asset, configuration, and change management modules. This can facilitate the necessary workflow that the remediation process follows once a vulnerability is discovered.
  • A number of vulnerability scanning tool vendors have started offering remediation as part of their software features. This includes the automation and orchestration functionality and configuration and asset management to track its remediation activities.
  • A side benefit of the asset discovery feature in vulnerability scanning tools is that it can help enhance an organization’s asset inventory and license compliance, particularly in cases where end users are able to install software on their workstations.
Stock photo of a smartphone scanning a barcode.

For guidance on tool vendors

Visit SoftwareReviews for information on vulnerability management tools and vendors.

Vulnerability scanning tool best practices

How often should scans be performed?

One-off scans provide snapshots in time. Repeated scans over time provide tracking for how systems are changing and how well patches are being applied and software is being updated.

The results of a scan (asset inventory, configuration data, and vulnerability data) are basic information needed to understand your security posture. This data needs to be as up to date as possible.

ANALYST PERSPECTIVE: Organizations should look for continuous scanning

Continuous scanning is the concept of providing continual scanning of your systems so any asset, configuration, or vulnerability information is up to date. Most vendors will advertise continuous scanning but you need to be skeptical of how this feature is met.

Continuous Scanning Methods

Continuous agent scanning

Real-time scanning that is completed through agent-based scanning. Provides real-time understanding of system changes.

On-demand scanning

Cyclical scanning is the method where once you’re done scanning an area, you start it again. This is usually done because doing some scans on some areas of your network take time. How long the scan takes depends on the scan itself. How often you perform a scan depends on how long a scan takes. For example, if a scan takes a day, you perform a daily scan.

Cloud-based scanning

Cloud-scanning-as-a-Service can provide hands-free continuous monitoring of your systems. This is usually priced as a subscription model.

Vulnerability scanning tool best practices

Where to perform a scan.

What should be scannedHow to point a scanner
The general idea is that you want to scan pretty much everything. Here are considerations for three environments:
Mobile Devices

You need to scan mobile devices for vulnerabilities, but the problem is these can be hard to scan and often come and go on your network. There are always going to be some devices that aren’t on the network when scanning occurs.

Several ways to scan mobile devices:

  • Intercept the device when it remotes into your network using a VPN. You catch the device with a remote scan. This can only be done if a VPN is required.
  • An agent-based approach can be used for mobile devices. Locally installed software gives the information needed to evaluate the security posture of a device. Discernibly, concerns around device processing, memory, and network bandwidth come into play. Ease of installation becomes key for agents.
Virtualization
  • In a virtual environment, you will have servers being dynamically spun up. Ensure your tool is able to scan these new servers automatically.
  • Often, vulnerability scanning tool providers will restrict scanning to preapproved scanners. Look for tools that are preapproved by the VM vendors.
Cloud Environments
  • You can set your tool to scan a given cloud environment. The main concern here is who owns the cloud. If it is a private cloud, there is little concern.
  • If it is a third-party cloud (AWS, Azure, etc.) you need to confirm with the cloud service provider that scanning of your cloud environment can occur.
  • There is a trend to allow more scanning of cloud environments.
  • You need to tell the scanner an IP address, a group of IP addresses, an asset group, or a combination of those.
  • You can categorize by functional classifications – internet-facing servers, workstations, network devices, etc., or by organizational structure – Finance, HR, Legal, etc.
  • If you have a strong change management system, you can better hone when and where to perform a scan based on actual changes.
  • You can set the number of concurrent outbound TCP connections that are being made. For example, set the tool so it sends out to 10 ports at a time, rather than pinging at 64k ports on a machine, which would flood the NIC.
  • Side Note: Flooding a host with pings from a scanning tool can be done to find out DoS thresholds on a machine. There are no bandwidth concerns for a network DoS, however, because the packets are so small.

Vulnerability scanning tool best practices

Communication and measurement

Pre-Scan Communication With Users

  • It is always important to inform owners and users of systems that a scan will be happening.
  • Although it is unlikely any performance issues will arise, it is important to notify end users of potential impact.
  • Local admins or system owners may have controls in place that stop vulnerability scans and you need to inform the owners so that they can safelist the scanner you will be using.
Vulnerability Scanning Tool Tracking Metrics
  • Vulnerability score by operating system, application, or organization division.
    • This provides a look at the widely accepted severity of the vulnerability as it relates across the organization’s systems.
  • Most vulnerable applications and application version.
    • This provides insight into how outdated applications are creating risk exposure for an organization.
    • This will also provide metrics on the effectiveness of your patching program.
  • Number of assets scanned within the last number of days.
    • This provides visibility into how often your assets are being scanned and thus protected.
  • Number of unowned devices or unapproved applications.
    • This metric will track how many unowned devices or unapproved applications may be on your network. Unowned devices may be rogue devices or just consultant/contractor devices.

Third-party vulnerability information sources

IT security forums and mailing lists are another source of vulnerability information.

Proactively identify new vulnerabilities as they are announced.

By monitoring for vulnerabilities as they are announced through industry alerts and open-source mechanisms, it is possible to identify vulnerabilities beyond your scanning tool’s penetration tests.

Common sources:
  • Vendor websites and mailing lists
    • Vendors are the trusted sources for vulnerability and patch information on their products, particularly with new industry vulnerability disclosure requirements. Vendors are the most familiar with their products, downloads are most likely malware free, and additional information is often included.
    • There are some issues: vendors won’t announce a vulnerability until a patch is created, which creates a potential unknown risk exposure; numerous vendor sites will have to be monitored continually.
  • Third-party websites
    • A non-vendor site providing information on vulnerabilities. They often will cover a specific technology or an industry section, becoming a potential “one-stop shop” for some. They will often provide vulnerability information that is augmented with different remediation recommendations faster than vendors.
    • However, it’s more likely that malicious code could be downloaded and it will often not be comprehensive information on patching.
  • Third-party mailing lists, newsgroups, live paid subscriptions, and live open-source feeds
    • These are alerting and notification services for the detection and dissemination of vulnerability information. They provide information on the latest and most critical vulnerabilities, e.g. US-CERT Cybersecurity Alerts.
  • Vulnerability databases
    • These usually consist of dedicated databases on vulnerabilities. They perform the hard work of identifying and aggregating vulnerability and patch information into a central repository for end-user consumption. The commentary features on these databases provide excellent insight for practitioners, e.g. National Vulnerability Database (NVD).
Stock photo of a student checking a bulletin board.

Third-party vulnerability information sources

IT security forums and mailing lists are another source of vulnerability information.

Third-party sources for vulnerabilities

  • Open Source Vulnerability Database (OSVDB)
    • An open-source database that is run independently of any vendors.
  • Common Vulnerabilities and Exposures (CVE)
    • Free, international dictionary of publicly known information security vulnerabilities and exposures.
  • National Vulnerability Database (NVD)
    • Through NIST, the NVD is the US government’s repository of vulnerabilities and includes product names, flaws, and any impact metrics.
    • The National Checklist Repository Program (NCRP), also provided by NIST, provides security checklists for configurations of operating systems and applications.
    • The Center for Internet Security, a separate entity unrelated to NIST, provides configuration benchmarks that are often referenced by the NCRP.
  • Open Web Application Security Project (OWASP)
    • OWASP is another free project helping to expose vulnerabilities within software.
  • US-CERT National Cyber Alert System (US-CERT Alerts)
    • Cybersecurity Alerts – Provide timely information about current security issues, vulnerabilities, and exploits.
    • Cybersecurity Tips – Provide advice about common security issues for the general public.
    • Cybersecurity Bulletins – Provide weekly summaries of new vulnerabilities. Patch information is provided when available.
  • US-CERT Vulnerability Notes Database (US-CERT Vulnerability Notes)
    • Database of searchable security vulnerabilities that were deemed not critical enough to be covered under US-CERT Alerts. Note that the NVD covers both US-CERT Alerts and US-CERT Notes.
  • Open Vulnerability Assessment Language (OVAL)
    • Coding language for security professionals to discuss vulnerability checking and configuration issues. Vulnerabilities are identified using tests that are disseminated in OVAL definitions (XML executables that can be used by end users).

1.4.1 Develop a monitoring and review process for third-party vulnerability sources

60 minutes

Input: Third-party resources list

Output: Process for review of third-party vulnerability sources

Materials: Whiteboard, Whiteboard markers, Vulnerability Management SOP Template

Participants: IT Security Manager, SecOps team members, ITOps team members, CISO

  1. Identify what third-party resources are useful and relevant.
  2. Shortlist your third-party sources.
  3. Identify what is the best way to receive information from a third party.
  4. Document the method to receive or check information from the third-party source.
  5. Identify who is responsible for maintaining third-party vulnerability information sources
  6. Capture this information in the Vulnerability Management SOP Template.
Download the Vulnerability Management SOP TemplateSample of the Third Party Vulnerability Monitoring tables from the Vulnerability Management SOP Template.

Incidents and vulnerability management

Incidents can also be a sources of vulnerabilities.

When any incident occurs, for example:

  • A security incident, such as malware detected on a machine
  • An IT incident, such as an application becomes unresponsive
  • A crisis occurs, like a worker accident

There can be underlying vulnerabilities that need to be processed.

Three Types of IT Incidents exist:
  1. Information Security Incident
  2. IT Incident and/or Problem
  3. Crisis

Note: You need to have developed your various incident response plans to develop information feeds to the vulnerability mitigation process.
If you are missing an incident response plan, take a look at Info-Tech’s Related Resources.

Info-Tech Related Resources:
If you do not have a formalized information security incident management program, take a look at Info-Tech’s blueprint Develop and Implement a Security Incident Management Program.

If you do not have a formalized problem management process, take a look at Info-Tech’s blueprint Incident and Problem Management.

If you do not have a formalized IT incident management process, take a look at Info-Tech’s blueprint Develop and Implement a Security Incident Management Program.

If you do not have formalized crisis management, take a look at Info-Tech’s blueprint Implement Crisis Management Best Practices.

1.4.2 Incident management and vulnerability management

60 minutes

Input: Existing incident response processes, Existing crisis communications plans

Output: Alignment of vulnerability management program with existing incident management processes

Materials: Whiteboard, Whiteboard markers, Vulnerability Management SOP Template

Participants: IT Security Manager, SecOps team members, ITOps team members, including tiers 1, 2, and 3, CISO, CIO

  1. Inventory what incident response plans the organization has. These include:
    1. Information Security Incident Response Plan
    2. IT Incident Plan
    3. Problem Management Plan
    4. Crisis Management Plan
  2. Identify what part of those plans contains the post-response recap or final analysis.
  3. Formalize a communication process between the incident response plan and the vulnerability mitigation process.

Note: Most incident processes will cover some sort of root cause analysis and investigation of the incident. If a vulnerability of any kind is detected within this analysis it needs to be reported on and treated as a detected vulnerability, thus warranting the full vulnerability mitigation process.

Download the Vulnerability Management SOP Template

Implement Risk-Based Vulnerability Management

Phase 2

Triage & prioritize

Phase 1

1.1 What is vulnerability management?
1.2 Define scope and roles
1.3 Cloud considerations for vulnerability management
1.4 Vulnerability detection

Phase 2

2.1 Triage vulnerabilities
2.2 Determine high-level business criticality
2.3 Consider current security posture
2.4 Risk assessment of vulnerabilities

Phase 3

3.1 Assessing remediation options
3.2 Scheduling and executing remediation
3.3 Continuous improvement

Phase 4

4.1 Metrics, KPIs & CSFs
4.2 Vulnerability management policy
4.3 Select and implement a scanning tool
4.4 Penetration testing

This phase will walk you through the following activities:

Examine the elements that you will use to triage and analyze vulnerabilities, prioritizing using a risk-based approach, and prepare for remediation options.

This phase involves the following participants:

  • IT Security Manager
  • SecOps team members
  • ITOps team members, including tiers 1, 2, and 3
  • CISO
  • CIO

Step 2.1

Triage vulnerabilities

Activities
  • 2.1.1 Evaluate your identified vulnerabilities

This step will walk you through the following activities:

Review your vulnerability information sources and determine a methodology that will be used to consistently evaluate vulnerabilities as your scanning tool alerts you to them.

This step involves the following participants:

  • IT Security Manager
  • SecOps team members
  • ITOps team members, including tiers 1, 2, and 3
  • CISO
  • CIO

Outcomes of this step

A consistent, documented process for the evaluation of vulnerabilities in your environment.

Triage & prioritize
Step 2.1Step 2.2Step 2.3Step 2.4

Triaging vulnerabilities

Use Info-Tech’s methodology to allocate urgencies to your vulnerabilities to assign the appropriate resources to each one.

When evaluating numerous vulnerabilities, use the following three factors to help determine the urgency of vulnerabilities:

  • The intrinsic qualities of the vulnerability
  • The business criticality of the affected asset
  • The sensitivity of the data stored on the affected asset

Intrinsic qualities of the vulnerability — Vulnerabilities need to be examined for the inherent risk they pose specifically to the organization, which includes if an exploit has been identified or if the industry views this as a serious and likely threat.

Business criticality of the affected asset — Assets with vulnerabilities need to be assessed for their criticality to the business. Vulnerabilities on systems that are critical to business operations or customer interactions are usually top of mind.

Sensitivity of the data of the affected asset — Beyond just the criticality of the business, there must be consideration of the sensitivity of the data that may be compromised or modified as a result of any vulnerabilities.

Info-Tech Insight

This methodology allows you to determine urgency of vulnerabilities, but your remediation approach needs to be risk-based, within the context of your organization.

Triage your vulnerabilities, filter out the noise

Triaging enables your vulnerability management program to focus on what it should focus on.

Use the Info-Tech Vulnerability Mitigation Process Template to define how to triage vulnerabilities as they first appear.

Triaging is an important step in vulnerability management, whether you are facing ten to tens of thousands of vulnerability notifications.
Many scanning tools already provide the capability to compare known vulnerabilities against existing assets through integration with the asset inventory.

There are two major use cases for this process:
  1. For organizations that have identified vulnerabilities but do not know their own systems well enough. This can be due to a lack of a formal asset inventory.
  2. For proactive organizations that are regularly staying up to date with industry announcements regarding vulnerabilities. Once an alert has been made publicly, this process can assist in confirming if the vulnerability is relevant to the organization.
The Info-Tech methodology for initial triaging of vulnerabilities:
Flowchart of the Info-Tech methodology for initial triaging of vulnerabilities, beginning with 'Vulnerability has been identified' and ending with either 'Vulnerability has been triaged' or 'No action needed'.

Even if neither of these use cases apply to your organization, triaging still addresses the issues of false positives. Triaging provides a quick way to determine if vulnerabilities are relevant.

After eliminating the noise, evaluate your vulnerabilities to determine urgency

Consider the intrinsic risk to the organization.

Is there an associated, verified exploit?
  • For a vulnerability to become a true threat to the organization, it must be exploited to cause damage. In today’s threat landscape, exploit kits are sold online that allow individuals with low technical knowledge to exploit a vulnerability.
  • Not all vulnerabilities have an associated exploit, but this does not mean that these vulnerabilities can be left alone. In many cases, it is just a matter of time before an exploit is created.
  • Another point to consider is that while exploits can exist theoretically, they may not be verified. Vulnerabilities always pose some level of risk, but if there are no known verified exploits, there is less risk attached.
Is there a CVSS base score of 7.0 or higher?
  • Common Vulnerability Scoring System (CVSS) is an open-source industry scoring method to assess the potential severity of vulnerabilities.
  • CVSS takes into account: attack vector, complexity, privileges required, user interaction, scope, confidentiality impact, integrity impact, and availability impact.
  • Vulnerabilities that have a score of 4.0 or lower are classified as low vulnerabilities, while scores between 4.0 and 6.9 are put in the medium category. Scores of 7 or higher are in the high and critical categories. As we will review in the Risk Assessment section, you will want to immediately deal with high and critical vulnerabilities.
Is there potential for significant lateral movement?
  • Even though a vulnerability may appear to be part of an inconsequential asset, it is important to consider whether it can be leveraged to gain access to other areas of the network or system by an attacker.
  • Another consideration should be whether the vulnerability can be exploited by remote or local access. Remote exploits pose a greater risk as this can mean that attackers can perform an exploit from any location. Local exploits carry less risk, although the risk of insider threats should be considered here as well.

2.1.1 Evaluate your identified vulnerabilities

60 minutes

Input: Visio workflow of Info-Tech’s vulnerability management process

Output: Adjusted workflow to reflect your current processes, Vulnerability Tracking Tool

Materials: Whiteboard, Whiteboard markers, Vulnerability Management SOP Template

Participants: IT Security Manager, SecOps team members, ITOps team members, including tiers 1, 2, and 3, CISO, CIO

Using the criteria from the previous slide, Info-Tech has created a methodology to evaluate your vulnerabilities by examining their intrinsic qualities.

The methodology categorizes the vulnerabilities into high, medium, and low risk importance categorizations, before assigning final urgency scores in the later steps.

  1. Review the evaluation process in the Vulnerability Management Workflow library.
  2. Determine if this process makes sense for the organization; otherwise, change the flow to include any other considerations of process flows.
  3. As this process is used to evaluate vulnerabilities, document vulnerabilities to an importance category. This can be done in the Vulnerability Tracking Tool or using a similar internal vulnerability tracking document, if one exists.

Download the Vulnerability Management SOP Template

Step 2.2

Determine high-level business criticality

Activities
  • 2.2.1 Determine high-level business criticality
  • 2.2.2 Determine your high-level data classifications

This step will walk you through the following activities:

Determining high-level business criticality and data classifications will help ensure that IT security is aligned with what is critical to the business. This will be very important when decisions are made around vulnerability risk and the urgency of remediation action.

This step involves the following participants:

  • IT Security Manager
  • SecOps team members
  • CISO

Outcomes of this step

Understanding and consistency in how business criticality and business data is assessed by IT in the vulnerability management process.

Triage & prioritize
Step 2.1Step 2.2Step 2.3Step 2.4

Understanding business criticality is key to determining vulnerability urgency

Prioritize operations that are truly critical to the operation of the business, and understand how they would be impacted by an exploited vulnerability.

Use the questions below to help assess which operations are critical for the business to continue functioning.

For example, email is often thought of as a business-critical operation when this is not always the case. It is important to the business, but as regular operations can continue for some time without it, it would not be considered extremely business critical.

Questions to askDescription
Is there a hard-dollar impact from downtime?This refers to when revenue or profits are directly impacted by a business disruption. For example, when an online ordering system is compromised and shut down, it impacts sales, and therefore, revenue.
Is there an impact on goodwill/ customer trust?If downtime means delays in service delivery or otherwise impacts goodwill, there is an intangible impact on revenue that may make the associated systems mission critical.
Is regulatory compliance a factor?Depending on the circumstances of the vulnerabilities, it can be a violation of regulatory compliance and would cause significant fines.
Is there a health or safety risk?Some operations are critical to health and safety. For example, medical organizations have operations that are necessary to ensure that individuals’ health and safety are maintained. An exploited vulnerability that prevents these operations can directly impact the lives of these individuals.
Don’t start from scratch – your disaster recovery plan (DRP) may have a business impact analysis (BIA) that can provide insight into which applications and operations are considered business critical.

Analyst Perspective

When assessing the criticality of business operations, most core business applications may be deemed business critical over the long term.

Consider instead what the impact is over the first 24 or 48 hours of downtime.

2.2.1 Determine high-level business criticality

120 minutes; less time if a Disaster recovery plan business impact analysis exists

Input: List of business operations, Insight into business operations impacts to the business

Output: List of business operations and their criticality and impact to the business

Materials: Vulnerability Management SOP Template

Participants: Participants from the business, IT Security Manager, CISO, CIO

  1. List your core business operations at a high level.
  2. Use a High, Medium, or Low ranking to prioritize the business operations based on mission-critical criteria and the impact of the vulnerability.
  3. When using the process flow, consider if the vulnerability directly affects any of these business operations and move through the process flow based on the corresponding High, Medium, or Low ranking.
Example prioritization of business operations for a manufacturing company:Questions to ask:
  1. Is there a hard-dollar impact from downtime?
  2. Is there impact on goodwill or customer trust?
  3. Is regulatory compliance a factor?
  4. Is there a health or safety risk?

Download the Vulnerability Management SOP Template

Determine vulnerability urgency by its data classification

Consider how to classify your data based on if the Confidentiality, Integrity, or Availability (CIA) is compromised.

To properly classify your data, consider how the confidentiality, integrity, and availability of that data would be affected if it were to be exploited by a vulnerability. Review the table below for an explanation for each objective.
Confidentiality

Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.

Integrity

Guarding against improper information modification or destruction, and ensuring information non-repudiation and authenticity.

Availability

Ensuring timely and reliable access to and use of information.

Each piece of data should be ranked as High, medium, or low across confidentiality, integrity, and availability based on adverse effect.Arrow pointing right.Low — Limited adverse effect

Moderate — Serious adverse effect

High — Severe or catastrophic adverse effect

If you wish to build a whole data classification methodology, refer to our Discover and Classify Your Data blueprint.

How to determine data classification when CIA differs:

The overall ranking of the data will be impacted by the highest objective’s ranking.

For example, if confidentiality and availability are low, but integrity is high, the overall impact is high.

This process was developed in part by Federal Information Processing Standards Publication 199.

2.2.2 Determine your high-level data classifications

120 minutes, less time if data classification already exists

Input: Knowledge of data use and sensitivity

Output: Adjusted workflow to reflect your current processes, Vulnerability Tracking Tool

Materials: Whiteboard, Whiteboard markers, Vulnerability Management SOP Template

Participants: IT Security Manager, CISO, CIO

If your organization has formal data classification in place, it should be leveraged to determine the high, medium, and low rankings necessary for the process flows. However, if there is no formal data classification in place, the process below can be followed:

  1. List common assets or applications that are prone to vulnerabilities.
  2. Consider the data that is on these devices and provide a high (severe or catastrophic adverse effect), medium (serious adverse effect), or low (limited adverse effect) ranking based on confidentiality, availability, and integrity.
    1. Use the table on the previous slide to assist in providing the ranking.
    2. Remember that it is the highest ranking that dictates the overall ranking of the data.
  3. Document which data belongs in each of the categories to provide contextual evidence.

Download the Vulnerability Management SOP Template

This process should be part of your larger data classification program. If you need assistance in building this out, review the Info-Tech research, Discover and Classify Your Data.

Step 2.3

Consider current security posture

Activities
  • 2.3.1 Document your defense-in-depth controls

This step will walk you through the following activities:

Your defense-in-depth controls are the existing layers of security technology that protects your environment. These are relevant when considering the urgency and risk of vulnerabilities in your environment, as they will mitigate some of the risk.

This step involves the following participants:

  • IT Security Manager
  • SecOps team members
  • ITOps team members, including tiers 1, 2, and 3
  • CISO
  • CIO

Outcomes of this step

Understanding and documentation of your current defense-in-depth controls.

Triage & prioritize
Step 2.1Step 2.2Step 2.3Step 2.4

Review your current security posture

What you have today matters.
  • In most cases, your vulnerability scanning tool alone will not have the context of your security posture in the results of its scans. This can skew the true urgency of detected vulnerabilities in your environment.
  • What you have in place today is what comprises your organization’s overall security posture. This bears high relevance to the determination of the risk that a vulnerability poses to your environment.
  • Elements such as enterprise architecture and defense in depth mechanisms should be factored into determining the risk of a vulnerability and what kind of immediacy is warranted to address it.
  • Details of your current security posture will also contribute to the assessment and selection of remediation options.
Stock image of toy soldiers split into two colours, facing eachother down.

Enterprise architecture considerations

What does your network look like?
  • Most organizations have a network topology that has been put in place with operational needs in mind. These includes specific vLANs or subnets, broadcast domains, or other methods of traffic segregation.
  • The firewall and network ACLs (access control lists) will manage traffic and the routes that data packets follow to traverse a network.
  • Organizations may physically separate data network types, for example, a network for IT services and one for operational technology (OT)(OT is often known as ICS (industrial control systems) or SCADA (supervisory control and data acquisition)) or other types of production technology.
  • The deployment of distribution and access switches across an enterprise can also be a factor, where a flatter network will have fewer network devices within the topology.
  • In a directory services environment such as Windows Active Directory, servers and applications can be segregated by domains and trust relationships, organizational units, and security groups.
What’s the relevance to vulnerability management?

For a vulnerability to be exploited, a malicious actor must find a way to access the vulnerable system to make use of the vulnerability in question.

Any enterprise architecture characteristics that you have in place may lessen the probability of a successful vulnerability exploit.

This may potentially “buy time” for SecOps to address and remediate the vulnerability.

Defense-in-depth

Defense-in-depth provides extra layers of protection to the organization.

  • Defense-in-depth refers to the coordination of security controls to add layers of security to the organization.
    • This means that even if attackers are able to get past one control or layer, they are hindered by additional security.
  • Defense-in-depth is distinct from the previous section on enterprise architecture as these are security controls put in place with the purpose of being lines of defense within your security posture.
  • This can be extremely useful in managing vulnerabilities; thus, it is important to establish the existing defense-in-depth controls. By establishing the base model for your defense-in-depth, it will allow you to leverage these controls to manage vulnerabilities.
  • Controls are typically distributed across endpoints, network infrastructure, servers, and physical security.

Note: Defense-in-depth controls do not entirely mitigate vulnerability risk. They provide a way in which the vulnerability cannot be exploited, but it continues to exist on the application. This must be kept in mind as the controls or applications themselves change, as it can re-open the vulnerability and cause potential problems.

Examples of defense-in-depth controls can consist of any of the following:
  • Antivirus software
  • Authentication security
  • Multi-factor authentication
  • Firewalls
  • Demilitarized zones (DMZ)
  • Sandboxing
  • Network zoning
  • Application whitelisting
  • Access control lists
  • Intrusion detection & prevention systems
  • Airgapping
  • User security awareness training

2.3.1 Document your defense-in-depth controls

2 hours, less time if a security services catalog exists

Input: List of technologies within your environment, List of IT security controls that are in place

Output: List of defense-in-depth controls

Materials: Whiteboard/flip charts, Vulnerability Management SOP Template

Participants: IT Security Manager, Infrastructure Manager, IT Director, CISO

  1. Document the existing defense-in-depth controls within your system.
  2. Review the initial list that has been provided and see if these are controls that currently exist.
  3. Indicate any other controls that are being used by the organization. This may already exist if you have a security services catalog.
  4. Indicate who the owners of the different controls are.
  5. Track the information in the Vulnerability Management SOP Template.

Download the Vulnerability Management SOP Template

Sample table of security controls within a Defense-in-depth model with column headers 'Defense-in-depth control', 'Description', 'Workflow', and 'Control Owner'.

Step 2.4

Risk assessment of vulnerabilities

Activities
  • 2.4.1 Build a classification scheme to consistently assess impact
  • 2.4.2 Build a classification scheme to consistently assess likelihood

This step will walk you through the following activities:

Assessing risk will be the cornerstone of how you evaluate vulnerabilities and what priority you place on remediation. This is actual risk to the organization and not simply what the tool reports without the context of your defense-in-depth controls.

This step involves the following participants:

  • IT Security Manager
  • IT Operations Management
  • CISO
  • CIO

Outcomes of this step

A risk matrix tailored to your organization, based on impact and likelihood. This will provide a consistent, unambiguous way to assess risk across the vulnerability types that is reported by your scanning tool.

Triage & prioritize
Step 2.1Step 2.2Step 2.3Step 2.4

Vulnerabilities and risk

Vulnerabilities must be addressed to mitigate risk to the business.
  • Vulnerabilities are a concern because they are potential threats to the business. Vulnerabilities that are not addressed can turn from potential threats into actual threats; it is only a matter of time and opportunity.
  • Your organization will already be familiar with risk management, as every decision carries a business risk component. There may even be a senior manager assigned as corporate risk officer to manage organizational risk.
  • The organization likely has a risk tolerance level that defines the organization’s risk appetite. This may be measured in dollars, non-productivity time, or other units of inefficiency.
  • The risk of a vulnerability can be calculated using impact and likelihood. Impact is the effect that the vulnerability will have if it is exploited by a malicious actor. Likelihood is the degree to which a vulnerability exploit can possibly occur.
Stock image of a cartoon character in a tie hanging on the needle of a 'RISK' meter as it sits at 'LOW'.

Info-Tech Insight

Risk to the organization is business language that everyone can understand. This is particularly true when the risk is to productivity or to the company’s bottom line.

A risk-based approach to vulnerability management

CVSS scores are just the starting point!

Vulnerabilities are constant.
  • There will always be vulnerabilities in the environment, many of which won’t be reported as they are currently unknown.
  • Don’t focus on trying to resolve all vulnerabilities in your environment. You are neither resourced for it nor can the business tolerate the downtime needed to remediate every single vulnerability.
    • The constant follow of new vulnerabilities will quickly render your efforts useless and it will become a game of “whack-a-mole.”
  • Being able to prioritize which vulnerabilities require appropriate levels of response is crucial to ensuring that an organization stays ahead of the continual flow.
  • Your vulnerability scanning tool will report the severity of a vulnerability, often using an industry Common Vulnerability Scoring System (CVSS) system ranging from 0 to 10. It will then scan your environment for the presence of the vulnerability and report accordingly.
    • Your vulnerability scanning tool will not be aware of any mitigation components in your environment, such as compensating controls, network segregation, server/application hardening, or any other measures that can reduce the risk. That is why determining actual risk is a crucial step.

Stock image of a whack-a-mole game.

Info-Tech Insight

Vulnerability scanning is a valuable function, but it does not tell the full picture. You must determine how urgent a vulnerability truly is, based on your specific environment.

Prioritize remediation by levels of risk

Address critical and high risk with high immediacy.

  • Addressing the critical and high-risk vulnerabilities with urgency will ensure that you are addressing a more manageable number of vulnerabilities.
  • An optimized vulnerability management process will address the medium and low risk vulnerabilities within the regular cycle.
  • This may be very similar to what you do today in an ad hoc fashion:
    • Zero-day vulnerabilities tend to warrant a stop in operations and are dealt with immediately (or as soon as a vendor has a fix).
    • The standard remediation process (patching/updating, change of configuration, etc.) happens within a regular controlled time cycle.
  • Formalizing this process will ensure that appropriate attention is given to vulnerabilities that warrant it and that the remaining vulnerabilities are dealt with as a regular, recurring activity.

Mitigate the risk surface by reducing the time across the phases

Chart titled 'Mitigate the risk surface by reducing the time across the phases' with the axes 'Risk Level' and 'Time' with lines created by individual risks. The highlighted line begins in 'Critical' and eventually drops to low. A note on the line reads 'Objective: Reduce risk surface by reducing time to address'. The area between the line and your organization's risk tolerance is labelled 'Risk Surface, to be addressed with high priority'. A bracket around Risk levels 'High' and 'Critical' reads 'Priority focus zone (risk surface)'. Risk lines within levels 'Low' and 'Medium' read 'Follow standard vulnerability management cycles'.

Risk matrix

Risk = Impact x Likelihood
  • Info-Tech’s Vulnerability Management Risk Assessment Tool provides a method of calculating the risk of a vulnerability. The risk rating is assigned using the impact of the risk and the likelihood or probability that the event may occur.
  • The tool puts the vulnerability into your organization’s context: How many people will be affected? What service types are vulnerable and how does that impact the business? Is there an anticipated update from the vendor of the system being affected?
  • Urgency of remediation should be based on the business consequences if the vulnerability were to be exploited, relative to the business’ risk tolerance.

Info-Tech Insight

Risk determination should be done within the context of your current environment and not simply based on what your vulnerability tool is reporting.

A risk matrix is useful in calculating a risk rating for vulnerabilities. Risk matrix with axes 'Impact' and 'Time' and individual vulnerabilities mapped onto it via their risk rating. The example 'Organizational Risk Tolerance Threshold' line runs diagonally through the 'Medium' squares.

2.4.1 Build a classification scheme to consistently assess impact

60 minutes

Input: Knowledge of IT environment, Knowledge of business impact for each IT component or service

Output: Vulnerability Management Risk Assessment Tool formatted to your organization

Materials: Vulnerability Management Risk Assessment Tool

Participants: Functional Area Managers, IT Security Manager, CISO

Risk always has a negative impact, but the size of the impact can vary considerably in terms of cost, number of people or sites affected, and the severity of the impact. Impact questions tend to be more objective and quantifiable than likelihood questions.

  1. Define a set of questions to measure risk impact or edit existing questions in the tool.
  2. For each question, assign a weight that should be placed on that factor.
  3. Define criteria for each question that would categorize the risk. The drop-down box content can be modified in the hidden Labels tab.

Note that you are looking to baseline vulnerability types, rather than categorizing every single vulnerability your scanning tool reports. The volume of vulnerabilities will be high, but vulnerabilities can be categorized into types on a regular basis.

Download the Vulnerability Management Risk Assessment Tool

Screenshot of table from Info-Tech's Vulnerability Management Risk Assessment Tool for assessing Impact. Column headers are 'Weight', 'Question', 'OS vulnerability', 'Application vulnerability', 'Network vulnerability', and 'Vendor patch release'.

2.4.2 Build a classification scheme to consistently assess likelihood

60 minutes

Input: Knowledge of IT environment, Knowledge of business impact for each IT component or service

Output: Vulnerability Management Risk Assessment Tool formatted to your organization

Materials: Vulnerability Management Risk Assessment Tool

Participants: Functional Area Managers, IT Security Manager, CISO

Risk always has a negative impact, but the size of the impact can vary considerably in terms of cost, number of people or sites affected, and the severity of the impact. Impact questions tend to be more objective and quantifiable than likelihood questions.

  1. Define a set of questions to measure risk impact or edit existing questions in the tool.
  2. For each question, assign a weight that should be placed on that factor.
  3. Define criteria for each question that would categorize the risk. The drop-down box content can be modified in the hidden Labels tab.

Note that you are looking to baseline vulnerability types, rather than categorizing every single vulnerability that your scanning tool reports. The volume of vulnerabilities will be high, but vulnerabilities can be categorized into types on a regular basis.

Download the Vulnerability Management Risk Assessment Tool

Screenshot of table from Info-Tech's Vulnerability Management Risk Assessment Tool for assessing Likelihood. Column headers are 'Weight', 'Question', 'OS vulnerability', 'Application vulnerability', and 'Network vulnerability'.

Prioritize based on risk

Select the best remediation option to minimize risk.

Through the combination of the identified risk and remediation steps in this phase, the prioritization for vulnerabilities will become clear. Vulnerabilities will be assigned a priority once their intrinsic qualities and threat potential to business function and data have been identified.

  • Remediation options will be identified for the higher urgency vulnerabilities.
  • Options will be assessed for whether they are appropriate.
  • They will be further tested to determine if they can be used adequately prior to full implementation.
  • Based on the assessments, the remediation will be implemented or another option will be considered.
Prioritization
  1. Assignment of risk
  2. Identification of remediation options
  3. Assessment of options
  4. Implementation

Remediation plays an incredibly important role in the entire program. It plays a large part in wider risk management when you must consider the risk of the vulnerability, the risk of the remediation option, and the risk associated with the overall process.

Implement Risk-Based Vulnerability Management

Phase 3

Remediate vulnerabilities

Phase 1

1.1 What is vulnerability management?
1.2 Define scope and roles
1.3 Cloud considerations for vulnerability management
1.4 Vulnerability detection

Phase 2

2.1 Triage vulnerabilities
2.2 Determine high-level business criticality
2.3 Consider current security posture
2.4 Risk assessment of vulnerabilities

Phase 3

3.1 Assessing remediation options
3.2 Scheduling and executing remediation
3.3 Continuous improvement

Phase 4

4.1 Metrics, KPIs & CSFs
4.2 Vulnerability management policy
4.3 Select and implement a scanning tool
4.4 Penetration testing

This phase will walk you through the following activities:

  • Identifying potential remediation options.
  • Developing criteria for each option with regards to when to use and when to avoid.
  • Establishing exception procedure for testing and remediation.
  • Documenting the implementation of remediations and verification.

This phase involves the following participants:

  • CISO, or equivalent
  • Security Manager/Analyst
  • Network, Administrator, System, Database Manager
  • Other members of the vulnerability management team
  • Risk managers for the risk-related steps

Determining how to remediate

Patching is only one option.

This phase will allow organizations to build out the specific processes for remediating vulnerabilities. The overall process will be the same but what will be critical is the identification of the correct material. This includes building the processes around:
  • Identifying and selecting the remediation option to be used.
  • Determining what to do when a patch or update is not available.
  • Scheduling and executing the remediation activity.
  • Continuous improvement.

Each remediation option carries a different level of risk that the organization needs to consider and accept by building out this program.

It is necessary to be prepared to do this in real time. Careful documentation is needed when dealing with vulnerabilities. Use the Vulnerability Tracking Tool to assist with documentation in real time. This is separate from using the process template but can assist in the documentation of vulnerabilities.

Step 3.1

Assessing remediation options

Activities
  • 3.1.1 Develop risk and remediation action

This step will walk you through the following activities:

With the risk assessment from the previous activity, we can now examine remediation options and make a decision. This activity will guide us through that.

This step involves the following participants:

  • IT Security Manager
  • SecOps team members
  • ITOps team members, including tiers 1, 2, and 3
  • CISO
  • CIO

Outcomes of this step

List of remediation options and criteria on when to consider each.

Remediate vulnerabilities
Step 3.1Step 3.2Step 3.3

Identify remediation options

There are four options when it comes to vulnerability remediation.

Patches and Updates

Patches are software or pieces of code that are meant to close vulnerabilities or provide fixes to any bugs within existing software. These are typically provided by the vendor to ensure that any deployed software is properly protected after vulnerabilities have been detected.

Configuration Changes

Configuration changes involve administrators making significant changes to the system or network to remediate against the vulnerability. This can include disabling the vulnerable application or specific element and can even extend to removing the application altogether.

Remediation

Compensating Controls

By leveraging security controls, such as your IDS/IPS, firewalls, or access control, organizations can have an added layer of protection against vulnerabilities beyond the typical patches and configuration changes. This can be used as a measure while waiting to implement another option (if one exists) to reduce the risk of the vulnerability in the short or long term.

Risk Acceptance

Whenever a vulnerability is not remediated, either indefinitely or for a short period of time, the organization is accepting the associated risk. Segregation of the vulnerable system can occur in this instance. This can occur in cases where a system or application cannot be updated without detrimental effect to the business.

Patches and updates

Patches are often the easiest and most common method of remediation.

Patches are usually the most desirable remediation solution when it comes to vulnerability management. They are typically provided by the vendor of the vulnerable application or system and are meant to eliminate the existing vulnerability.

When to use

  • When adequate testing can be performed on the patch to be implemented.
  • When there is a change window approaching for the affected systems.
  • When there is standardization across the IT assets to allow for easier installation of patches.

When to avoid

  • When the patch cannot be adequately tested.
  • When a patch has been tested, but it caused an unfavorable consequence such as a system or application failure.
  • When there is no near change window in which to install the patches, which is often the case for critical systems.
When to consider other remediation options
  • For critical systems, it can be difficult to implement a patch as they often require the system to be rebooted or go through some downtime. There must be consideration towards whether there is a change window approaching if a patch is to be implemented on a business-critical system.
    • If there is no opportunity to implement the patch, or no approaching change window, it is wise to leverage another remediation option.
  • When patches are not currently available from the vendor or they are in production, other remediation options are needed.
  • Other remediation options can be used in tandem with the patch. For example, if a patch is being deferred until the change window, it would be wise to use alternate remediation options to close the vulnerability.

Compensating controls

Compensating controls can decrease the risk of vulnerabilities that cannot be (immediately) remediated.

  • Compensating controls are measures put in place when direct remediation measures are impractical or non-existent.
  • Similar to the payment card industry’s PCI DSS 1.0 provision of compensating controls, these are meant to meet the intent or rigor of the original requirement; unlike PCI DSS, these measures are to mitigate risk rather than meet compliance.
  • The compensating control should be viewed as only a temporary measure for dealing with a vulnerability, although circumstances may dictate a degree of permanence in the application of the compensating control.
  • Examples where compensating controls may be needed are:
    • The software vendor is developing an update or patch to address a vulnerability.
    • Through your testing process, a patch will adversely affect the performance or operation of the target system and be detrimental to the business.
    • A critical application will only run on a legacy operating system, the latter of which is no longer supported by the vendor.
    • A legacy application is no longer being supported but is critical to your operations. A replacement, if one exists, will take time to implement.
Examples of compensating controls
  • Segregating a vulnerable server or application on the network, physically or logically.
  • Hardening the operating system or application.
  • Restricting user logins to the system or application.
  • Implementing access controls on the network route to the system.
  • Instituting application whitelisting.

Configuration changes

Configuration changes involve making changes directly to the application or system in which there is a vulnerability. This can vary from disabling or removing the vulnerable element or, in the case of applications built in-house, changing the coding of the application itself. These are commonly used in network vulnerabilities such as open ports.

When to use

  • A patch is not available.
  • The vulnerable element can be significantly changed, or even disabled, without significantly disrupting the business.
  • The application is built in-house, as the vulnerability must be closed internally.
  • There is adequate testing to ensure that the configuration change does not affect the business.
  • A configuration change in your network or system can affect numerous endpoints or systems, reducing endpoint patching or use of defense-in-depth controls.

When to avoid

  • When a suitable patch is available.
  • When the vulnerability is on a business-critical element with no nearby change window or it cannot be disabled.
  • When there is no opportunity in which to perform testing to ensure that there are no unintended consequences.
When to consider other remediation options
  • Configuration changes require careful documentation as changes are occurring to the system and applications. If there is a need to perform a back-out process and return to the original configuration, this can be extremely difficult without clear documentation of what occurred.
  • If business systems are too critical or important to the regular business function to perform any changes, it is necessary to consider other options.

Info-Tech Insight

Remember your existing processes: configuration changes may need to be approved and orchestrated through your organization’s configuration and change management processes.

Case Study

Remediation options do not have to be used separately. Use the Shellshock 2014 case as an example.

INDUSTRY: All
SOURCE: Public Domain
Challenge

Bashdoor, more commonly known as Shellshock, was announced on September 24, 2014.

This bug involved the Bash shell, which normally executes user commands, but this vulnerability meant that malicious attackers could exploit it.

This was rated a 10/10 by CVSS – the highest possible score.

Within hours of the announcement, hackers began to exploit this vulnerability across many organizations.

Solution

Organizations had to react quickly and multiple remediation options were identified:

  • Configuration changes – Companies were recommended to use other shells instead of the Bash shell.
  • Defense-in-depth controls – Using HTTP server logs, it could be possible to identify if the vulnerability had been exploited.
  • Patches – Many vendors released patches to close this vulnerability including Debian, Ubuntu, and Red Hat.
Results

Companies began to protect themselves against these vulnerabilities.

While many organizations installed patches as quickly as possible, some also wished to test the patch and leveraged defense-in-depth controls in the interim.

However, even today, many still have the Shellshock vulnerability and exploits continue to occur.

Accept the risk and do nothing

By choosing not to remediate vulnerabilities, you must accept the associated risk. This should be your very last option.

Every time that a vulnerability is not remediated, it continues to pose a risk to the organization. While it may seem that every vulnerability needs to be remediated, this is simply not possible due to limited resources. Further, it can take away resources from other security initiatives as opposed to low-priority vulnerabilities that are extremely unlikely to be exploited.

Common criteria for vulnerabilities that are not remediated:
  • Affected systems are of extremely low criticality.
  • Affected systems are deemed too critical to take offline to perform adequate remediation.
  • Low urgency is assigned to those vulnerabilities.
  • Cost and time required for the remediation are too high.
  • No adequate solutions exist – the vendor has not released a patch, there are weak defense-in-depth controls, and it is not possible to perform a configuration change.

Risk acceptance is not uncommon…

  • With an ever-increasing number of vulnerabilities, organizations are struggling to keep up and often, intentionally or unintentionally, accept the risk associated.
  • In the end, non-remediation means full acceptance of the risk and any consequences.

Enterprise risk management
Arrow pointing up.
Risk acceptance of vulnerabilities

While these are common criteria, they must be aligned to the enterprise risk management framework and approved by management.

Don’t forget the variables that were assessed in Phase 2. This includes the risk from potential lateral movement or if there is an existing exploit.

Risk considerations

When determining if risk acceptance is appropriate, consider the cost of not mitigating vulnerabilities.

Don’t accept the risk because it seems easy. Consider the financial impact of leaving vulnerabilities open.

With risk acceptance, it is important to review the financial impact of a security incident resulting from that vulnerability. There is always the possibility of exploitation for vulnerabilities. A simple metric taken from NIST SP800-40 to use for this is:

Cost not to mitigate = W * T * R

Where (W) is the number of work stations, (T) is the time spent fixing systems or lost in productivity, and (R) is the hourly rate of the time spent.

As an example provided by NIST SP800-40 Version 2.0, Creating a Patch and Vulnerability Management Program:

“For an organization where there are 1,000 computers to be fixed, each taking an average of 8 hours of down time (4 hours for one worker to rebuild a system, plus 4 hours the computer owner is without a computer to do work) at a rate of $70/hour for wages and benefits:

1,000 computers * 8 hours * $70/hour = $560,000”

Info-Tech Insight

Always consider the financial impact that can occur from an exploited vulnerability that was not remediated.

3.1.1 Develop risk and remediation action

90 minutes

Input: List of remediation options

Output: List of remediation options sorted into “when to use” and “when to avoid” lists

Materials: Whiteboard/flip charts, Vulnerability Management SOP Template

Participants: IT Security Manager, IT Infrastructure Manager, IT Operations Manager, Corporate Risk Officer, CISO

It is important to define and document your organization-specific criteria for when a remediation option is appropriate and inappropriate.

  1. List each remediation option on a flip chart and create two headings: “When to use” and “When to avoid.”
  2. Each person will list “when to use” criteria on a green sticky note and “when to avoid” criteria on a red one for each option; these will be placed on the appropriate flip chart.
  3. Discuss as a group which criteria are appropriate and which should be removed.
  4. Move on to the next remediation option when completed.
    • Ensure to include when there are remediation options that will be connected. For example, the risk may be accepted until the next available change window, or a defense-in-depth control is used before a patch can be fully installed.
  5. Once the criteria has been established, document this in the Vulnerability Management SOP Template.
When to use:
  • When adequate testing can be performed on the patch to be implemented.
  • When there is a change window approaching, especially for critical systems.
  • When there is standardization across the IT assets to allow for easier installation of patches.
When to avoid:
  • When the patch cannot be adequately tested.
  • When a patch has been tested, but it has caused an unfavorable consequence such as a system or application failure.
  • When there is no near change window in which to install the patches.
(Example from the Vulnerability Management SOP Template for Patches.)

Download the Vulnerability Management SOP Template

Step 3.2

Scheduling and executing remediation

Activities

None for this section.

This step will walk you through the following activities:

Although there are no specific activities for this section, it will walk you through your existing processes configuration and change management to ensure that you are leveraging those activities in your vulnerability remediation actions.

This step involves the following participants:

  • IT Security Manager
  • SecOps team members
  • ITOps team members, including tiers 1, 2, and 3
  • CISO
  • CIO

Outcomes of this step

Gained understanding of how IT operations processes configuration and change management can be leveraged for the vulnerability remediation process. Don’t reinvent the wheel!

Remediate vulnerabilities
Step 3.1Step 3.2Step 3.3

Implementing the remediation

Vulnerability management converges with your IT operations functions.
  • Once a remediation strategy has been formulated, you can leverage your release and change management processes to orchestrate the testing, version tracking, scheduling, approval, and implementation activities.
  • Each of these processes should exist in your environment in some form. Leveraging these will engage the IT operations team to carry out their tasks in the remediation process.
  • There can be a partial or full handoff to these processes, however, the owner of the vulnerability management program is responsible for verifying the application of the remediation measure and that the overall risk has been reduced.
  • Although full blueprints exist that cover each of these processes in great detail, the following slides provide an overview of each of these IT operations processes and how they intersect with vulnerability management.
Stock image of a person on a laptop overlaid by an icon with gears indicating settings.

Release Management

Control the quality of deployments and releases of software updates.

  • The release management process exists to ensure that new software releases (such as patches and updates) are properly tested and documented with version control prior to their implementation into the production environment.
  • The process should map out the logistics of the deployment process to ensure that it is consistent and controlled.
  • Testing is an important part of release management and the urgency of a vulnerability remediation operation can expedite this process to ensure minimal delays. Once testing has been completed successfully, the update is then “promoted” to production-ready status and submitted into the change management process.
  • Often a separate release team may not exist, however, release management still occurs.

For guidance on implementing or improving your release management process, refer to Info-Tech’s Stabilize Release and Deployment Management blueprint or speak to one of our experts.

Info-Tech Insight

Many organizations don’t have a separate release team. Rather, whomever is doing the deployment will submit a change request and the testing details are vetted through the organization’s change management process.

For guidance on the change management process review our Optimize Change Management blueprint.

Change Management

Leverage change control, interruption management, approval, and scheduling.
  • Change management likely exists in some shape or form in your organization. There is usually someone or a committee, such as a change advisory board (CAB), that gives approval for a change.
  • Leveraging the change management process will ensure that your vulnerability remediation has undergone the proper review and approval before implementation. There will usually be business sign-off as part of a change management approval process.
  • Communication will also be integrated in the change management process, so the change manager will ensure that appropriate, timely communications are sent to the proper key stakeholders.
  • The change management process will link to release management and configuration management processes if they exist.

For further guidance on implementing or improving your change management process, refer to Info-Tech’s Optimize Change Management blueprint or speak to one of our experts.

“With no controls in place, IT gets the blame for embarrassing outages. Too much control, and IT is seen as a roadblock to innovation.” (VP IT, Federal Credit Union)

Post-implementation activities

Vulnerability remediation isn’t a “set it and forget it” activity.
  • Once vulnerability remediation has occurred, it is imperative that the results are reported back to the vulnerability management program manager. This ensures that the loop is closed and the tracking of the remediation activity is done properly.
    • Organizations that are subject to audit by external entities will understand the importance of such documentation.
  • The results of post-implementation review from the change management process will be of great interest, particularly if there was any deviation from the planned activities.
  • Although change execution will usually undergo some form of testing during the maintenance window, there is always the possibility that something has broken as a result of the software update. Be quick to respond to these types of incidents!
    • One example of an issue that is near impossible to test during a maintenance window is one that manifests only when the system or software comes under load. This is what makes for busy Monday mornings after a weekend change window.
A scan with your vulnerability management software after remediation can be a way to verify that the overall risk has been reduced, if remediation was done by way of patching/updates.

Info-Tech Insight

After every change completion, whether due to vulnerability remediation or not, it is a good idea to ensure that your infrastructure team increases its monitoring diligence and that your service desk is ready for any sudden influx of end-user calls.

Step 3.3

Continuous improvement

Activities

None for this section.

This step will walk you through the following activities:

Although this section has no activities, it will review the process by which you may continually improve vulnerability management.

This step involves the following participants:

  • IT Security Manager
  • SecOps team members
  • ITOps team members, including tiers 1, 2, and 3
  • CISO
  • CIO

Outcomes of this step

An understanding of the importance of ongoing improvements to the vulnerability management program.

Remediate vulnerabilities
Step 3.1Step 3.2Step 3.3

Drive continuous improvement

  • Also known as “Continual Improvement” within the ITIL best practice framework.
  • Your vulnerability management program will not be perfect on first launch. In fact, due to the ever-changing nature of vulnerabilities and the technology designed to detect and combat vulnerabilities, the processes within your vulnerability management program will need to be tweaked from time to time.
  • Continuous improvement is a sustained, proactive approach to process improvement. The practice allows for all process participants to observe and suggest incremental improvements that can help improve the overall process.
  • In many cases, continuous improvement can be triggered by changes in the environment. This makes perfect sense for vulnerability management process improvement as a change in the environment will require vulnerability scanning to ensure that such changes have not introduced new vulnerabilities into the environment, increasing your risk surface.
  • One key method to tracking continuous improvement is through the effective use of metrics, covered in Section 4.1 of this blueprint.
“The success rate for continual improvement efforts is less than 60 percent. A major – if not the biggest – factor affecting the deployment of long-term continual improvement initiatives today is the fundamental change taking place in the way companies manage and execute work.” (Industry analyst at a consulting firm, 2014)

Continuous Improvement

Continuously re-evaluate the vulnerability management process.

As your systems and assets change, your vulnerability management program may need updates in two ways.

When new assets and systems are introduced:

  • When new systems and assets are introduced, it is important for organizations to recognize how these can affect vulnerability management.
  • It will be necessary to identify the business criticality of the new assets and systems and the sensitivity of the data that can be found on them.
  • Without doing so, these will be considered rogue systems or assets – there is no clear process for assigning urgencies.
  • This will only cause problems as actions may be taken that are not aligned with the organization’s risk management framework.

Effective systems and asset management are needed to track this. Review Info-Tech’s Implement Systems Management to Improve Availability and Visibility blueprint for more help.

Document any changes to the vulnerability management program in the Vulnerability Management SOP Template.

When defense-in-depth capabilities are modified:

  • As you build an effective security program, more controls will be added that can be used to protect the organization.
  • These should be documented and evaluated based on ability to mitigate against vulnerabilities.
  • The defense-in-depth model that was previously established should be updated to include the new capabilities that can be used.
  • Defense-in-depth models are continually evolving as the security landscape evolves, and organizations must be ready for this.

To assist in building a defense-in-depth model, review Build an Information Security Strategy.

Implement Risk-Based Vulnerability Management

Phase 4

Measure and formalize

Phase 1

1.1 What is vulnerability management?
1.2 Define scope and roles
1.3 Cloud considerations for vulnerability management
1.4 Vulnerability detection

Phase 2

2.1 Triage vulnerabilities
2.2 Determine high-level business criticality
2.3 Consider current security posture
2.4 Risk assessment of vulnerabilities

Phase 3

3.1 Assessing remediation options
3.2 Scheduling and executing remediation
3.3 Continuous improvement

Phase 4

4.1 Metrics, KPIs & CSFs
4.2 Vulnerability management policy
4.3 Select and implement a scanning tool
4.4 Penetration testing

This phase will walk you through the following activities:

  • You will determine what ought to be measured to track the success of your vulnerability management program.
  • If you lack a scanning tool this phase will help you determine tool selection.
  • Lastly, penetration testing is a good next step to consider once you have your vulnerability management program well underway.

This phase involves the following participants:

  • IT Security Manager
  • SecOps team members
  • Procurement representatives
  • CISO
  • CIO

Step 4.1

Metrics, Key Performance Indicators (KPIs), and Critical Success Factors (CSFs)

Activities
  • 4.1.1 Measure your program with metrics, KPIs, and CSFs

This step will walk you through the following activities:

After a review of the differences between raw metrics, key performance indicators (KPI), and critical success factors (CSF), compile a list of what metrics you will be tracking, why, and the business goals for each.

This step involves the following participants:

  • IT Security Manager
  • SecOps team members
  • CISO
  • CIO

Outcomes of this step

Outline of metrics you can configure your vulnerability scanning tool to report on.

Measure and formalize
Step 4.1Step 4.2Step 4.3Step 4.4

You can’t manage what you can’t measure

Metrics provides visibility.

  • Management consultant Peter Drucker introduced the concept of metrics tied to key performance indicators (KPIs), and the concept holds true: without metrics, you lack the visibility to manage or improve a process.
  • Metrics aren’t just a collection of statistics, they have to be meaningful, they have to tell the story, and most importantly, they have to answer the “so what?” question. What is the significance of a metric – do they illustrate a trend or an anomaly? What actions should be carried out when a metric hits a certain threshold?
  • It would be prudent to track several metrics that can be combined to tell the full story. For example, tracking the number of critical vulnerabilities alone does not give a sense of the overall risk to the organization, nor does it offer any information on how quickly they have been remediated or what amount of effort was invested.
Stock image of measuring tape.

Metrics, KPIs, and CSFs

Tracking the right information and making the information relevant.
  • There is often confusion between raw metrics, key performance indicators, and critical success factors.
  • Raw metrics are what is trackable from your systems and processes as a set of measurements without any context. Raw metrics in themselves are useful in telling the story of “what are we doing?”
  • KPIs are the specific metric or combination of metrics that help you track or gauge performance. KPIs tell the story of “how are we doing?” or “how well are we doing?”
  • CSFs are the specific KPIs that track the activities that are absolutely critical to accomplish for the business or business unit to be successful.
The activity tracker on your wrist is a wealth of metrics, KPIs, and CSFs.

If you wear an activity tracker, you are likely already familiar with the differences between metrics, key performance indicators, and critical success factors:

  • The raw metrics are your heart rate, step count, hours of sleep, caloric intake, etc.
  • KPIs are the individual goals that you have set: maintain a heart rate within the appropriate range for your age/activity level, achieve a step count goal per day, get x hours of sleep per night, consume a calorie range of y per day, etc.
  • CSFs are your overall goal: increase your cardiovascular capacity, lose weight, feel more energetic, etc.

Your security systems can be similarly measured and tracked – transfer this skill!

Tracking relevant information

Tell the story in the numbers.

Below are a number of suggested metrics to track, and why.

Business Goal

Critical Success Factor

Key Performance Indicator

Metric to track

Minimize overall risk exposureReduction of overall risk due to vulnerabilitiesDecrease in vulnerabilitiesTrack the number of vulnerabilities year after year.
Appropriate allocation of time and resourcesProper prioritization of vulnerability mitigation activitiesDecrease of critical and high vulnerabilitiesTrack the number of high-urgency vulnerabilities.
Consistent timely remediation of threats to the businessMinimize risk when vulnerabilities are detectedRemediate vulnerabilities more quicklyMean time to detect: track the average time between the identification to remediation.
Track effectiveness of scanning toolMinimize the ratio, indicating that the tool sees everythingRatio between known assets and what the scanner tracksScanner coverage compared to known assets in the organization.
Having effective tools to track and addressAccuracy of the scanning toolDifference or ratio between reported vulnerabilities and verified onesNumber of critical or high vulnerabilities verified, between the scanning tool’s criticality rating and actual criticality.
Reduction of exceptions to ensure minimal exposureVisibility into persistent vulnerabilities and risk mitigation measuresNumber of exceptions grantedNumber of vulnerabilities in which little or no remediation action was taken.

4.1.1 Measure your program with metrics, KPIs, and CSFs

60 minutes

Input: List of metrics current being measured by the vulnerability management tool

Output: List of relevant metrics to track, and the KPIs, CSFs, and business goals related to the metric

Materials: Whiteboard/flip charts, Vulnerability Management SOP Template

Participants: IT Security Manager, IT operations management, CISO

Metrics can offer a way to view how the organization is dealing with vulnerabilities and if there is improvement.

  1. Determine the high-level vulnerability management goals for the organization.
  2. Even with a formal process in place, the organization should be considering ways it can improve.
  3. Determine metrics that can help quantify those goals and how they can be measured.
  4. Metrics should always be easy to measure. If it’s a complex process to find the information required, it means that it is not a metric that should be used.
  5. Document your list of metrics in the Vulnerability Management SOP Template.

Download the Vulnerability Management SOP Template

Step 4.2

Vulnerability Management Policy

Activities
  • 4.2.1 Update the vulnerability management program policy

This step will walk you through the following activities:

If you have a vulnerability management policy, this activity may help augment it. Otherwise, if you don’t have one, this would be a great starting point.

This step involves the following participants:

  • IT Security Manager
  • CISO
  • CIO
  • Human resources representative

Outcomes of this step

An inaugural policy covering vulnerability management

Measure and formalize
Step 4.1Step 4.2Step 4.3Step 4.4

Vulnerability Management Program Policy

Policies provide governance and enforcement of processes.
  • Policies offer formal guidance on the “rules” of a program, describing its purpose, scope, detailed program description, and consequences of non-compliance. Often they will have a employee sign-off acknowledging understanding.
  • In many organizations, policies are endorsed by senior executives, which gives the policy its “teeth” across the company. The human resources department will always have input due to the implications of the non-compliance aspect.
  • Policies are written to ensure an outcome of consistent expected behavior and are often written to protect the company from liability.
  • Policies should be easy to understand and unambiguous, reflect the current state, and be enforceable. Enforceability can come in the form of audit, technology, or any other means of determining compliance and enforcing behavior.
Stock image of a judge's gavel.

4.2.1 Update the vulnerability management policy

60 minutes

Input: Vulnerability Management SOP, HR guidance on policy creation and approval

Output: Completed Vulnerability Management Policy

Materials: Vulnerability Management SOP, Vulnerability Management Policy Template

Participants: IT Security Manager, IT operations management, CISO, Human resources representative

After having built your entire process in this project, formalize it into a vulnerability management policy. This will set the standards and expectations for vulnerability management in the organization, while the process will be around the specific actions that need to be taken around vulnerability management.

This is separate and distinct from the Vulnerability Management SOP Template, which is a process and procedure document.
  1. Review Info-Tech’s Vulnerability Management Policy and customize it to your organization’s specifications.
  2. Use your Vulnerability Management SOP as a resource when specifying some of the details within the policy.
Sample of Info-Tech's Vulnerability Management Policy Template

Download the Vulnerability Management Policy Template

Step 4.3

Select and implement a scanning tool

Activities
  • 4.3.1 Create an RFP for vulnerability scanning tools

This step will walk you through the following activities:

If you need to select a new vulnerability scanning tool, or replace your existing one, this activity will help set up a request for proposal (RFP).

This step involves the following participants:

  • IT Security Manager
  • SecOps team members
  • CISO

Outcomes of this step

The provisions needed for you to create and deploy an RFP for a vulnerability management tool.

Measure and formalize
Step 4.1Step 4.2Step 4.3Step 4.4

Vulnerability management and penetration testing

Similar in nature, yet provide different security functions.

Vulnerability Scanning Tools

Scanning tools focus on the network and operating systems. These tools look for items such as missing patches or open ports. They won’t detect specific application vulnerabilities.

Exploitation Tools

These tools will look to exploit a detected vulnerability to validate it.

Penetration Tests

A penetration test simulates the actions of an external or internal cyber attacker that aims to breach the information security of the organization. (Formal definition of penetration test)

‹————— What’s the difference again? —————›
Vulnerability scanning tools are just one type of tool.When you add an exploitation tool to the mix, you move down the spectrum.Penetration tests will use scanning tools, exploitation tools, and people.

What is the value of each?

  • For vulnerability scans, the person performing the scan provides the value – value comes from the organization itself.
  • For exploitation tools on their own, the value comes from the tool itself being used in a safe environment.
  • For penetration tests, the tester is providing the value. They are the value add.

What’s the implication for me?

Info-Tech Recommends:
  • A combination of vulnerability scanning and penetration testing. This will improve your security posture through systematic risk reduction and improve your security program through the testing of prevention, detection, and response capabilities with unique recommendations being generated.
  • Start with as much vulnerability scanning as possible to identify gaps to fix and then move onto a penetration test to do a more robust and validated assessment.
  • For penetration tests, start with a transparent box test first, then move to an opaque box. Ideally, this is done with different third parties.

Vulnerability scanning software

All organizations can benefit from having one.

Scanning tools will benefit areas beyond just vulnerability management

  • Network security: It improves the accuracy and granularity of your network security technologies such as WAFs, NGFWs, IDPS, and SIEM.
  • Asset management: Vulnerability scanning can identify new or unknown assets and provide current status information on assets.
  • System management: Information from a vulnerability scan supports baselining activities and determination of high-value and high-risk assets.

Vulnerability Detection Use Case

Most organizations use scanners to identify and assess system vulnerabilities and prioritize efforts.

Compliance Use Case

Others will use scanners just for compliance, auditing, or larger GRC reasons.

Asset Discovery Use Case

Many organizations will use scanners to perform active host and application identification.

Scanning Tool Market Trends

Vulnerability scanning tools have expanded value from conventional checking for vulnerabilities to supporting configuration checking, asset discovery, inventory management, patch management, SSL certificate validation, and malware detection.

Expect to see network and system vulnerability scanners develop larger vulnerability management functions and develop exploitation tool functionality. This will become a table stakes option enabling organizations to provide higher levels of validation of detected vulnerabilities. Some tools already possess these capabilities:

  • Core Impact is an exploitation tool with vulnerability scanning aspects.
  • Metasploit is an exploitation tool with some new vulnerability scanning aspects.
  • Nessus is mainly a vulnerability scanning tool but has some exploitation aspects.

Device proliferation (BYOD, IoT, etc.) is increasing the need for stronger vulnerability management and scanners. This is driving the need for numerous device types and platform support and the development of baseline and configuration norms to support system management.

Increased regulatory or compliance controls are also stipulating the need for vulnerability scanning, especially by a trusted third party.

Organizations are outsourcing security functions or moving to cloud-based deployment options for any security technology they can. Expect to see massive growth of vulnerability scanning as a service.

Vulnerability scanning market

There are several technology types or functional differentiators that divide the market up.

Vulnerability Exploitation Tools

  • These will actually test defences and better emulate real life than just scanning. These tools include packet manipulation tools (such as hping) and password cracking tools (such as John the Ripper or Cain and Abel).
  • These tools will provide much more granular information on your network, operations systems, and applications.
  • The main limitation of these tools is how to use them. If you do not have development or test environments that mimic your real production environments to run the exploit tools, these tools may not be appropriate. It may work if you can find some downtime on production systems, but only in very specific and careful instances.
  • Lower maturity security programs usually just do network and application vulnerability scanning. Higher maturity programs will also use penetration testing, application testing, and vulnerability exploitation tools.
  • Network vulnerability scanning tools should always be used. Once you identify any servers or ports running web applications, then you run a web application vulnerability scanner.
  • Exploitation tools and application testing tools are used in more specific use cases that are often related to more-demanding security programs.

Scanning Tool Market Trends

  • These are considered baseline tools and are near commoditization.
  • Vulnerability scanning tools are not granular enough to detect application-level vulnerabilities (thus the need for application scanners and testing tools) and they don’t validate the exploitability of the vulnerability (thus the need for exploit tools).

Web Application Scanning Tools

These tools perform dynamic application security testing (DAST) and static application security testing (SAST).

Application Scanning and Testing Tools

  • These perform a detailed scan against an application to detect any problematic or malicious code and try to break the application using known vulnerabilities.
  • These tools will identify if something is vulnerable to an exploit but won’t actually run the exploit.
  • These tools are evaluated based on their ability to detect application-specific issues and validate them.

Vulnerability scanning tool features

Evaluate vulnerability scanning tools on specific features or functions that are the best differentiators.

Differentiator

Description

Deployment OptionsDo you want a traditional on-premises, cloud-based, or managed service?
Vulnerability Database CoverageScanners use a library of known vulnerabilities to test for. Evaluate based on the amount of exploits/vulnerabilities the tool can scan for.
Scanning MethodEvaluate if you want agent-based, authenticated active, unauthenticated active, passive, or some combination of those scanning methods.
IntegrationWhat is the breadth of other security and non-security technologies the tool can integrate with?
RemediationHow detailed are the recommended remediation actions? The more granular, the better.

Differentiator

Description

PrioritizationDoes the tool evaluate vulnerabilities based on commonly accepted methods or through a custom-designed prioritization methodology?
Platform SupportWhat is the breadth of environment, application, and device support in the tool? Consider your need for virtual support, cloud support, device support, and application-specific support. Also consider how often new scanning modules are supported (e.g. how quickly Windows 10 was supported).
PricingAs with many security controls that have been around for a long time and are commonly used, pricing becomes a main consideration, especially when there are so many open-source options available.

Common areas people mistake as tool differentiators:

  • Accuracy – Scanning tools are evaluated more on efficiency than effectiveness. Evaluate on the ability to detect, remediate, and manage vulnerabilities rather than real vulnerability detection and the number of false positives. To reduce false positives, you need to use exploitation tools.
  • Performance – Scanning tools have such a small footprint in an environment and the actual scanning itself is such a small impact that evaluation on performance doesn’t matter.

For more information on vulnerability scanning tools and how they rate, review the Vulnerability Management category on SoftwareReviews.

Vulnerability scanning deployment options

Understand the different deployment options to identify which is best for your security program.

Option

Description

Pros

Cons

Use Cases

On-PremisesEither an on-premises appliance or an on-premises virtualized machine that performs external and internal scanning.
  • Small resource need, so limited network impact.
  • Strong internal scanning.
  • Easier integration with other technologies.
  • Network footprint and resource usage.
  • Maintenance and support costs.
  • Most common deployment option.
  • Appropriate if you have cloud concerns or strong internal network scanning, or if you require strong integration with other systems.
CloudEither hosted on a public cloud infrastructure or hosted by a third party and offered “as a service.”
  • Small network footprint.
  • On-demand scanning as needed.
  • Optimal external scanning capabilities.
  • Can only do edge-related scanning unless authenticated or agent based.
  • No internal network scanning with passive or unauthenticated active scanning methods.
  • Very limited network resources.
  • Compliance obligations that dictate external vulnerability scanning.
ManagedA third party is contracted to manage and maintain your vulnerability scanner so you can dedicate resources elsewhere.
  • Expert management of environment scanning, optimizing tool usage.
  • Most scanning work time is report customization and tuning and remediation efforts; thus, managed doesn’t provide sizable resource alleviation.
  • Third party has and owns the vulnerability information.
  • Limited staff resources or expertise to maintain and manage scanner.

Vulnerability scanning methods

Understand the different scanning methods to identify which tool best supports your needs.

Method

Description

Pros

Cons

Use Cases

Agent-Based ScanningLocally installed software gives the information needed to evaluate the security posture of a device.
  • Provides information that can’t be discovered remotely such as installed applications that aren’t running at a given time.
  • Device processing, memory, and network bandwidth impact.
  • Asset without an agent is not scanned.
  • Need for continuous scanning.
  • Organization has strong asset management
Authenticated Active ScanningTool uses authenticated credentials to log in to a device or application to perform scanning.
  • Provides information that can’t be discovered remotely such as installed applications that aren’t running at a given time.
  • Best accuracy for vulnerability detection across a network.
  • Aggregation and centralization of authenticated credentials creates a major risk.
  • All use cases.
Unauthenticated Active ScanningScanning of devices without any authentication.
  • Emulates realistic scan by an attacker.
  • Provides limited scope of scanning.
  • Some compliance use cases.
  • Perform after either agent or authenticated scanning.
Passive ScanningScanning of network traffic.
  • Lowest resource impact.
  • Not enough information can be provided for true prioritization and remediation.
  • Augmenting scanning technique to agent or authenticated scanning.

IP Management and IPv6

IP management and the ability to manage IPv6 is a new area for scanning tool evaluation.

Scanning on IPv4

Scanning tools create databases of systems and devices with IP addresses.
Info-Tech Recommends:

  • It is easier to do discovery by directing the scanner at a set IP address or range of IP addresses; thus, it’s useful to organize your database by IPs.
  • Do discovery by phases: Start with internet-facing systems. Your perimeter usually is well-defined by IP addresses and system owners and is most open to attack.
  • Stipulate a list of your known IP addresses through the DHCP registration and perform a scan on that.
  • Depending on your IP address space, another option is to scan your entire IP address space.

Current Problem With IP Addresses

IP addresses are becoming no longer manageable or even owned by organizations. They are often provided by ISPs or other third parties.

Even if it is your range, chances are you don't do static IP ranges today.

Info-Tech Recommends:

  • Agent-based scanning or MAC address-based scanning
  • Use your DHCP for scanning

Scanning on IPv6

First, you need to know if your organization is moving to IPv6. IPv6 is not strategically routed yet for most organizations.

If you are moving to IPv6, Info-Tech recommends the following:

  • Because you cannot point a scanner at an IPv6 IP range, any scanning tool needs to have a strategy around how to handle IPv6 and properly scan based on IP ranges.
  • You need to know IPv4 to IPv6 translations.
  • Evaluate vulnerability scanning tools on whether any IPv6 features are on par with IPv4 features.

If you are already on IPv6, Info-Tech recommends the following:

  • If you are on an IPv6 native network, it is nearly impossible to scan the network. You have to always scan your known addresses from your DHCP.

4.3.1 Create an RFP for vulnerability scanning tools

2 hours

Input: List of key feature requirements for the new tool, List of intersect points with current software, Network topology and layout of servers and applications

Output: Completed RFP document that can be distributed to vendor proponents

Materials: Whiteboard/flip charts, Vulnerability Scanning Tool RFP Template

Participants: IT Security Manager, IT operations managers, CISO, Procurement department representative

Use a request for proposal (RFP) template to convey your desired scanning tool requirements to vendors and outline the proposal and procurement steps set by your organization.

  1. Determine what kind of requirements will be needed for your scanning tool RFP, based on people, process, and technology requirements.
  2. Consider items such as the desired capabilities and the scope of the scanning.
  3. Conduct interviews with relevant stakeholders to determine the exact requirements needed.
  4. Use Info-Tech’s Vulnerability Scanning Tool RFP Template. It lists many requirements but can be customized to your organization’s specific needs.

Download the Vulnerability Scanning Tool RFP Template

4.3.1 Create an RFP for vulnerability scanning tools (continued)

Things to Consider:
  • Ensure there is adequate resource dedication to support and maintenance for vulnerability scanning.
  • Consider if you will benefit from an RFP. If there is a more appropriate option for your need and your organization, consider that instead.
  • If you don’t know the product you want, then perform an RFI.
  • In the RFP, you need to express your driving needs for the tool so the vendor can best understand your use case.
  • Identify who should participate in the RFP creation and evaluation. Make sure they have time available and it does not conflict with other items.
  • Determine if you want to send it to a select few or if you want to send it to a lot of vendors.
  • Determine a response date so you can know who is soliciting your business.
  • You need to have a process to handle questions from vendors.
Info-Tech RFP Table of Contents:
  1. Statement of Work
  2. General Information
  3. Proposal Preparation Instructions
  4. Scope of Work, Specifications, and Requirements
  5. Vendor Qualifications and References
  6. Budget and Estimated Pricing
  7. Vendor Certification

Download the Vulnerability Scanning Tool RFP Template

Step 4.4

Penetration testing

Activities
  • 4.1.1 Create an RFP for penetration tests

This step will walk you through the following activities:

We will review penetration testing, its distinction from vulnerability management, and why you may want to engage a penetration testing service.

We provide a request for proposal (RFP) template that we can review if this is an area of interest.

This step involves the following participants:

  • IT Security Manager
  • SecOps team members
  • CISO
  • CIO

Outcomes of this step

An understanding of penetration testing, and guidance on how to get started if there is interest to do so.

Measure and formalize
Step 4.1Step 4.2Step 4.3Step 4.4

Penetration testing

Penetration tests are critical parts of any strong security program.

Penetration testing will emulate the methods an attacker would use in the real world to circumvent your security controls and gain access to systems and data.

Penetration testing is much more than just running a scanner or other automated tools and then generating a report. Penetration testing performs critical exploit validation to create certainty around your vulnerability.

The primary objective of a penetration test is to identify and validate security weaknesses in an organization’s security systems.

Reasons to Test:

  • Assess current security control effectiveness
  • Develop an action plan of items
  • Build a business case for a better security program
  • Increased security budget through vulnerability validation
  • Third-party, unbiased validation
  • Adhere to compliance or regulatory requirements
  • Raise security awareness
  • Demonstrate how an attacker can escalate privileges
  • Effective way to test incident response

Regulatory Considerations:

  • There is a lot of regulatory wording saying that organizations can’t get a system that is managed, integrated, and supported by one vendor and then have it tested by the same vendor.
  • There is the need for separate third-party testing.
  • Penetration testing is required for PCI, cloud providers, and federal entities.

How and where is the value being generated?

Penetration testing is a service provided by trained and tested professionals with years of experience. The person behind the test is the most important part of the test. The person is able to emulate a real-life attacker better than any computer. It is just a vulnerability scan if you use tools or executables alone.

“A penetration test is an audit with validation.” (Joel Shapiro, Vice President Sales, Digital Boundary Group)

Start by considering the spectrum of penetration tests

Network Penetration Tests

Conventional testing of network defences.

Testing vectors include:

  • Perimeter infrastructure
  • Wireless, WEP/WPA cracking
  • Cloud penetration testing
  • Telephony systems or VoIP
Types of tests:
  • Denial-of-service testing
  • Out-of-band attacks
  • War dialing
  • Wireless network testing/war driving
  • Spoofing
  • Trojan attacks
  • Brute force attacks
  • Watering hole attacks
  • Honeypots
  • Cloud-penetration testing
Application Penetration Tests

Core business functions are now being provided through web applications, either to external customers or to internal end users.

Types: Web apps, non-web apps, mobile apps

Application penetration and security testing encompasses:

  • Code review – analyzing the application code for sensitive information of vulnerabilities in the code.
  • Authorization testing – testing systems responsible for user session management to see if unauthorized access can be permitted.
  • Authentication process for user testing.
  • Functionality testing – test the application functionality itself.
  • Website pen testing – active analysis of weaknesses or vulnerabilities.
  • Encryption testing – testing things like randomness or key strength.
  • User-session integrity testing.
Human-Centric Testing
  • Penetration testing is developing a people aspect as opposed to just being technology focused.
  • End users and their susceptibility to social engineering attacks (spear phishing, phone calls, physical site testing, etc.) is now a common area to test.
  • Social engineering penetration testing is not only about identifying your human vulnerabilities, but also about proactively training your end users. As well as discovering and fixing potential vulnerabilities, social engineering penetration testing will help to raise security awareness within an organization.

Info-Tech Insight

Your pen test should use multiple methods. Demonstrating weakness in one area is good but easy to identify. When you blend techniques, you get better success at breaching and it becomes more life-like. Think about prevention, detection, and response testing to provide full insight into your security defenses.

Penetration testing types

Evaluate four variables to determine which type of penetration test is most appropriate for your organization.

Evaluate these dimensions to determine relevant penetration testing.

Network, Application, or Human

Evaluate your need to perform different types of penetration testing.

Some level of network and application testing is most likely appropriate.

The more common decision point is to consider to what degree your organization requires human-centric penetration testing.

External or Internal

External: Attacking an organization’s perimeter and internet-facing systems. For these, you generally provide some level of information to the tester. The test will begin with publicly available information gathering followed by some kind of network scanning or probing against externally visible servers or devices (DNS server, email server, web server, firewall, etc.)

Internal: Carried out within the organization’s network. This emulates an attack originating from an internal point (disgruntled employee, authorized user, etc.). The idea is to see what could happen if the perimeter is breached.

Transparent, Semi-Transparent, or Opaque Box

Opaque Box: The penetration tester is not provided any information. This emulates a real-life attack. Test team uses publicly available information (corporate website, DNS, USENET, etc.) to start the test. These tests are more time consuming and expensive. They often result in exploitation of the easiest vulnerability.
Use cases: emulating a real-life attack; testing detection and response capabilities; limited network segmentation.

Transparent Box: Tester is provided full disclosure of information. The tester will have access to everything they need: building floor plans, data flow designs, network topology, etc. This represents what a credentialed and knowledgeable insider would do.
Use cases: full assessment of security controls; testing of attacker traversal capabilities.

Aggressiveness of the Test

Not Aggressive: Very slow and careful penetration testing. Usually spread out in terms of packets being sent and number of calls to individuals. It attempts to not set off any alarm bells.

Aggressive: A full DoS attack or something similar. These would be DoS attacks that take down systems or full SQL injection attacks all at once versus small injections over time. Testing options cover anything including physical tests, network tests, social engineering, and data extraction and exfiltration. This is more costly and time consuming.

Assessing Aggressiveness: How aggressive the test should be is based on the threats you are concerned with. Assess who you are concerned with: random individuals on the internet, state-sponsored attacks, criminals, hacktivists, etc. Who you are concerned with will determine the appropriate aggressiveness of the test.

Penetration testing scope

Establish the scope of your penetration test before engaging vendors.

Determining the scope of what is being tested is the most important part of a penetration test. Organizations need to be as specific as possible so the vendor can actually respond or ask questions.

Organizations need to define boundaries, objectives, and key success factors.

For scope:
  • If you go too narrow, the realism of the test suffers.
  • If you go too broad, it is more costly and there’s a possible increase in false positives.
  • Balance scope vs. budget.
Boundaries to scope before a test:
  • IP addresses
  • URLs
  • Applications
  • Who is in scope for social engineering
  • Physical access from roof to dumpsters defined
  • Scope prioritized for high-value assets
Objectives and key success factors to scope:
  • When is the test complete? Is it at the point of validated exploitation?
  • Are you looking for as many holes as possible, or are you looking for how many ways each hole can be exploited?

What would be out of scope?

  • Are there systems, IP addresses, or other things you want out of scope? These are things you don’t explicitly want any penetration tester to touch.
  • Are there third-party connections to your environment that you don’t want to be tested? These are instances such as cloud providers, supply chain connections, and various services.
  • Are there things that would be awkward to test? For example, determine if you include high-level people in a social engineering test. Do you conduct social engineering for the CEO? If you get their credentials, it could be an awkward moment.

Ways to break up a penetration test:

  • Location – This is the most common way to break up a penetration test.
  • Division – Self-contained business units are often done as separate tests so you can see how each unit does.
  • IT systems – For example, you put certain security controls in a firewall and want to test its effectiveness.
  • Applications – For example, you are launching a new website or a new portal and you want to test it.

Penetration testing appropriateness

Determine your penetration testing appropriateness.

Usual instances to conduct a penetration test:
  • Setting up a new physical office. Penetration testing will not only test security capabilities but also resource availability and map out network flows.
  • New infrastructure hardware implemented. All new infrastructure needs to be tested.
  • Changes or upgrades to existing infrastructure. Need for testing varies depending on the size of the change.
  • New application deployment. Need to test before being pushed to production environments.
  • Changes or upgrades to existing applications. When fundamental functional changes occur, perform testing:
    • Before upgrades or patching
    • After upgrades or patching
  • Periodic testing. It is a best practice to periodically test your security control effectiveness. Consider at least an annual test.

Specific timing considerations: Testing should be completed during non-production times of day. Testing should be completed after a backup has been performed.

Assess your threats to determine your appropriate test type:

Penetration testing is about what threats you are concerned about. Understand your risk profile, risk tolerance level, and specific threats to see how relevant penetration tests are.

  • Are external attackers concerning to you? Are you distressed about how an attacker can use brute force to enter your network? If so, focus on ingress points, such as FWs, routers, and DMZ.
  • Is social engineering a concern for you (i.e. phone-based or email-based)? Then you are concerned about a credentialed hacker.
  • Is it an insider threat, a disgruntled employee, etc.? This also includes an internal system that is under command and control (C&C).

ANALYST PERSPECTIVE: Do a test only after you take a first pass.
If you have not done some level of vulnerability assessment on your own (performing a scan, checking third-party sources, etc.) don’t waste your money on a penetration test. Only perform a penetration test after you have done a first pass and identified and remediated all the low-hanging fruit.

4.4.1 Create an RFP for penetration tests

2 hours

Input: List of criteria and scope for the penetration test, Systems and application information if white box

Output: Completed RFP document that can be distributed to vendor proponents

Materials: Whiteboard/flip charts, Penetration Test RFP Template

Participants: IT Security Manager, IT operations managers, CISO, Procurement department representative

Use an RFP template to convey your desired penetration test requirements to vendors and outline the proposal and procurement steps set by your organization.

  1. Determine what kind of requirements will be needed for your penetration test RFP based on people, process, and technology requirements.
    • Consider items such as your technology environment and the scope of the penetration tests.
  2. Conduct an interview with relevant stakeholders to determine the exact requirements needed.
  3. Use Info-Tech’s Penetration Test RFP Template, which lists many requirements but can be customized to your organization’s specific needs.

Download the Penetration Test RFP Template

4.4.1 Create an RFP for penetration tests (continued)

Steps of a penetration test:
  1. Determine scope
  2. Gather targeted intelligence
  3. Review exploit attempts, such as access and escalation
  4. Test the collection of sensitive data
  5. Run reporting
Info-Tech RFP Table of Contents:
  1. Statement of Work
  2. General Information
  3. Proposal Preparation Instructions
  4. Scope of Work, Specifications, and Requirements
  5. Vendor Qualifications and References
  6. Budget and Estimated Pricing
  7. Vendor Certification

Download the Penetration Test RFP Template

Penetration testing considerations – service providers

Consider what type of penetration testing service provider is best for your organization

Professional Service Providers

Professional Services Firms. These firms will often provide a myriad of professional services across auditing, financial, and consulting services. If they offer security-related consulting services, they will most likely offer some level of penetration testing.

Security Service Firms. These are dedicated security consulting or advisory firms that will offer a wide spectrum of security-related services. Penetration testing may be one aspect of larger security assessments and strategy development services.

Dedicated Penetration Testing Firms. These are service providers that will often offer the full gamut of penetration testing services.

Integrators

Managed Security Service Providers. These providers will offer penetration testing. For example, Dell SecureWorks offers numerous services including penetration testing. For organizations like this, you need to be skeptical of ulterior motives. For example, expect recommendations around outsourcing from Dell SecureWorks.

Regional or Small Integrators. These are service providers that provide security services of some kind. For example, they would help in the implementation of a firewall and offer penetration testing services as well.

Info-Tech Recommends:

  • Always be conscientious of who is conducting the testing and what else they offer. Even if you get another party to test rather than your technology provider, they will try to obtain you as a client. Remember that for larger technology vendors, security testing is a small revenue stream for them and it’s a way to find technology clients. They may offer penetration testing for free to obtain other business.
  • Most of the penetration testers were systems administrators (for network testing) or application developers (for application testing) at some point before becoming penetration testers. Remember this when evaluating providers and evaluating remediation recommendations.
  • Evaluate what kind of open-source tools, commercial tools, and proprietary tools are being used. In general, you don’t want to rely on an open-source scanner. For open source, they will have more outdated vulnerability databases, system identification can also be limited compared to commercial, and reporting is often lacking.
  • Above all else, ensure your testers are legally capable, experienced, and abide by non-disclosure agreements.

Penetration testing best practices – communications

Communication With Service Provider

  • During testing there should be designated points of contact between the service provider and the client.
  • There needs to be secure channels for communication of information between the tester and the client both during the test and for any results.
  • Results should always be explained to the client by the tester, regardless of the content or audience.
  • There should be a formal debrief with the results report.
Immediate reporting of issues
  • Before any testing commences, immediate reporting conditions need to be defined. These are instances when you would want immediate notification of something occurring.
  • Stipulate certain systems or data types that if broken into or compromised, you would want to be notified right away.
  • Example:
    • If you are conducting social engineering, require notification for all account credentials that are compromised. Once credentials are compromised, it destroys all accountability for those credentials and the actions associated with those credentials by any user.
    • Require immediate reporting of specific high-critical systems that are compromised or if access is even found.
    • Require immediate reporting when regulated data is discovered or compromised in any way.

Communication With Internal Staff

Do you tell your internal staff that this is happening?

This is sometimes called a “double blind test” when you don’t let your IT team know of the test occurring.

Pros to notifying:
  • This tests the organization’s security monitoring, incident detection, and response capabilities.
  • Letting the team know they are going to see some activity will make sure they don’t get too worried about it.
  • There may be systems you can’t jeopardize but still need to test so notification beforehand is essential (e.g. you wouldn’t allow ERP testing with notification).
Cons:
  • It does not give you a real-life example of how you respond if something happens.
  • Potential element of disrespect to IT people.

Penetration testing best practices – results and remediation

What to expect from penetration test results report:

A final results report will state all findings including what was done by the testers, what vulnerabilities or exploitations were detected, how they were compromised, the related risk, and related remediation recommendations.

Expect four major sections:
  • Introduction. An overview of the penetration test methodology including rating methodology of vulnerabilities.
  • Executive Summary. A management-level description of the test, often including a summary of any recommendations.
  • Technical Review. An overview of each item that was looked at and touched. This area breaks down what was done, how it was done, what was found, and any related remediation recommendations. Expect graphs and visuals in this section.
  • Detailed Findings. An in-depth breakdown of all testing methods used and results. Each vulnerability will be explained regarding how it was detected, what the risk is, and what the remediation recommendation is.
Two areas that will vary by service provider:

Prioritization

  • Most providers will boast their unique prioritization methodology.
  • A high, medium, and low rating scale based on some combination of variables (e.g. ease of exploitation, breadth of hole, information accessed resulting in further exploitation).
  • The prioritization won’t take into account asset value or criticality.
  • Keep in mind the penetration test is not an input into ultimate vulnerability prioritization, but it can help determine your urgency.

Remediation

  • Remediation recommendations will vary across providers.
  • Generally, fairly generic recommendations are provided (e.g. remove your old telnet and input up-to-date SSH).
  • Most of the time, it is along the lines of “we found a hole; close the hole.”

Summary of Accomplishment

Problem Solved

At the conclusion of this blueprint, you will have created a full vulnerability management program that will allow you to take a risk-based approach to vulnerability remediation.

Assessing a vulnerability’s risk will enable you to properly determine the true urgency of a vulnerability within the context of your organization; this ensures you are not just blindly following what the tool is reporting.

The risk-based approach will allow you to prioritize your discovered vulnerabilities and take immediate action on critical and high vulnerabilities while allowing your standard remediation cycle to address the medium to low vulnerabilities.

With your program defined and developed, you now need to configure your vulnerability scanning tool or acquire one if you don’t already have a tool in place.

Lastly, while vulnerability management will help address your systems and applications, how do you know if you are secure from external malicious actors? Penetration testing will offer visibility, allowing you to plug those holes and attain an environment with a smaller risk surface.

If you would like additional support, have our analysts guide you through other phases as part of an Info-Tech workshop.

Contact your account representative for more information.

workshops@infotech.com 1-888-670-8889

Additional Support

If you would like additional support, have our analysts guide you through other phases as part of an Info-Tech workshop.

Photo of Jimmy Tom.

Contact your account representative for more information.

workshops@infotech.com 1-888-670-8889

To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-Tech analyst team.

Info-Tech analysts will join you and your team at your location or welcome you to Info-Tech’s historic Toronto office to participate in an innovative onsite workshop.

The following are sample activities that will be conducted by Info-Tech analysts with your team:

Sample of the Implement Vulnerability Management storyboard.
Review of the Implement Vulnerability Management storyboard
Sample of the Vulnerability Mitigation SOP template.
Build your vulnerability management SOP

Contributors

Contributors from 2016 version of this project:

  • Morey Haber, Vice President of Technology, BeyondTrust
  • Richard Barretto, Manager, Information Privacy and Security, Cimpress
  • Joel Shapiro, Vice President Sales, Digital Boundary Group

Contributors from current version of this project:

  • 2 anonymous contributors from the manufacturing sector
  • 1 anonymous contributor from a US government agency
  • 2 anonymous contributors from the financial sector
  • 1 anonymous contributor from the medical technology industry
  • 2 anonymous contributors from higher education
  • 1 anonymous contributor from a Canadian government agency
  • 7 anonymous others; information gathered from advisory calls

Bibliography

Arya. “COVID-19 Impact: Vulnerability Management Solution Market | Strategic Industry Evolutionary Analysis Focus on Leading Key Players and Revenue Growth Analysis by Forecast To 2028 – FireMon, Digital Shadows, AlienVault.” Bulletin Line, 6 Aug. 2020. Accessed 6 Aug. 2020.

Campagna, Rich. “The Lean, Mean Vulnerability Management Machine.” Security Boulevard, 31 Mar. 2020. Accessed 15 Aug. 2020.

Constantin, Lucian. “What are vulnerability scanners and how do they work?” CSO Online, 10 Apr. 2020. Accessed 1 Sept. 2020.

“CVE security vulnerabilities published in 2019.” CVE Details. Accessed 22 Sept. 2020.

Garden, Paul, et al. “2019 Year End Report – Vulnerability QuickView.” Risk Based Security, 2020. Accessed 22 Sept. 2020.

Keary, Eoin. “2019 Vulnerability Statistics Report.” Edgescan, Feb. 2019. Accessed 22 Sept. 2020.

Lefkowitz, Josh. ““Risk-Based Vulnerability Management is a Must for Security & Compliance.” SecurityWeek, 1 July 2019. Accessed 1 Nov. 2020.

Mell, Peter, Tiffany Bergeron, and David Henning. “Creating a Patch and Vulnerability Management Program.” Creating a Patch and Vulnerability Management Program. NIST, Nov. 2005. Web.

“National Vulnerability Database.” NIST. Accessed 18 Oct. 2020.

“OpenVAS – Open Vulnerability Assessment Scanner.” OpenVAS. Accessed 14 Sept. 2020.

“OVAL.” OVAL. Accessed 21 Oct. 2020.

Paganini, Pierluigi. “Exploiting and Verifying Shellshock: CVE-2014-6271.” INFOSEC, 27 Sept. 2014. Web.

Pritha. “Top 10 Metrics for your Vulnerability Management Program.” CISO Platform, 28 Nov. 2019. Accessed 25 Oct. 2020.

“Risk-Based Vulnerability Management: Understanding Vulnerability Risk With Threat Context And Business Impact.” Tenable. Accessed 21 Oct. 2020.

Stone, Mark. “Shellshock In-Depth: Why This Old Vulnerability Won’t Go Away.” SecurityIntelligence, 6 Aug. 2020. Web.

“The Role of Threat Intelligence in Vulnerability Management.” NOPSEC, 18 Sept. 2014. Accessed 18 Aug. 2020.

“Top 15 Paid and Free Vulnerability Scanner Tools in 2020.” DNSstuff, 6 Jan. 2020. Accessed 15 Sept. 2020.

Truta, Filip. “60% of Breaches in 2019 Involved Unpatched Vulnerabilities.” Security Boulevard, 31 Oct. 2019. Accessed 2 Nov. 2020.

“Vulnerability Management Program.” Core Security. Accessed 15 Sept. 2020.

“What is Risk-Based Vulnerability Management?” Balbix. Accessed 15 Sept. 2020.

White, Monica. “The Cost Savings of Effective Vulnerability Management (Part 1).” Kenna Security, 23 April 2020. Accessed 20 Sept. 2020.

Wilczek, Marc. “Average Cost of a Data Breach in 2020: $3.86M.” Dark Reading, 24 Aug. 2020. Accessed 5 Nov 2020.

About Info-Tech

Info-Tech Research Group is the world’s fastest-growing information technology research and advisory company, proudly serving over 30,000 IT professionals.

We produce unbiased and highly relevant research to help CIOs and IT leaders make strategic, timely, and well-informed decisions. We partner closely with IT teams to provide everything they need, from actionable tools to analyst guidance, ensuring they deliver measurable results for their organizations.

Member Rating

9.0/10
Overall Impact

$229,314
Average $ Saved

44
Average Days Saved

After each Info-Tech experience, we ask our members to quantify the real-time savings, monetary impact, and project improvements our research helped them achieve.

Read what our members are saying

What Is a Blueprint?

A blueprint is designed to be a roadmap, containing a methodology and the tools and templates you need to solve your IT problems.

Each blueprint can be accompanied by a Guided Implementation that provides you access to our world-class analysts to help you get through the project.

Get off the patching merry-go-round and start mitigating risk!

Need Extra Help?
Speak With An Analyst

Get the help you need in this 4-phase advisory process. You'll receive 8 touchpoints with our researchers, all included in your membership.

Guided Implementation #1 - Identify vulnerability sources
  • Call #1 - Scope requirements, objectives, and your specific challenges.
  • Call #2 - Discuss current state and vulnerability sources.

Guided Implementation #2 - Triage vulnerabilities and assign priorities
  • Call #1 - Identify triage methods and business criticality.
  • Call #2 - Review current defense-in-depth and discuss risk assessment.

Guided Implementation #3 - Remediate vulnerabilities
  • Call #1 - Discuss remediation options and scheduling.
  • Call #2 - Review release and change management and continuous improvement.

Guided Implementation #4 - Measure and formalize
  • Call #1 - Identify metrics, KPIs, and CSFs.
  • Call #2 - Review vulnerability management policy.

Author

Jimmy Tom

Contributors

  • 2 anonymous contributors from the manufacturing sector
  • 1 anonymous contributor from a US government agency
  • 2 anonymous contributors from the financial sector
  • 1 anonymous contributor from the medical technology industry
  • 2 anonymous contributors from higher education
  • 1 anonymous contributor from a Canadian government agency
  • 7 anonymous others, information gathered from advisory calls
Visit our COVID-19 Resource Center and our Cost Management Center
Over 100 analysts waiting to take your call right now: 1-519-432-3550 x2019