OCTAVESM Method Frequently Asked Questions

OCTAVE^SM Method Frequently Asked Questions (FAQ) 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.   How long does it take and how much does it cost to do an OCTAVE?
5.   How can I properly scope an initial OCTAVE effort?
6.   Is there a recommended analysis team composition that would enhance the effectiveness and efficiency of the OCTAVE effort?
7.   How easy is it to tailor the OCTAVE Method?
8.   Is it possible to abuse/misuse the OCTAVE Method?
9.   What types of assets does the OCTAVE Method address?
10. What kinds of tools are available for the OCTAVE Method?
11. How does the OCTAVE Method incorporate probability?
12. Can I use OCTAVE effectively if my primary technology platform is a mainframe or mid-range (AS/400, etc.) computer?
13. What are the restrictions on using OCTAVE, and can it be licensed?
14. What does my organization do after OCTAVE is done?

What is the OCTAVE approach?
The Operationally Critical Threat, Asset, and Vulnerability Evaluation^SM (OCTAVE^SM) approach is a systematic way for an organization to address its information security risks, sorting through the complex web of organizational and technological issues.
At the core of the approach is the concept of self-direction, where the organization manages and directs the information security risk evaluation. The OCTAVE approach uses a small, interdisciplinary team of an organization's personnel, the analysis team, to lead the process. This team includes people from the business units and information technology (IT). Information security is the responsibility of everyone in the organization, not just the IT department. People from the business units know what information is important to complete their tasks as well as how they access and use the information. The information technology staff understands issues related to computing infrastructure configuration as well as what is needed to keep it running. These perspectives are important in understanding the global, organizational view of information security risk.
The OCTAVE approach, shown in the diagram below, includes a set of criteria that defines the requirements for a comprehensive, self-directed information security risk evaluation, and a set of methods consistent with the criteria. The OCTAVE Method, available now, was built with larger organizations in mind. A second method, OCTAVE-S^SM will focus on smaller organizations. These two methods will provide the end points of a continuum of various methods aimed at different sizes and types of organizations. We expect many of these other methods to be developed by other organizations, using the criteria as basic requirements.

How is OCTAVE different from other security assessments?
There are several types of security assessments currently being performed. The most common are technical vulnerability assessments, information system audits, and security risk assessments. These are described below.

Vulnerability Assessment
A vulnerability assessment is a systematic, usually tool-driven, examination of an organization's technology base, policies, and procedures. It includes a complete analysis of the security of an internal computing infrastructure and its vulnerability to internal and external attacks. These assessments generally

use standards for specific IT security activities
assess the entire computing infrastructure
use (sometimes proprietary) software tools to analyze the system infrastructure
analyze the detected technological vulnerabilities and may include recommended steps to address those vulnerabilities

Information Systems Audit
Information systems audits are independent appraisals of a company's internal controls to assure management, regulatory authorities, and company shareholders that information is accurate and valid. Audits typically use industry-specific process models, benchmarks, standards of due care, or established best practices. They look at both financial and operational performance. An audit may also be based on proprietary business process risk control and analysis methods and tools. Audits are usually performed by licensed auditors and have legal implications and liabilities.

Security Risk Assessment
A security risk assessment (which can be done by an internal or external group) expands upon the vulnerability assessment to look at the security-related risks within a company, including internal and external sources of risk as well as electronic-based and people-based risks. These assessments

examine the corporate practices to identify strengths and weaknesses
examine the IT infrastructure to determine technological vulnerabilities
focus on different parts of the technology infrastructure such as mainframe systems, distributed systems, networks and communications, policy, and physical security
help decision makers examine trade-offs to select cost-effective countermeasures

The OCTAVE approach is a variation of the third type. It focuses first on identifying what information assets are critical to the businesses success and operations and then uses that information to set the scope of the rest of the evaluation.

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 the OCTAVE Method 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 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
you are a large (300 or more employees) organization

We are developing another OCTAVE-consistent method for smaller organizations (expected release is December 2002); but for now, you may be able to tailor or scale down the OCTAVE Method. If your organization is smaller than 300 employees, you should download Volumes 1 and 2 of the OCTAVE Method Implementation Guide from the CERT/CC web site http://www.cert.org/octave/omig.html. They will give you a better idea of the scope and extent of the OCTAVE Method. You should then discuss with your managers or senior managers the need for this type of evaluation and decide if you want to do a limited pilot effort or a full evaluation.

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 absolute shortest amount of time to conduct the OCTAVE Method is 2 to 3 weeks, but scheduling often drives it to at least 6 weeks. 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.
Cost is a generally related to time – time for the analysis team to do its work and the time of other participants. OCTAVE Method Implementation Guide, Volume 2, pages PG-8 and PG-12, (see http://www.cert.org/octave/omig.html) has several detailed tables identifying the expected time for different types of participants. This is a good starting place for estimating costs. You also need to consider the cost of training (if you want it), and you may need to consider purchasing vulnerability assessment tools or contracting someone to run the tools. Finally, the results of the OCTAVE Method 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.
Note: Other implementations of the OCTAVE approach require different amounts of time.

How can I properly scope an initial OCTAVE effort?
"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 in order 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 effort is unique to each organization. Additional guidance on determining scope for your implementation of the OCTAVE Method is provided in the OCTAVE Method Implementation Guide, Volume 2 "Preliminary Activities," in the section named "Select Operational Areas to Participate in OCTAVE." The "Tailoring guidelines" section also provides some tips.

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 the OCTAVE Method. 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. Analysis 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 the OCTAVE Method 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 the OCTAVE Method 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.
Additional guidance on developing your analysis team is provided in the OCTAVE Method Implementation Guide, Volume 2 "Preliminary Activities," in the section named "Select Analysis Team Members."

How easy is it to tailor the OCTAVE Method?
The OCTAVE Method is highly configurable to the needs of the organization being evaluated and its domain.
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, 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 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 all too easy to overlook or dismiss a seemingly minor step that has significant impact later in the process.

Is it possible to abuse/misuse the OCTAVE Method?
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 tailored variation of the OCTAVE Method should adhere to. These are documented in the OCTAVE criteria [3]. 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 that are likely to occur are violations of the following properties [3]:

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 (knowledge elicitation 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, skipping Processes 4 and 7 of the OCTAVE Method (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 of Processes 4 to 8A.

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

What types of assets does the OCTAVE Method address?
In the OCTAVE Method, 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 the OCTAVE Method, 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 Processes 1-3. 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, facilities, etc.
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 (pages G1-8 to G1-11)
Volume 4, Activity A2.1 (pages G2-8 to G21-11)
Volume 5, Activity A3.1 (pages G3-8 to G3-11)

What kinds of tools are available for the OCTAVE Method?
The current range of tools supporting OCTAVE Method delivery, designed or developed by the Software Engineering Institute, is limited. Other organizations pursuing licensing of the OCTAVE Method are expected to automate the method and provide other types of tools, such as databases. For now, since the organization itself is the ultimate driver and beneficiary of the OCTAVE Method, 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

Facilitating the OCTAVE Method – 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)

Enabling analysis and presentation of results. Some suggestions are

Word processing 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.)

How does the OCTAVE Method 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 to 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.

Can I use the 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. The OCTAVE Method does not exclude risks that are present at the mainframe and mid-range hardware platforms. The asset-based focus of the OCTAVE Method 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 Processes 5 and 6, 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.

What are the restrictions on using OCTAVE and can it be licensed?
There are two aspects to consider – internal use and external use. There are no restrictions on internal use. You may use the OCTAVE Method inside your organization in whatever manner works for you. We expect that you will tailor the process and artifacts to meet your own needs and that you will reproduce whatever materials are needed to use the OCTAVE Method. That's what the CD-ROM is for. The internal "license" is purchased when you buy the OCTAVE Method Implementation Guide.
External use – facilitating or delivering an evaluation to another customer – is regulated by SEI licensing. We do recognize that there are organizations who want additional help running this evaluation, who may not want to spend the resources setting up analysis teams, or who feel they are too lacking in the right knowledge and skills to do this on their own. The SEI will license other organizations to provide these services. There are several forms of licensing, differing in cost and the benefits to the licensee. For more information, check www.cert.org/octave/licensing.html. To discuss getting a license, send email to octave-licensing@sei.cmu.edu.

What does my organization do after OCTAVE is done?
The OCTAVE Method produces three results: a protection strategy for your organization, mitigation plans for the risks to critical assets, and short-term action items. After conducting the OCTAVE Method, 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]

Sources Referenced in this FAQ

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.
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.
Alberts, C., Dorofee, A. OCTAVE Criteria: Version 2.0. (Technical report CMU/SEI-01-TR-016) Software Engineering Institute, December 2001. Available online; see http://www.cert.org/octave/.

Copyright 2002 Carnegie Mellon University
CERT and CERT Coordination Center are registered in the U.S. Patent & Trademark Office.
Operationally Critical Threat, Asset, and Vulnerability Evaluation, OCTAVE, and OCTAVE-S are service marks of Carnegie Mellon University.
Disclaimers and copyright information
Last updated May 23, 2002