The Collins English Dictionary defines a methodology as a way of proceeding or doing something, especially a systematic or regular one.

The discipline of risk management has its fair share of methodologies, some of which are described here.

METHODOLOGIES

CORAS

CORAS is an open-source risk management tool available from SourceForge without the additional scope included in Sherwood Applied Business Security Architecture (SABSA; see below). It consists of eight distinct steps,¹ which follow the generic risk management principles:

• Step 1 is the initial preparations for a risk analysis. The main objectives are to understand what the target is and what the size of the analysis will be.
• Step 2 is to establish the overall goals of the analysis and the target to be analysed. The objectives are to achieve a common understanding of the target and the major areas of concern.
• Step 3 aims to ensure a common understanding of the target of analysis, including its focus, scope and main assets. This step will conduct a rough, high-level analysis to identify major threat scenarios, vulnerabilities and enterprise level risks.
• Step 4 aims to ensure that the background documentation for the rest of the analysis, including the target, focus and scope, is correct and complete and is approved. Step 4 furthermore includes deciding the risk evaluation criteria for each asset. This analysis step concludes the context establishment.
• Step 5 is risk identification using structured brainstorming. Risk identification involves a systematic identification of threats, unwanted incidents, threat scenarios and vulnerabilities with respect to the identified assets. The results are documented by means of CORAS threat diagrams.
• Step 6 aims to determine the risk levels of the risks that are represented by the identified unwanted incidents.
• Step 7 examines which of the identified risks are acceptable, and which of the risks must be further evaluated for possible treatment.
• Step 8 is concerned with the identification and analysis of treatments. The risks that are found to be unacceptable are evaluated to find means to reduce them. Since treatments can be costly, they are assessed with respect to their cost–benefit, before a final treatment plan is made.

The platform-independent CORAS risk management tool is available as a free download from https://www.coras.sourceforge.net/, as is a guided tour of the CORAS method.

Factor Analysis of Information Risk (FAIR)

FAIR is a framework developed in the early 2000s and now maintained by the FAIR Institute (https://www.fairinstitute.org).

FAIR follows a similar route to risk assessment as other methodologies, but uses slightly different terminology together with its method of deriving the likelihood of an event. It carries out the risk assessment in a different order and consists of four stages:

Stage 1 – Identify scenario components (much the same as asset identification)

1. Identify the asset at risk.
2. Identify the threat community under consideration. The threat community is used to group different threat sources together, such as internal staff or the hacking community.

Stage 2 – Evaluate the loss event frequency (the likelihood)

3. Estimate the probable threat event frequency that, within a given timeframe, a threat agent will act against an asset.
4. Estimate the threat capability or the probable level of force that a threat agent is capable of applying against an asset.
5. Estimate the strength of existing controls, which, over a given timeframe, are measured against a baseline level of force.
6. Derive the vulnerability, or the probability, that an asset will be unable to resist the actions of a threat agent.
7. Derive the loss event frequency, or the probable frequency, within a given timeframe, that a threat agent will inflict harm upon an asset.

Stage 3 – Evaluate probable loss magnitude (the impact or consequence)

8. Estimate worst-case loss.
9. Estimate probable loss.

Stage 4 – Derive and articulate risk (the risk analysis)

10. Derive and articulate risk, by combining the probable frequency and probable magnitude of loss.

Although FAIR covers risk assessment, it does not address an organisation’s risk appetite or tolerance and makes no mention of risk treatment, and so is only really useful for the earlier stages of an information risk management programme.

Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE)

OCTAVE originates from the Carnegie Mellon Software Engineering Institute.

The OCTAVE method uses a three-phased approach to examine organisational and technology issues, assembling a comprehensive picture of the organisation’s information security needs. It is aimed at organisations with around 300 or more people. The method is organised into a progressive series of workshops, and the process is supported with guidance, worksheets and questionnaires.

In phase 1 the organisation builds asset-based profiles, identifying assets, threats, current practices, organisational vulnerabilities and security requirements. This is achieved in four distinct processes:

1. Identify senior management knowledge.
2. Identify operational area management knowledge.
3. Identify staff knowledge.
4. Create threat profiles.

Moving to the second phase, which involves two processes, the organisation will identify infrastructure vulnerabilities:

1. Identify key components.
2. Evaluate selected components and establish technical vulnerabilities.

In the third and final phase, the organisation will develop security strategies and plans:

1. Conduct risk analysis.
2. Develop protection strategy.

The method then uses a catalogue of practices to apply appropriate controls.

The strategic practices are:

• security awareness and training;
• security strategy;
• security management;
• security policies and regulations;
• collaborative security management;
• contingency planning and disaster recovery.

The operational practices are:

• Physical security – physical security plans and procedures; physical access control; monitoring and auditing physical security.
• Information technology security – system and network management; system administration tools; monitoring and auditing IT security; authentication and authorisation; vulnerability management; encryption; security architecture and design.
• Staff security – incident management; general staff practices.

OCTAVE-S

Whereas OCTAVE relies on a progressive series of workshops involving managers from different levels within the organisation, OCTAVE-S, which is designed for organisations with fewer than 100 people, uses the skills and experience of a smaller team of people (typically three to five in number) who have extensive knowledge of the organisation.

It also differs from OCTAVE in that the OCTAVE-S worksheets and guidance already contain security concepts, which permits less experienced information risk management practitioners to assess a very broad range of risks, many of which may be unfamiliar to them.

Finally, OCTAVE-S is less demanding on information relating to the organisation’s information infrastructure, since smaller organisations tend to have less capability to use vulnerability tools.

OCTAVE Allegro

OCTAVE Allegro is a more streamlined version of OCTAVE, and takes a slightly different approach from OCTAVE in that, although it makes use of progressive workshops, the focus is more on the information assets themselves, the use to which they are put, stored, transported and processed and how they are impacted by threats, vulnerabilities and disruptions.

The method consists of four stages:

Stage 1 – Establish drivers

1. Establish risk measurement criteria.

Stage 2 – Profile assets

2. Develop information asset profile.
3. Identify information asset containers.

Stage 3 – Identify threats

4. Identify areas of concern.
5. Identify threat scenarios.

Stage 4 – Identify and mitigate risks

6. Identify risks.
7. Analyse risks.
8. Select mitigation approach.

Information on all three OCTAVE methodologies can be found at https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=309051.

SABSA

Developed by John Sherwood in 1995 and published in 1996 as SABSA: a method for developing the enterprise security architecture and strategy, the SABSA framework has evolved as a ‘best practice’ method for delivering cohesive information security solutions to enterprises. It is a six-layer model covering all four parts of the IT life cycle: strategy, design, implementation, and management and operations.

This makes SABSA a very powerful tool that is not limited just to risk management. It is designed to ensure that the security needs of enterprises are met and that security services are designed, delivered and supported as an integral part of an IT management infrastructure and it provides guidance for aligning architecture with business value.

SABSA looks at security architecture from several perspectives:

• The business view, referred to as the contextual security architecture, which examines the business assets, risks, processes, organisation, geography and time dependencies.
• The architect’s view, referred to as the conceptual security architecture, which examines the strategic and risk management objectives and the organisation’s high-level roles and responsibilities.
• The designer’s view, referred to as the logical security architecture, which examines the policies and logical security services such as authentication, confidentiality and integrity protection, non-repudiation and system assurance, people, their roles and responsibilities, and the security domains.
• The builder’s view, referred to as the physical security architecture, which examines the business data model, rules, security mechanisms, people dependencies and security technology infrastructure.
• The tradesman’s view, referred to as the component security architecture, which examines the standards, tools and products used to implement the overall security architecture.
• Cutting across all these is the service manager’s view, referred to as the security service management architecture, which examines the delivery management, operational risk management, personnel management and environmental management of the security infrastructure.

Each of these security architectures is mapped against a series of basic questions: what? why? how? who? where? and when? to form the SABSA Matrix.

SABSA mimics the PDCA model as its life cycle, but names the parts slightly differently as ‘Strategy and planning’; ‘Design’; ‘Implement’; ‘Manage and measure’. It then examines the use of business attributes to provide a link between the organisation’s business requirements and the technology and process design, either in the form of ICT business attributes or general business attributes:

ICT attributes:

• user;
• management;
• operational;
• risk management;
• legal and regulatory;
• technical strategy;
• business strategy.

High-level general business attributes:

• financial;
• physical;
• human;
• process;
• strategic;
• system.

In terms of the generic information risk management method, SABSA also includes the processes to provide consultation and communication, referred to as ‘communicate’, and monitor and review, referred to as ‘assure’, and has the capability to do this at four distinct levels.

More information on SABSA is available from https://www.sabsa.org/.

OTHER GUIDELINES AND TOOLS

BS 7799-3

BS 7799-3:2017 – Information security management systems. Guidelines for information security risk management.

Recently updated, BS 7799-3 summarises the information risk management process extremely well, with numerous references to the ISO IEC 27001:2017 standard. It is well worth obtaining a copy as background reference material.

Its main sections follow the standard risk management process and are a revision of the earlier ISO/IEC 27005 standard.

• An overview of the information security risk assessment and risk treatment process in section 4, including the information security risk treatment process diagram (see Chapter 1 of this book).
• A description on communication and consultation in section 5.
• A description of context establishment in section 6, with examples of:
  • logarithmic likelihood scales;
  • logarithmic consequence scales;
  • indicator scales.
• Section 7 covers risk identification and analysis, and contains an example of scenarios that give coverage of the controls in ISO/IEC 27001:2017, Annex A.
• Section 8 discusses information security risk treatment.
• Section 9 describes the verification of necessary controls, and includes a diagrammatic representation of the cross-checking processes.
• Section 10 briefly discusses approval of the risk treatment controls.
• Section 11 briefly describes operation of the overall organisational process.
• Section 12 examines monitoring, audit and review.

BS 7799-3:2017 can be obtained in PDF or hard copy formats from the BSI online shop at https://www.bsigroup.com/Shop.

NIST SP800-30

Guide for Conducting Risk Assessments – NIST Special Publication 800-30 Revision 1

While there are some minor differences in the approach of SP800-30 from those described elsewhere in this book, it remains an extremely comprehensive and detailed information risk management standard.

One of the most useful sections is its final two-page Appendix L – Summary of tasks:

Step 1 Prepare for risk assessment

• Identify purpose.
• Identify scope.
• Identify assumptions and constraints.
• Identify information sources.
• Identify risk model and analytic approach.

Step 2 Conduct risk assessment

• Identify threat sources.
• Identify threat events.
• Identify vulnerabilities and predisposing conditions.
• Determine likelihood.
• Determine impact.
• Determine risk.

Step 3 Communicate and share risk assessment results

• Communicate risk assessment results.
• Share risk-related information.

Step 4 Maintain risk assessment

• Monitor risk factors.
• Update risk assessment.

The first chapter introduces the content and organisation of the remainder of the standard, which consists of:

Chapter 2 The fundamentals

• Risk management process.
• Risk assessment.
• Key risk concepts.
• Application of risk assessments.

Chapter 3 The process

• Preparing for the risk assessment.
• Conducting the risk assessment.
• Communicating and sharing risk assessment information.
• Maintaining the risk assessment.

Appendix A References

Appendix B Glossary

Appendix C Acronyms

Appendix D Threat sources

Appendix E Threat events

Appendix F Vulnerabilities and predisposing conditions

Appendix G Likelihood of occurrence

Appendix H Impact

Appendix I Risk determination

Appendix J Informing risk response

Appendix K Risk assessment reports

Appendix L Summary of tasks (listed above)

As with all NIST standards, they may be downloaded free of charge from https://doi.org/10.6028/NIST.SP.800-30r1.

Risk assessment tools

The internet lists numerous risk management software tools, many of which are not especially well-suited to use in information risk management, some of which are aimed at the larger enterprise and others that can be better used by smaller organisations.

It is not intended to endorse or make any recommendations as to which (if any) of the tools are best suited to information risk management use, but instead to provide some suggestions as to the key attributes you may wish to consider when selecting one. Please note that these do not include the ‘usual’ considerations, such as cost, support capability and so on.

1. Does the tool address any or all of the standards to which the organisation is working or aims to reach?
2. Does the tool provide a complete risk management overview, or is it limited to risk assessment only (i.e. no risk treatment)?
3. Does the tool contain predefined:
   • types of asset;
   • types of impact;
   • threats;
   • vulnerabilities;
   • controls;

   and can additional ones be user-defined?

4. Can the tool import an asset list from a spreadsheet or database?
5. Does the tool permit the user to break down the impact assessment by confidentiality, integrity and availability?
6. Does the tool permit more than one threat or vulnerability for each asset?
7. Does the tool permit more than one control for each risk identified?
8. Does the tool provide output in the form of a risk register?
9. Does the tool provide output in graphical form?
10. Is the tool scalable to enterprise level?
11. Is the tool single-user or multi-user?
12. Can the tool be run on multiple operating systems (for example, Windows, MacOS, Unix and Linux), and are there mobile applications (for example, iPhone, iPad, Android) that can interwork with it?
13. Are you able to download a trial version of the tool?

1 See Lund, M.S., Solhaug, B. and Stølen, K. ( 2011) Model-Driven Risk Analysis: The CORAS Approach. Berlin, Heidelberg: Springer-Verlag.