2.4 Identify Infrastructure Vulnerabilities

Part 2 of the OCTAVE method involves a comprehensive evaluation of your organization's technology infrastructure to determine what additional security measures need to be taken in order satisfy the security requirements laid out in Part 1 of the evaluation process.

Some of the changes in the infrastructure will be easy. The changes recommended by employees in Part 1 of the evaluation might be implemented quickly. What will probably be more difficult is correcting security vulnerabilities of which members within your organization are unaware. Determining and fixing additional vulnerabilities not gathered during the first phase may involve using a third-party vendor who specializes in this type of work.

Of course, if the skill set to perform these tests exists within your organization, feel free to use it, but you must understand the steps involved in testing a system, and how to properly interpret the results; otherwise , this crucial part of your security evaluation will be useless.

OCTAVE groups security vulnerabilities into three categories:

1. Design ” A vulnerability that is a flaw based in hardware, software, or a protocol. This could be a security hole in an operating system or a problem with the version of a specification, such as the security flaws found in SSL 1.0.

2. Implementation ” A vulnerability that lies in the way a system is being used, not in how it is deployed or designed.

3. Configuration ” The most common vulnerabilities. Configuration vulnerabilities stem from administrative errors: a bad password, insecure system access, or other errors.

Each system within your IT infrastructure will most likely have multiple vulnerabilities that span all three categories. In order to maintain best practices while testing the system, OCTAVE requires that an organization use an established catalog of vulnerabilities.

2.4.1 CVE

The most popular catalog of vulnerabilities is the Common Vulnerabilities and Exposures (CVE) dictionary, sponsored by the Mitre Corporation (cve.mitre.org). CVE is used by many organizations as a way to standardize vulnerabilities across multiple platforms. Rather than act as a database or a repository (similar to BugTraq) of information, CVE provides a standard naming convention for vulnerabilities. Other organizations that support CVE use the names defined within CVE in their products. From an end- user perspective, this means that all devices that are CVE-compliant will list CVE-2001-0494 as a buffer overflow problem with the IPSwitch SMTP Server.

Dictionary systems, such as CVE, provide a valuable tool to network administrators because they make it easier to determine what vulnerabilities an intrusion detection system (IDS) tool will detect. The downside to tools like CVE is that, because it tries to be vendor neutral, incidents that are added to the CVE database are determined by a group of industry experts. This can mean that the official CVE database can lag several months behind the report of a security incident.

Fortunately, CVE also supplies a list of candidates for inclusion into the database. Candidates have not been officially added, but many CVE vendors will include them in their tools in an effort to be as complete as possible. Candidates are distinguished from actual dictionary entries by their titles. A dictionary entry includes the letters CVE, followed by the year, and the incident number. In the example given earlier, the IPSwitch vulnerability is incident number 494 of 2001. Candidates have the letters CAN, followed by the year and the incident number. The incident CAN-2002-0085 describes a potential Apache exploit involving PHP, which was reported in February 2002. Before it can be listed in the dictionary it has to receive enough accept votes from members of the CVE board. Voting, and detailed information about the incident, are available with each listing.

A wide range of IDS tools uses the CVE system. The tools that use CVE include VLAD the Scanner, an open source scanner available from BindView, and Cisco IDS (formerly known as NetRanger). The CVE website lists more than 1,600 systems that use the CVE dictionary.

2.4.2 Assess the Results

Using whatever dictionary and IDS system your organization's staff feels comfortable with, analyze your critical IT systems.

When the analysis is complete, another meeting needs to be held with the core group and the IT staff. The results of the testing should be analyzed and placed into three separate groups:

1. Vulnerabilities outside the organization

2. Vulnerabilities within the organization

3. Vulnerabilities in each system

Every vulnerability should be reviewed, within the context of its group, by the organization's IT staff before moving on to Part 3 of the OCTAVE evaluation.