1. What is the OCTAVE approach?
2. How is OCTAVE different from other security assessments?
3. Who needs an OCTAVE? How do I know if I need one in my organization?
4. What's the difference between the OCTAVE Method and OCTAVE-S?
5. How long does it take and how much does it cost to do an OCTAVE?
6. How can I properly scope an initial OCTAVE effort?
7. Is there a recommended analysis team composition that would enhance the effectiveness and efficiency of the OCTAVE effort?
8. How easy is it to tailor OCTAVE?
9. Is it possible to abuse/misuse OCTAVE?
10. What types of assets does OCTAVE address?
11. What kinds of tools are available for OCTAVE?
12. How does OCTAVE incorporate probability?
13. Can I use OCTAVE effectively if my primary technology platform is a mainframe or mid-range (AS/400, etc.) computer?
14. What does my organization do after OCTAVE is done?

1. What is the OCTAVE approach?

   The Operationally Critical Threat, Asset, and Vulnerability Evaluation^SM (OCTAVE^®) approach is a risk-based strategic assessment and planning technique for security. OCTAVE is self-directed—a small team of people from the operational (or business) units and the IT department work together to address the security needs of the organization. The team draws on the knowledge of many employees to define the current state of security, identify risks to critical assets, and set a security strategy. In addition, OCTAVE is flexible—it can be tailored for most organizations.

   OCTAVE is different from typical technology-focused assessments. It focuses on organizational risk and strategic, practice-related issues, balancing operational risk, security practices, and technology. The OCTAVE approach (pdf) is driven by two of the aspects: operational risk and security practices. Technology is examined only in relation to security practices, enabling an organization to refine the view of its current security practices. By using the OCTAVE approach, an organization makes information-protection decisions based on risks to the confidentiality, integrity, and availability of critical information-related assets.

2. How is OCTAVE different from other security assessments?

   The following table summarizes key differences between OCTAVE and other evaluations:

   OCTAVE	Other Evaluations
   Organization evaluation	System evaluation
   Focus on security practices	Focus on technology
   Strategic issues	Tactical issues
   Self directed	Expert led

3. Who needs an OCTAVE? How do I know if I need one in my organization?

   Any organization that uses information assets, especially electronic information, to meet its business goals and objectives should consider reviewing how that information needs to be protected. Consider using OCTAVE if

   • you have always relied on your IT department or service provider to provide security in isolation, without working with them to identify what needs to be protected and how
   • you have never done any kind of security assessment, or you have looked only at your computing systems in previous security assessments
   • you want to improve your security practices across the entire organization
   • you are required by law or regulation to do security risk evaluations and management

   Refer to the Introduction to the OCTAVE Approach (pdf) for guidance in choosing an appropriate OCTAVE-consistent method.

4. What's the difference between the OCTAVE Method and OCTAVE-S?

   The OCTAVE Method is structured for an analysis team with some understanding of IT and security issues, employing an open, brainstorming approach for gathering and analyzing information. On the other hand, OCTAVE-S is more structured. Security concepts are embedded in OCTAVE-S worksheets, allowing less experienced practitioners to use them. Experienced teams may find OCTAVE-S too constraining, while inexperienced teams may become lost using the OCTAVE Method.

   While only two methods have been developed by the SEI, some users may find that neither method is exactly what they need. It is possible to integrate pieces of the two methods to create something "in between." As long as the tailored methods still meet the OCTAVE criteria, they are still considered to be OCTAVE-consistent evaluations.

   For more details, see the Introduction to the OCTAVE Approach (pdf).

5. How long does it take and how much does it cost to do an OCTAVE?

   The OCTAVE Method is a series of at least 12 workshops, most of which are a half-day or full-day long. The length of time it takes depends on several factors, primarily

   • the scope of the evaluation—how many operational areas you look at and how many critical assets you carry forward through the evaluation
   • how much time the analysis team can devote to these workshops—a team that can work full time on the evaluation will finish sooner than one that can only devote one day a week
   • how long it takes to conduct the technology vulnerability assessment in OCTAVE Process 6—running tools can take quite some time, particularly if permissions and scheduling are complex
   • the degree of organizational change required to prepare for the evaluation—getting senior management sponsorship, training the analysis team, and scheduling workshops can take quite a while to accomplish in some situations, particularly if the prevalent assumption is that security is an IT-only problem

   The shortest reasonable amount of time to conduct the OCTAVE Method is 2-3 weeks, but scheduling often drives the time to anywhere from 6 weeks to several months. With 16-hour days, it has been condensed to 7 working days; but some organizations have had difficulty with scheduling and preliminary activities and have taken more than 6 months. The degree of tailoring you do to the method can also affect the length of time. For example, one customer added an extensive policy and regulation research activity to the front end that took several weeks to complete.

   OCTAVE-S requires less time to complete, primarily because of the lack of information-gathering workshops in Phase 1 and an abbreviated Phase 2. The average schedule for OCTAVE-S is 2-3 days, assuming adequate preparation.

   Cost is a generally related to time—time for the analysis team to do its work and the time of other participants. Several detailed tables identifying the expected time for different types of participants can be found in Volume 2 of the OCTAVE Method Implementation Guide and in Volume 2 of the OCTAVE-S Implementation Guide.

   These are good starting places for estimating costs. You also need to consider the cost of any training you pursue, and you may need to consider purchasing vulnerability assessment tools or contracting someone to run the tools. Finally, the results of OCTAVE are a protection strategy aimed at improving the organization, and mitigation plans for the information security risks that you identified. Implementing these plans also has costs associated with it. If extensive organizational change is called for, then implementation could take a year or more, resulting in a higher cost than implementing more limited changes.

6. How can I properly scope an initial OCTAVE effort?

   OCTAVE Method
   "Scoping" the use of the OCTAVE Method primarily refers to selecting the operational areas to investigate, but it includes tailoring as well. The general guidance is to select the IT department and at least three areas representing a broad spectrum of the organization. The non-IT areas should reflect the primary operational or business functions as well as the important support functions (for example, Finance and Accounting). Business areas are usually the "owners" of information systems, processes, and data, rather than the technical areas where these information assets are supported. The IT areas tend to be the "custodians" of these assets. Regardless of which areas are chosen, keep in mind that the evaluation concentrates on your organization's critical assets, and both business and technical personnel are needed to identify risks and develop appropriate protection strategies.

   Other factors can guide the selection of scope, including size, complexity, geographic locations, and limitation in sponsorship by senior management. In very large or complex organizations, an initial pilot of the OCTAVE Method may be aimed at a specific functional level, with subsequent evaluations performed on other major departments. In structurally deep organizations, evaluations could be started at a lower layer and expand upward, or begin near the top and filter down.

   Geographic considerations may cause you to perform the OCTAVE Method in parallel at multiple sites, integrating the results later to find common risks and strategies. Where senior management sponsorship is weak or non-existent, you may want to start with a small evaluation in one department or one group, work on one asset, and use the results to build sponsorship.

   You may also find hints in other activities already being performed in your organization. For example, if a risk management function has been implemented across an organization, it may yield several areas with high risk that should be further examined by performing the OCTAVE Method. Other activities, such as recently performed audits, may indicate important areas where the OCTAVE Method could provide additional information on risk and mitigation strategies.

   The scope of the OCTAVE Method effort is unique to each organization. Additional guidance on determining scope for your implementation of the OCTAVE Method is provided in Volume 2, "Preliminary Activities," of the OCTAVE Method Implementation Guide, in the section named "Select Operational Areas to Participate in OCTAVE." The "Tailoring guidelines" section also provides some tips.

   OCTAVE-S
   Scoping OCTAVE-S is considerably easier. In general, OCTAVE-S is used in companies that are so small or so simply organized that the entire organization can be assessed. Some guidance is provided in Volume 2 of the OCTAVE-S Implementation Guide.

7. Is there a recommended analysis team composition that would enhance the effectiveness and efficiency of the OCTAVE effort?

   There are many factors to consider when forming the analysis team that will conduct OCTAVE. First, there is size—3 to 5 members. Second, there are skills—especially the basic skills, such as good facilitation, communication, analytical, and problem-solving skills. However, attention to other factors can contribute to developing an effective analysis team.

   It's important to note that analysis team members do not have to be drawn entirely from the areas under evaluation. Team members need to adequately represent, and have knowledge of, the business and IT perspectives of the organization. Balancing these perspectives is fundamental to successfully using OCTAVE in your organization. For example, an analysis team composed entirely of technical personnel may result in an inclination to discuss and solve current technical issues, distracting from the asset- and risk-focused nature of the process. A team with no technical members may miss the significance of some of the more technical findings and will need help when reaching the more technology-focused processes.

   Ultimately, successful completion of OCTAVE depends on the analysis team's ability to identify risks and assess their impact on your organization. However, the team needs to draw on other resources of your organization to fulfill this task. Technical resources should be drawn into the analysis activities whenever their expertise is needed. In addition, other personnel in your organization, such as people who are knowledgeable about the critical assets, may be helpful in specific activities such as evaluating risks or developing protection strategies.

   In addition, OCTAVE-S requires a team that understands the breadth of the organization and its assets since there are no knowledge-gathering workshops. All the information about assets and threats comes from the team itself.

   Additional guidance on developing your analysis team is provided in Volume 2 of the OCTAVE Method Implementation Guide and in Volume 2 of the OCTAVE-S Implementation Guide.

8. How easy is it to tailor OCTAVE?

   Both the OCTAVE Method and OCTAVE-S are highly configurable to the needs of the organization being evaluated and its domain. The OCTAVE Method is easier to tailor than OCTAVE-S because it is less structured. Since there is no specific guidance available, anyone interested in tailoring OCTAVE-S should refer to the OCTAVE Method tailoring guidance.

   There are many aspects to tailoring, which are discussed throughout the OCTAVE Method Implementation Guide but are concentrated in Volume 2, "Tailoring Guidance." You can tailor both the overall process and the smaller pieces, such as the templates and the catalog of practices. The only constraint on tailoring is the OCTAVE criteria, which defines the requirements for the OCTAVE approach. These requirements include the principles, attributes, and outputs that must be produced for an evaluation to be considered an OCTAVE-consistent method. This still leaves an extremely wide range of tailoring.

   One aid to tailoring can be found in the table on pages PT-9 through PT-12 of Volume 2 in the OCTAVE Method Implementation Guide. This table defines some of the tailoring options and the data dependencies that exist between OCTAVE processes. This information, along with the OCTAVE Method data flow in Volume 16, can help you avoid eliminating or incorrectly moving a critical activity or piece of data. If you change the catalog of practices, you need to update the surveys used in Processes 1 to 3, taking into consideration the appropriateness of each practice to the level of the organization.

   In addition to Volume 2 guidance, both general and specific tailoring information can be found in Volumes 3 to 11 of the OCTAVE Method Implementation Guide. Along with other artifacts, these volumes contain the core process guides for the evaluation process. In each process volume, a set of activities describes how to complete individual steps in the process. Included with almost all of these activities are detailed process and tailoring guidance.

   However, before you tailor the method, we recommend you try it as is, or close to it, to fully understand what happens and how the data is used at each step of the way. Otherwise, it is easy to overlook or dismiss a seemingly minor step that has significant impact later in the process.

9. Is it possible to abuse/misuse OCTAVE?

   It is always possible to misuse any methodology. Whether that "misuse" results in useless data or in different data depends on what you do. At the core of the OCTAVE approach are principles and characteristics that any variation of OCTAVE should adhere to. These are documented in the OCTAVE criteria. The broad range of tailoring allowed by the criteria can result in an endless variety of methods. It is possible, however, to go beyond the criteria, at which point you are no longer consistent with the OCTAVE approach.

   The most likely "misuses" of the OCTAVE approach are violations of the following properties:

   • Self-direction
   • Asset-driven concentration
   • Operational focus
   • Strategic and tactical risk incorporation

   Methods that are not consistent with the OCTAVE approach include these:

   • Non-informational security risk analysis/assessment—assessment of the information technology infrastructure and development of protection strategies without consideration of the information assets you are actually trying to protect; for example, skipping Phase 1 of the OCTAVE Method (identifying assets and threat profiles).
   • Non-risk focused assessment—an assessment that does not look at risks to critical assets or determine the potential impact of threats to the organization; for example, not defining the critical asset, threat, and risk profiles.
   • Consulting that does not include any decision making by the customer—an assessment in which the consultant collects and analyzes all the data and presents a final strategy and plan to the customer; in other words, lack of customer participation on the analysis team or in any of the strategic decision making.

   We do know that some components of the OCTAVE Method and OCTAVE-S could be used in other security-related processes and methods. When you do this, you are not using OCTAVE (and cannot call it that); but you are using pieces of OCTAVE, and the usual copyright restrictions apply. The results you get may still be useful to you.

10. What types of assets does OCTAVE address?

    In OCTAVE, an asset is defined as something of value to an organization. In general, information technology assets are the combination of logical and physical assets that can be grouped into the following categories:

    • information—documented (paper or electronic) data or intellectual property used to meet the mission of an organization.
    • systems—systems that process and store information. Systems are a combination of information, software, and hardware.
    • software—software applications and services (operating systems, database applications, networking software, office applications, etc.) that process, store, or transmit information.
    • hardware— information technology physical devices (workstations, servers, etc.). Normally, hardware assets focus solely on the replacement costs for physical devices.
    • people—the people in an organization who possess unique skills, knowledge, and experience that are difficult to replace.

    Each asset category is linked to information in some way. In OCTAVE, a common pitfall is identifying assets that have no direct relation to information or information technology. For example, people might identify a business process, or they might focus on a piece of physical equipment or facility that has no link to the organization's computing infrastructure (for example, the building that houses the organization). Or people might be tempted to identify intangible assets such as reputation. You identify information-related assets during Phase 1. During Process 7, you link these assets to other types of organizational assets (such as facilities or reputation) when you create and evaluate risk profiles. Each risk in a risk profile provides a link between an information-related asset and other types of organizational assets, such as reputation, business processes, productivity, and facilities.

    A second pitfall is identifying assets that are too general in nature. For example, people often say, "Our systems and our people are our two most important assets." To which systems and which people are they referring? How do those assets relate to information security? You need to focus on information-related assets and be as specific as possible. You can find additional information about asset identification in the following sections of the OCTAVE Method Implementation Guide:

    • Volume 3, Activity A1.1
    • Volume 4, Activity A2.1
    • Volume 5, Activity A3.1

    For OCTAVE-S, additional information can be found in Volumes 3 and 4 of the OCTAVE-S Implementation Guide.

11. What kinds of tools are available for OCTAVE?

    The current range of tools supporting OCTAVE, designed or developed by the Software Engineering Institute, is limited. Other organizations are building other types of tools, such as databases. For now, since the organization itself is the ultimate driver and beneficiary of OCTAVE, we suggest that your organization make use of its own tools and techniques in order to facilitate, schedule, analyze, and document the asset-based risk assessment process.

    To help recognize and employ the tools you may already have at your disposal, we suggest searching for tools capable of

    1. Facilitating OCTAVE—supporting the logistics and data collection activities. Some suggestions are
       • Project management tools (resource enumeration, timelines, Gantt / PERT Charts, etc.)
       • Schedule software for personnel and resources (rooms, equipment, supplies, etc.)
       • Artifacts collection and preservation software (spreadsheet, database, groupware applications)

    2. Enabling analysis and presentation of results. Some suggestions are
       • Word processing, spreadsheets, and presentation software
       • System analysis and development software (flow chart, CASE, dataflow diagrams)
       • Decision support software and structures for the information collected (data collection/mining, expert systems, management information systems, decision support systems, etc.)

12. How does OCTAVE incorporate probability?

    Probability is not explicitly defined in the OCTAVE Method. The analysis approach that we have incorporated into the OCTAVE Method is derived from a technique called scenario planning. During Process 4, you create threat profiles for critical assets. You then discard scenarios with a negligible likelihood of occurring or that do not apply, and you move forward scenarios that you believe have a non-negligible likelihood of occurring. When you do this, you are implicitly evaluating the probability using the binary values of negligible (1) and non-negligible (0).

    During Process 7, you expand threat profiles into risk profiles by identifying potential impacts on the organization for each threat scenario—risk scenarios for each critical asset. During Process 8, you form a protection strategy that best addresses the range of risk scenarios that your organization faces. As you do this, you assume that the probability for all risk scenarios is equally likely. This technique addresses the following issues:

    • There is a general lack of data about many types of threats. Scenario-based analysis does not require analysis teams to forecast probabilities without sufficient threat data.
    • Many traditional techniques for information security risk analysis do not adequately address extreme events (low-probability, very high-impact events). Scenario-based analysis enables analysis teams to address extreme or catastrophic events.

    The analysis technique incorporated into the OCTAVE Method is strategic in nature and is based on accepted security practices. We designed it this way to compensate for the lack of data about many types of threats and to handle extreme and catastrophic events. A binary form of probability is used during Process 4 to establish the range of risk scenarios to carry forward in the evaluation. After that, all probabilities are assumed to be equally likely. This technique avoids the potential of skewed results based on subjective probability estimates. It also forces an organization to form a protection strategy that best addresses the range of risks that it faces. Some organizations might prefer analysis techniques based on probability or might be required to use probability because of regulations. In these cases, you can tailor the OCTAVE Method to incorporate probability.

    OCTAVE-S incorporates a simple, qualitative approach to probability that relies on the existence of historical or other data to support a reasonable estimate of probability. If this version continues to provide a useful way to incorporate probability, it will be integrated into the OCTAVE Method at a later date. In the meantime, OCTAVE Method users may wish to review OCTAVE-S and tailor the OCTAVE Method to include probability.

13. Can I use OCTAVE effectively if my primary technology platform is a mainframe or mid-range (AS/400, etc.) computer?

    Many organizations have mainframe or mid-range platforms integrated into their distributed processing. For example, many mainframes or enterprise servers are assigned an Internet Protocol (IP) address so that they can be addressed over a distributed network. OCTAVE does not exclude risks that are present at the mainframe and mid-range hardware platforms. The asset-based focus of OCTAVE places more importance on the information asset than the platform on which it resides. The platform, or key component, of an information asset is important in Phase 2, in which the current state of vulnerabilities is determined. Mainframe and mid-range servers may be one of these key components for which vulnerabilities must be identified.

    However, vulnerability scanning tools for these platforms are scarce. Network scanning tools can provide information about the network to which the mainframe or mid-range hardware is connected, but they do not tell you much about vulnerabilities at this platform. As a result, if you have mainframe or mid-range servers as key components, you may want to have a conversation with your mainframe or mid-range support personnel (such as system programmers or administrators) to identify and understand any vulnerabilities that may exist in these platforms.

14. What does my organization do after OCTAVE is done?

    OCTAVE produces three results: a protection strategy for your organization, mitigation plans for the risks to critical assets, and short-term action items. After conducting OCTAVE, you might consider

    • implementing the strategy, plans, and actions—implement the needed security practices (for example, routine vulnerability scans or periodic user refresher training)
    • monitoring progress and report issues to an appropriate individual or group
    • adjusting the strategy and plans as needed to correct for deviations or actions that do not produce the desired results
    • watching for new risks or assets that are you believe are critical enough that they need to be dealt with
    • considering whether to expand your evaluation to additional important assets or other operational areas—this depends on how you scoped the initial evaluation
    • considering when to re-evaluate your organization

    Evaluations can be done periodically, every 1-3 years, or on an as-needed basis due to some specific event (such as a major change or replacement of critical systems). The items listed above are accomplished in between evaluations.

[top]

1. Alberts, C., Dorofee, A., Stevens, J., and Woody, C. Introduction to the OCTAVE Approach. Software Engineering Institute, August 2003. Available online; see http://www.cert.org/octave/approach_intro.pdf (pdf)
2. Alberts, C., Dorofee, A. "Volume 1: Introduction." OCTAVE Method Implementation Guide V2.0. Software Engineering Institute, June 2001. Page I-4. Available online; see http://www.cert.org/octave/omig.html.
3. Alberts, C., Dorofee, A. "Volume 2: Preliminary Activities." OCTAVE Method Implementation Guide V2.0. Software Engineering Institute, June 2001. Pages PT-1-PT-12. Available online; see http://www.cert.org/octave/omig.html.
4. Alberts, C., Dorofee, A. OCTAVE Criteria: Version 2.0. (Technical report CMU/SEI-01-TR-020) Software Engineering Institute, December 2001. Available online; see http://www.cert.org/octave/criteria.html.
5. Alberts, C., Dorofee, A., Stevens, J., and Woody, C. "Volume 1: Introduction to OCTAVE-S." OCTAVE Implementation Guide, Version 0.9. Software Engineering Institute, August 2003. Available online; see http://www.cert.org/octave/osig.html
6. Alberts, C., Dorofee, A., Stevens, J., and Woody, C. "Volume 2: Preparation Guidance" OCTAVE Implementation Guide, Version 0.9. Software Engineering Institute, August 2003. Available online; see http://www.cert.org/octave/osig.html

Other Reading

1. Alberts, C., Dorofee, A. Managing Information Security Risks: The OCTAVE Approach. New York: Addison-Wesley, 2003. Available for online order.