The article will provide a quick overview and introduction into the Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Allegro  methodology, its approach and terminology. OCTAVE Allegro is an asset centric and lean risk assessment successor of the OCTAVE method. The method supports a straight-forward qualitative risk assessment and structured threat analysis which mainly fits for smaller organisations (few hundred employees). Figure 1 is based on  and groups the methodology steps into four major phases.
OCTAVE Allegro Phases
- Phase “Establish Drivers” aims to justify and prioritise the measurement criteria for risk for a specific organisation.
- Phase “Profile Assets” is designed to identify and document logical, technical, physical and people assets.
- Phase “Identify Threats” focuses on the identification of threats against the identified assets.
- Phase “Identify and Mitigate Risk” supports the valuation of the risks posed against the critical information assets. Finally, after this step, the mitigation strategy for each of the identified risks is defined.
Figure 1: OCTAVE Allegro steps and phases 
OCTAVE Allegro Steps
This section goes through all of the OCTAVE Allegros steps to provide an introduction into the methodology. Moreover, each step will be accompanied by a fictitious example related to AMI. Note, that dark coloured steps in figure 1 are considered major steps in order to conduct a threat analysis whereas light coloured steps are crucial when approaching a complete risk assessment.
Step 1 advises to identify all areas that impact an organisation. The methodology requires for a minimum set of areas which includes safety, health, productivity, reputation, financial and fines. For each of the impact areas, a set of criteria to measure low, medium and high impact must be developed. Table 1 provides an example for loss of revenue in case of data privacy violation. Finally, the major areas will be ranked and assigned values in order to allow for risk scoring. In case five areas have been identified and “legal penalties” is considered the top risk area, then the area would be assigned a five. An example is provided in table 6.
Table 1: OCTAVE Allegro Step 1: Establish Risk Measurement Criteria. Impact Area Example
Step 2 provides guidance in identifying critical information assets for the organisation. The methodology also provides a set of questions and asks for example for the value of assets or the dependency on assets for the day-to-day business of the organisation. Each identified information asset will be attributed additional cornerstone such as the security requirements to make up a whole information asset profile. An example for key material in a smart meter is provided in table 2. Moreover, each profile’s most important security requirement is being identified to support the later valuation of the potential impacts. OCTAVE Allegro does not provide much guidance and structure on how to identify security requirements. A way to model such requirements is by means of misuse cases . The misuse case approach lends it from the unified modelling language (UML) such as used in common software engineering processes where success and fail scenarios of interaction with data and processes is being modelled. Though, the modelling of misuse cases rather focuses on the abuse of such scenarios by malicious actors (misusers).
Table 2: OCTAVE Allegro Step 2: Develop Information Asset Profile. Critical Information Asset Example
Step 3 collects information asset containers in the form of an information asset risk environment map. Information asset containers, as the name implies, can hold, process or somehow get in touch with information assets. The methodology classifies containers as technical, physical and people. Table 3 provides examples for each of the types. Correspondingly, containers are being attributed whether they are of type internal which means under control of the organisation or whether the container is external.
Table 3: OCTAVE Allegro Step 3: Identify Information Asset Containers. Container Examples
For the analysis of an organisation the type column can be attributed with minimal effort. However, for an abstract analysis such as network protocols or embedded devices, some assumptions must be made. There is no general rule on what assumptions to make.
Step 4‘s goal is to identify major areas of concern. Thereby the method foresees to consider all containers and to identify issues that could affect assets within the container. The compiled list of “areas of concern” is then expanded with the according actor, the means to realise the threat, the motive of the actor and the potential outcome. Whereby an outcome is always one out of disclosure, modification, interruption or destruction. The method documentation further lists loss next to destruction. An example, implicitly referencing the affected information asset, is provided in table 4. This step does not aim to identify a complete list of threats but helps to capture the major concerns in short time.
Table 4: OCTAVE Allegro Step 4: Identify Areas of Concern. Area of Concern Example
Note, that I have made use of this step in order to capture area of concerns for the smart meter and wireless M-Bus analysis within my master thesis.
Step 5 ensures structured identification of all potential threats. Threat trees ensure robust consideration of threats. The step relies on four trees in total. Two considering human actors with either technical or physical means and two considering technical and other problems. Part of the “Human Actors Using Technical Means” tree originating of the methodology documentation  is shown in figure 2.
Figure 2: OCTAVE Allegro “Human Actors Using Technical Means” Tree 
With each information asset, each branch of the four trees will be traversed to ensure thorough coverage and identification of threats. The guidance provides worksheets and questionnaires to simplify the activity. The result of the walk through will be a comprehensive list of threat entries as shown in table 4. Optionally, each resulting list entry can be assigned the probability of the realisation of the concerned threat scenarios with either low, medium or high likelihood.
As this is a tedious task in an assessment based on OCTAVE Allegro, I would not dig too much into it unless the previous step “Identify Areas of Concern” does not provide sufficient material or the analysis significantly lacks coverage. However, if thorough coverage is a requirement, that step cannot be circumvented.
Step 6 consists of a single activity and aims to identify the impact if a certain threat scenario becoming realised. Following that, each threat scenario will be attributed a consequence. Thus, table 4 has been expanded with an additional column to describe the consequence for each scenario. Part of table 4 and the newly added column is shown in table 5.
Table 5: OCTAVE Allegro Step 6: Identify Risks. Risk Example
Step 7 focuses on creation of a relative risk scores for each identified threat scenario. The impact on each impact area as well as the impact area importance will be reflected in the total risk score. The score should help to decide on what mitigation approach to choose in the ultimate step of the methodology. Assumed the impact area ranking in table 6 and threat scenario listed in table 5 the risk score for that specific scenario calculates as shown in table 6.
Table 6: OCTAVE Allegro Step 7: Analyse Risk. Example Risk Score Calculation
Basically, for each impact area the impact will be measured according to the criteria defined in step 1. An example of such criteria is provided in table 1. High impact will be assigned a value of three and low impact accordingly a value of one. The impact area ranking is then multiplied with the threat scenario impact value whereby the result of that calculation contributes to the total risk score.
Step 8 the ultimate step in the OCTAVE Allegro qualitative risk assessment method deals with the mitigation approach of identified risks. In general risks can be accepted, mitigated, transferred, avoided or being further monitored (deferred) whereas mitigation aims to avoid or limit the risk. However, the efforts for avoidance and limitation should never outweigh a potential impact.
Though numbers have been assigned as risk scores, their specific value only provides indication to whether a risk should to be mitigated or not. One might also take the likelihood of occurrence and some organisation specifics into account. It is suggested to divide the risks into four pools, pool one to pool four, whereby each pool groups threats for a range of the total risk score. The four pools are then approached as follows:
- Pool 1: Mitigate
- Pool 2: Mitigate or Defer
- Pool 3: Defer or Accept
- Pool 4: Accept
Depending on whether probabilities have been assigned in step 5 of the methodology it is suggested to either form a list of all risks and then split it into four pools or create a matrix which reflects the four pools and takes the probability into account. Finally, a mitigation strategy should be formulated for all risks that need to be mitigated. The mitigation strategy should list the information asset container to which the controls will be applied. Plus, the chosen strategy should consider and outline potential residual risks. An example of such a mitigation strategy is provided in table 7.
Table 7: OCTAVE Allegro Step 8: Select Mitigation Approach. Mitigation Strategy Example
OCTAVE Allegro is a lean risk assessment method and does not provide guidance in selecting security controls as with extensive information security management standards such as ISO 27000 . However, ISO 27002  and NIST SP 800-53  provide a comprehensive list of controls to choose from, if needed.
 R.A. Caralli, J.F. Stevens, L.R. Young, W.R. Wilson. The OCTAVE Allegro Guidebook, v1.0. Cert Program, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213. May 2007, Online http://www.cert.org/octave/allegro.html
 R.A. Caralli, J.F. Stevens, L.R. Young, W.R. Wilson. Introducing OCTAVE Allegro: Improving the Information Security Risk Assessment Process. CMU/SEI-2007-TR-012, CERT Program, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213. May 2007, Online http://www.cert.org/archive/pdf/07tr012.pdf
 G. Sindre and A.L. Opdahl. Eliciting security requirements with misuse cases. Requirements Engineering Vol. 10 No. 1, pp. 34-44. Jun. 2004 (DOI 10.1007/s00766-004-0194-4)
 ISO-27000:2009: Information technology – Security techniques – Information security management systems – Overview and vocabulary
 ISO 27002:2005: Information technology – Security techniques – Code of practice for information security management
 NIST. Security and Privacy Controls for Federal Information Systems and Organizations. Special Publication 800-53, Rev. 4, Final Public Draft, Feb. 2013, Online http://csrc.nist.gov/publications/drafts/800-53-rev4/sp800_53_r4_draft_fpd.pdf