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,1 which follow the generic risk management principles:
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)
Stage 2 – Evaluate the loss event frequency (the likelihood)
Stage 3 – Evaluate probable loss magnitude (the impact or consequence)
Stage 4 – Derive and articulate risk (the risk analysis)
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:
Moving to the second phase, which involves two processes, the organisation will identify infrastructure vulnerabilities:
In the third and final phase, the organisation will develop security strategies and plans:
The method then uses a catalogue of practices to apply appropriate controls.
The strategic practices are:
The operational practices are:
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
Stage 2 – Profile assets
Stage 3 – Identify threats
Stage 4 – Identify and mitigate risks
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:
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:
High-level general business attributes:
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.
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
Step 2 Conduct risk assessment
Step 3 Communicate and share risk assessment results
Step 4 Maintain risk assessment
The first chapter introduces the content and organisation of the remainder of the standard, which consists of:
Chapter 2 The fundamentals
Chapter 3 The process
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.
and can additional ones be user-defined?
1 See Lund, M.S., Solhaug, B. and Stølen, K. ( 2011) Model-Driven Risk Analysis: The CORAS Approach. Berlin, Heidelberg: Springer-Verlag.