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:
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.
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]:
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.
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:
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:
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.