BS7999-3:2017 Study Notes
BSI Standards Publication Information Security Management Systems Part 3: Guidelines for information security risk management, BS7799-3, 2017
Important: The latest standard is ISO 27001:2022, but the course lists standard document ISO 27001:2017 coupled with BS7999-3, which are both now out of date. BS7999-3 specifically has been withdrawn and most of its content incorporated into ISO 27005:2017 (now updated to ISO 27005:2022).
Study Notes on Introduction and Clauses 1-6.
Introduction
This standard builds on the requirements of ISO/IEC 27001 in addressing and treating risks that affect your organisation, specifically the following clauses:
6.1 Actions to address risks and opportunities, including:
- 6.1.1 General
- 6.1.2 Information security risk assessment
- 6.1.3 Information security risk treatment
8 Operation, including:
- 8.1 Operational planning and control
- 8.2 Information security risk assessment
- 8.3 Information security risk treatment
This document is intended to perform as a guide for organisations to assess risks and treat them accordingly regardless of size, type or nature. The requirements can be customised as needed by the organisation.
As with all international standards, clauses 1, 2 and 3 explain the scope, references, and terms & definitions for the document: there are no deliverables required.
Clause 1 Scope
Provides guidance for fulfilling the requirements of ISO 27001 by defining risks and opportunities affecting the business, and utilise risk management processes in an information security (IS) context.
Pertains to organisations who already have or require an ISMS that conforms to the ISO 27001 standard, and persons involved within that ISMS, and applies to organisations of any type, size, or nature.
Clause 2 Normative References
Information security, cyber security and privacy protection – Information Security Management Systems – Requirements, BS EN ISO/IEC 27001, 2023
Clause 3 Terms & Definitions
Terms given within Information security, cyber security and privacy protection – Information Security Management Systems – Requirements BS EN ISO/IEC 27001, 2023.
Clause 4 Overview of information security risk assessment and risk treatment
ISO 27001 is a management system standard and information security risk management standard, using risk assessment and risk treatment as primary tools.
The objectives of organisations means risks can be encountered in fulfilling those objectives. These risks can be management, or information security oriented. ISO 27001 require an organisation to address IS risks and opportunities.
Clauses 6.1.1 and 8.1 relate to all management system standards
Clauses 6.1.2, 6.1.3, 8.2 and 8.3 relate to information security risks only.
The steps involved (illustrated in Figure 1 below):
- establish the context of the organisation
- establish requirements of interested parties
- perform a risk assessment to identify risks and their chances of happening, and the potential impact on the business
- determine whether the risk can be avoided or accepted, and if so, what controls will be put in place to ensure criteria is met
- check plans against ISO 27001 Annex A to check all necessary controls are present
- risk owners approve risk treatment plans and they are then put into operation
Clause 5 Communication and consultation
Risk owners need to be communicated with and consulted throughout the process. Their approval is required to sign off the plan, so agreement on how much information should be shared between the risk owners and other interested parties is important. This information can include as much or as little detail as necessary and communication should go both ways.
Risk owners MUST be identified, as they will be approving the risk treatment plan and responsible for any residual risk. Acknowledgment and acceptance from the risk owner is crucial for a successful risk management plan. It is also important to agree on how much of a threat a potential risk could be, and how much is shared about that the risk and its impact on the business.
Clause 6 Context Establishment
6.1 Organisational Context
An organisation should perform the following with the aim to understand how they operate to enable them to identify any risks:
- gather information regarding external and internal issues
- interested parties and their requirements
Keep in mind the IS policy could constrain risk treatment, ie, the policy may not allow it.
There are two types of risk identification and analysis methods:
- event-consequence method – understand all organisational processes that occur internally (within the organisation) and externally (with the rest of the world), good and bad
- asset-threat-vulnerability method – understand potential threats and vulnerabilities that could be exploited
ISO 27001 clause 6.1.3 Information Security Risk Treatment requires organisations to compare necessary controls with risks outlined in Annex A so the organisation can identify and repair any errors in an organisation’s documented context.
6.2 Risks and opportunities
An organisation should identify or create opportunities and exploit them to meet its objectives.
Opportunity Exploitation Plan example:
- Objective: selling product
- Opportunity: internet technology, ie online shop
- Exploitation: creating an ecommerce website
Risks involved:
- insecure data storage resulting in customer data being stolen
- bad design resulting in usability issues
- uncompetitive prices resulting in no sales
Note that only the first item is an information security risk, and the latter two are business risks outside the scope of the ISMS.
Risks that affect outcome of ISMS:
- failure to identify IS risks
- failure to treat IS risks
- failure to implement risk treatment plan
Strictly speaking, none of these are IS risks as such but can expose the organisation to IS risk.
6.3 Scope of information security risk assessment and risk treatment
The scope and boundaries of the IS risk assessment and risk treatment are related to the ISMS scope, outline in ISO 27001 clause 4.3: Determining the scope of the information security management system.
If issues are identified in the risk assessment that are outside the scope of the ISMS, then:
- the issue should be excluded from the ISMS
- the ISMS should be expanded to include the issue
For instance, once the ISMS boundary has been defined, later risk identification could mean the two options need to be considered and applied accordingly.
A risk assessment can have its own scope which can be included within the ISMS’s scope. This combined scope should help identify risks that affect the CIA triad, and be consistent with the ISMS.
6.4 Defining risk criteria
6.4.1 General
ISO 27001:2023 Clause 6.1.2 Information security risk assessment requires organisations to define how significant a risk is by defining the criteria to decide:
- how acceptable a risk is
- when risk assessments take place
6.4.2 Criteria concerning consequences
ISO 27001:2023 Clause 6.1.2 Information security risk assessment refers to any loss of CIA information within the ISMS scope, and the organisation must decide how significant these losses will be considering any wider consequences defined as follows:
- Loss of life or harm to individuals or groups
- loss of freedom dignity or right to privacy
- loss of staff and intellectual capital
- loss of business advantage or market share
- damage to public trust
- failure of the business function or organisation
- breaches of information security eg loss of confidentiality integrity and availability
- impaired operations internal or third parties
- loss of business and financial value
- disruption of plans and deadlines
- Damage of reputation
- breaches of legal regulatory or statutory requirements
- breaches of contracts or service levels
Risk owners and assessors need to be precise in explaining the consequences of information security breaches, ie, stating exact financial loss and how many hours or days of server down-time.
Financial data should be used to communicate impact, using criteria such as: contract value, labour, material costs and fines, repair work, loss of revenue etc.
The effect of these consequences should be considered for each risk owner and their departments.
6.4.3 Criteria concerning likelihood
This clause is complex and further investigation is required to assist comprehension.
Likelihood is defined by the frequency of an IS event.
Likelihood criteria needs to be anticipate IS events, such as:
- The degree of motivation of a deliberate attack
- the required skill of an attacker
- the tools and resources available to an attacker
- influences such as serious crime, terrorist organisations or foreign intelligence
- the probability of occurrence of accidental or natural events, eg force majeure events
- the degree of exposure of relevant information or the asset related to information to an attacker
- the type of opportunity that the organisation gives to an attacker
- technology failure
- human error
Although events can be ascertained using probability tools, there is generally intrinsic uncertainty in estimating likelihood.
Three basic uncertainties are:
- personal uncertainty by the assessor
- methodological uncertainty, using simple event modelling tools
- systemic uncertainty about not knowing about the anticipated event
6.4.4 Criteria concerning level of risk
Level of risk = likelihood * impact
This risk formula is referred to as an aggregate loss expectancy; if using time periods to define loss, this would be an annualised loss expectancy, usually expressed in monetary terms.
Both quantifiable and qualitative data can be used, however using terms such as “never/seldom/sometimes/often/always” means no real risk matrix can be developed, resulting in a misrepresentation of real IS risk acceptance criteria.
In basic terms, risk should be communicated using a numbered scale to accurately represent the level of risk, this can then be compared with other risks in determining their severity and what to tackle first. It is also important for the organisation to determine how they want to deal with risk – something that has a minor impact but happens frequently should be addressed before a more unlikely event that could have worse consequences.
Risk levels should be communicated to all interested parties in a way that can be easily understood and not misleading; for example, if using a logarithmic scale, stakeholders must be advised on how to read them. More information and example matrices here: https://b-advisory.ch/risk_matrices.html
The benefits of logarithmic scales mean:
- a wider range of values can be better represented than on a linear scale
- increments of interest in risk assessment are multiplicative, not additive, meaning the values shown are more accurate
Qualitative data can be represented using a table such as the one below, with the risk severity coloured to show a ‘heatmap’ to emphasise tolerance, with red being unacceptable and green tolerated.
6.4.5 Criteria concerning the acceptance of risk
This clause defines the risk appetite of the organisation: the amount of risk the organisation deems acceptable. So for example, any risk classified as ‘medium’ or above is not acceptable, and must be addressed to reduce the risk to what is acceptable.
The image below, from B Advisory’s blog, shows a stairway step line to indicate risk appetite.
The standard goes on to state that a simple criterion like this does not always work in practice, and that rare catastrophic events can happen where the risk appetite does not apply; and nothing can be done to prevent or reduce the risk severity. Additional criterion should be specified in these cases.
An organisation may not want to have to deal with small-scale events that happen frequently that have negligible impact on the company; for example maybe a hacker changes your password every morning. This would be extremely annoying, but not harmful. Again, additional criterion should be defined.
As well as an upper bound, an organisation can set a lower bound, so any extremely rare events with little impact are simply acknowledged and accepted. This prevents micro-management and over-complication of policies which are not necessary.
When developing a risk acceptance criteria, the following should be taken into account:
- different risk acceptance criteria can apply to different types of risk; risks that result in non-compliance might not be accepted; acceptance of high risk is allowed if as part of a contract
- risk acceptance criteria can include future plans to address that risk, for example a risk can be accepted if a long-term plan to mitigate that risk is in the pipeline
- authorised management should make risk acceptance decisions and their thresholds
- which unacceptable risks should be reported to a higher level
Risk acceptance criteria can change depending on what risks exist, some could be temporary but still need to be addressed.
Risk acceptance criteria can be expressed in the following terms:
- business criteria
- legal and regulatory aspects
- operations
- technology
- finance
- processes
- supplier relationships
- social and humanitarian factors
6.4.6 Consistent, valid and comparable results
Information security risk assessments should produce consistent, valid, and comparable results as specified in ISO/IEC 27001:2017 clause 6.1.2 Information security risk assessment.
This clause requires that the organisation defines and applies an information security risk assessment process that establishes and maintains risk criteria, makes sure repeated assessment produce consistent, valid, and comparable results; identifies, analyses, and evaluates information security risks; and publishes a document about the information security risk process.
Consistency: if assessments are performed by different people, the same process should be followed with the same inputs (threats, vulnerabilities, scenarios). Assessors should be properly trained and ambiguity avoided in the assessment.
Validity: do the assessment results align with the real case scenarios; this is accomplished by ensuring risk owners and assessors understand the organisational context and risk criteria.
Comparability: different classes of risk should be able to be compared with each other, this can be avoided to ensure the same scale is used for assessing risk severity, and using a quantitative approach.
References
BS 7799 The Code of Practice for information security management
Everything you need to know about ISO 27005: summary, requirements, pros and cons
NCSC Guidance: Risk Management
NSCS Guidance: Cyber Security Toolkit for Boards
What Is Cyber Risk Management with FAIR?
Cyber Risk Resources for Practitioners – Institute of Risk Management