7.1 Overview of Process 5

Upon completion of process 4 you identified your organization's critical assets and examined the threats to those assets. In process 5 you use this information to determine how to evaluate your organization's computing infrastructure for technology vulnerabilities.

You need to focus on the vulnerability evaluation to complete it in an efficient and effective manner. To understand your risk, you need to collect vulnerability information only on key components relative to the critical assets. Process 5 enables you to identify those key components.

Process 5 Workshop

Process 5 is implemented using the core analysis team members as well as any supplemental personnel that this team decides to include. Since this workshop also marks the beginning of the technology-intensive activities of the evaluation, you might include additional information technology personnel in the workshop.

The workshop should take an experienced analysis team two to four hours to conduct. Remember to review all activities for process 5 and decide whether your team collectively has the required knowledge and skills to complete all tasks successfully. We suggest that your team members have the following skills:

• Understanding of the organization's business environment and how business staff legitimately use information technology in the organization

• Understanding of the organization's information technology environment and knowledge of its network topology

• Good communication skills

• Good analytical skills

• Understanding of common exploits of technology vulnerabilities and the types of tools used to check for technology vulnerabilities

Table 7-1 summarizes the workshop activities for process 5.

Before looking at process 5 in detail, let's examine technology vulnerabilities and the supporting information you'll need to conduct this process.

Technology Vulnerabilities

Ultimately, your goal during phase 2 of OCTAVE is to identify technological weaknesses in the computing infrastructure. Technology vulnerabilities are weaknesses in systems, devices, and components that can directly lead to unauthorized action [NSTISSC 98]. Technology vulnerabilities are present in and apply to network services, architecture, operating systems, and applications. They are often grouped into three categories [Howard 98]:

• Design vulnerabilities— a vulnerability inherent in the design or specification of hardware or software whereby even a perfect implementation will result in a vulnerability

• Implementation vulnerabilities— a vulnerability resulting from an error made in implementing software or hardware of a satisfactory design

• Configuration vulnerabilities— a vulnerability resulting from an error in the configuration and administration of a system or component

Consider a case in which designers specify a weak authentication mechanism for a system that will store classified information. This can be considered a design vulnerability. If system developers implement the requirement as specified, the resulting authentication mechanism will allow attackers to break into the system easily.

Table 7-1. Process 5 Activities

Activity	Description
Identify key classes of components	The analysis team establishes the system(s) of interest for each critical asset. The team then identifies the classes of components that are related to the system(s) of interest.
Identify infrastructure components to examine	The analysis team selects specific components to evaluate. The team selects one or more infrastructure components from each key class to evaluate. In addition, the team also selects an approach and specific tools for evaluating vulnerabilities.

Now let's look at a common implementation vulnerability, the buffer overflow. A buffer overflow exploit takes advantage of programs that improperly parse data and inadvertently attempt to store too much data in a storage (memory) area that is too small, causing an overflow. One possible result of a buffer overflow is that an attacker can execute whatever command is desired, thus potentially affecting the confidentiality, integrity, or availability of the data on that system. Buffer overflows can also force a system to abort because it is trying to perform illegal instructions, compromising the availability of that system.

Or consider the following examples of configuration vulnerabilities:

• A system contains accounts with default passwords, allowing an attacker to gain access to the system by using a commonly known password.

• File permissions on a system are set up to allow "world write" permission for new files, meaning that anyone with access to the system can read or change information on that system.

• Services that are known to be vulnerable are running on a system, allowing attackers to exploit the vulnerability and gain access to the system.

Each of the above examples of configuration vulnerabilities stems from systems not being securely configured by administrators. You should also note that once design and implementation vulnerabilities become known (often because someone has exploited them and gained access to a system), vendors typically work to address the vulnerabilities and make software patches containing the fix available to their customers. It is then the responsibility of system and network administrators to apply the patches to the appropriate systems. Thus, you can see how design and implementation vulnerabilities can eventually be transformed into related configuration vulnerabilities.

In an operational information security risk evaluation, you primarily focus on configuration vulnerabilities. You check systems for known technological weaknesses, looking for indications of errors in the configuration of your organization's systems and networks. This information complements some of the information that you collected in process 3, whereby information technology staff members discussed current security practices related to configuring and maintaining the organization's computing infrastructure. Figure 7-1 highlights those areas from the catalog of practices that focus on configuring and maintaining systems and networks. Technology vulnerabilities that are identified during phase 2 of OCTAVE can provide objective data that you can use to refine your understanding of the organization's current information technology practices.

Mapping the Computing Infrastructure

During process 5 you select components from your computing infrastructure to examine for technology vulnerabilities. As you do this, you will most likely refer to information about your computing infrastructure. For this, you will need a network topology, or map, that represents the layout of the computing infrastructure, including all access points to the organization's networks. You can also use a listing of the systems in the organization. It is important that one member of your team be able to read and interpret the network topology. The following list highlights three potential sources of information about your computing infrastructure that you can use:

• Network topology diagrams— electronic or paper documents used to display the logical or physical mapping of a network. These documents identify the connectivity of systems and networking components. They usually contain less detail than that provided by network mapping tools.

• Network mapping tools— software used to search a network, identifying the physical connectivity of systems and networking components. The software also displays detailed information about the interconnectivity of networks and devices (routers, switches, bridges, hosts).

• Computer prioritization listings— a listing of the computer inventory owned by an organization. This listing typically depicts a prioritized ordering of systems or networking components based on their importance to the organization (e.g., mission-critical systems, high/medium/low-priority systems, administrative systems, support systems, etc).

Any of the above sources of information can be used. You need to decide how much and what type of information you need to select the key classes of components. Typically, a network topology diagram is sufficient for the activities in process 5.

Next we look at the first activity of process 5, in which you identify key classes, or types, of components in your computing infrastructure.