Author: Anuj Tewari
Unfortunately, hope is not a plan, so organizations look to standards bodies like ISO, OCTAVE, PCI DSS, NIST, etc for guidance on security best practices. But choosing a best practices standard or framework to follow is its challenge. There are many of them and many factors to evaluate, including the standards’ similarities to existing organizational practices, costs, complexity, supporting documentation.
Risk Assessment Methodologies:
The term methodology means an organized set of principles and rules that drive action in a particular field of knowledge. A methodology does not describe specific methods; nevertheless it does specify several processes that need to be followed. These processes constitute a generic framework. They may be broken down in sub-processes, they may be combined, or their sequence may change. However, any risk management exercise must carry out these processes in one form or another; the following document compares the processes foreseen by three leading standards (ISO 27005, NIST SP 800-30 & OCTAVE).
ISO/IEC 27005:2008 is applicable to all types of organizations (e.g. commercial enterprises, government agencies, non-profit organizations) which intend to manage risks that could compromise the organization’s information security.” ISO 27005 is widely accepted methodology and it covers technology, people and process in risk assessment.
ISO 27005 Framework
The framework can divided in the following steps:
- Risk analysis, further divided in:
- Risk identification
- Risk estimation
- Risk evaluation
The ISO/IEC 27002:2005 Code of practice for information security management recommends the following be examined during a risk assessment:
- security policy,
- organization of information security,
- asset management,
- human resources security,
- physical and environmental security,
- communications and operations management,
- access control,
- information systems acquisition, development and maintenance
- information security incident management,
- business continuity management, and
- Regulatory compliance.
Risk identification states what could cause a potential loss; the following are to be identified:
- assets, primary (i.e. Business processes and related information) and supporting (i.e. hardware, software, personnel, site, organization structure)
- existing and planned security measures
- related business processes
The output of sub process is made up of:
- list of asset and related business processes to be risk managed with associated list of threats, existing and planned security measures
- list of vulnerabilities unrelated to any identified threats
- list of incident scenarios with their consequences.
Risk estimation has as input the output of risk analysis and can be split in the following steps:
- assessment of the consequences through the valuation of assets
- assessment of the likelihood of the incident (through threat and vulnerability valuation)
- assign values to the likelihood and consequence of the risks
Purely quantitative risk assessment is a mathematical calculation based on security metrics on the asset (system or application). Qualitative risk assessment (three to five steps evaluation, from Very High to Low) is performed when the organization requires a risk assessment be performed in a relatively short time or to meet a small budget, a significant quantity of relevant data is not available, or the persons performing the assessment don’t have the sophisticated mathematical, financial, and risk assessment expertise required. Qualitative risk assessment can be performed in a shorter period of time and with less data. Qualitative risk assessments are typically performed through interviews of a sample of personnel from all relevant groups within an organization charged with the security of the asset being assessed. Qualitative risk assessments are descriptive versus measurable. Usually a qualitative classification is done followed by a quantitative evaluation of the highest risks to be compared to the costs of security measures.
The risk evaluation process receives as input the output of risk analysis process. It compares each risk level against the risk acceptance criteria and prioritises the risk list with risk treatment indications.
NIST SP 800 30 framework
NIST SP 800-30 is most suited for Technology related risk assessment aligned with common criteria.
The risk assessment methodology encompasses nine primary steps:
- Step 1 System Characterization
- Step 2 Threat Identification
- Step 3 Vulnerability Identification
- Step 4 Control Analysis
- Step 5 Likelihood Determination
- Step 6 Impact Analysis
- Step 7 Risk Determination
- Step 8 Control Recommendations
- Step 9 Results Documentation
Risk mitigation, the second process according to SP 800-30, the third according to ISO 27005 of risk management, involves prioritizing, evaluating, and implementing the appropriate risk-reducing controls recommended from the risk assessment process.
ISO 27005 framework
The risk treatment process aim at selecting security measures to:
Risk and produce a risk treatment plan, that is the output of the process with the residual risks subject to the acceptance of management.
NIST SP 800 30 framework
Risk mitigation is a systematic methodology used by senior management to reduce mission risk.
Risk mitigation can be achieved through any of the following risk mitigation options:
- Risk Assumption. To accept the potential risk and continue operating the IT system or to implement controls to lower the risk to an acceptable level
- Risk Avoidance. To avoid the risk by eliminating the risk cause and/or consequence (e.g., forgo certain functions of the system or shut down the system when risks are identified)
- Risk Limitation. To limit the risk by implementing controls that minimize the adverse impact of a threat’s exercising a vulnerability (e.g., use of supporting, preventive, detective controls)
- Risk Planning. To manage risk by developing a risk mitigation plan that prioritizes, implements, and maintains controls
- Research and Acknowledgement. To lower the risk of loss by acknowledging the vulnerability or flaw and researching controls to correct the vulnerability
- Risk Transference. To transfer the risk by using other options to compensate for the loss, such as purchasing insurance.
OCTAVE is targeted at organizational risk and focused on strategic, practice-related issues. It is a flexible evaluation that can be tailored for most organizations. OCTAVE is most suited for process specific risk assessment which is based on people’s knowledge.
The organizational, technological and analysis aspects of an information security risk evaluation are undertaken by a three-phased approach with eight processes.
- Phase 1: Build asset-based threat profiles (organisational evaluation) — The analysis team determines critical assets and what is currently being done to protect them. The security requirements for each critical asset are then identified. Finally, the organisational vulnerabilities with the existing practices and the threat profile for each critical asset are established.
- Process 1 – Identify senior management knowledge
- Process 2 – Identify operational area management knowledge
- Process 3 – Identify staff knowledge
- Process 4 – Create threat profile
- Phase 2: Identify infrastructure vulnerabilities (technological evaluation) –
The analysis team identifies network access paths and the classes of IT components related to each critical asset. The team then determines the extent to which each class of component is resistant to network attacks and establishes the technological vulnerabilities that expose the critical assets.
- Process 5 – Identify key components
- Process 6 – Evaluate selected components
Phase 3: Develop security strategy and mitigation plans (strategy and plan development) — The analysis team establishes risks to the organisation’s critical assets based on analysis of the information gathered and decides what to do about them. The team creates a protection strategy for the organisation and mitigation plans to address identified risks. The team also determines the ‘next steps’ required for implementation and gains senior management’s approval on the outcome of the whole process.
- Process 7 – Conduct risk analysis
- Process 8 – Develop protection mitigation plan
Differences – Organizational Perspective
- NIST is primarily a management system and allows for third party execution. NIST SP 800-30 is most suited for Technology related risk assess. NIST guidance explores more tactical, organizational issues.
- OCTAVE Method is self directed. Only organizational resources are allowed to implement the process. Evaluation is an actual process managed by conducting elicitation, consolidation and analysis workshops.
- ISO 27005 covers People, Process & Technology and is generally geared towards higher-level, management practices.
- Assessment Team
- NIST mentions roles in methodology but does not create an assessment team
- OCTAVE details the creation on an analysis (assessment) team comprising representatives from both the business lines and the IT department of the organization
- ISO 27005 mention that right persons (both technical and business people) are involved in the risk assessment
- Information Gathering/Communication
- NIST uses typical techniques for information gathering such as questionnaires, interviews and document reviews
- OCTAVE uses a workshop-based approach to both gather information and make decisions
- ISO 27005 uses same techniques as used in NIST SP 800 – 30 with addition to observation of processes mentioned in organization policies.
Differences – Technical Perspective
- Human Resources
- NIST does not address human resources as a possible organizational asset
- OCTAVE Method seeks to identify human resources that may be a “mission-critical” asset with respect to IT issues
- ISO 27005 specifically covers human resource security which include employees, contractors and third – party users.
- Software Tools
- NIST relies on role definition to determine use for testing purposes
- OCTAVE uses a workshop for process 5, whose participants are primarily the core team, to use software tools specifically for previously identified vulnerabilities.
- ISO 27005 uses system and network audit tools for technical compliance checking
- NIST develops Security Requirements Checklists for the security areas of management, operational and technical.
- OCTAVE relies upon the creation of three catalogs of information: catalog of practices, threat profile and catalog of vulnerabilities. These catalogs then create the baseline for the organization.
- ISO 27005 documentation covers all security controls clauses defined in ISO 27002 standard. And each clause contains a number of main security categories based on which an organization identify applicable clauses.