CompTIA CySA+ Cybersecurity Analyst Certification: Threat and Vulnerability Management - Vulnerability Management Activities

Objective 1.3  Given a scenario, perform vulnerability management activities

Vulnerability Identification
As cybersecurity analysts, we’re tasked with performing vulnerability identification to determine how exploitable our organization is as well as with remediating discovered vulnerabilities before attackers find them first.
So, what is a vulnerability? As it relates to information security, vulnerabilities are weaknesses in an information system’s design, implementation, operation, or management that, when exploited, can lead to the compromise of the confidentiality, integrity, or availability of that system. Countless vulnerabilities exist, so we will need to define a broader selection of vulnerabilities to get things started. Following are some examples of common potential vulnerabilities:
- Hardware: Susceptibility to humidity, dust, moisture, electrostatic discharge (ESD), and inadequate physical protection
- Software: Lack of testing and auditing, design flaws, missing patches, legacy, and misconfiguration
- Network: Unprotected cables, insecure network architecture, poor or missing encryption, poor segmentation, and poorly positioned network appliances
- Personnel: Poor recruiting practices, lack of security policy adherence, and poor cybersecurity awareness
- Physical site: Susceptibility to floods, fires, power outages, unauthorized entry, lack of surveillance, and lack of security guards
- Organizational: Lack of business continuity plans and disaster recovery plans

Vulnerability identification is a big undertaking that involves consistent internal vulnerability assessments, in addition to the acquisition of vulnerability intelligence from numerous vulnerability identification sources, as listed here:
- CVE
- Exploit Database
- IT system audit reports
- National Vulnerability Database (NVD)
- Open Web Application Security Project (OWASP)
- Previous risk assessments
- SANS Internet Storm Center
- Security advisories
- Security requirements checklist
- System security testing
- US-CERT
- Vendor advisories (Cisco, IBM, Google, Microsoft)
- Vulnerability listings
This module is about performing a variety of vulnerability management activities. We’ll start by fleshing out some important vulnerability identification considerations, including asset criticality, active and passing scanning, and mapping and enumeration techniques.

Asset Criticality
Determining the criticality of organizational assets helps us prioritize our vulnerability management efforts. Assets are anything of value to the organization, including its people, facilities, networks, systems, information, processes, and reputation. Asset values are usually described in quantitative or qualitative terms:
- Quantitative: Measure of asset value expressed numerically. For example, an organization values a firewall asset at $1,000 for its replacement cost.
- Qualitative: Measure of asset value expressed in a more scenario-driven or generalized way. For instance, the organization values that same firewall asset as “critical” to its business processes.
- Semi-quantitative: Measure of asset value expressed in both quantitative and qualitative terms.
Organizations often perform “asset valuations” as part of broader cybersecurity initiatives like risk management and business continuity planning. Central to these initiatives is the determination of which assets are most critical to the organization. Being able to answer the following questions will help with this effort:
- Criticality: Which assets are most critical for the organization to continue its normal operations?
- Probability: Which assets have the highest probability of being compromised (lost, stolen, made obsolete, or experiencing a failure)?
- Impact: Which assets would cause the highest financial impact to the organization if compromised? What would be the non-financial impacts to the organization, such as loss of reputation?

Note: Remember, the identification of critical assets helps anchor the organization’s vulnerability remediation efforts to the most critical assets first.

Active vs. Passive Scanning
The most direct way to identify system vulnerabilities is through vulnerability scanning. Vulnerability scanning is the process of scanning hardware and software systems to identify weaknesses. These weaknesses can include the following:
- Application flaws
- Buffer overflow
- Default installations
- Default passwords
- Design flaws
- Misconfigurations
- Missing patches
- Open services
- Operating system flaws

In addition to being knowledgeable about the different types of vulnerabilities, you should also be aware of the active and passive ways in which scanning tools collect vulnerability data:
- Active scanning: Occurs when a scanning tool identifies system vulnerabilities by communicating directly with the system. For example, the OpenVAS vulnerability scanner scans a system and identifies dozens of well-known Windows 10 vulnerabilities officially tagged with CVE IDs.
- Passive scanning: Occurs when a scanning tool indirectly identifies system vulnerabilities but does not communicate with the system. Instead, the scanner looks for any unusual behaviors or known issues by observing the system’s network traffic. As an example, the Wireshark packet sniffer captures packets coming from an Internet-facing web server sending out NetBIOS or SMB traffic—which will invite all kinds of trouble if not immediately resolved.

Exam tip: Active scanning will result in more detailed vulnerability information but at the expense of the increased system and network resources. Conversely, passive scanning generates little to no load on the system and network resources but generally yields fewer vulnerability insights. It is helpful to the analyst to have a mixture of passive and active scans.

Mapping/Enumeration
Vulnerability scanning focuses on telling us what vulnerabilities we have, yet this is just a single step on the vulnerability assessment ladder. Sometimes referred to as vulnerability mapping or enumeration, vulnerability assessments are the broader process of identifying, quantifying, and prioritizing vulnerabilities with our devices and software. Mapping all the network assets and enumerating potentially vulnerable services through scans is important, but our cybersecurity posture will not be enhanced until we complete the full set of steps of vulnerability assessments, as outlined here:
- Discover: Perform a complete inventory of hardware and software assets.
- Assign criticality: Label assets according to organizational criticality.
- Identify vulnerabilities: Scan assets to identify vulnerabilities (vulnerability scanning occurs here).
- Assess risk: Determine the likelihood of threats exploiting vulnerabilities.
- Mitigate risk: Remediate vulnerabilities based on priority and cost-effectiveness.

Exam tip: The ultimate goals of vulnerability assessments are to explain the vulnerability risks faced by the organization before mitigation and to devise a plan to remediate the vulnerabilities before attackers exploit them.

Validation
After identifying potential vulnerabilities, the next step is to make sure they are real. Vulnerability validation is the process of reconciling the potential vulnerabilities with other information sources inside and outside the organization. Validation attempts to answer the following questions:
- Are the reported vulnerabilities real or false positives?
- Did this scan cover all assets, including mobile devices, cloud services, and even the Internet of Things (IoT)?
- How exploitable are the vulnerabilities?
- Can we correlate the vulnerabilities with other data points in our environment?
- How much risk do the vulnerabilities pose to the organization?

The key is to correlate vulnerability scan results with other data points, such as network, operating system, or application logs. As with witnesses in a trial, if multiple sources say something is true, it’s more likely to be the case.

Note: Vulnerability remediation depends on an accurate vulnerability report. Without accurate vulnerability information, the organization would likely miss potential vulnerabilities that would not be remediated.
Vulnerability validation can yield many results, which can include true positives, false positives, true negatives, and false negatives. Let’s take a look at each of these in the following sections.

True Positive
A true positive occurs when an assessment tool correctly indicates the presence of a specific vulnerability that we do in fact have. In other words, our tool cried “wolf” when there was indeed a wolf present.

Scenario: True Positive
Tenable’s Nessus vulnerability scanner correctly detected a “critical” Linux vulnerability with Bash Remote Code Execution (Shellshock). The CVE ID is CVE-2014-6271.

False Positive
A false positive occurs when an assessment tool falsely indicates the presence of a specific vulnerability that we do not have. In other words, our tool cried “wolf” when there wasn’t a wolf present. Another name for a false positive is a Type I error.

Scenario: False Positive
A web application scanner indicates the presence of a specific SQL injection vulnerability when in reality there it isn’t present.

Note: Although the web application scanner may have been wrong with this particular indication, it doesn’t mean that there aren’t any SQL injection vulnerabilities lurking about on the web server.

True Negative
A true negative occurs when an assessment tool correctly does not indicate the presence of a specific vulnerability because there isn’t one. In other words, our tool does not cry “wolf” because there isn’t a wolf present.

Scenario: True Negative
You use an Nmap script to scan a system for the Heartbleed bug but were unable to locate the vulnerability because the system already had implemented Heartbleed bug patches.

False Negative
A false negative occurs when an assessment tool neglects to indicate a specific vulnerability that is present. In other words, our tool does not cry “wolf” even though a wolf is present. A false negative is also known as a Type II error.

Scenario: False Negative
Microsoft recently publicized new vulnerabilities with Windows 10. Using Nessus, you scan systems and were unable to detect the vulnerabilities. You then realize that Nessus hasn’t been updated in a week. After updating Nessus, you re-run the scans and successfully discover the recently publicized vulnerabilities. To be clear, this scenario has now changed from false negative to true positive.

Note: Whereas a false positive can take up time and other resources in the effort to identify it or validate a finding, a false negative is the worst possible scenario because there is a vulnerability that goes unidentified and therefore unmitigated.

Remediation/Mitigation
After we’ve finished scanning, identifying, and validating vulnerabilities, we finally arrive at remediation. What qualifies as remediation? Let’s take a look:
- Patch vulnerabilities, upgrade, or change configurations for hardware, operating systems, and applications.
- Perform larger-scale refresh on organizational infrastructure.
- Make changes to governing policies, processes, procedures, and configuration standards.

Note: Despite the temptation, don’t rush remediation unless you’re willing to risk adding new vulnerabilities or losing functionality to one or more systems. Mitigations are more like surgery than applying a band-aid; therefore, care must be taken.

We’re also not rushing through remediation because several prerequisite steps need to be taken in advance:
- Organizational budget: Ensure mitigations are funded.
- Staff and infrastructure resources: Ensure remediations can be facilitated.
- Prioritization: Ensure we focus on the most important remediations first. These priorities might be based on vulnerabilities with the highest critical CVSS scores or the criticality of the assets themselves.
- Quality assurance testing: Ensure remediations are tested in a sandboxed environment to ensure they don’t break anything.
- Change control: Ensure proposed remediations conform to organizational change control policy. Remember, sometimes remediations can break functionality.
- Timelines: Ensure remediation predictability while minimizing disruption to other business units.
Although rushing is risky, moving too slowly is even riskier. Severe organizational losses can result from the exploitation of a single vulnerability. Navigating between the two fires of “caution” and “urgency” requires mastery of supporting processes such as configuration baselines, patching, hardening, compensation controls, risk acceptance, and verification of mitigation—all of which we’re covering in the next several sections.

Configuration Baseline
Although most vulnerabilities are mitigated with patches, others are resolved by changing configurations to a device, operating system, or application. Yet, a potential roadblock to configuration changes is the existence of configuration baselines. Configuration baselines are a documented set of technical specifications for devices, operating systems, or applications that have been formally reviewed and agreed on at a given point in time. Proposing a change to a system’s configuration means we’re looking to create a new configuration baseline. Such a change can only proceed through an established change control process that ensures such proposals are properly vetted for considerations of costs, benefits, and compliance with organizational policies.
Assuming the change control committee approves the configuration change request, the prescribed remediation will be scheduled for deployment to resolve a particular vulnerability. Assuming this goes well, the current configuration state will be adopted as the newest configuration baseline.

Note: What if a new configuration results in no change in vulnerability status, introduces a new vulnerability, or causes a system functionality loss? If remediation goes wrong, we can always return a system’s configuration to the most recent configuration baseline that worked.

Patching
No matter how great an individual or team of software developers are, all software has flaws. These flaws can affect anything from the software’s functionality, security, to its reliability. Most flaws discovered by vendors and attackers alike will be security-related. As vulnerabilities are discovered, developers create and distribute software “patches” to fix the flaws. Patching is the process of applying a software fix to an operating system, application, or hardware devices such as the firmware for firewalls, intrusion detection systems (IDSs), and intrusion prevention systems (IPSs).
Remediation through patching sometimes feels like you’re picking your poison. If you patch systems too quickly, you risk breaking your systems. If you patch systems too slowly through initial quality assurance testing, you risk security flaws being exploited. Many organizations deploy a centralized patch management system to ensure that patches are deployed in a not-too-fast, not-too-slow manner. With this system, administrators can test and review all patches before deploying them to the systems they affect. Administrators can also schedule updates to occur during non-peak hours to minimize business impact. This is a good time to mention patch criticality—those patches that are deemed critical have priority over those that simply fix functionality. The criticality of systems or patches plays a role in scheduling and managing patches.

Types of Patches
Patches come in all sorts of varieties; the following list details the types of patches you can see in a Microsoft environment. Although other operating systems (such as macOS and Linux) have different names for their updates, they are similar in functionality.
- Security patch: Software updates that fix operating system and application vulnerabilities. Typically scheduled for release on a predictable cycle (like Microsoft’s original Patch Tuesday).
- Hotfix Critical updates for various software issues that, unlike patches, should not be delayed.
- Service packs: Large collection of updates for a particular operating system or application released as one installable package. A service pack usually includes new features, patches, and hotfixes. This is now frowned upon due to the turbulence experienced by combining new features and patches.
- Rollups: Cumulative updates that contain a group of patches or hotfixes for a particular piece of software.
- Feature updates (bi-annually): New versions of Windows 10 that come out roughly every six months during the spring and fall. They are focused on providing new OS features only.
- Quality updates (monthly): Monthly cumulative updates to Windows 10 patches that fix bugs and errors, patch security vulnerabilities, and improve the reliability with the OS. They do not include new features.

Hardening
As discussed previously, vulnerability remediations also stem from changed configurations. Earlier you learned how configuration baselines help lock in a standard set of system configurations. However, what security benefits do we gain from security baselines? Simply, our systems get “hardened.” Hardening is the general process of securing a system by reducing its attack surface. In other words, we’re reducing the number of ways adversaries can attack our systems by removing unnecessary system components and services, securing configuration settings, and patching security flaws.

The following are some examples of hardening techniques:
- Remove or disable unnecessary or built-in accounts.
- Change default passwords.
- Remove unnecessary applications.
- Disable unnecessary services.
- Apply patches.
- Restrict USB, Bluetooth, FireWire, Wi-Fi, and NFC access on host devices, as appropriate.

Exam tip: Hardening techniques must only be implemented to the extent that they meet security objectives, which must, in turn, align with organizational objectives. Security must always be balanced with both functionality and available resources.

Compensating Controls
For a variety of reasons, our preferred cybersecurity controls aren’t always effective, don’t always work the way we plan, or can’t be fully implemented. Rather than doing nothing, as a result, we come up with a “Plan B,” which is called compensating controls. A compensating control is an alternative security control put into place to compensate for any technical or business constraints placed upon a primary security control. Constraints can mean technology failures as well as lack of budget, personnel, or even expertise. Regardless of the cause, it’s important to choose compensating controls that help fill in any security gaps left behind to ensure the organization maintains compliance with security requirements.
According to Payment Card Industry Data Security Standard (PCI DSS) v3.2.1, organizations must ensure that compensating controls satisfy the following criteria:
- Meet the intent and rigor of the originally stated requirement.
- Provide a similar level of defense as the original PCI DSS requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against.
- Be “above and beyond” other PCI DSS requirements.
- Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement.
Curious to see some examples of primary and compensating controls?
 

Compensating Controls


Risk Acceptance
So, we’ve completed the trifecta of identifying, validating, and remediating vulnerabilities to all our valued hardware, operating systems, and applications. What does this ultimately mean? It means that the original risks presented by the vulnerabilities have been reduced to a level that we must determine if it is enough. That level is what we call risk acceptance, which means that we will accept any residual risk that remains after all mitigations have been applied. We acknowledge that bad stuff can still happen, but we’re willing to “risk it.” At this tipping point, spending more dollars to reduce the risk further would be counterproductive.

Caution: Never forget that the goal is to reduce risk to an acceptable level. Go any further, and you might harm the organization’s ability to perform crucial business tasks. If security negatively affects an organization’s business processes, that, in itself, increases the organization’s risk.

Verification of Mitigation
After we mitigate all known vulnerabilities, we should rerun our vulnerability scans to verify that previously identified vulnerabilities are gone and that no new vulnerabilities have been introduced. To be extra safe, verification may involve a separate auditing process to ensure remediated vulnerabilities are truly gone. This step not only helps you see that mitigations were successful but also ensures transparency and accountability across the company. It is through this verification process that we arrived at the point of risk acceptance.

Scanning Parameters and Criteria
Vulnerability scanning is relatively straightforward once all the key vulnerability scanning decisions, parameters, and other information are sorted out in advance.

Although there’s a lot to consider, here is a brief description of those questions that we’re going to need answers to:
- Risk: Are we prepared to mitigate the risks that scanning introduces, such as downtime?
- Vulnerability feed: Are we getting the most up-to-date vulnerability information?
- Scope: Which systems are we going to scan?
- Credentialed vs. non-credentialed: Do we require authentication to scan systems?
- Server-based vs. agent-based: Do the assets require locally installed scanning software or can it be done remotely?
- Internal vs. external: Will scans be conducted on internal or external assets, and will they be conducted from within the organization or outside on the Internet?
- Special considerations: Data types, technical constraints, workflows, sensitivity levels, and regulatory requirements.

Risks Associated with Scanning Activities
Ironically, vulnerability scans not only help reduce organizational risk, but also introduce some risk of their own. For example, if too many vulnerability scanner plug-ins are selected—particularly the DoS variety—a scan could crash certain systems. Vulnerability scans can also consume a lot of network bandwidth and system resources. The cybersecurity analyst would be wise to address any deterioration in the system and network performance of the target systems during scanning.
Malicious or improper use of scanning tools also presents a risk to the organization through the harm that may be caused to systems. A risk assessment might be to determine what risks are presented by vulnerability scanning, and how they should be mitigated beforehand. The organization would be well-served to establish policies and procedures that formalize vulnerability assessments.
Yet another risk, albeit a controlled one, is the risk that required downtime to scan introduces to critical business processes. We should consider standing up alternative processing systems that can take over while primary ones are being scanned or make the decision as to whether we can afford to halt critical processes while we are scanning.

Vulnerability Feed
Like threat intelligence feeds, vulnerability feeds are repositories of vulnerabilities made available to the public via commercial or community sources. Although your vulnerability scanning tool will likely be connected to its vendor-specific vulnerability feed, many scanners, like Nessus, have a connector to the NIST NVD via a standardized set of vulnerability best practices collectively called the Security Content Automation Protocol (SCAP). Regardless of your fed, you need to ensure that it is reliable and has the most up-to-date information on current vulnerabilities.

Note: SCAP was created by NIST as a way of standardizing the way vulnerability scanning practices are expressed, including automation, reporting, scoring, and prioritization of scans.

Scenario: Nessus Vulnerability Feed
As part of a PCI DSS quarterly requirement, you initiate a vulnerability scan on your Windows workstations using Nessus. Once the scan is completed, the tool generates a report indicating dozens of vulnerabilities, including one in particular labeled CVE-2020-0796. This vulnerability affects the Server Message Block 3.1.1 protocol on Windows 10 and Windows Server 2016. It also achieves the rare distinction of a CVSS Base Score of 10.0 (Critical). Further research reveals this vulnerability can be patched via the KB4551762 update.

Scope
The scope of a scan defines which systems and networks will be scanned and how they will be scanned. You may wish to broaden the scope to see more potential issues or narrow it down to quickly identify problems you already suspect are present. Generally, the scope is all-encompassing in that scans will cover the entire organization. Yet, larger organizations tend to have network hierarchies divided up by firewalls, routers, and switches; therefore, more targeted scans on a segment-by-segment basis will be common. The risks and criticality of assets will often drive the scope of scans.

Exam tip: Scope might also include time-of-day requirements and frequency to ensure scans minimize impact to the business.

Credentialed vs. Non-Credentialed
Credentialed or non-credentialed scanning (also known as authenticated or unauthenticated scanning)? That is an important question. When a vulnerability scanner is using a domain or system account (typically a privileged account) to perform a vulnerability scan on a target, this is known as a credentialed scan. Not surprisingly, a non-credentialed scan involves a vulnerability scanner not using a domain or system account to perform the scan.
Credentialed scans are generally considered the superior of the two because, simply stated, more rights equal more vulnerability data acquired. Since the scan is conducted from the context of an authenticated user with elevated credentials, you’ll see a view of the system’s security posture from that account’s perspective. You can expect to see more detailed reporting, less false positives, and more accurate reporting, too.
The best thing about non-credentialed scans is their “disconnected” nature makes such scans easier to execute and faster to complete. Plus, they don’t require the provisioning of an account to conduct the scan, and they are less resource-intensive on both the network and the system being scanned. Another possible advantage to a non-credentialed scan is that by getting the same results an attacker would see if they do not have credentials, you can target vulnerabilities that are more visible and likely to be “low-hanging fruit” for an attacker.

Caution: Non-credentialed scans are easier, but easier doesn’t equate to more discovery and remediation of vulnerabilities. Avoid non-credentialed scans unless your goal is to simulate the vulnerability scanning perspective of the attacker.

Server-Based vs. Agent-Based
Vulnerability scanning generally falls into one of two camps: server-based or agent-based. Server-based scans (agentless), which is sometimes known as network-based scanning, occur when a vulnerability scanner is installed on a single physical or virtual machine and scans a variety of other systems over the network. Here are the benefits of agentless-based scanning:
- Scans will work on devices that don’t support agents.
- Scans can be performed immediately.
- Scans don’t require the initial overhead of deploying agents to all devices.


Caution: Agentless scans are often frowned upon due to the number of network resources they consume. You’ll be better off performing agentless scans during business off-hours.
The preferred of the two, agent-based scanning, involves the installation of software (agent) on assets that require vulnerability scans. Although agents may be installable on network devices, you’ll more commonly find them on servers, workstations, or laptops. The benefits of agent-based scans are as follows:
- False positives are reduced.
- Reports contain greater accuracy and detail.
- Scans are generated within the system and then sent to the server; therefore, there is very little network overhead.
- Scans are more comprehensive when they run with privileges and are launched from within the target system.
- Scans can be scheduled to run during business hours on non-critical assets.
- Scans can be tailored to run on a frequency tailored to compliance requirements.
- Scans can run using credentials native to the system; therefore, no separate credentials are required.
- Scans can run on disconnected devices such as company laptops, smartphones, and tablets.

Internal vs. External
Internal vulnerability scans are conducted from within the internal network, which is the same as saying “behind the firewall.” Internal scans are conducted on internal organizational assets such as desktops, laptops, servers, VoIP phones, scanners, and printers. It is commonly performed to verify proper patching has occurred while providing valuable insights into your patch management process. You may also be interested in simply generating a report of vulnerabilities in your environment.

Note: Given the vantage point of being on the “inside,” and the tendency to use credentials to authenticate the scans, you should expect to collect a lot more vulnerability details from internal scans.
External vulnerability scans are conducted from an Internet system, or “outside” the firewall, to identify holes in your organization’s perimeter network and systems. Chief among them is the identification of firewall vulnerabilities and open ports. You’ll also want to look at other perimeter systems such as your public-facing web server, e-mail server, DNS server, VPN server, reverse proxy server, and more. You are more likely to encounter the use of external scans if you use a “scanning-as-a-service” cloud-based provider rather than setting up your scanning infrastructure.

Caution: External scanning provides organizations with the “hacker viewpoint” of your network. Remediation of any vulnerable assets here should be a high priority.

Special Considerations
There are other considerations to vulnerability scanning that don’t fit neatly into any of the previous categories. These are the topics we’re going to expand upon throughout the next section:
- Types of data: What data types will we need to scan?
- Technical constraints: Will any technology, resource availability, or licensing constraints hinder our scans?
- Workflow: When and how should scans be performed to minimize the business impact?
- Sensitivity levels: What sensitivity should our scanning tools assign to vulnerabilities?
- Regulatory requirements: How frequently should scans be performed?
- Segmentation: How will segmentation help “compensate” for our vulnerability gaps?
- Intrusion prevention system (IPS) and firewall settings How might the configurations of network appliances affect vulnerability scans?

Types of Data
Vulnerability scanners can usually scan more data types than anyone would need. As a result, you’ll typically want to condense the scanning of data to what is needed for regulatory or compliance purposes. Compliance-based scans will often compel you to scan sensitive or classified data types since vulnerabilities in these areas would need to be prioritized. You’ll also want to be mindful that scanning different data types, and the subsequent reporting, will be driven by different target audiences. When in doubt, get feedback from key stakeholders in the organization to determine what data types should be scanned. Also, limiting the types of files scanned improves the performance of the scan and our ability to enumerate the results.

Technical Constraints
Another valuable NIST publication, SP 800-115, “Technical Guide to Information Security Testing and Assessment,” states that security assessments require resources such as time, staff, hardware, and software, and resource availability is often a limiting factor in the type of frequency of security assessments. In short, vulnerability scans can only be as effective as the technical resources afforded to them. Top-tier vulnerability scanners like Nessus and OpenVAS won’t do much good if the network infrastructure, servers, desktops, laptops, and mobile devices aren’t powerful enough to support the scans. Then, of course, there’s the expertise (or lack thereof) of the technology professionals who are wielding the vulnerability scanning tools alongside those networks and systems. Finally, if you only have one scanning device, you are limited by the amount of scanning a single device can perform.

Note: Licensing constraints with commercial vulnerability scanners may impair your scanning in terms of the number of IP addresses that can be scanned, bandwidth consumed, or the number of scans running concurrently.

Workflow
In quantum physics, the “observer effect” states that the mere observation of a phenomenon changes that phenomenon. Scanning systems is a form of observation, and one that could result in a system performing noticeably slower or, worse, becoming unavailable if we’re not careful. We also want to be mindful of the experts conducting and analyzing the scan results. They, too, are not an unlimited resource.
Whether we’re following the compliance requirements of PCI DSS or the requirements or guidelines of our internal security policies, what we want are standardized and repeatable vulnerability management processes. The impact of vulnerability scanning to organizational workflows should’ve already been figured out earlier when we were talking about risks associated with vulnerability scanning. Stemming from our requirements or guidelines is the need to maximize organizational workflow. This may involve constraining our scans to business off-hours, throttling the resource consumption of scans to minimize the impact of those systems during business hours, or reducing the frequency of the scans.

Sensitivity Levels
With seemingly endless systems to scan, cybersecurity analysts should take note of which systems contain sensitive data. Prioritization should guide every facet of vulnerability management. If any systems have the following sensitive data types, it should be prioritized for detection and remediation:
- Classified data (confidential, secret, top secret)
- Personally identifiable information (PII) such as Social Security numbers or addresses
- Financial information such as credit card numbers or bank account information
- Passwords
- Driver’s license or passport numbers
- Medical information

Note: These systems present a serious confidentiality risk to the organization if they were ever breached. They should be addressed before moving onto lesser critical systems.
Recall our previous discussion on how scanning introduces risks of its own to systems? If you think about it, this creates a double-edged sword. Scanning can sometimes create availability challenges for systems, and systems with sensitive data can’t afford to be unavailable. Is the risk of making the sensitive data unavailable through the scan greater than the risk of not detecting and mitigating the system’s vulnerabilities after being scanned? The good news is, as cybersecurity analysts, we’re tasked with determining precisely which systems containing sensitive data should be scanned immediately versus deferred to a more opportune time to prevent potential availability issues.

Regulatory Requirements
Organizations are beholden to legal and regulatory requirements, which can vary based on country, state, or industry. Industry standards such as PCI DSS require vulnerability scans to be performed quarterly, after significant network changes take place, and by an approved vendor, for example, so we comply with the standard. Failing to abide by regulatory requirements can result in severe fines, business shutdown, and even the arrest of certain senior leadership members.
Here’s a short list of examples of other compliance standards and their requirements regarding vulnerability scans:
- ISO 27001: Requires scans to be performed in a timely fashion
- HIPAA: Doesn’t specifically require network vulnerability scans, but it does require the assimilation of vulnerability data that is best collected from network vulnerability scans
- FISMA: Requires an annual report on selected controls that is typically satisfied through NIST’s requirement for an organizationally defined scanning frequency

Cross-Reference
Compliance is covered in more detail in Domain 5.0.

Segmentation
Mitigating vulnerabilities with patches and configuration changes is great, but there’s a small problem. They might be initially delayed by a few weeks to undergo the necessary change management and testing procedures. Although temporary, this gap in our security poses a significant risk to the organization. Fortunately, compensating controls can help here, particularly in the form of network segmentation.
Segmentation is the practice of dividing networks into smaller logically or physically separated subnetworks to enhance performance, manageability, and security. Without segmentation, attackers can take advantage of a single point of compromise to potentially breach all networked systems. With segmentation in place, we can perform vulnerability scans on very specific segments without affecting the performance of other systems. This might be a good idea when we must scan critical hosts but can’t afford the downtime or delay in scanning the entire network. With segmentation, we can better manage and schedule scans to account for downtime and delays due to the configuration management process. Scanning specific segments incrementally can also help to identify and remediate any segmentation weaknesses in firewall rules, network switch configurations, or even with air-gapped systems.

Note: Typically reserved for the most extreme scenarios, air gapping provides the most restrictive type of segmentation. Air-gapped devices have zero network connectivity with anything. The most common way to exchange data with an air-gapped device is through a USB flash drive.
Segmentation is also vital to the containment phase of incident response. To prevent malware from running amuck, a properly configured segment can help isolate malware from further spread.

Intrusion Prevention System (IPS), Intrusion Detection System (IDS), and Firewall Settings
Like anything else, network appliances like firewalls, IPSs, and IDSs have vulnerable default rules and configurations that an IT or security professional should change immediately.

Failure to do so could lead to the following outcomes:
- Vulnerable firewall: Permits unauthorized access to networks and systems or unauthorized blocking of networks and systems.
- Vulnerable IDS: Increased false negatives of well-known malicious traffic.
- Vulnerable IPS Increased false negatives of well-known malicious traffic. Also, compromised IPSs can lead to unauthorized traffic dropping.

Inhibitors to Remediation
It should be simple enough to solve problems once you have the solution, right? Not exactly. There are several possible remediation inhibitors, including the fear that remediation could temporarily disrupt or degrade business continuity, lack of approval from stakeholders, legacy or proprietary system challenges, and contractual restrictions. We’re going to take a look at each of these considerations in the next several sections.

Memorandum of Understanding (MOU)
A memorandum of understanding (MOU) is usually a legally non-binding document used to describe an agreement between two or more parties. It is a written agreement documenting a set of intended actions between the parties concerning some common pursuit or goal. MOUs may contain specific security requirements or limitations on scanning scopes, frequency, schedule, and more. Because of their non-binding nature, MOUs are most often used between internal divisions of a larger single organization to delineate support responsibilities. For agreements between two different organizations, which are typically required to have legal enforcement, you likely will see contracts or service level agreements used.

Service Level Agreement (SLA)
A service level agreement (SLA) is an agreement between parties detailing the expectations of services to be provided to consumers by a service provider. SLAs are typically included as part of a service contract and set the level of technical expectations. As with MOUs, SLAs may contain specific requirements on scanning scopes, frequency, schedule, and more.

Organizational Governance
Organizational governance refers to the process of top-level management exerting strategic control over all organizational functions. The governance committee ensures that all managerial roles under it are following business processes to ensure the business vision, mission, and objectives are being met. With the focus on business objectives cemented into their minds, governance committees may not see the benefits of certain cybersecurity initiatives and may fail to approve certain remediation efforts. Organizational security governance is most often seen in the forms of an information security strategy and security policies that articulate rules and requirements. Policy, the primary instrument of internal organizational governance, can be a double-edged sword here. A policy may dictate particulars with vulnerability scanning that both constrain the cybersecurity analysts responsible for vulnerability while at the same time force different divisions within the organization to allow their assets to be scanned and remediated.

Business Process Interruption
As discussed earlier in the module, scanning should not be performed to the extent that it outright prevents the organization from conducting business. However, there must be a balance between vulnerability scanning and remediation and conducting business processes. There are different ways to allow these two divergent processes to coexist, such as scanning primary systems while business processes are running on secondary systems, scheduling scans during off-peak business hours, and deferring scans until business processes can safely be interrupted. All of these involve accepting some level of risk.

Degrading Functionality
Largely just a smaller version of business interruption, we don’t want vulnerability scans can occasionally disrupt or degrade systems and applications in the infrastructure. For less-crucial systems, this may be tolerated, but certainly not for critical systems. As previously mentioned, the organization should consider deferring the vulnerability assessments to a more opportune time to limit or prevent the degradation of functionality. If this proves not possible, the organization should research alternative solutions or consider accepting the risk as it is.

Legacy Systems
Legacy systems are any devices, operating systems, applications, or other technologies that are outdated but still in use at the organization. Although these products still work, they probably aren’t supported by the vendor anymore, which usually means no more patches are being produced. However, some organizations aren’t aware of which systems (and how many of them) constitute a legacy system and what risks they present to the business. A vulnerability scan may help us identify such systems and, hopefully, identify any present vulnerabilities afflicting them.
So, how does one remediate legacy system vulnerabilities if the vendor has abandoned the product? Although we can’t mitigate the vulnerability directly, we can implement compensating controls such as system hardening, monitoring, and segmentation to minimize the inherent risk to the organization.

Proprietary Systems
Perhaps more difficult to mitigate than legacy systems are proprietary systems. Whereas legacy systems are largely outdated but otherwise well-known entities, proprietary systems are more likely to be fringe, and, by extension, obscure to us.
A good example of a proprietary system is a supervisory control and data acquisition (SCADA) system, which you’ll encounter in industrial environments like power, water, sewage, and nuclear organizations. Whereas traditional computing systems usually have a better balance of confidentiality, integrity, and availability capabilities, SCADA equipment is designed to be available, period. Such a design can make certain security efforts almost impossible. Although patching is often made available, it can take months of testing before approval due to the critical nature of the systems.

Scenario: SCADA
A large power company has merged much of its SCADA systems with its IP-based network. Despite the company gaining enhanced control and monitoring benefits, the merger also exposes the SCADA systems to a new frontier of IP-based attacks that they weren’t designed to deal with. Given the proprietary nature of the SCADA equipment, vulnerability scans are run with surgical precision to offset the risk of knocking a SCADA system offline (for many of these organizations, this is would be a serious incident). After coordinating with the SCADA vendor, the company decides to chance installing a patch during its annual maintenance period.

Note: Some oil companies are known to wait a couple of years before installing a patch to ensure all the kinks have been ironed out. There are few organizations in the world more risk-averse than the industrial variety.

Review
Objective 1.3: Given a scenario, perform vulnerability management activities

Vulnerability identification is an important part of the vulnerability management process. The key to this effort is the identification and prioritization of the most critical organizational assets to ensure their vulnerabilities are addressed first. Given the variety of system and network types under your purview, you’ll likely employ a combination of active and scanning techniques to ensure all required systems can be scanned.
After identifying potential vulnerabilities, the next step is ensuring they are valid. Vulnerability validation helps us separate real vulnerabilities from false positives, determine their exploitability, correlate them with other data points in our environment, and evaluate their overall risk to the organization.
Once we validate the existence and severity of our organization’s vulnerabilities, we create a plan to remediate the vulnerabilities. Remediation will typically involve installing software patches or implementing configuration changes. Planning mitigations is crucial because cybersecurity analysts must navigate the potential minefield of change management procedures, revisions to configuration baselines, hardening requirements, and compensating controls in case mitigations fail. The success of mitigations must be independently verified to determine that our vulnerability risk is at an acceptable level.
Many factors influence vulnerability scanning in terms of when, how, and where they should be performed. The risk of the scans themselves will need to be ironed out. Tempering the scanning risks requires a balanced approach of keeping abreast of the latest vulnerability feed data, scoping scans to only required internal or external systems and networks, knowing when to use credentials (or not), and knowing when agents are a viable option (or not). In addition, we need to know what data type should be scanned, any constraints placed upon our scans, and any potential interruptions of workflows (particularly to systems with sensitive data), as well as ensure all regular requirements on vulnerability scans are met.
Despite the complexities inherent in the preceding criteria, there are also several potential remediation inhibitors, including the fear that remediation could temporarily disrupt or degrade business continuity, lack of approval from stakeholders, legacy or proprietary system challenges, and contractual restrictions contained in MOUs or SLAs.