Implement Risk-Based Vulnerability Management

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

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

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.

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.

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.

• 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.

Vulnerability Management

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

1

Identify

• scanning tool
• external threat intel
• internal threat intel

2

Analyze

Triage based on risk ›

Your organization's risk tolerance threshold

3

Assess

• risk tolerance
• compensating controls
• business impact

Key deliverable:

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.

Template for your vulnerability management policy.

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

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

Methodology to assess vulnerability risk by determining impact and likelihood.

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.

Define the process, scope, roles, vulnerability sources, and current state
• Consultant at $100 an hour for 16 hours = $1,600

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

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

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

Phase 1

Phase 2

Phase 3

Phase 4

Call #2: Discuss current state and vulnerability sources.

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

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

Call #8: Review vulnerability management policy.

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

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

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

• 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 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.

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.

Arrows denote direction of information feed

• 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

• Incident Management: Standardize the Service Desk and Incident and Problem Management
• Release Management: Stabilize Release and Deployment Management
• Change Management: Optimize Change Management
• IT Asset Management: Implement Hardware Asset Management and Implement Software Asset Management
• Security Risk Management: Combine Security Risk Management Components Into One Program
• Threat Intelligence: Integrate Threat Intelligence Into Your Security Operations
• Application Security Testing: Five Fundamentals of a Successful Application Test Strategy
• Vulnerability Disclosure: Design a Coordinated Vulnerability Disclosure Program

• 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 Insight

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

Case Study

INDUSTRY: Manufacturing
SOURCE: Cimpress, 2016

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.

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.

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.

• 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)?

• 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.

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.

• 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.

• 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.

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

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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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 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.

For guidance on tool vendors

Visit SoftwareReviews for information on vulnerability management tools and vendors.

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

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-scanning-as-a-Service can provide hands-free continuous monitoring of your systems. This is usually priced as a subscription model.

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.

• 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).

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.

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 formalized crisis management, take a look at Info-Tech’s blueprint Implement Crisis Management Best Practices.

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

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.

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.

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.

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.

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.

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?

Each piece of data should be ranked as High, medium, or low across confidentiality, integrity, and availability based on adverse effect.

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.

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.

• 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.

• 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.

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 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.

• 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

Download the Vulnerability Management SOP Template

• 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.

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.

• 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.

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.

• 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

• 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.

Download the Vulnerability Management Risk Assessment Tool

Download the Vulnerability Management Risk Assessment Tool

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.

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.

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

• 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.

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 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

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.

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.

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.

• 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 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.

• 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.

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.

• 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

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.

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.

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.

• 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

Risk acceptance of vulnerabilities

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.

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.

“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.

• 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 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.

• 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.

• 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 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.

• 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.

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.

• 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.

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.

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

• 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.

• 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.

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!

Business Goal

Critical Success Factor

Key Performance Indicator

Metric to track

• 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.

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.

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.

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

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 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?

• 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.

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 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.

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.

Option

Description

Pros

Cons

Use Cases

• 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.

• 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.

• 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.

Method

Description

Pros

Cons

Use Cases

• 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

• 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.

• Emulates realistic scan by an attacker.

• Provides limited scope of scanning.

• Some compliance use cases.
• Perform after either agent or authenticated scanning.

• Lowest resource impact.

• Not enough information can be provided for true prioritization and remediation.

• Augmenting scanning technique to agent or authenticated scanning.

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.

• 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.

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

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)

Conventional testing of network defences.

Testing vectors include:

• Perimeter infrastructure
• Wireless, WEP/WPA cracking
• Cloud penetration testing
• Telephony systems or VoIP

• 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

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.

• 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.

Network, Application, or Human

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

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.)

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.

Aggressiveness of the Test

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.

• 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.

• IP addresses
• URLs
• Applications
• Who is in scope for social engineering
• Physical access from roof to dumpsters defined
• Scope prioritized for high-value assets

• 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?

• 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.

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.

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

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

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.

• 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

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

• 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).

• It does not give you a real-life example of how you respond if something happens.
• Potential element of disrespect to IT people.

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.”

Contact your account representative for more information.

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