Division of Responsibilities | General Requirements

The basic division of responsibility can be critical for meeting compliance and audit requirements in a large institution. The primary concern is to avoid having the vulnerability check parameters changed by a group or an individual with a vested interest in not appearing vulnerable. In addition to concealing vulnerabilities, this behavior is not unlike the age-old accounting problem where a business unit reports better results from one quarter to the next by changing the accounting rules. In the security realm, this leads to an overall security weakness that can threaten a large portion of an organization since vulnerability audit parameters can be applied globally.

Divided responsibility may not only have a compliance component, but a simple operational excellence one as well. In the delivery of IT services to the business, various groups are accountable and yet dependent upon other groups. This is no less true for the role of VM in the delivery of IT services. For example, the network group may have service level agreements (SLAs) to maintain that may be impacted by vulnerability scans. Those service levels are subject to change, depending on internal customer requirements, and may have many complex elements. The internal service provider, which may be a network group or server platform group, will need to exercise some control over when a vulnerability assessment takes place and perhaps how much of the provided service’s resources are consumed in the process. The network team may be concerned with how much bandwidth is consumed on a particular WAN link during an active scan.

A server team, however, may be concerned about the system resources required to operate an agent in different modes. Perhaps during an active assessment of the host, the agent consumes an excessive amount of CPU or conflicts with a single business-critical application service. So, limited control of the auditing process may be necessary, while control over the quality elements should be restricted to security and/or compliance.

A virtual machine environment can amplify the impact of an agent where multiple guest OS instances will require the operation of multiple vulnerability assessment agents. Also, the impact risk on multiple OSs simultaneously is increased by the fact that the host OS running a hypervisor may also have an agent running. Regardless of the group managing the resource scheduling for an assessment, given the testing and management required for certain activities, a single security group may not want to have this responsibility when there are already knowledgeable individuals who would prefer to take ownership.

In summary, the message here is that each group in an IT organization is accountable for the services it provides. The introduction of a new IT function has an impact on operations in other groups. Inclusion of representatives from the affected groups will be instrumental in identifying the impacts and requirements of the VM product. One good tool to facilitate the identification of these requirements is the process dependency diagram. Figure 1 shows an example diagram where the VM service is the focal point. However, this diagram can be expanded to identify dependencies that may be created for other services where their requirements may change.

 
Figure 1: Identifying VM system requirements.

From Figure 1, we should be able to quickly identify requirements for the VM system that not only achieve the objectives of identifying vulnerabilities, but also enhance the service levels of the affected systems. In this diagram, Network Services has provided requirements that affect the existing service levels:

• audit scheduling around business hours;
• bandwidth consumption requirements per site or other grouping such as source network; and
• simultaneous network connections to minimize impact on routers and firewalls.

The Business Applications Services group, however, has requirements that not only affect the performance of the applications, but also a requirement to perform certain types of vulnerability checks. This is a common result of enhancing SLAs to reflect the security of a system. An SLA for an application services group may specify that tests will be performed on every new release for cross-site scripting and SQL injection vulnerabilities. The VM system has, then, not only generated service delivery burdens for a particular IT service, but has also enabled enhancements to existing SLAs through an operational level agreement (OLA) arrangement.

Using Nessus

This section assumes that the user has installed both the Nessus client and the server. No instruction on these topics will be provided as it is well-covered in other books and the Nessus documentation itself. Nessus has two areas in the user interface: Scan and Report. The function of each is self-explanatory. Figure 1 shows the scan target window. It allows the user to enter a host IP address, DNS name, IP address range, subnet specification, or an input file with a list of hosts/IP addresses. Each of these target specifications are saved so that scans can be repeated in the future.

 
Figure 1: Nessus target selection panel.

Next, the user can define the parameters of the scan by creating a scan policy. Shown in Figure 2, this policy contains:

• Basic options about the scan (aggressiveness, packet captures, types of port scans, logging, etc).
• Credentials if white box testing is to be performed.
• Plug-in selection to employ the latest and most relevant checks. The library of plug-ins for Nessus is extensive. The key to efficient scanning is to select only the plug-ins needed for the target network.
• Network congestion control settings (simultaneous connections, time outs, target disengagement rules).
• Advanced parameter settings for various protocols and checks.

 
Figure 2: Nessus Scan Policy plugin selection.

Once all of these parameters are selected, the scan can be performed. When complete, the report is available in a hierarchical, navigable format. This report can also be exported to HTML. The report is easy to read, as shown in Figure 3. This example entry from the report shows the port and protocol used to obtain the information, SSL forNessus (tcp/1241). Then, the report shows that the Supported SSL Cipher Suites plug-in was used to find the vulnerability. In this case, it is not actually a vulnerability but an enumeration. After that, the remainder of the report item is self-explanatory. A very nice feature of Nessus is that it shows the output from the plug-in, which in this case reveals the extent of the information that was revealed by the SSL service. Even better than this, for the technically inclined analyst, the Nessus ID will link to the details of the plug-in on the Tenable Web site. This plug-in also has source code that can be reviewed so that the method of checking can be fully understood.

 
Figure 3: Nessus vulnerability details report.

Scan Modes | Nessus

Nessus provides three types of checks or scan modes:

• Discovery: This process uses basic discovery protocols such as ICMP echo request/reply and TCP sweeps to identify active hosts on the network. Some products today do not have the ability to simply perform a quick discovery but instead require a full audit. This capability represents a useful tool to narrow unknown network ranges when defining networks in a commercial product. Alternatively, similar functionality can be obtained using the command-line NMAP product.
• OS fingerprinting: This is performed by a handful of methods that have already been described in this book. Simple malformed packets to legitimate SNMP queries are used to gather involuntary and voluntary information, respectively. These and other methods may not always work, depending on the target. Other vendors may have developed other means to gather this information.
• Complete scans: This type of scan performs discovery and OS fingerprinting and adds numerous vulnerability checks, including brute-force password attacks. It is subject to all of the same limitations and concerns discussed previously in this chapter.

One other feature worth mentioning about Nessus is the availability of Web application checks. This capability is not available “out of the box” from many vendors. In many cases, one must pay extra for the feature. Nessus provides this without reservation. It requires some configuration to be relevant to the targets, but is certainly worthwhile. The user has the ability to test cross-site scripting (XSS), SQL injection, and Common Gateway Interface (CGI) vulnerabilities.

Nessus is a capable product with a greater level of control compared to most other products. However, it lacks the scalability of many commercial offerings because it’s a very centralized approach to scanning. All scans take place from a central location rather than having many physically distributed scanners with a central data-collection point. However, it may be well-suited to many business/IT architectures and quite suitable at a good price point.