History of OCTAVE

Before we developed OCTAVE, we performed expert-led Information Security Evaluations (ISEs) for organizations. A team of security experts would visit a site, interview selected information technology personnel and users of key systems, and examine selected pieces of the computing infrastructure for technological weaknesses. The assessors used their expertise to create a list of organizational and technological weaknesses (vulnerabilities). When the managers at a site received the list of vulnerabilities and corresponding recommendations, they often did not know how to begin to overcome the weaknesses. Which issues should they address first, the organizational or the technological? With limits on the funds and staff available, what are the top five priorities? These are good questions. Unfortunately, when you examine only vulnerabilities, it is hard to establish appropriate guidelines. You need to look at the vulnerabilities in the context of what the organization is trying to achieve before you can start establishing priorities.

In addition to our experience with vulnerability evaluations, we had also developed and applied a variety of software development risk evaluation and man agement techniques [Williams 00 and Dorofee 96]. These techniques focused on the critical risks that could affect project objectives.

With these experiences, we decided to focus on a risk-based approach rather than a vulnerability-based approach. A risk-based approach could help people understand how information security affects their organization's missions and business objectives, establishing which assets are important to the organization and how they are at risk. Vulnerability evaluations could then be performed in the context of this risk information. Because information security risks are tied to an organization's missions and business objectives, it became necessary to include business staff in addition to information technology personnel in the evaluation.

A second important observation from our vulnerability evaluation days concerned a given site's level of involvement and subsequent ownership of the results. Because the vulnerability evaluations were highly dependent on the expertise of the assessors, site personnel involved in the process participated very little. When we were able to go back to a site, we saw the same vulnerabilities from one visit to the next. There had been little or no organizational learning. People in those organizations did not feel "ownership" of the various evaluations' results and had therefore not implemented the findings. We decided that sites needed to be more involved in security evaluations in order to learn about their security processes and participate in developing improvement recommendations. We started to develop a self-directed evaluation approach that

• Focused on risks to information assets

• Focused on practice-based mitigation using recognized, good security practices^[1]

  ^[1] Practices in the catalog of practices (Appendix C) were derived from several sources of security practices including CERT/CC, the British Standards Institute, the National Institute for Standards and Technology, and government regulations.

• Included business personnel as well as staff from the information technology department

• Involved a site's personnel in all aspects of the evaluation

In June 1999 we published a report describing the OCTAVE framework [Alberts 99], a specification for an information security risk evaluation. This was refined into the OCTAVE Method [Alberts 01a], which was developed for large-scale organizations. In addition, we are developing a second method targeted at small organizations. During these efforts, we determined that the OCTAVE framework did not sufficiently capture the general approach to, or requirements for, the self-directed information security risk evaluations that we wanted. We refined the framework into the OCTAVE criteria [Alberts 01b], namely, a set of principles, attributes, and outputs that define the OCTAVE approach.