Vulnerability assessment tools
5.1 Introduction
The vulnerabilities and exploitable flaws in the software or hardware of a computer system give individuals, who are aware of these flaws, the opportunity to use them to gain access to sensitive information assets within an organization. The purpose of computer security technologies is to prevent these intrusions from occurring and to protect information assets.
The previous chapter identified vulnerability assessment as the most effective security technology to implement when attempting to determine the VRS of a computer system. The purpose of this chapter is to evaluate the VA tools available. The different types of VA tools will be identified and a tool best suited to assist in the creation of VRS will be chosen.
5.2 Vulnerability assessment tools
Some definitions of VA tools are listed as follows:“A primary role of security vulnerability assessment tools involves viewing
your network, servers and hosts through the eyes of a hacker.” [MIKS 01]
“A vulnerability analysis system tests each service that a computer offers to
see whether it is vulnerable to attack.” [SANS 01]
“The tools (VA) can be used to identify exploitable vulnerabilities and to take
proactive measures to protect the networks and systems.” [MOHA 01]
5
Studying the definitions listed above reveals that VA tools are software packages and programs that search computer systems for vulnerabilities and exploitable flaws which may compromise a computer system. VA tools reveal an intruder’s view of the network in that they expose flaws that an intruder may be searching for.
First generation vulnerability tools identified vulnerabilities and generated plain text reports. They were difficult to update and alter and useful only to those who knew exactly how they worked. As security vulnerabilities have evolved during recent years, so have the tools that seek to counter them. The second generation of VA tools, which have improved interface and automated updating capabilities [LOPY 01], will now be discussed.
5.2.1 Types of vulnerability assessment tools
From the literature ([ISS 01], [ISS 98], [POWE 99], [ICSA 98] and [BACE 99]) six main types of VA tools may be identified.
a) Network vulnerability scanners
Network vulnerability scanners use active and invasive techniques against a computer system to determine whether that system is susceptible to attacks [ICSA 98]. Attack scenarios are replicated and used against a targeted computer system from a remote source. The computer’s reactions to these attack scenarios are then monitored to establish the attacks to which the computer system is vulnerable [MIKS 01]. These vulnerability scanners may also come in the form of an online solution [FOUN 03].
An advantage of this assessment approach is that it is platform-independent, which means that reconfiguration is unnecessary for different computer systems. One disadvantage of using this invasive assessment tool against a computer system is that the performance of the target system and network may be inhibited [KINN 02].
b) Host vulnerability scanners
Host vulnerability scanners implement passive and non-intrusive techniques to determine whether the computer system’s general security configurations and settings pose a security threat [ICSA 98]. The scanning software is installed on the target computer system to determine these settings [HUMP 00]. Examples of the settings assessed are file permissions and whether correct operating system patches are in place. Another type of evaluation through host-based vulnerability scanners is the testing of password weaknesses by guessing usernames and passwords. This forms part of some host vulnerability scanners [CYBE 01].
An advantage of this scanning tool is that a very accurate description of the host’s vulnerabilities is revealed. One disadvantage is that host vulnerability scanners need to be reconfigured for every individual computer system they assess and this means they are platform-dependent [KINN 02].
c) File integrity checkers
File integrity checkers use passive, non-intrusive techniques for vulnerability identification, as in the case of host vulnerability scanners. File integrity checkers focus on the integrity of certain system and data files as well as system objects and attributes [FYOD 00]. This is dissimilar to the host vulnerability scanner in that the file integrity checker determines whether certain files have been changed since the last time the checker tested the system. Examples of the objects and files the file integrity checker may analyze are hidden data streams, databases and registry keys. Message digest checksums of the files are used to determine whether the files have been altered since the last time the scan was completed. Checksums of files are stored and when a scan occurs, these historical values are compared to the most recent checksums generated from the files to determine whether changes have been made [BAUD 95]. If anyone changes a file, the file integrity checker will be able to identify it.
An advantage of file integrity checkers is the fact that they are very flexible, because almost everything on a computer system may be monitored for
Formatted: Bullets and Numbering
changes or only important files may be chosen. One disadvantage is that they must be reconfigured upon every individual computer system on which they are installed. File integrity checkers are therefore platform-dependent, as are host vulnerability scanners [ICSA 98].
d) Software application scanners
Software application scanners use passive, non-intrusive techniques to analyze software applications for errors in configuration and settings that are known to cause security compromise [ICSA 98]. This is much the same as the host vulnerability scanners mentioned above, but software application scanners do not inspect general configuration errors and vulnerabilities. Rather, they analyze very specific applications and the vulnerabilities they are known to have. For example, software application scanners may examine mail and web servers for inherent vulnerabilities which are unique to them.
An advantage of software application scanners is that they are very accurate in identifying vulnerabilities in specific applications, but the one disadvantage is that they are useful only to very specific applications. Monitoring general computer systems would not yield such thorough results, which means that this scanning tool is not very flexible.
e) Wardialers
Wardialers connect to telephone lines and dial random numbers to determine which numbers are answered by a modem [ISS 03]. This information is important because it is possible for an intruder to connect to a computer system via a modem, if a modem is present and active. This modem access would bypass a standard firewall, as the computer system’s network is not used for the modem’s input and output traffic [POWE 99]. If a modem is present and switched on, a wardialer will reveal its existence.
f) Database vulnerability scanners
As the name implies, a database vulnerability scanner examines databases for vulnerabilities that may be resident [ISS 01]. These vulnerabilities range from weak passwords, unknown and suspicious macros to Trojans.
Formatted: Bullets and Numbering
Formatted: Bullets and Numbering
5.2.1
Critical analysis of VA tools
Having discussed the VA tools, a tool must be chosen to aid the creation of the VRS of a computer system. Vulnerability risk status is vulnerability risk analysis in a general sense, which should be applicable to almost all types of computer systems. This means that some of the more specific types of vulnerability scanners may be ruled out at this time. The host and network vulnerability scanners are the only VA tools which have a more general scanning nature.
The discussions above disclosed that selecting the host vulnerability scanner means that only one computer system’s VRS may be examined at a time, but it is examined very thoroughly. Choosing the network vulnerability scanner, on the other hand, means that the vulnerability scans will not be as thorough as in the case of the host vulnerability scanner, but more than one computer may be scanned.
There are VA tools available on the market which seek to combine the features of the two vulnerability scanners. Examples are CyberCop Scanner [CYBE 01] and RealSecure [REAL 01]. Therefore, it seems feasible to choose a combination of host and network vulnerability scanners for VRS generation.
None of the state-of-the-art VA tools mentioned above determine the VRS of a computer system. The scanners provide a list of all vulnerabilities detected on a computer system, but do not give a summary of the measure of risk the vulnerabilities pose to the computer system at the time of the scan. For a vulnerability scanner to aid the creation of VRS, it may be necessary to examine its architectural elements and how they function to determine how the tool may be of help in the VRS problem.
5.3 Generic architecture of a vulnerability scanner
A discussion of the key concepts in a vulnerability scanner’s architecture is necessary to determine which element(s) may need to be modified to achieve the creation of a computer’s vulnerability status. After examining theCyberCop Scanner [CYBE 01] and RealSecure [REAL 01] vulnerability scanners thoroughly, the researcher has determined that the generic architectural elements of a vulnerability scanner may include the elements listed and discussed below. The different elements, which form part of the vulnerability scanner’s generic architecture, are shown in fig. 5.1.
Vulnerability database
User interface and configuration
Scanning engine Flow 1 Flow 2 Flow 3 Flow 5 Flow 4 Result repository
Fig. 5.1 Generic architecture of a vulnerability scanner
5.3.1 User interface and configuration
The user interface and configuration element of the vulnerability scanner’s architecture can be seen as the user’s interface with the vulnerability scanner. This means that all configuration of scan settings, such as which computer system(s) to scan or which specific vulnerabilities to check, occurs in this part of the vulnerability scanner’s architecture. The user configuration element can be seen as a template of the scan that will occur.
Other elements, such as the scanning engine and the result repository, interact with the user configuration element to determine the specifications of the scan and how scan output will be displayed. This is shown in flows 1 and 2 in fig. 5.1.
5.3.2 Scanning engine
This is the active scanning component of the vulnerability scanner that executes the vulnerability checks on the target system. The target system
referred to is the computer system that is being scanned. As shown in flow 1 of fig. 5.1, the scanning engine communicates with the user interface and configuration element to determine the specifications of the scan. This means it gets its scanning criteria and settings from this element and does its vulnerability checks according to these specifications.
The scanning engine sends packets of information to the target system, and receives packets in return. The scanning engine compares the answers it receives from the target system to the list of expected answers stored in the vulnerability database and, according to the answers it receives, determines whether a vulnerability is resident on the target system. The scanning engine stores the vulnerabilities found on every computer system in the result repository.
This interaction between the vulnerability database, result repository and the scanning engine is depicted in flows 3 and 4 in fig. 5.1.
5.3.3 Vulnerability database
This database stores a list of all the known vulnerabilities the scanner will search for and holds the correct answers to the prompts that the scanning engine will use to interrogate the target system. The list of vulnerabilities that the scanning engine is searching for is stored in the form of signatures. The signature of a vulnerability is a combination of specific elements which uniquely identify a vulnerability in much the same way as a person’s signature serves as a means of identification. If the scanning engine detects this combination of elements, the vulnerability is deemed to be present.
This interaction between scanning engine and vulnerability database is shown in flow 3 of fig. 5.1.
5.3.4 Result repository
This element in the vulnerability scanner architecture stores the output from the scanning engine. This is shown in flow 4 of fig. 5.1. The scanning engine captures the vulnerabilities found in a scan in the result repository and, according to the user specifications in the user interface and configuration
element, reports are generated to list the vulnerabilities found during the scan. This interaction between the result repository and the user interface and configuration element is revealed in flow 1 of fig. 5.1.
The result repository and vulnerability databases are linked so that additional vulnerability information is available to be placed in the reports generated. This additional information may include suggestions of possible steps that may be taken to eliminate the vulnerability that has been detected. This is represented by flow 5 in fig. 5.1.
5.4 Modifying
the
generic
architecture
The discussion of the generic architectural elements of the vulnerability scanner leads to the choice of element(s) to modify in search of VRS creation. It seems that the scanning engine and user interface and configuration elements do not need to be modified, as their functioning in their current state is necessary to detect vulnerabilities. The vulnerability database and the result
repository, on the other hand, show some potential for modification.
5.4.1 Modification of the vulnerability database
As mentioned above, the vulnerability database stores information on the vulnerabilities searched for by the scanning engine. In the previous chapters it was proposed that a measure of risk be assigned to an individual vulnerability to aid VRS creation. Because the vulnerability database stores vulnerability information, the database may be modified slightly by storing a measure of risk for each vulnerability in addition to other vulnerability information. When each vulnerability has a risk, there is the potential for creating the VRS of a computer system. An example of how this risk value might be constructed and assigned will be revealed in chapter 7.
5.4.2 Modification of the result repository
The result repository stores the vulnerabilities found by the scanning engine, on a specific computer system. When vulnerabilities are detected, the VRS of
the computer system will be determined by the risk of each vulnerability found resident upon it.
Assume that a measure of risk for each vulnerability has been added to the vulnerability database. The risks of the vulnerabilities found on the specific computer system should be manipulated to create the computer system’s VRS. The VRS should then be stored in the result repository. In its current application, the result repository does not have this storage feature and should, therefore, be modified slightly.
5.5 Conclusion
This chapter has discussed some types of VA tools available on the information security market, which may aid the creation of the VRS of a computer system. After an examination of the different types of VA tools, a combination of the network and host vulnerability scanners was chosen to help determine VRS.
The current application of the vulnerability scanner does not create the VRS of the computer system that it scans. A discussion of the generic architectural elements of a vulnerability scanner revealed that some elements showed potential to be modified to achieve this. The vulnerability database and result repository were selected.
The next chapter will discuss the vulnerability database and result repository further and reveal how these databases may be altered to achieve the VRS of a computer system scanned with a vulnerability scanner.
