Organizations identify and then categorize and assess their vulnerability as part of their ongoing security assessment efforts. To do this, they conduct vulnerability scans that check their assets for known vulnerabilities. Assets include servers, routers, and other hardware devices. In addition, assets also include operating systems and their installed applications and services. Vulnerabilities found on an asset may be exploited, allowing an intruder to gain access to a company’s network. Therefore, it’s important to identify vulnerabilities and remediate them, but assessing vulnerabilities requires more than scanning and fixing them. In fact, fully assessing vulnerabilities requires an understanding of the vulnerabilities that exist, the likelihood of exploit, and the business drivers and requirements that influence how they are remediated or handled.
As with any security endeavor, this process starts by determining the goals of vulnerability scanning for the organization. Clearly identified goals can help ensure that the scan results are meaningful and have the most impact. If no scanning has previously been done, it is wise to step back and assess the goals prior to initiating a vulnerability scanning program. Obviously, the overarching goal is to reduce the number of unaddressed vulnerabilities in an environment to reduce risk. However, running a vulnerability scan on the entire network would likely be a huge mistake. It could easily result in such a massive amount of data that sorting through the results would take weeks and resolving issues may not be done in a timely manner. Ask some questions to aid in identifying an appropriate scope for your scanning efforts.
- What servers and devices support business-critical functions?
- Which hosts are accessible via the Internet and therefore at greater risk of compromise?
- Where are databases and file repositories with sensitive information?
The answers to these questions can help identify a starting point for your vulnerability identification efforts. However, it is indeed only a starting point. It is foolish to think there are unimportant devices that do not need to be remediated. A variety of entry points into your network exist that you may not think are important, in the traditional sense. However, that unpatched vulnerability may be all an attacker needs to completely compromise your network.
There are several popular tools that can be used for vulnerability scanning, including open source and commercial options. They all share common features. They are automated tools that scan a range of IP addresses or a single host and identify vulnerabilities, missing patches, and other security issues on the targeted hosts. They typically include a severity classification, a brief description, and information regarding patching or remediating the vulnerability. For example, the scan may identify a web server with known weaknesses in its TLS cipher suite. It can classify the ciphers identified by the scan as weak, medium, or strong. Based on the security posture of the organization, the company can then mandate the use of only the strong cipher suites, so those ciphers are no longer utilized. Many of the items found will only be informational, such as the presence of a web server. Critical issues may include a Common Vulnerability Scoring System (CVSS) score, a scoring system created by NIST.
As a best practice in security, vulnerability scans should be conducted regularly, and findings from these scans should be remediated in a timely fashion. Continuous scanning is an increasingly common option, often in partnership with continuous integration and DevOps practices that result in constant changes and upgrades in software and IT infra- structure. A common practice is to scan each change before it is approved for production, after it enters production, and on a recurring basis. With some organizations making hundreds or thousands of changes a day, continuous scanning is a necessity to match that rate of change.
In addition, certain industry regulations, such as PCI DSS and the Health Insurance Portability and Accountability Act (HIPAA), mandate regular vulnerability scans and prompt remediation of critical vulnerabilities. New assets should also be scanned whenever they are added to the network. Changes, such as the upgrade of an application, installation of a software package, or reconfiguration of a service or firewall, should also require a rescan of the affected asset. In addition, for a vulnerability scanning program to be effective, it is important to have all of these best practices included as corporate policy.
Communication and Planning
Vulnerability scanning tools generate a lot of traffic toward the scan target. Depending on the total number of targets being scanned, this can create issues with traffic load through network devices, such as switches and routers, and the load may also overwhelm a target. Some targets being scanned may also behave erratically after the scan is completed. The target may become unresponsive, or erratic behavior may not manifest until hours after the scan because of application instability or other problems caused by the scanner. In addition to network and service problems, scans can create alerts in system and security management tools, and need to be accounted for or added to exception lists so that they do not create additional work or alerts.
Planning for all possible contingencies is the best solution to the unexpected impact from scanning. That is easier said than done, of course. When planning the vulnerability scan, determine the route through the network the traffic will take. Which devices in the network will carry the load? This may be a collection of routers and switches. Owners of the devices should be identified, emergency contacts and escalation processes should be documented, and all scanning activity should be coordinated with the owners and customers who may be impacted. This includes determining who may be impacted if one of the network devices fails or suffers from degraded performance during scanning. Quite quickly, the negative impact of the scan can grow. It may be prudent to have someone con- duct the actual scan, while another individual coordinates communication for the scan.
Because of these issues, it is important to have a documented and defined process for the vulnerability scan, which includes communication of the testing to any parties that may be impacted by an outage. This includes the server and application owners, management, and customers, as appropriate. A new vulnerability scanning program may begin by scanning a development or test network. As confidence in the settings and process increases, scanning of production servers may begin. Scanning should also initially be conducted during nonproduction times or during a scheduled maintenance window for the organization, if possible. It is also important to ensure that scanning doesn’t conflict with maintenance or other activities that might be negatively impacted by the scan, such as backups or patching. In continuous scanning environments, system designs need to account for continuous scanning as part of how maintenance, upgrades, and patching are done.
Scanning certain systems and applications may also have unintended consequences. For example, some scanning tools may complete forms and submit them automatically or add useless information into a back-end database. This is especially common when scanning web applications. Consider preventive measures in these scenarios, for example:
- Identify any systems that have mail forms or back-end database.
- Redirect the emails or disable email functionality temporarily.
- Back up the database prior to the scan, and restore it after the scan.
- Consider disabling any alerting that triggers text or email alerts to staff for the duration of the scan.
By communicating the plan, informing the appropriate parties, testing, and taking appropriate precautions, vulnerability scanning can be an invaluable resource for improving an organization’s overall security.
Part of the planning process should also include the identification of critical systems. In fact, if the company has completed a business continuity plan (BCP) or may have prepared a business impact analysis (BIA), this information may already be available and can be used to identify critical systems. Scanning critical systems may cause outages, so these systems should be handled with the greatest care. Additionally, remediating vulnerabilities on these systems should be the highest priority. If there is no information available from the BCP or BIA, then you can use the following criteria as a starting point for identifying critical servers:
- Supports business critical operations
- Contains sensitive information (such as PCI, HIPAA, PII, or financial information)
- Provides critical network services (such as Domain Name System, Active Directory, or authentication)
Critical servers typically should be scanned and remediated before noncritical servers. Often common sense should prevail. However, ensure that management is aware of the findings, risks, and prioritization of remediation tasks.
Scan Configuration Considerations
Most scans can be configured to scan less aggressively by throttling the rate of packets sent to the target. This can aid in preventing unexpected consequences from a saturated network. Start cautiously by sending traffic at a lower and slower rate, and increase it in subsequent tests. Monitor equipment, including network equipment, the targeted services, and DNS, when significantly changing the test parameters. Don’t hesitate to contact the scanning tool’s support team to clarify functionality or review settings and features. Ideally, members of the network team and server teams especially should be available while scanning in case of an outage or issue. This can minimize downtime if there’s an outage.
Another technique that can help prevent outages when running scans is to disable any potentially unsafe tests. Many scanning tools provide an ability to disable unsafe checks, either by manually deselecting them or by turning off a category of tests that are known to have potential negative impacts. It is important to understand the types of tests that are enabled so that a conscious decision can be made about unsafe tests.
Other typical scanning configuration options include selecting credentialed or non- credentialed scans. A noncredentialed scan sends traffic to the open ports on the server to determine whether vulnerabilities or issues exist. A credentialed scan is a feature that allows the scanning tool to additionally connect to a target and log in with valid credentials to perform testing. The scanning tool must be configured with the credentials needed to log in. Credentialed scans are generally preferable, for several reasons:
- Reduced traffic on the network, by using fewer packets to identify vulnerabilities on the server
- Increased accuracy, by checking for file versions associated with known vulnerabilities
- Improved vulnerability identification, as some issues can be identified only by logging into the server, such as enumerating applied patches to identify missing patches
It is common to have a different set of scan settings for different servers that you are scanning, as a single group of settings is rarely sufficient for most organizations. Organizations may choose to have specific configurations for Linux and Windows servers, workstations, Supervisory Control and Data Acquisition (SCADA) or Industrial Control System (ICS) devices, or applications and servers with known issues that are caused by scans. Crafting scan policies to balance effective, efficient security assessment against resources and time is a key task for security professionals.
When first reviewing scan results, the number of vulnerabilities is often much larger than anticipated, especially for systems that may have older versions of soft- ware, such as Java or Flash. It’s important to understand how the scanner counts vulnerabilities and the difference between the number of vulnerabilities and the number of fixes that need to be applied. Simply, five vulnerabilities may all be resolved by a single patch.
For example, say an application called Widget v5.0 had a security vulnerability.
The scanner will check for Widget v5.0. The issue was theoretically patched in Widget v5.1. Another bug was found, and Widget v5.2 was created, as well as Widget v5.3. Each version had a bug that was patched in the subsequent version. Now, assume the target system is scanned, and it is on Widget v5.0. The vulnerability scanner may indicate the system has three vulnerabilities: one for each version of the application 5.0, 5.1, and 5.2, except for 5.3, which is the latest version.
So, the application has three vulnerabilities; however, one update to version 5.3 will resolve the issues identified in Widget v5.0, 5.1, and 5.2; a single patch brings the application up to date and resolves the three vulnerabilities. Because of the differences in the number of vulnerabilities versus the number of patches needed, it may be preferable to modify the scan settings to help reduce the number of vulnerabilities and the paper- work that each generates. For instance, most scanners allow vulnerability checks to be disabled. A vulnerability scanner could simply disable the checks in the scan configuration for versions lower than the latest, most recent version. So, the scanner would check to see whether Widget v5.3 was installed. If any older versions were installed, the Widget v5.3 vulnerability check would indicate there was a single vulnerability, resolved by updating to Widget v5.3.
Decisions like this must be made with a full understanding of how the organization treats vulnerabilities and patching. If the organization responds promptly to issues such as the discovery of an old version of software and prioritizes it the same way, then a single detection option may be appropriate. If the organization does not respond this way, knowing that there are multiple vulnerabilities, potentially with different exploits and thus different risk levels, may be important to the prioritization process.
While this may not seem worth the trouble for many applications, there are a handful of enterprise applications that update frequently or that commonly have multiple major vulnerabilities found in any given year. A failure to patch these applications can result in large jumps in the number of vulnerabilities on a given machine. Vulnerability checks for applications such as Java, WordPress, and some Adobe applications can benefit from this configuration methodology.
Distributed Scanning
Another consideration arises when considering the path that the vulnerability scanning software will take. To scan an endpoint, the vulnerability scanner may need to send traffic through routers, firewalls, and proxy servers. Any of these devices may impact the results by restricting the traffic sent to the target. In a vulnerability scanning situation, where accurately identifying security gaps is crucial, dropped traffic is simply unacceptable.
The scan must identify all issues that are present, and this necessity may be negatively impacted by a firewall rule or proxy server dropping connections. The traffic generated by a scan can appear to be malicious, so interference from intermediary network devices is a common issue, and allowing scanning systems through every security device on a net- work may be problematic or undesirable, since understanding how the security devices would impact similar traffic can be important.
One solution to address the problem and increase the accuracy of the scan is to set up a distributed scanning environment. This involves setting up scanning agents in each subnet. The agents will receive scanning directives and scanning configuration from a centralized host. The centralized host can schedule scans to begin as needed and automatically send the scan instructions to the appropriate host in the correct subnet. There is no need, with sufficient scanners, to scan through a firewall or proxy server. All scan results are sent to the centralized host to generate reports. The scanning load is also distributed in this model, so the duration of the scans is reduced. It requires more effort (and cost) to set up a distributed scanning environment; however, there are tangible benefits in the long run, including an improved security posture and potentially reduced bandwidth consumption due to having local scanning devices.
Managing Scan Results
Completing a vulnerability scan and analyzing the multitude of vulnerabilities and informational findings can be a daunting task. Handing a vulnerability report to a server administrator with the simple directive to “fix this” can be even more overwhelming for the administrator. Vulnerability scans of multiple hosts can generate hundreds of pages of issues that need remediation. An effective vulnerability scanning program must also consider keeping the remediation task manageable. This can typically be accomplished in a few different ways.
- Prioritize scanning and remediation efforts based on the organization’s business impact analysis.
- Use credentialed scans to reduce false positives.
- Assign more staff to the task.
- Reduce the scope of scanned device.
- Increase the length of time allowed for remediation.
- Use central management and patching tools to allow patching to be done in an automated fashion.
Management will weigh the cost and risks of the approach and decide on the path that best fits their risk appetite. Each approach has pros and cons. Ideally, enough staff can be assigned to the task to complete the most severe issues found on mission-critical servers within an acceptable time frame.
Once the scan has completed, the results should be reviewed for false positives. The results can then be presented to management to determine the action plan for remediation. A general plan should already be in place; however, the results may indicate a need to modify the plan. Several critical issues, for instance, may require immediate attention and prompt remediation. The remediation plan and action items should have the full support of management. Vulnerabilities that cannot be addressed, either because of a lack of a patch or workaround or because of a business requirement, should be formally accepted by management and should be reviewed on a periodic basis to ensure that the underlying reason why it couldn’t be addressed has not changed.
