True or false? an intrusive test only identifies weaknesses and does not attempt to exploit them.

Vulnerability Scanning

PCI requirements include both internal and external vulnerability scanning. An area that is commonly overlooked when performing vulnerability scans is the proprietary devices and appliances that manage the SAN and network. Many of these have Web interfaces and run Web applications on board.

Vulnerability-scanning considerations:

Use the Change Management/Change Control process to schedule the scans. Even trained security professionals who are good at not causing network problems sometimes cause network problems.

Know exactly what will be scanned.

Perform both internal and external vulnerability scans.

Scan the Web application and appliances that manage the SAN and the network.

Use more than one tool to scan.

Document results and define metrics to know whether vulnerabilities are increasing or decreasing.

Set up a scanning routine and scan regularly with updated tools.

Vulnerability Testing

Vulnerability scanning (also called vulnerability testing) scans a network or system for a list of predefined vulnerabilities such as system misconfiguration, outdated software, or a lack of patching. A vulnerability testing tool such as Nessus (http://www.tenable.com/products/nessus-vulnerability-scanner) or OpenVAS (http://www.openvas.org) may be used to identify the vulnerabilities.

We learned that Risk = Threat × Vulnerability in Chapter 2, Domain 1: Security and Risk Management. It is important to remember that vulnerability scanners only show half of the risk equation: their output must be matched to threats to map true risk. This is an important half to identify, but these tools only perform part of the total job. Many organizations fall into the trap of viewing vulnerabilities without matching them to threats, and thus do not understand or mitigate true business risk.

Vulnerability Identification

Vulnerability scanning automates the process of determining what well-known vulnerabilities exist on the network. Imagine having to look at every computer manually, across the network, and trying to figure out what vulnerabilities existed. Some of these tools are freeware, such as Nessus (www.nessus.org), while others are commercial in nature, such as Saint (www.saintcorporation.com).The goal of this process is to collect as much useful information as we can in the shortest amount of time.

The two tools listed in the previous paragraph are general vulnerability scanners and will attempt to find issues in a large number of services and host types across an organization's network. Other tools, such as SPI Dynamic's WebInspect (www.spidynamics.com) or NGS's NGSSQuirrel (www.nextgenss.com), specialize in vulnerabilities on specific applications. For example, the NGS application is written by some of the world's foremost experts in database security and will help locate issues in databases that could provide an avenue into the network.

Vulnerability Scanning

Good vulnerability analysis requires automatic tools plus human analysis for verification. Don’t listen to those software salesmen who say different.

Vulnerability scanning is generally a fully automated method of identifying security weaknesses on a system. This is performed by tools that will test for a multitude of potential weaknesses very quickly, reporting on those that are found. Assuming that the scanning software is up to date, this testing will check for most security problems on any open service. General-purpose scanners that check many aspects of a system, such as ISS Internet Scanner and Network Associates CyberCop, are available. However, vulnerability scanners designed for specific services are also available, such as Whisker, which checks for weaknesses specifically in Web servers.

After running such tools, a good tester will verify that the service is truly vulnerable and able to facilitate intrusion. Be prepared for a lot of hard work here. Forty percent error rates are not unusual. I use two automated tools—and correlate the results.

By the end of this stage, the tester will have a map of hosts and their open services, plus a list of real vulnerabilities on each system. At this time the tester may also realize that some more testing may be required, so there’s another iteration through the process for, say, a newly discovered host.

Vulnerability scanning

Vulnerability scanning is one of the initial steps of most penetration tests where a scope of multiple hosts is included as it is a fast way to check multiple hosts and to provide an initial list of vulnerabilities that can be further tested by the consultant. In order to perform vulnerability scanning, a vulnerability scanning tool is required. Luckily, there are many commercial and open-source scanners available for most platforms and a Google search will return many results. There is a list of available scanner on the SecTools.org website at http://sectools.org/tag/vuln-scanners/.

One free open-source scanner that can be used is OpenVAS that is available from http://www.openvas.org.

Vulnerability scanners are provided with a list of IP address or resolvable hostnames and they perform the process of scanning by first ascertaining the availability of the host before performing a service discovery via various port scanning techniques. Once the hosts and services are confirmed the scanner then moves onto performing an analysis of the hosts, looking for software vulnerabilities and configuration vulnerabilities. Most vulnerability scanners allow what is termed as a credential scans to be carried out. This is a vulnerability scan where the scanner can be given administrative rights so that it can map drives to the target hosts and also interrogate items such as the hosts registry in order to provide a much more detailed level of assessment.

A software vulnerability is an identified bug in an installed piece of software, either commercial or open source. One example of a software vulnerability may be the existing of the Conficker vulnerability that Microsoft announced in their security bulletin MS08-067. This is a well-known Windows Server vulnerability (that amazingly the authors still find in commercial networks) and Microsoft fixed it in a security patch. The vulnerability scanner knows how to identify this vulnerability from its plugin database and it will report it along with the corresponding risk details in the scanning management interface. There are literally thousands of these identified every year across all vendors and the majority of these are recorded by NIST at their National Vulnerability Database—http://nvd.nist.gov. These are all allocated what is referred to as a CVE reference. The example software vulnerability above was issues CVE number CVE-2008-4250 and can be found at http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-4250. This number refers to the year it was identified and the chronological order starting at 0001. Therefore, the first vulnerability to be issued a CVE in 2014 would be CVE-2014-0001.

A configuration vulnerability is related to the way a piece of software is configured, or more appropriately, misconfigured. Various software applications require configuration. It is hoped that software vendors today issue software with a default secure configuration but this has not always been the case with many historical providers releasing software that is insecure, relying on the user to secure it. This can be referred to an open or closed configuration. It is preferred to start with a closed configuration and open that parts needed. However, the easiest solution is to start with an open configuration and close the parts that are not needed but far too often these parts never get closed and this then leads to a configuration vulnerability which will always be exploited by a serious penetration tester or worse, a potential attacker. An example of a configuration vulnerability may be a network device, such as router or switch, with the insecure connection method of Telnet enabled rather than the secure method of SSH. This may also be further compounded if no password is required in order to gain access to the device. Both of these are configuration vulnerabilities that can be remedied through correct configuration of the device.

Vulnerability scanning can be used in an internal test to check for both software and configuration vulnerabilities. This can be beneficial to confirm the patch levels of the servers, which are very useful in Windows environments to ensure that all of the critical security patches have been applied. This type of scanning can also be useful to look for any configuration errors that may exist on devices within your organization. Keeping up with the results found on a vulnerability scan and ensuring that any hosts have no high-level vulnerabilities is a great way to increase the security posture and greatly reduce the ability for a potential attacker to gain access to any corporate resources.

Vulnerability Management Cycle

Because vulnerability scanning must be repeated on a regular basis, you must develop appropriate policies and procedures to accommodate this. These should include a schedule for when, and under what circumstances, a given host should be scanned. There should be a process for the appropriate parties to sign off when a system is deemed “clean,” as well as a procedure to accept a given risk in cases where it is undesirable or impossible to remediate at this time. A typical vulnerability scanning cycle would consist of the following steps (see Figure 8.2):

Perform the Initial Scan This gives you a baseline of issues and is used in subsequent steps.

Verify the Scan Results Some of the issues a vulnerability scanner finds may be false positives. In other cases they may be legitimate issues, but the issues may not be relevant because of other compensating controls the scanner cannot account for.

Remediate Valid Issues This will include following all your change control procedures in an attempt to remove or mitigate the risk that the vulnerability scanner found.

Rescan This last step is often skipped but it is important. This not only verifies that your remediation steps were successful, but demonstrates to management and, if needed, to auditors, that you are actively taking steps to safeguard your network.

This cyclical process will be never ending in that once you have scanned a host, verified the scan results, performed remediation for any issues, and then rescanned the host to verify your remediation efforts, it will be time to begin the process again.

Introduction

Enterprise vulnerability scanning is quite complicated, and as such requires a certain amount of planning, preparation, and adjustment. The key factors for effectively scanning the enterprise for security vulnerabilities are easy administration, periodic scanning, and accurate results.

There is no trivial way to take a scanner such as Nessus and use it to scan the entire enterprise network. Simply pointing it toward the network and scanning will not be enough. This chapter shows some of the caveats that make this process difficult. You’ll learn, for example, why simply scanning the entire network from a single point is often not viable. This involves exploring distributed scanning, differential reporting, report correlation, and automated updating.

At this point in the book, we expect that you are most likely already using Nessus for regular security testing, and are looking to take it up a notch—from maintaining a list of hosts you regularly scan, to scanning your entire enterprise and using the results to improve your enterprise’s security status.

Vulnerability Scanning

Vulnerability Scanning is the process of methodically reviewing the configuration of a set of hosts by attempting to discover previously identified vulnerabilities that may be present. Automated tools are available, with some of these described earlier under “Vulnerability Scanners.” It is also possible to perform this exercise manually if the use of an automated tool against a critical host is not allowed due to the potential for any negative impact to the performance and availability of the host.

Manual Vulnerability Scanning consists of collecting information using some of the command-line tools described earlier, and individually comparing the revision information of the operating system, applications and services against databases of known vulnerabilities. Two of the popular databases of vulnerabilities are the National Vulnerability Database12 (NVD) hosted by NIST, and the Open-Source Vulnerability Database13 (OSVDB). There are more than 100,000 vulnerabilities tracked between these two databases, with most vulnerabilities also tracked against a “common enumeration” system known as Common Vulnerabilities and Exposures (CVE).

An example of a simple manual vulnerability assessment is detailed here:

The wmic command is used with the product get option to list all of the installed applications running on a Windows 2003 Server host.

The SCADA application software is shown as “IGSS32 9.0” with the vendor name “7-Technologies” and a version of 9.0.0.0.

Using OSVDB, “igss” is entered in the Quick Search field and several results are returned. Selecting the most recent item, a link is provided to an advisory published by ICS-CERT that confirms that the installed version of software has a published vulnerability.

The advisory contains information on how to download and install a software patch from the software provided.

It is apparent that this process can be very time-consuming, and that a great deal of cross-referencing must be performed. The use of automated tools simplifies this process by systematically assessing the target and quickly comparing the information extracted against a local database of documented vulnerabilities. Vulnerability scanning applications depend on external data to maintain a current local database, so the application should be updated before conducting any assessments. It is also recommended to always include the update sequence number or data used when generating a vulnerability report with the security test.

As mentioned earlier, there are several commercial vulnerability scanners available. The important feature to consider when using a particular product—commercial or open-sourced—is the ability to assess the applications that are installed on the target system. Even if there are no application-specific vulnerabilities in the database (as would be the case with many embedded ICS devices), the scanner may still be able to provide useful information regarding active services and potential weaknesses associated with those services.

What is important when using a vulnerability scanning application is to obtain as accurate of results as possible. The way that this is most often performed is via an “authenticated scan.” This performs an effective “white box” assessment of the target by authenticating remotely on the device and then performing a variety of internal audits, including Registry reviews and network statistics. These results provide an accurate reflection of the true security posture of the target, and not just what is visible to a potential attacker. An authenticated scan is also more “friendly” on the target and does not typically inject as much hostile traffic into the network interfaces against various listening services. Figure 8.7 shows an example of the Nessus vulnerability scanner from Tenable Network Security where a “black box” unauthenticated scan yielded only four high-severity vulnerabilities, while a scan against the same target using authentication yielded 181 high-severity vulnerabilities.

The most common method of vulnerability scanning utilizes active mechanisms that place some packets on the network. The “aggressiveness” of the scan can be controlled in many applications, but as with any active technique, close attention must be paid to the potential impact of the scanner on the target.

Passive vulnerability scanners are available that collect the information needed for analysis via network packet capture rather than packet injection. Unlike active scanners that represent a “snapshot” view of the vulnerabilities on the target, passive methods provide a continuous view of the network. They are able to enumerate the network and detect when new devices are added. This type of scanner is well suited for industrial networks because of the static nature of the network topology and the regular traffic patterns and volumes that exist.

Host-based vulnerability scanners are also available; however, they would not likely be accepted within the ICS zones on industrial networks due to the fact that they must be installed on the target. These scanners do facilitate compliance auditing of configurations and content inspection, so they do fit a need. A good example of a host-based scanner would be the Microsoft Baseline Security Analyzer (MBSA).

It should be obvious at this point that vulnerability scanners are only capable of assessing a target against vulnerabilities that are known. In other words, it offers no guidance of any “zero-day” or those vulnerabilities that exist that have been discovered but the presence has not been communicated. This is why a strong defense-in-depth security program must depend on the ability to prevent, detect, respond, and correct against not only the threats that are known today, but also those threats that may appear tomorrow.

Caution

A vulnerability scanner should never be used on an online ICS and industrial network without prior testing and approval from those directly responsible for the operation of the ICS.

Tip

Just because a system has no vulnerabilities does not mean that it has been configured in a secure manner.

Stakeholders: security, IT, audit, and management

Report notes: Vulnerability scanning activities run on a 30-day rotation. All systems are scanned and data are refreshed every 30 days. The details of the report will be published and be made available for all interested parties and stakeholders every 30 days. If any teams or departments are involved in remediation activities, the SOC will support those efforts with ad-hoc scans and individualized reports to aid in the cleanup efforts. Additionally the SOC is available to discuss any issues or technical concerns related to the patching or applying of remediation’s detailed in these reports.

Vulnerability Enumeration

Following from reconnaissance is vulnerability enumeration or scanning. Vulnerability scanning is a common activity in the commercial security industry, and numerous scanners exist. A typical scanner has a database of tens of thousands of security vulnerabilities, and is able to test for the presence of those issues. The types of tests vary; in some instances a test consists of simply checking a software version number extracted from a service banner. Other tests may require running an actual exploit to confirm exploitability. By unleashing the scanner on a wide range of targets, a database of vulnerable machines can be saved before a CW.

Vulnerable systems are not the only benefit of wide-scale scanning. Even a database of version numbers or technology types will improve targeting: for example, when vulnerabilities for a system are discovered in the future.

The problem with scanners is that they are not subtle. They often test for issues unrelated to the technology on which the service runs, and protection mechanisms such as intrusion detection systems are tuned to detect vulnerability scans. One improvement is scanning for specific issues across the target’s networks, which reduces the likelihood of detection and masks tests to evade signature-based detection methods. Passive vulnerability enumeration is also possible although the results are not as rich as active vulnerability scanning.