ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability 1704570824, 9781704570822

Citation preview

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

Dr David Brewer

First edition. © David Brewer, 2021 Whilst every care has been taken in developing and compiling this publication, Dr David Brewer accepts no liability for any loss or damage caused, arising directly or indirectly in connection with reliance on its contents except to the extent that such liability may not be excluded in law. While every effort has been made to trace all copyright holders, anyone claiming copyright should get in touch with Dr Brewer at [email protected]. Dr David Brewer has no responsibility for the persistence or accuracy of URLs for external or third-party internet websites referred to in this book and does not guarantee that any content on such websites is, or will remain, accurate or appropriate.

Contents Foreword .......................................................................................................... v Acknowledgements ..........................................................................................vi Chapter 1 – Overview and concepts................................................................ 7 Introduction .................................................................................................. 7 ISO/IEC 27001 requirements ...................................................................... 8 The Statement of Applicability ................................................................... 11 The event-consequence method ............................................................... 14 Risk squares .............................................................................................. 15 Control properties ...................................................................................... 16 Dealing with ISMS risks ............................................................................. 20 Relevant resources .................................................................................... 20 Chapter 2 – Risk assessment ........................................................................ 22 Introduction ................................................................................................ 22 The ISO/IEC 27001 requirement ............................................................... 22 Risk scenarios – events and consequences ............................................. 24 Scales ........................................................................................................ 27 Determination of consequence .................................................................. 28 Determination of likelihood ........................................................................ 29 Determination of inherent risk.................................................................... 32 Risk criteria ................................................................................................ 32 Risk owner ................................................................................................. 33 Schedules and previous results................................................................. 34 Documenting the process .......................................................................... 34 Documenting the results ............................................................................ 34 Risk assessment instructions .................................................................... 34 Chapter 3 – Risk treatment ............................................................................ 36 Introduction ................................................................................................ 36 The ISO/IEC 27001 requirement ............................................................... 36 Treating risk – tell it like a story ................................................................. 38 Layout of a risk treatment plan .................................................................. 39 Writing the story ......................................................................................... 40 Determination of residual risk .................................................................... 41 Risk acceptance ........................................................................................ 42 Previous results ......................................................................................... 42 Documenting the process .......................................................................... 42 Documenting the results ............................................................................ 42 Risk treatment instructions ........................................................................ 42 Chapter 4 – Statement of Applicability........................................................... 44 Introduction ................................................................................................ 44 The ISO/IEC 27001 requirement ............................................................... 44 ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

iii

Content of the SOA.................................................................................... 45 The reference control superset.................................................................. 47 Performing the cross-checking process .................................................... 48 Necessary control statement form ............................................................. 49 Constructing the SOA ................................................................................ 49 Instructions for producing the SOA ........................................................... 51 Chapter 5 – Maintenance and improvements................................................ 52 Introduction ................................................................................................ 52 Reviews and reassessments ..................................................................... 52 Extending reference control sets ............................................................... 52 Determining your own scenarios ............................................................... 53 Dealing with future ISO/IEC 27001 transitions .......................................... 53 On-line support .......................................................................................... 54 Appendix A – Documented information examples......................................... 55 A.1 How to use this appendix .................................................................... 55 A.2 Risk assessment process ................................................................... 55 A.3 Risk treatment process ....................................................................... 57 A.4 Risk assessment results ..................................................................... 60 A.5 Risk treatment results ......................................................................... 63 A.6 The on-line Assistant ........................................................................... 73 Appendix B – An example RTP story ............................................................ 76 B.1 Optimum approach .............................................................................. 76 B.2 Reverse engineering approach ........................................................... 77 Appendix C – Control questions .................................................................... 80 Acronyms ..................................................................................................... 105 Compendium of definitions .......................................................................... 106 Bibliography ................................................................................................. 107 Standards publications ............................................................................ 107 Other publications .................................................................................... 108

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

iv

Foreword ISO/IEC 27001:2013 is the requirements specification standard for an information security management system, or ISMS for short. There are requirements for performing information security risk assessments, risk treatments, and for producing a “Statement of Applicability”. Reputedly, some organisations have found difficulty with these requirements because they state what must be done, not how to do it. There are standards in the ISO/IEC 27xxx series that offer guidance on how to fulfil the requirements of ISO/IEC 27001. These are descriptive in nature. They describe how organisations could perform risk assessments and offer advice on how to construct a Statement of Applicability (SOA). However, they are lacking in worked examples. Having assisted many organisations to achieve ISO/IEC 27001 certification, I have developed and fine-tuned a methodology for fulfilling these requirements. This methodology is embodied in the IMS-Smart On-Line technology. Its approach to risk assessment uses events and consequences as advocated in ISO 31000:2018 (Risk management – Guidelines) and BS 7799-3:2017 (Guidelines for information security risk management). IMS-Smart defines twelve events and invites the organisations that use the technology to devise tell-it-like-a-story risk treatment plans for each event to determine the necessary information security controls. Organisations are then invited to link phrases in the story text to the ISO/IEC 27001 reference controls, which in turn assists them to produce the SOA. This book recasts the IMS-Smart methodology as a series of questions, the answers to which will construct the risk assessment, the twelve risk treatment plans and the produce the SOA. The recasting results in an evolution of the IMS-Smart methodology. There is also some supporting technology that automatically transforms the answers to the questions into the documented information required by ISO/IEC 27001 for the organisations risk assessment/treatment results and its SOA. The questions fall into two broad categories: those concerning risk and those concerning controls. The control questions are derived from a superset of the ISO/IEC 27001 Annex A controls and those which are likely to appear in the new edition of ISO/IEC 27002, and thereby offers greater value to organisations for ensuring that no necessary control has been inadvertently overlooked.

David Brewer

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

v

Acknowledgements Figures 1-1, 1-3 and 2-2 have been reproduced by kind permission of IMS-Smart Limited. Cover photographs: front cover — Octar the iguana in La Vanille, Mauritius, March 2017 © David Brewer; back cover — Climbing up to the Mirador View, La Casella, Mauritius, January 2018 © David Brewer.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

vi

Chapter 1 – Overview and concepts Introduction ISO/IEC 27001:2013 is the requirements specification standard for an information security management system, or ISMS for short. Its goal is to assist organisations to implement the controls necessary to achieve acceptable information security risks. Although many organisations are exposed to the same threats, their risks are a function of an organisation’s business, the environment in which it operates and the technology that it uses, to name but three such factors. Moreover, the person or group of people who control and direct an organisation (referred in the standard as “top management”) can have an appetite for risk that differs from that of the top management of other organisations. The ISO standard therefore sets about achieving its goal by requiring organisations: a) to express its risk appetite in terms of criteria for the acceptance of risk; and b) perform a risk assessment to determine those risks that require treatment. Risk treatment is the process by which an organisation determines the controls it deems necessary to modify unacceptable risks such that they meet its risk acceptance criteria. Because there will inevitably be a degree of subjectivity in this process, the standard requires organisations to compare their necessary controls with those in a reference set of controls to determine whether they have inadvertently omitted anything of importance. The standard further requires organisations to produce a “Statement of Applicability” (SOA) that includes the necessary controls and justifies why any reference control has been judged unnecessary. The SOA is an example of what ISO Management System Standards (MSS) refer to as “documented information”. The aim of this Chapter is to fully explain these ISO/IEC 27001 requirements and their relationship to the other requirements of the standard. The Chapter describes the event-consequence approach to risk assessment and explains why it has been selected for this book in preference to other methods.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

7

Chapter 1 – Overview and concepts

ISO/IEC 27001 requirements Clauses 6.1 and 8 The ISO/IEC 27001 requirements for risk assessment and risk treatment are in Clauses 6.1.2, 6.1.3, 8.2 and 8.3. Clause 6, in common with all other ISO MSS, such as ISO 9001 (quality) and ISO 14001 (environmental protection), concern planning the Management System (MS). Since the process of risk treatment is used to determine the necessary controls, and the controls form part of the MS, Clauses 6.1.2 and 6.1.3 start with the phrase “The organisation shall define and apply …”. Clause 8 concerns operations, and here ISO/IEC 27001 specifies the requirements for repeated risk assessments and for implementing the controls. It is necessary to repeat the risk assessment at planned intervals (and when significant changes are proposed or occur) to maintain the effectiveness of the controls, particularly in response to new threats and changes in business operations. An output of Clause 6.1.3 is the risk treatment plan. There are two generally accepted interpretations of this term. One is that it is a project plan for implementing the controls determined by the process of risk treatment. The other, which is used in this book, is that it is a plan for how the controls are intended to work together (e.g., their temporal, logical and physical relationship to one another) to modify risk. The former interpretation is transient: once implemented the plan assumes an historical significance. The latter interpretation has a permanency about it: the plan should always show how the controls are intended to work together, just like a building plan.

Relationship to other clauses Figure 1-1 shows a schematic representation of the ISO/IEC 27001 requirements. The headings in blue are common to all MSS. Those in red are specific to ISO/IEC 27001 and represent those that specifically concern information security.

Figure 1-1 Schematic representation of the ISO/IEC 27001 requirements Understanding your organisation and its business, cultural and societal contexts is key to establishing an effective ISMS. The mantra should be one of moulding the standard around the organisation, not the other way round. From this, and knowledge about the needs and expectations of interested parties, and the information that is within scope of the ISMS, the organisation can begin the process of identifying its information security risks.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

8

Chapter 1 – Overview and concepts

Although Figure 1-1 shows the requirements in a cyclic arrangement, and the Establish, Implement, Maintain and Improve labels are reminiscent of the Deming Cycle (PLAN-DO-CHECK-ACT), the order in which the requirements are presented in the standard do not imply the order in which they are to be implemented. Thus, although Clause 8.2 requires organisations to repeat risk assessments when certain criteria are met, there is no corresponding requirement to repeat the risk treatment process. This is because such a requirement is unnecessary. The inputs to the risk treatment process are the outputs of the risk assessment process. Suppose a reassessment of risk produces results that necessitate a change in risk treatment. If those changes are not made, the requirements of Clause 6.1.3 are no longer fulfilled, thereby creating a nonconformity. Moreover, since the requirements of Clause 10.1 are to correct nonconformities, it too becomes nonconformant until the necessary modifications are made by repeating the risk treatment process. In turn, this corrects both nonconformities. This process is the self-healing property of a management system. Over time it ensures that all documented information corresponds to reality. There are other examples of this non-cyclic behaviour:  There will be aspects of the Information security policy (Clause 5.2) that cannot be known until the information security controls have been determined (e.g., the organisation’s access control and backup policies)  There are sixteen requirements for the organisation to retain or maintain documented information scattered throughout the standard, yet the requirements for the control of documented information are in Clause 7.5.

Why risks and opportunities? Risk is defined as “the effect of uncertainty on objectives” and comes from another ISO standard, ISO 31000 (Risk management — Principles and guidelines). There is a note to the definition which states that an “effect is a deviation from the expected – positive or negative”. By way of further explanation, it is the effect that can be positive or negative, not the deviation. Thus, there can be a beneficial side to risk, and is the reason why ISO MSS refer to “risks and opportunities”. However, risk only makes a small contribution to the opportunities that an organisation can seize upon and exploit. Other opportunity sources include reputation, innovation, market position, market demand, etc. Indeed, organisations create and seize opportunities to fulfil their objectives and in doing so encounter risks which must be managed. There is another note to the definition of risk, which states that risk is often expressed in terms of a combination of the consequences of an event and the associated likelihood of occurrence.

The objective of RA/RT The objective of risk assessment and risk treatment is to determine the necessary controls. It is important not to lose sight of this objective. Organisations should therefore not become obsessed with striving for accuracy or identifying every conceivable risk. Once such efforts fail to determine any new necessary controls, it is time to stop.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

9

Chapter 1 – Overview and concepts

Scope The scope of the ISMS includes everything of interest to the ISMS. The organisation within scope of the ISMS does not have to be a company or other legal entity. For many certified ISMS, the organisation is just part of a legal entity, e.g., part of a department within a faculty of a university. In some cases, the organisation can be a set of subsets of legal entities, e.g., a trade body and its members, or a group of competing companies that are cooperating (and therefore need to share information) to assist in recovery from some natural disaster. The scope of the ISMS does not include suppliers and customers (or that part of a larger organisation of which the ISMS organisation is a part) but can include their activities. It should also include the activities (or effects) of external risk sources. The scope does include the requirements of interested parties. Such requirements include laws, regulations, and contractual requirements. Whist organisations are generally obliged to fulfil such requirements, there are others that organisations should consider, but not fulfil. For example, a hacker is an interested party and is likely to have a requirement for weak security. Organisations should, of course, do the opposite in this case. The scope of certification is generally the ISMS organisation but can be smaller (e.g., one site of a multi-sited organisation). The scope of the risk assessment should be the same as the scope of the ISMS as:  anything within scope of the ISMS can present a risk, which must therefore be assessed; and  the assessment cannot consider anything outside the scope of the ISMS, because to do so, that something becomes of interest to the ISMS and must therefore lie within its scope. ISO/IEC 27001, Clause 6.1.2 c) 1) explicitly requires organisations to identify risks associated with the loss of confidentiality, integrity, and availability for information within scope of the ISMS. In practice, however, this is an inadvertent restriction as: a) It is possible for an attacker to hijack the organisation’s ICT (Information and Telecommunications Technology) to launch an attack against a third party [e.g., Dyn 2016] . In such cases the information held by that third party is not within scope of the organisation’s ISMS, and therefore consideration of such risks is not required. Nevertheless, ISO/IEC 27014 says that there are four threads to (information security) governance, of which the third is “preventing the organisation’s information technology from being used to harm other organisations.” b) Organisations should protect themselves from the ingress of undesirable (e.g., fake news) or illegal information and the illegal processing or retention of personally identifiable information (PII). c) It is a reasonable expectation that ICT vendors supply goods and services that are free from vulnerability. Upon discovery of a vulnerability, vendors should therefore be quick to disclose it and take remedial action. Again, the information protected by such ICT need not be within scope of the vendor’s ISMS, although vulnerability disclosure is a reasonable interested party requirement that is generally implied even if not stated in any contractual agreement. There are seven years between the publication dates of ISO/IEC 27001 and ISO/IEC 27014. Perhaps when ISO/IEC 27001 is revised, the requirements of this clause will be rephrased to include these societal and other relevant considerations: “risks associated with the loss of confidentiality, integrity, and availability, and the use and misuse of information and associated assets within scope of the ISMS” would be the author’s suggestion.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

10

Chapter 1 – Overview and concepts

The Statement of Applicability What is it? The Statement of Applicability (SOA) is an item of documented information “that contains:    

the necessary controls; justification for their inclusion; whether the necessary controls are implemented or not; and the justification for excluding any of the [ISO/IEC 27001] Annex A controls”.

ISO/IEC 27001, Annex A is the reference set of controls used by ISO/IEC 27001.

Strengths and weaknesses If the process of risk treatment has determined all necessary controls, the comparison process will not find any missing necessary controls. However, if a necessary control has been overlooked, but that control is not in the reference set of controls, then the comparison process will not find it. This is the weakness of the approach. Of course, if the missing control is in the reference set, then the comparison process will find it. That is a strength, but there are other strengths as well:  Every organisation that has an ISO/IEC 27001 conformant ISMS will have compared their necessary controls to those in the same reference set.  The SOA acts as a comprehensive catalogue of an organisation’s information security controls.  The ISO/IEC 27001 Annex A reference set is a robust mix of organisational, people, physical and technological controls.  ISO/IEC 27002 gives guidance and supporting information for each reference control.  The controls and guidance in this reference set are drawn from generally accepted good information security practice.  ISO/IEC 27001 Annex A and ISO/IEC 27002 a common language that is recognised internationally.  For organisations new to information security, the controls in this reference provide a good starting point.

History of the term The origin of ISO/IEC 27001 was a British Standard, BS7799-2:1998. The purpose of this standard was to act as bridge between the Code of Practice, BS7799:1995 and certification, having recognised that not all BS7799 controls were applicable to all organisations. Hence the term “Statement of Applicability” – a statement of all applicable controls. Nevertheless, the meaning of the term has evolved with successive editions of the ISMS standard, see Table 1-1.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

11

Chapter 1 – Overview and concepts

Table 1-1: Characteristics of successive editions of ISO/IEC 27001 Standard BS 7799-2

ISO/IEC 27001

Year(s) of publication 1998, 1999

Location of controls Main body

Requirement

2002 2005

Annex A

Controls must be selected from Annex A

2013

All controls are required unless declared (in the SOA) as being nonapplicable

Necessary controls determined by process of risk treatment and compared to those in Annex A as a check to confirm that no necessary control has been overlooked

Relevance of the SOA to certification audits The SOA is a principal driver of certification audits. Common practice amongst certification bodies is to devise an assessment programme that covers all the controls in Annex A as well as the ISMS requirements (i.e., ISO/IEC 27001 Clauses 4 – 10). It is important to realise, however, that the controls in ISO/IEC 27001 Annex A are not requirements, albeit the necessary controls in the SOA are organisational requirements. The ISO requirement (Clause 6.1.3 c)) is the comparison process. Moreover, there is no requirement to express the organisation’s necessary controls in terms of the Annex A controls. That means: a) The SOA does not need to have the same structure as Annex A. b) Provided that there are no unnecessary controls in Annex A, the SOA does not have to contain any Annex A controls (otherwise the SOA will have to identify and justify those that are unnecessary). However, it is prudent to be able to demonstrate conformity with Clause 6.1.3 c), and most organisations do that by adopting the structure of Annex A for their SOA. Thus, the practice of auditing all the controls in Annex A is just a shorthand for auditing all the necessary controls.

Custom controls, obviations, and variants ISO/IEC 27003 provides guidance and understanding of the ISO/IEC 27001 requirements. In its explanation of the SOA, it introduces the concepts of a custom control and an obviated control:  A custom control is a necessary control that is not in Annex A.  An obviated control is an Annex A control that is rendered unnecessary because of the presence of a custom control. For example, there is an Annex A control that concerns the management of removeable media. If an organisation uses a control that prevents the use of removeable media, then that control: a) is a custom control because there is no such control in Annex A; and b) obviates the need for the management of removeable media control.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

12

Chapter 1 – Overview and concepts

Both controls must be included in the SOA: the custom control because it is a necessary control, and the obviated Annex A control because it has been rendered unnecessary. A variant is an extension of these two concepts. A variant is a custom control that is an instantiation of an Annex A control. Of necessity, the Annex A controls are generic controls designed to be meaningful in a wide range of contexts. An instantiation renders the control specific to the organisation and should be a precise specification of what the organisation does. For example: A generic control

Equivalent instantiated control

The policies for information security shall be reviewed at planned intervals or if significant changes occur to ensure their continuing suitability, adequacy, and effectiveness.

Policies are considered at management review meeting. Decisions are then taken whether they need to be reviewed to ensure their continuing suitability, adequacy, and effectiveness.

The two control specifications are similar. However, if an organisation claims that it implements the generic control but in practice implements the instantiated control it should be ruled nonconformant. This is because the generic control states that “… at planned intervals or if significant changes occur…”, and the organisation does not do that. Thus, organisations should not claim Annex A controls as necessary controls unless they implement the control precisely as specified. If they do not, declaring a variant of the Annex A control is the safest option. Nevertheless, organisations should insist that audits are carried out against their SOA, not Annex A, as it is the necessary controls in the SOA that are the requirements, not the Annex A controls. Also note that, whereas the generic control is expressed as a requirement, the instantiated control is expressed as a statement of fact.

Future editions of the standard Currently ISO/IEC 27001 is not under revision, but a revised edition of ISO/IEC 27002 is anticipated in late 2021, early 2022. The new edition of ISO/IEC 27002 provides organisations with an updated reference control set. Specifically, there will be new controls, thereby reducing the possibility that if an organisation has overlooked a necessary control, comparison with the updated reference set will not find it. Thus, it will be advantageous to find a way for organisations to compare their controls with the new reference set before ISO/IEC 27001 enters revision and a new edition emerges.

Alternative reference control sets Fortunately, there is a way to do this: Step 1) Compare the necessary controls with those in an alternative reference set. Step 2) Compare the controls in the alternative reference set with those in Annex A. Provided the alternative reference set is a superset of the controls in Annex A, the combination of the two steps will provide a comparison of the necessary controls with those in Annex A in conformity with ISO/IEC 27001:2013. Moreover, if the alternative reference set is aligned with the controls that will be in the new edition of ISO/IEC 27002, this approach also has the advantage referred to in the previous section.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

13

Chapter 1 – Overview and concepts

Of course, since these are independent steps, Step 2 can be performed first and for all organisations. Subsequently, organisations perform Step 1 and use the results of Step 2 in the construction of their SOA. We make use of this innovation later in this book.

The event-consequence method What is it? Risk is the occurrence of an event that results in one or more consequences. For example, a laptop is stolen – the event – resulting in the undesirable disclosure of personally identifiable information (PII) – the consequence. The level of risk is: (the likelihood of the occurrence of the event) multiplied by (the severity of the consequence) The event-consequence method of risk assessment is simply:    

Identify the risks (i.e., choose an event-consequence pair). Assess the severity of the consequence. Assess the likelihood of the occurrence of the event. Multiply the likelihood and the severity to determine the level of risk

These steps are in one-to-one correspondence to the requirements of ISO/IEC 27001 Clauses 6.1.2 c)1), d)1), d)2) and d)3). The method is central to the guidance given in ISO 31000 and specific information security relevant guidance is given in BS 7799-3:2017 and in the book “An introduction to ISO/IEC 27001:2013[DBB01].

Other methods Historically, information security risk assessments were performed by an analysis of assets, threats, and vulnerabilities. Indeed, this was a requirement of ISO/IEC 27001:2005. However, the need to determine vulnerabilities means that the method cannot cope with zero-day vulnerabilities. Moreover, whilst the standard regarded an “asset” as “anything that has value to organisation”, it is better to interpret “asset” as meaning “information that needs to be protected”, lest organisations that store other organisation’s information (e.g., a Website Hosting Service Provider) neglect to consider such information because they regard it as a liability (as in the accounting practice sense). However, perhaps the greatest criticisms of the method are that, by casting the analysis in technical terms, it is easy to lose sight of the overall purpose of determining necessary controls; it is not readily understood by top management (see DBB01, Chapter 4, Page 131, paperback edition); and it can omit considerations of the societal and other relevant risks (see Scope, above). Thus, there are situations that the method does not deal with very well, if at all. We therefore discount this method and just use the event-consequence method.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

14

Chapter 1 – Overview and concepts

The need for reference set coverage It would be most fortunate if, having applied the event-consequence method and having determined the necessary controls, the comparison process does not identify any necessary controls that have been overlooked. To guarantee this desirable result, the events should be chosen such that they give coverage of the controls in the comparison process’ reference set. The events that we use in Chapter 2 collectively have this desirable property.

Standard events These events are referred to as the standard events. There are twelve such events, as described in Chapter 2.

Risk squares Risk is often illustrated graphically using a graph such as Figure 1-2. The figure shows the background for a graph of the frequency or likelihood (FoL) of the occurrence of an event against the severity of the consequence (Sev). Frequency is used in conjunction with likelihood because whilst the likelihood of an attack might be very low, the frequency of attacks following the first can be very high. Information security controls, particularly technological controls for the prevent and detection of network penetration attacks should be designed to withstand high attack frequencies, despite the likelihood of an initial attack being very low. The graph indicates lines of constant risk, and these are colour-coded to represent different degrees of acceptable risk, e.g.:  Green  acceptable  Yellow  borderline  Red  unacceptable. The graph on the left uses linear scales, and therefore the lines of constant risk are hyperbolic. The tails are very close to the x and y axes, squashing the green lines towards the origin, forcing all data points in this area to lie on top of one another. The graph on the right uses logarithmic scales. In this case, the lines of constant risk are straight lines, allowing clear separation of data points.

Figure 1-2: Example risk squares ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

15

Chapter 1 – Overview and concepts

The axes of the right-hand graph are labelled 1-5, but it is important to recognise that these correspond to the linear values 101,102, 103, 104 and 105. Thus, such a graph has a dynamic range of 1-5 (i.e., 5 orders of magnitude) for both axes. A dynamic range of 5 is reasonable for many organisations. Using money for the measurement of severity, if 1 represents £100, 5 represents £1,000,000. However, for FoL a dynamic range of 5 is woefully inadequate. The FoL for an information security event can range from once a century to many thousand times a second. It is therefore prudent to remember this and not limit risk value to fit within the graph boundaries. The graph shown in Figure 1-3 shows two such off scale values with caption to indicate the attribute values of one of the data points.

Figure 1-3: Risk square showing off-scale values (The caption indicates that the point is associated with an event called S9, with a log (FoL) value of 7 (~ every 5 minutes) for loss of Confidentiality with a log (Sev) value of 4.7 (~ £500,000))Control properties

Definitions According to ISO 31000:2018, a control is a measure that modifies or maintains risk. This definition is slightly different from that defined in ISO/IEC 27000, which is the dictionary of terms used in the 27000 series of standards, but is more descriptive of the ‘controls’ in ISO/IEC 27001, Annex A, and ISO/IEC 27002. By the definition in ISO/IEC 27000 (…a measure that modifies risk) many of the Annex A controls are not controls as they do not modify risk. For example, one such control is that organisations should have a security policy. Having a security policy, by itself does nothing to modify risk. To modify risk, policy needs to be combined with some other measure, such as disciplinary action. In this case, the combined measures do modify risk as people will now comply with the policy else risk some disciplinary action, such as losing their job. We use the ISO 31000 definition of control in this book. We explicitly refer to “measures that modify risk” when necessary.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

16

Chapter 1 – Overview and concepts

The Time Theory The Time Theory [TIME 2004] (Brewer and List, 2004) asserts that an effective system of internal control detects both opportunities and events in sufficient time to do something positive about them. The theory can be illustrated with the aid of three diagrams, which plot revenue and costs for a commercial company as a function of time, and as might be generated to illustrate financial performance in a given financial year. The cost of control is shown as an addition to business cost. P1 indicates the company’s profit. In the absence of any events the graph would comprise straight lines, as shown in Figure 1-4(a).

Figure 1-4 (a) Performance in the absence of events Figure 1-4(b) illustrates what happens if an event occurs (at time E) but there are no controls that prevent or detect the event (or there are controls, but they fail). At some time later (at time W) a consequence of that event occurs. This is represented by a dip in the revenue line, and the difference W – E is called the time window. At some later time (time M), company management recognizes that something is amiss and acts (at time F1) to recover the situation. Such action is represented by an increase in cost of control. The net result is a decrease in profit: from P1 (as first introduced in Figure 1-4 (a) to P2.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

17

Chapter 1 – Overview and concepts

Figure 1-4 (b) Performance following an event that is not dealt with in time In contrast, Figure 1-4 (c) shows what happens if there is a detective control that detects the event – which occurred at time E – at time D, in sufficient time to prevent the consequence from occurring, i.e., it permits the remedial action to take place (at time F2) before time W. In this case, the profit is much greater than that in the previous case, i.e., P3 > P2 (note that P1 indicates the company’s profit in the absence of any events). If a preventive control is used instead of a detective control, one might argue that either times D and F2 coincide with time E or the event simply does not occur. In either case, it is likely that there is no increase in costs, as in Figure 1-4 (a).

Figure 1-4 (c) Performance following an event that is dealt with in time Figure 1-4 (b) shows a decline in revenue after time W. This represents a worsening situation over time, which can be reduced by shortening the time between the onset of the consequence and the time of correction (i.e., F1 - W). ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

18

Chapter 1 – Overview and concepts

Prevent, detect, and react The Time Theory supports the view that there are three types of measure that modify risk, as described in BS7799-3:  Preventive: a measure that is intended to prevent the occurrence of an information security event that would otherwise lead to the occurrence of one or more consequences.  Detective: a measure that is intended to detect the occurrence of an information security event.  Reactive: a measure that is intended to limit the consequences. Preventive and detective measures act before expiry of the time window and modify the likelihood of occurrence of the event. Reactive measures act after the expiry of the time window and modify the severity of the consequence. Just because reactive measures act after the expiry of the time window, does not mean that they are deployed after the expiry of the time window. Most often, they must at least be initiated prior to the occurrence of the event. For example, following data loss, an organisation will attempt recovery by restoring a data backup. However, they must, of course, have an appropriate backup to restore, and the task of taking the backup must be performed before the occurrence of the data loss. The value of this attribute can depend on the context in which the measure is used. Hard disc encryption does not prevent the theft of a laptop but does modify the consequence of the thief being able to comprehend the data that it contains. In this context, hard disc encryption is a reactive control. If, however, we change our view of the event from the “theft of the laptop” to “person comprehends the data contained on the stolen laptop” then hard disc encryption is a preventive control. Note that the attribute value is not related to when the control must be deployed. In both cases for the hard disc encryption control to work, it must be deployed before the event happens.

N-factor, excess, and strangulation The relationship between the activation of a measure and the time window is an example of a control attribute. Another attribute concerns how the measure modifies risk. Some measures work on the principle of knowing a secret. If a person (or entity, such as a computer program) knows the secret, then the activity that the measure is controlling is allowed, otherwise it is disallowed. However, if an attacker successfully guesses the secret then the activity will be allowed. If the nature of the secret is such that 1 in N guesses will be correct, then the effect of the measure is to reduce the likelihood by a factor of N. This type of behaviour is referred to as N-factor. Other measures are designed to replace one consequence with another. For example, if upon the theft of an automobile, the owner makes a successful insurance claim, then the financial loss will be the insurance excess rather than the replacement value of the vehicle. This type of behaviour is referred to as excess. Some measures will work perfectly satisfactorily whilst the frequency of events is below some threshold. For example, a bookkeeper might find an error in the accounts and have time to correct the error before the due date for publication. However, if as the work proceeds more errors are discovered, it is possible that the bookkeeper will be overwhelmed and either the accounts are published with errors or the deadline is missed. This type of behaviour is referred to as strangulation.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

19

Chapter 1 – Overview and concepts

Other attributes Other attributes that we make use of in this book include events and consequences. We also use the prevent, detect, and react attributes in the context of controls. In this case, if the control is a measure that maintains risk, saying that the control is preventive, means that it contributes towards the prevention of an event.

Dealing with ISMS risks ISO/IEC 27001, Clause 6.1.1 specifies a requirement that is common to all MSS and is intended for the identification and treatment of risks to the intended outcome of the ISMS that are not information security specific. For example, a lack of resources could result in internal audits being missed. Whilst this could represent a nonconformity in respect of ISO/IEC 27001, Clause 9.2 (Internal audits), its effect on exposure to information security is indirect and depends on whether any information security controls are in scope of the audits that might be missed. Whilst an organisation could use the full rigour of Clauses 6.1.2 and 6.1.3 to identify and treat such risk, it does not have to – an informal approach – essentially just following what it says in the standard will be sufficient.

Relevant resources ISO standards ISO/IEC 27000 provides an overview of all the standards in the 27000 series, together the vocabulary of terms that they use. The principal standards are:  ISO/IEC 27000, Information technology — Security techniques — Information security management systems — Overview and vocabulary;  ISO/IEC 27001, Information technology — Security techniques — Information security management systems — Requirements;  ISO/IEC 27002, Information technology — Security techniques — Code of practice for information security controls  ISO/IEC 27003, Information technology — Security techniques — Information security management system implementation guidance. The following standard explores the relationship between an ISMS and governance:  ISO/IEC 27014, Information security, cybersecurity and privacy protection 1 Governance of Information Security.

The name of the responsible committee, ISO/IEC JTC1 SC27, changed from “Security techniques” to “Information security, cybersecurity and privacy protection” in June 2019.

1

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

20

Chapter 1 – Overview and concepts

The following standards provide sector-specific interpretations of ISO/IEC 27002 and additional reference controls:  ISO/IEC 27010, Information technology — Security techniques — Information security management for inter-sector and inter-organizational communications  ITU-T Recommendation X.1051 | ISO/IEC 27011, Information technology — Security techniques — Information security management guidelines for telecommunications organizations based on ISO/IEC 27002  ISO/IEC 27017, Information technology — Security techniques —Information security management – Code of practice for information security controls based on ISO/IEC 27002 for cloud computing services  ISO/IEC 27018, Information technology — Security techniques —Information security management – Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors. ISO/IEC 27001 is a requirements standard, meaning that an organisation’s ISMS can be certified for conformity against it. The other standards are guidance standards.

British standards  BS 7799-3:2017, Information security management systems — Part 3 Guidelines for information security risk management. In September 2017, the UK withdrew BS ISO/IEC 27005:2011 and replaced it with BS 7799-3:2017 (Guidelines for information security risk management). BS 7799-3 is aligned to ISO/IEC 27001:2013, whereas ISO/IEC 27005 is not — it is aligned to the previous edition, ISO/IEC 27001:2005. A new edition of ISO/IEC 27005 was published in 2018, but that merely explains that it is not aligned. We will perhaps have to wait until 2022 before there is a revised edition of ISO/IEC 27005 that is correctly aligned.

Other resources The following book provides detailed guidance on every ISO/IEC 27001 requirement.  “An introduction to ISO/IEC 27001:2013”, David Brewer, Available on Amazon, ISBN-10 1704570824; ISBN-13 978-1704570822

On-line support:  to help organisations establish, implement, maintain and improve their ISMS is available from IMS-Smart Limited (see https://imssmart.com/Technology/index.php)  for this book (see https://ims-smart.com/Technology/RApSOA.php).

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

21

Chapter 2 – Risk assessment Introduction This Chapter presents a prescription for conducting a risk assessment that conforms to the requirements of ISO/IEC 27001 Clauses 6.1.2 and 8.2. It uses the eventconsequence method described in Chapter 1. The Chapter explains the requirements of these ISO/IEC 27001 clauses. The Chapter uses a set of 12 events. These collectively give coverage of all the controls in our reference set, which as explained in Chapter 1 is a superset of the controls in ISO/IEC 27001, Annex A. They are referred to as the “twelve standard events” later in this book. The Chapter explains how to determine the severity of their associated consequences and their likelihood of occurrence, and thereby determine their risk values. The Chapter presents a set of risk criteria and explains how to apply them and prioritise risks for treatment. The Chapter explains how to identify risk owners and document the risk assessment process and its results. Finally, the Chapter gives instructions on how to apply the prescribed method.

The ISO/IEC 27001 requirement Define and apply ISO/IEC 27001 Clause 6.1.2 requires organisations to define and apply a risk assessment process that satisfies the requirements detailed in the subsequent five bullet points (a) – (e) and explained below. The reason for saying “define and apply”, is because, as explained in Chapter 1 (Clauses 6.1 and 8), the necessary controls that the organisation requires form part of the ISMS but are determined through the process of risk assessment and risk treatment. It is therefore necessary to perform those processes (i.e., “apply” them). However, since organisations are free to choose its approach to risk assessment (provided it meets the requirements of Clauses 6.1.2 a) – e)), it must first “define” that process. Hence, “define and apply”.

Risk criteria ISO/IEC 27001 Clause 6.1.2 a) requires that organisations define their risk criteria. The standard cites two types of criteria:

a) its criteria for accepting risk; and b) its criteria for performing risk assessments.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

22

Chapter 2 – Risk assessment

Since ISO/IEC 27001 Clause 8.2 requires risk assessments to be performed at planned intervals and when significant changes are proposed or occur, the performance criteria must address planning and what constitutes a significant change. The results of a risk assessment, other than the first, can be that there is no change.

Validity ISO/IEC 27001 Clause 6.1.2 b) states that repeated risk assessment process must produce consistent, valid, and comparable results. Consistency implies repeated assessments will give the same results given the same inputs. Validity and comparability implies that the levels of risk determined by the assessment will be proportional to the likelihood and proportional to the consequence.

Identify risks (and owners) ISO/IEC 27001 Clause 6.1.2 c) requires organisations to identify the risks associated with the loss of confidentiality, integrity, and availability for information within scope of their ISMS. However, for the reasons given in Chapter 1 (see section on Scope), the author recommends that this requirement is interpreted as “…risks associated with the loss of confidentiality, integrity, and availability, and the use and misuse of information and associated assets within scope of the ISMS”. ISO/IEC 27001 Clause 6.1.2 c) requires organisations to identify the owners of those risks. The term “risk owner” has a special meaning: a “person or entity with the accountability and authority to manage a risk”, see ISO/IEC 27000.

Analyse risks ISO/IEC 27001 Clause 6.1.2 d) requires organisations to analyse their information security risks. It requires organisations to assess the consequences and the realistic likelihoods of those risks, and thereby determine the level of risk in each case.

Evaluate risks ISO/IEC 27001 Clause 6.1.2 e) requires organisations to evaluate their information security risks. Evaluation requires: a) comparing the levels of risk with the risk criteria; and b) prioritising the risks for treatment. For example, the risks with the greatest differences between the assessed level of risk and the level of acceptable risk should perhaps be treated first.

Retain documented information about process ISO/IEC 27001 Clause 6.1.2 finally requires organisations to retain documented information about the risk assessment process. Note that this requirement only concerns the process, even though the opening sentence of the clause says: “define and apply”. The requirement to retain documented information about the results is in Clause 8.2 (see below).

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

23

Chapter 2 – Risk assessment

Subsequent risk assessments ISO/IEC 27001 Clause 8.2 requires organisations to perform subsequent risk assessments at planned intervals and when significant changes are proposed or occur, in accordance with the criteria established in Clause 6.1.2 a).

Retain documented information about results ISO/IEC 27001 Clause 8.2 also requires organisations to retain documented information about the risk assessment results.

Risk scenarios – events and consequences Overview Table 2-1 lists the 12 standard events together with their associated consequences. For customisation, see Chapter 5. Further explanation of each event is given after the table. Table 2-1: Standard events and their consequences id S1 S2

S3

S4 S5 S6

S7

S8

Event name and description Theft/loss of mobile devices A mobile container of information is lost, stolen, reused or otherwise dispossessed. Office break-in Office premises are broken into and IT, media and paper documents are stolen. Acts of God, vandals, and terrorists Office premises and their contents are rendered unusable or inaccessible because of fire, flood, adverse weather, strike, riot, vandalism, terrorism, or other disruption. Software failure Software does not do what it is supposed to do or does do what it is not supposed to do. Hardware failure ICT hardware ceases to work, or work as it should, due to component failure. Power failure ICT hardware ceases to work or work as it should, due to power failure or adverse operating conditions. Internet/communications failure Wide area or local area network, including Internet connections are broken, denying the ability to make or receive phone calls, e-mail access, network access and web connectivity. Fraud or error Members of the public, customers, suppliers, or disaffected people practice deception to secure unfair or unlawful gain. People make mistakes.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

C

I

A

























24

Chapter 2 – Risk assessment

Event name and description

id

S9

S10 S11 S12

Hacking An attacker creates or otherwise exploits a vulnerability in the software and services that we use, or provide to other organisations, to cause the undesirable disclosure of information, fraud, denial of service or to launch an attack on another organisation. Web DOS The organisation’s website or cloud service is unavailable. Disclosure Sensitive information is improperly disclosed or otherwise misused. Breach of the law The actions of the organisation break the law.

C

I

A







  



S1 – Theft/loss of mobile devices Typical containers are documents, envelopes, briefcases, laptops, tablets, mobile phones, cameras, magnetic tapes, CDs, DVDs, USB sticks etc. Dispossession could be because the container is lost, stolen, damaged, destroyed, or misappropriated. Dispossession might also be because the container is disposed of or reused (by someone else). In all cases the owner, or rightful user, of the container no longer has the container in their possession. The event differs from “S2-Office break-in” as in the case of a mobile device, physical security is not under the control of the organisation.

S2 – Office break-in Such a theft might be carried out on a grand scale, where one could imagine an organised team of villains loading large quantities of equipment onto an articulated lorry one dark night. Alternatively, the theft might be of one or just a few items (pilfering).

S3 – Acts of God, vandals, and terrorists There may be severe loss of power, network connectivity and ICT functionality. Offices and facilities can be destroyed or rendered uninhabitable. Severe weather, riots, and incidents in their vicinity can render them physically inaccessible. Staff may be incapacitated or debilitated.

S4 – Software failure Software ceases to work because of design errors, coding errors and malware.

S5 – Hardware failure Hardware ceases to work because of component failure or because of adverse operating conditions (e.g., high ambient temperature).

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

25

Chapter 2 – Risk assessment

S6 – Power failure ICT requires power to function, as does air conditioning. Some equipment can be damaged, if it suffers an uncontrolled shut down, and that can result in software and hardware failure.

S7 – Internet/communications failure Denies the ability to make or receive phone calls, e-mail access, network access and web connectivity.

S8 – Fraud or error Any activity that is designed to practice deception is covered by this event. Thus, it includes social engineering as well as the activities of insiders who misuse their privileges for unauthorised access to information or financial gain (e.g., embezzlement). This event also covers errors made by well intention people.

S9 – Hacking This event concerns the exploitation of vulnerabilities in the technological components. Whilst such exploitation can cause the loss of confidentiality, integrity, or availability of information within scope of the ISMS it can also enable the attacker to use the organisation’s ICT to launch an attack on another organisation.

S10 – Web DOS This can result from a general Internet Service Provider failure, website errors (e.g., application code errors), site overload or that the webserver is suffering from a deliberate Denial of Service (DoS) attack.

S11 – Disclosure This event is intended to cover all ways that result in an undesirable disclosure of information that are not covered by any other event, for example, interception of telecommunications and being overheard.

S12 – Breach of the law In the UK, laws and regulations that are generally relevant to information security include:       

Data Protection Act, 2018 Companies Act, 2008 Electronic Commerce (EC Directive) Regulations, 2002 Computer Misuse Act, 2000 Regulation of Investigative Powers Act, 2000 Copyright, Designs and Patents Act, 1998 Official Secrets Act, 1989

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

26

Chapter 2 – Risk assessment

 Tort.

Scales Logarithmic This prescription uses logarithmic scales.

Consequence This prescription uses money measuring consequence. The following scale applies: Table 2-2: Consequences and scale values Consequence value

Scale value

£10

0

£100

1

£1,000

2

£10,000

3

£100,000

4

£1,000,000

5

£10,000,000

6

This scale is extensible. Thus, a scale value of 7 represents £100,000,000, and a scale value of -1, represents £1. Intermediate values are also meaningful, e.g., a scale value of 4.3 represents £200,000 and 4.7 represents £500,000. Organisations may shift the scale if they wish, e.g., by multiplying all the consequence values by a factor of 10 or a 100. To use Table 2-2 without scaling for an arbitrary sum of money, £x, determine log(x/10).

Frequency and likelihood This prescription uses reciprocal time for measuring frequency and likelihood. The following scale applies:

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

27

Chapter 2 – Risk assessment

Table 2-3: FoL and scale values Scale value

FoL value

0

Once a century

1

Once a decade

2

Once a year

3

Once a month

4

Twice a week

5

Every 8 hours

6

Every hour

7.8

Every minute

9.5

Every second

10.5

10 times a second

11.5

100 times a second

This scale is extensible. Thus, a scale value of -1 represents once a millennium, and a scale value of 13, represents 3,000 times a second. Intermediate values are meaningful, e.g., a scale value of 4.3 represents 4 times a week and 4.7 represents 10 times a week. To determine the scale value for some arbitrary FoL = f (e.g., f = 5.7 seconds), determine how many occurrences there would be in a year (e.g., 365 x 24 x 60 x 60 ÷ 5.7). Take the logarithm of the result and add 2 (e.g., log10(5,532,632) = 6.74, add 2 to give the answer, 8.74).

Determination of consequence It is prudent to first consider the severity of the consequences for each of the 12 events. If a consequence is unacceptable, no matter how unlikely the event, the risk must be flagged for treatment. To assign a monetary value to the consequence, consider:     

fines (e.g., that could result from a breach of data protection legislation); the value of existing contracts; the value of potential contracts; lost revenue; and unexpected/additional costs.

It is also prudent to consider consequential consequences. For example, in addition to a hefty fine, a breach of data protection legislation could result in reputational damage, which in turn could result in a loss of customers and future business. Moreover, the time taken to investigate the incident can create additional costs. Ask for:  confidentiality: “What would be the ‘cost’ to your organisation, if the most sensitive of all its information was improperly disclosed?”  integrity: “What would be the ‘cost’ to your organisation, if the information that you most relied upon, e.g., for making business decisions, was inaccurate, incomplete, or had otherwise suffered from some other loss of integrity?” ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

28

Chapter 2 – Risk assessment

 availability: “What would be the ‘cost’ to your organisation, if the information that you most relied upon, e.g., for making business decisions, was unavailable at the time your organisation needed it?” If your organisation is responsible for the safe keeping of other organisation’s information. Ask the same questions in respect of that information (e.g., “What would be the ‘cost’ to your organisation, if information that it is responsible for keeping safe was improperly disclosed?”) and use the higher result for each consequence.

Determination of likelihood Categories There are three categories. Category R: The organisation has no influence upon the likelihood of occurrence and has not experienced any incidents of this type. Examples in this class include fires, floods, earthquakes, strikes, riots, and burglaries, etc. In these cases, determine the likelihood of occurrence through a consideration of recent historical data obtained through research for the geographic region(s) in scope of the ISMS. Category E: The organisation has little or no influence upon the likelihood of occurrence but does have experience of one or more incidents of this type. Examples of this class can include software and power failure. In these cases, determine the likelihood of occurrence through a consideration of organisational records. Category O: The likelihood is dependent upon opportunities for event occurrence created by the organisation. For example, the likelihood of losing a laptop will be related to the number of times a laptop is taken beyond the organisation’s protected boundaries. Notice, in this case the likelihood of losing a laptop is also related to the number of laptops and people. Note that with experience of incident, Categories R and O migrate to become Category E.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

29

Chapter 2 – Risk assessment

Table 2-4: Standard events and determination of likelihood id

Event name

Initial category

S1

Theft/loss of mobile devices

O

S2

Office break-in

R

S3

Acts of God, vandals, and terrorists

R

S4

Software failure

E

S5

Hardware failure

E

S6

Power failure

E

S7

Internet/communications failure

E

S8

Fraud or error

R

S9

Hacking

R

S10

Web DOS

E

S11

Disclosure

R

S12

Breach of the law

R

Questions The following questions should assist you to estimate the likelihood of occurrence for each event. For some events, there are two or more questions. The third column explains how to combine them (“N/a” if there is only one question). Convert to a base 10 logarithm before adding to the severity. Table 2-5: Questions to assist in the determination of likelihood id

Question(s)

Combine by

S1

How often is a mobile device removed from a secure environment that is under the organisation’s responsible person’s control?

Divide the first answer by the second

[A responsible person is a person who the organisation holds responsible for the safe keeping of the mobile device.]

S2 S3

How many mobile devices can be outside of that secure environment at the same time? [Count x people with y devices each as x times y.] How often is there a burglary of similar premises in your vicinity? How often is there a fire in your vicinity? [For example, how often do you hear fire engines outside of your premises?]

N/a Use the highest frequency

How often does your neighbourhood suffer from flooding? How often is travel to your premises restricted by adverse weather? [For example, snow, storms, high winds…]

How often is travel to your premises restricted by transport strikes? How often is travel to your premises restricted by riots and protests? How often is travel to your premises restricted by Government intervention? ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

30

Chapter 2 – Risk assessment

id

Question(s) [For example, because of pandemic instructions.]

Combine by

How often have you experienced software failure in operational systems?

N/a

How often have your operational systems stopped working because of a hardware failure?

N/a

How often have you experienced a power failure in your vicinity?

N/a

How often have you experienced a communications failure?

N/a

How many hours are there in your typical working week? How many people do you have in your organisation who have access to your internal IT? On average, approximately how many mistakes do people make per hour? How many accesses do you typically have in a day on all your websites? How many network transactions do people make typically each day when accessing your networks remotely? How many people do that?

Multiply the three answers together. The result is the effective FoL in weeks.

How many accesses do you typically have in a day on all your websites?

Divide the answer into 86,400 to give the effective FoL in seconds.

S11

How many people do you have in your organisation who have access to sensitive information?

Divide the answer by the number of people who have access to your internal IT (answer from S8) and multiply by the S8 FoL

S12

How often do you hear of a case of legal prosecution or regulatory fine against organisations such as yours?

N/a

S4

[Only count software that you depend upon for your business.]

S5

[Include servers, PCs, and laptops. Failure could be a component failure of a hard disc, motherboard, interface…]

S6

[Include servers, pcs, and laptops. Failure could be a component failure of a hard disc, motherboard, interface…]

S7

[For example, Internet failure, telephone failure, loss of 4G/5G…]

S8

S9

S10

[The answer to this question is the same as the same question for S9.1]

Multiply the second and third answers and add to the first. Divide the result into 86,400 to give the effective FoL in seconds.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

31

Chapter 2 – Risk assessment

Note that for S3, the table instructs you to use the greatest FoL. An alternative would be to subdivide S3 into 6 components and use the answer to each question as the FoL for each component. Another alternative would be to group questions with similarly valued answers together and subdivide S3 that way. However, if S3 is subdivided you must create a separate Risk Treatment Plan (RTP) for each one (see Chapter 3). Nevertheless, if you do not subdivide S3, you should still have controls that are associated with each of the six questions, so the decision to subdivide reduces to “do you want to: a) have a single RTP that includes all these disaster-related controls; or b) spread the same controls across perhaps six RTPs, one for each subevent?” Both approaches will have the same end-result in terms of information security protection, but (a) results in significantly less work. This prescription therefore recommends using the highest greatest FoL. Remember, risk assessment in the context of ISO/IEC 27001 is a step towards the goal of determining your necessary information security controls. It is not an end in itself.

Determination of inherent risk Once the severities and FoLs have been determined, add them together to determine the resultant level of risk. These results are referred to as the inherent risks, or risks before treatment.

Risk criteria Risk acceptance criteria Since the risks are to be plotted on a risk square such as Figure 1-3, it is prudent to: a) offset the consequence scale, if necessary, so that the border line between acceptable and unacceptable risk a diagonal line intersecting the top left and bottom right corners. b) colour the graph background (as in Figure 1-3) and declare risks below the borderline are acceptable (i.e., those within the yellow and green regions) and those above (i.e., within the orange, pink and red regions) as being unacceptable. c) require the risk treatment plans to have an appropriate mix of: i. preventive and detective controls; or ii. detective and reactive controls; iii. or preventive, detective, and reactive controls. d) require the derivation of residual risk to take proper account of the behaviour of the controls used to treat the risk. The third criterion has three alternatives because it is not always possible or costeffective to prevent the event or react to the consequence. Examples are the impossibility of preventing an earthquake and of recovering from undesirable disclosure of information. The fourth criterion is a reference to the behaviours described in Chapter 1 (“Control properties”).

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

32

Chapter 2 – Risk assessment

The first criterion does not have to be a straight line. As shown in Figure 2-1 it can be modified by declaring that: a) high severity consequences with extremely low likelihoods will be tolerated (Figure 2-1 (b)); b) all high frequency events, regardless of consequence are unacceptable (Figure 2-1 (c)); and c) all risks below a given risk value are also unacceptable (Figure 2-1 (c)).

Figure 2-1: Risk acceptance criteria The first modification address the problem of catastrophic events which, should they occur, would cause everyone to be concerned with matters other than information security. The second modification assists in the treatment of high frequency events by drawing attention to them. The third modification steers organisations away from over-control.

Performance criteria In practice risk assessments are required because of changes. Examples of significant changes include ICT upgrades, new services, new laws and regulations, new societal practices, new threats, and expanding markets. However, such changes are irregular and therefore there can be large gaps between successive changes. This is prevented by having a schedule of planned risk assessments occurring on the anniversary (or every other anniversary) of the first risk assessment.

Risk owner ISO/IEC 27001, Clause 6.1.2 c) 2) requires organisations to identify the risk owners. The term “risk owner” has a special meaning: a “person or entity with the accountability and authority to manage a risk”, see ISO/IEC 27000. The risk owner should therefore accept responsibility if the risk is realised and the risk treatment plan fails.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

33

Chapter 2 – Risk assessment

Schedules and previous results An example schedule is shown in Figure 2-2.

Figure 2-2: An example risk assessment schedule In this example, solid squares represent planned risk assessments and dotted squares represent risk assessments for proposed changes and when changes occur. In the example, risk assessments that have been performed are dated and hyperlinked to the results.

Documenting the process An example, based on the prescription presented in this Chapter, is given in Appendix A, Section A.2.

Documenting the results An example, based on the prescription presented in this Chapter, is given in Appendix A, Section A.4.

Risk assessment instructions Step 1: Decide the form of the documented information (e.g., a document or web page) and prepare the risk assessment process documented information using Appendix A, Section A.2, completing the first form element (RAP1, shaded thus). Step 2: Determine and apply an offset to the consequence scale, if required, to ensure that the borderline between acceptable and unacceptable risk intersects the top left and bottom right corners of the risk square. Follow the RAP2 and RAP3 instructions. Step 3: Determine who will own all the risks, or how the risk owner(s) will be determined. Complete the RAP4 form element. Step 4: Create a risk square (a copy of Figure 1-3 can be used) and use it to complete the RAP5 form element. Step 5: Prepare the risk assessment results documented information using Appendix A, Section A.4. Decide on your schedule for planned risk assessments and complete the RAR1 form element. Add new row for subsequent years at the beginning of the table so that the table always has the latest (and therefore the most relevant) information at the beginning of the table. Step 6: Determine the severity values for the consequences of all twelve events and complete the RAR2 form elements.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

34

Chapter 2 – Risk assessment

Step 7: Determine the frequency or likelihood (FoL) values for all twelve events and complete the RAR3 form elements. Step 8: Add the severity and FoL values together for each of the twelve events in turn and complete the RAR4 form elements (18 values). Step 9: Plot the risk results on a risk square (using arrows for off-scale values) and complete the RAR5 form element. Step 10: Determine which events lie in the orange, pink, and red regions, and complete the RAR6 form element. Step 11: State the priority for risk treatment using suitable words and complete the RAR7 form element. Highest priority are off-scale points and those in the red region. Next priority are those in the pink and regions. The rest are third priority. Step 12: Determine the risk owner(s) and complete the RAR8 form element. Step 13: Convene a review meeting with the risk owner(s) to formally review the results of the risk assessment. Ensure that the review considers the consistency, validity, and comparability of the results. Minute the meeting. Step 14: Perform all required changes to the documented information for the risk assessment results. Repeat as necessary until the results are approved. Step 15: Record a reference to the risk assessment results approval meeting in the RAP9 form element.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

35

Chapter 3 – Risk treatment Introduction This Chapter presents a prescription for performing risk treatment that conforms to the requirements of ISO/IEC 27001 Clauses 6.1.3 and 8.3, except for Clauses 6.1.3 c) and d) which are dealt with in Chapter 4. The Chapter explains the requirements of these ISO/IEC 27001 clauses. The Chapter presents two ways of producing risk treatment plans (RTPs) in each case there being one such RTP for each of the twelve events. The Chapter explains how to determine the effectiveness of the RTPs, and thereby determine the values of residual risk. The Chapter explains how to address risk acceptance, changes in risk assessment results and document the risk treatment process and its results. Finally, the Chapter gives instructions on how to apply the prescribed method.

The ISO/IEC 27001 requirement Define and apply ISO/IEC 27001 Clause 6.1.3 requires organisations to define and apply a risk treatment process that satisfies the requirement detailed in the subsequent five bullet points (a) – (f) and explained below. The reason for saying “define and apply”, has explained in Chapter 1 (Clauses 6.1 and 8) and Chapter 2, and is because the necessary controls that the organisation requires form part of the ISMS, but are determined through the process of risk assessment and risk treatment.

Risk treatment options ISO/IEC 27001 Clause 6.1.3 a) requires organisations to select appropriate options for treating risk, taking account of the risk assessment results. The standard does not prescribe a catalogue of options from which an organisation should choose, and therefore the requirement is perhaps better expressed as “… determine appropriate options…”. ISO 31000 describes seven options, which include risk avoidance, acceptance, modification, and transference. However, that standard mixes up two concepts: the modification of risk and responsibility for the performing the control. In determining its options for risk treatment, organisations should consider both concepts. Moreover, since risk is only a function of FoL and severity, there are only two factors that can be modified. Table 3-1 shows the relationship between the seven risk treatment options given in ISO 31000 and these two concepts.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

36

Chapter 3 – Risk treatment

Table 3.1: Relationship between the ISO 31000 risk treatment options, risk modification and responsibility #

Option

Responsibility

Changing the likelihood

Risk modification Reduce FoL towards zero Increase FoL and/or Sev Reduce FoL and/or towards zero Reduce FoL

1

Avoiding the risk

2

Taking or increasing risk

3

Removing the risk source

4 5

Changing the consequences

Reduce Sev

The organisation

6

Sharing the risk

Reduce FoL and/or Sev

The organisation and some third party

7

Retaining the risk

No change to FoL or Sev

The organisation

The organisation The organisation The organisation The organisation

Thus, in practice, the options are to (a) modify FoL and/or Sev; and (b) transfer some of the risk to a third party.

Determine necessary controls ISO/IEC 27001 Clause 6.1.3 b) requires organisations to determine the controls that it needs to implement the chosen risk treatment options. In practice this means:

a) rejecting any option that the organisation does not want to use; b) using controls that in combination will modify the inherent risks so that they meet the risk acceptance criteria; and

c) involving third parties as necessary if the organisation has chosen to allow that option to be used.

There is a note to Clause 6.1.3 b) that points out that organisations are at liberty to design their own controls or identify them from any source. The note was included to make it clear that the controls in ISO/IEC 27001, Annex A are not requirements.

Compare with those in Annex A ISO/IEC 27001 Clause 6.1.3 c) requires organisations to compare the necessary controls that it determined in the previous clause (6.1.3 b)) with those in ISO/IEC 27001, Annex A to verify that no necessary control has been omitted. There is a note to Clause 6.1.3 c) pointing that ISO/IEC 27001, Annex A contains a comprehensive list of control objectives and controls, and that the reason for directing users of the standard to that Annex is to ensure that no necessary controls have been overlooked. (There is a corresponding explanation at the beginning of that annex saying that it is to be used in the context of Clause 6.1.3.) There is also a note to Clause 6.1.3 c) explaining why organisations are not required to determine the objectives of its necessary controls, and that the controls in Annex A, whilst comprehensive are not exhaustive. Other controls may therefore be required.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

37

Chapter 3 – Risk treatment

ISO/IEC 27001, Annex A specifies the objectives for groups of controls and, as an aid to understanding, the purpose of the controls. When an organisation determines a necessary control, it should know why and therefore there is no need to explain it to itself. The purpose should in any case be clear from the risk treatment plan.

Produce a Statement of Applicability ISO/IEC 27001 Clause 6.1.3 d) requires organisations to produce a Statement of Applicability (SOA). This is a complete topic and is dealt with in Chapter 4.

Formulate a risk treatment plan ISO/IEC 27001 Clause 6.1.3 e) requires organisations formulate a risk treatment plan. As mentioned in Chapter 1, there are two common interpretations of the meaning of this requirement and the prescription in this book interprets the meaning of the term as meaning a design. (Note that in referring to risk treatment plans, ISO 31000 talks about implementation and resourcing needs. In ISO/IEC 27001 (and other MSS) such matters are dealt with in other clauses and therefore the advice given in ISO 31000 maps onto many ISO/IEC 27001 clauses, not just Clause 6.1.3 e).)

Obtain approval of plan and residual risks ISO/IEC 27001 Clause 6.1.3 f) requires the risk owner(s) to approve the risk treatment plan and to accept the residual risks.

Retain documented information about the process ISO/IEC 27001 Clause 6.1.3 also requires organisations to retain documented information about the risk treatment process.

Implement the risk treatment plan(s) ISO/IEC 27001 Clause 8.3 requires organisations to implement its risk treatment plan(s). This means that designs contained in the RTPs become a reality, with all controls fully operational or otherwise in a state of readiness for deployment.

Retain documented information about the results ISO/IEC 27001 Clause 8.3 also requires organisations to retain documented information about the risk treatment results.Treating risk – tell it like a story

The concept Imagine a short movie starting with one of the twelve events and culminating with its consequences. Your movie will be in three scenes: preventive, detective, and reactive. ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

38

Chapter 3 – Risk treatment

As the movie director or script writer, imagine what the protagonists (i.e., the members of your organisation) do to prevent that event from happening. What you should be imagining is a necessary control, or at least a measure that maintains risk. Imagine, particularly for events that can be triggered by an attacker, what the attacker does to counter your control and what you do in response. This first scene ends once you have exhausted all feasible and affordable preventive controls. Repeat the exercise for scene two, imagining that the event has occurred and what the protagonists do to detect the event. For the final scene, imagine that the protagonists are now dealing with the consequences and what they are doing to reduce the severity of those consequences.

Detection is paramount If you cannot detect an event, you cannot determine whether your preventive controls are working. Therefore, in practice, it is prudent to first determine how the protagonists will detect the occurrence of the event.

Hindsight is permitted The English poet William Blake (1757-1827) said that “Hindsight is a wonderful thing, but foresight is better, especially when it comes to saving life, or some pain!”. However, during design, as that is what our imagination process is, hindsight is permitted, as it is the process of reimagination in the light of hindsight that gives rise to foresight and adds robustness to the story. Especially in the third scene, ask “what would our protagonists rather have done before the event occurred that will now come to their rescue?”.

A happy ending At the conclusion of a risk treatment plan story, the residual risk should satisfy the risk acceptance criteria. This is the equivalent of a happy ending.

Layout of a risk treatment plan This prescription adopts the principle of having a risk treatment plan for each event, and lays out each one as follows: a) event id, name, and description; b) risks before treatment presented in tabular and graphical formats; c) the risk treatment plan story: i. preventing the event; ii. detecting the event; iii. reacting to the consequences d) risks after treatment presented in tabular and graphical formats; e) evidence of approval; f) previous plans; and g) data used to estimate the residual risk.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

39

Chapter 3 – Risk treatment

Writing the story Optimum approach In this approach one starts with a blank electronic worksheet. Draw a line top to bottom, about ⅓ across from the right-hand side. Write the story in the left-hand column. About half-way down, start writing the story for detecting the event, followed by reacting to the consequence(s). Finish by writing the story for preventing the event (from the top of the page). When writing the story, do not consult ISO/IEC 27001, Annex A, or any other reference set of controls. Just write down what your organisation does. If, in doing so, you discover a weakness, repair that weakness, and write down what your organisation should now do that results in better security. You will often find points of weakness. Stop, however, if the residual risk is acceptable. For example, consider you are writing a story that concerns the failure of telecommunications. You might have written down “… if that fails, we switch to our other telecoms provider…”. If that resultant residual risk is acceptable, stop. There is no need to ask what if our second provider fails, should we have a third?”. Only ask that question if the residual risk having switched to the second provider is unacceptable. Nevertheless, if two providers fail, there must be a common point of failure. That is the point where an additional control is required, not necessarily a third provider (unless that one does not suffer from that common point of failure). As you write the story, make a note of your necessary controls in the right-hand column. You will need these for the Statement of Applicability, see Chapter 4. An example is given in Appendix B (Section B.1). This approach is the optimum approach because it uses the tell-it-like-a-story concept as a design tool. It encourages organisations to answer the all too important question “what if it does not work?”. It engenders awareness and understanding of information security, particularly as it applies to your organisation. It has the greatest assurance that the risk treatment plans correspond to reality.

Reverse engineering approach Nevertheless, since the requirements of ISO/IEC 27001 can be implemented in any order, it is possible to create the risk treatment plans from the SOA. Appendix C presents a reference set of controls in the form of questions. The questions are presented in a table and question is associated with one or more events, and its control type (preventive, detective or reactive). The significance of the other attributes in this table is explained in Chapter 4. Prepare an electronic worksheet with a column about ⅓ away from the right-hand side (as for the optimum approach) but with rows for each of the 12 events, and each further divided into rows for preventing the event, detecting the event, and reacting to the consequence(s) (one row per consequence). In the reverse engineering approach: 1. Answer all the questions with ‘Yes’, ‘No’ or ‘Similar’. 2. If the answer is similar, replace the question with another to which the answer is ‘Yes’. 3. Guided by the event and control type attributes, copy the questions with ‘Yes’ answers to the first correct row (first column) of the worksheet an put a ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

40

Chapter 3 – Risk treatment

suitable reference to the question in the second column (e.g., 34.2 for the second part of question 34). 4. Rewrite the questions as necessary control statements (e.g., “Does your organisation subscribe to…” becomes “Our organisation subscribes to…”). One can stop at that point and just copy the content of the first column cells to relevant point in the twelve RTP stories. An example is given in Appendix A, Section A.5.1.2. If one prefers, the necessary control lists can be reordered if a revised order renders the list more understandable. Alternatively, it can be turned into a story. An example is given in Appendix A, Section A.5.1.3. Be careful not to change the meaning of any of the necessary control statements unless the worksheet and the question answers are likewise revised. This is to ensure consistency with the Statement of Applicability, see Chapter 4.

Determination of residual risk Residual risk is determined separately for each risk by considering each story. The preventive and detective parts are taken together to determine the effect that the necessary controls have on FoL. The reactive parts for each consequence determine the effect that the necessary controls have on the severity of that consequence. In considering the chosen part, determine which of the necessary controls has the dominant effect. It has been often said that “… security is only as good as the weakest link”. In this example each chain link acts independently: if any link breaks, the chain fails. However, if the failure of the chain merely exposes a stronger control that must be overcome, then security is not dependent on the strength of the chain. In this case: “… security is as good as the strongest control along the weakest attack path”; the ‘attack path’ being a sequence of vulnerabilities exploited by an attacker to achieve whatever their goal of compromising security. Thus, analyse the story to determine the strongest control along the weakest path. This is the dominant control. Consider whether the necessary controls described in the story work in series or parallel, and how they can be bypassed, deactivated, corrupted or otherwise circumvented. For example, an attacker can break through all the physical security and bypass access control and remove the hard disc drive. If the drive is encrypted, then the attacker still must defeat the encryption. If they have no access to the keys, then the encryption is the dominant control, and the behaviour of the story is N-factor. Otherwise, some other control will be the dominant control. If the there is a plain text printout of the content of the disc drive sitting on the desk next to the computer, then the access control and hard disc encryption are irrelevant, and the dominant control is the physical security. If the plain text document is locked in a safe, then the dominant control is either the encryption or the safe. However, other factors should be considered in this case, such as the length of time the attacker has to make off with the computer, or hard disc (or even the safe) before detection and the deployment of additional controls. Having determined the next step is to determine the control behaviour. The three behaviours are N-Factor, excess and strangulation and are described in Chapter 1 (section on “N-factor, excess and strangulation”). In summary:  If the control uses a secret, e.g., it can be defeated by guesswork, it is Nfactor. As the frequency of events increases, so will the number of successful attacks.  If it cannot, it will be excess, unless as the frequency of events increases the control fails, in which case it is strangulation.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

41

Chapter 3 – Risk treatment

Estimate the effectiveness of the control. Alternatively, once the ISMS is a year or more old, you should have some empirical data for estimating the effectiveness of your RTPs (e.g., the number of relevant incidents, or lack of incidents). It is not possible to offer a standard set of behaviours as the behaviours are story dependent.

Risk acceptance Once the residual risks are known, they should be compared to the risk acceptance criteria. If the residual risks do not meet the criteria, the failing risk treatment plan (or plans) should be reworked until the criteria are met, or the criteria are rethought (see discussion of Figure 2-1 in Chapter 2). The risk owners should then review the plans and formally accept them and their residual risks.

Previous results It this is the first plan; its documented information should say so. Otherwise, it should reference the previous plan(s) with an indication of why and how they were changed.

Documenting the process An example, based on the prescription presented in this Chapter, is given in Appendix A, Section A.3.

Documenting the results An example, based on the prescription presented in this Chapter, is given in Appendix A, Section A.5.

Risk treatment instructions Step 1: Prepare the risk treatment process documented information using Appendix A, Section A.3, and complete form element RTP1 and attend to RTP2. Step 2: Prepare the risk treatment plan documented information using Appendix A, Section A.5.1.1. There should be twelve such plans. Step 3: For each RTP, complete form elements RTP1, RTP2, RTP3, and follow the instructions for RTP4. Step 4. Decide on whether you will use the Optimum or Reverse Engineering approach to risk treatment and prepare the worksheets (see Section on “Writing the story” in this Chapter). Optimum approach (for each event)

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

42

Chapter 3 – Risk treatment

Step 5a: Using the worksheet, write the story for detecting the event, taking note of the necessary controls that you are using. Step 5b: Likewise, write the story for reacting to the consequence(s). Step 5c: Likewise, write the story for preventing the event. Step 5d: Review the whole story and ensure that it results in acceptable risk. Revise, as necessary. Step 5e: Copy the resultant text to the correct location in the risk treatment plan documented information, and thereby complete form elements RTP5, 6, 7a, 7b, and 7c. Reverse engineering approach Step 5a: Answer all the questions in Appendix C with ‘Yes’, ‘No’ or ‘Similar’. Step 5b: For all question answered ‘Similar’, replace the question with one to which the answer is ‘Yes’. Step 5c: Guided by the event and control type attributes, copy the questions with ‘Yes’ answers to the correct part of the worksheet and reference the origin of the question. Step 5d: Rewrite the questions as necessary control statements. Step 5e: Reorder and/or recast as a story if desired. Step 5f: Copy the resultant text to the correct location in the risk treatment plan documented information, and thereby complete form elements RTP5, 6, 7a, 7b, and 7c. Step 6: Perform the cross-checking process described in Chapter 4 to verify that no necessary control contained in the reference control set has been inadvertently overlooked. Revise the RTP stories, as necessary. Step 7: For each event, determine the dominant control for prevention and detection, determine its behaviour and estimate how it modifies the event FoL. Complete form elements RTP12a, 12b and 12c for preventive and detective controls. Hence complete form elements RTP 8a. Step 8: For each event and consequence, determine the dominant control for reaction, determine its behaviour and estimate how it modifies the event severity. Complete form elements RTP12a, 12b and 12c for reactive controls. Hence complete form elements RTP 8b. Step 9: For each event, combine the data in form elements RTP 8a and 8c and place the result in form elements RTP 8c. Step 10: Draw the residual risk graph and add any desired descriptive text (form elements RTP9). Step 11: Convene a review meeting with the risk owner(s) to formally review the results of the risk treatment. Ensure that the review considers the necessary controls, how they work together to modify risk, the residual risks, and their relation to the risk acceptance criteria. Minute the meeting. Step 12: Perform all required changes to the documented information for the risk treatment results. Repeat as necessary until the results are approved. Step 13: Record a reference to the risk assessment results approval meeting in the RTP10 form element. Step 14: If this is the first plan, say so in the RTP11 form element. Otherwise record a reference to the previous plan and indicate how and why they were changed.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

43

Chapter 4 – Statement of Applicability Introduction This Chapter presents a prescription for producing a Statement of Applicability (SOA) that conforms to the requirements of ISO/IEC 27001 Clauses 6.1.3 c) and d). This Chapter expands on the explanation of these clauses given in Chapter 3. The Chapter presents two approaches to determining the content of the SOA. Your organisation’s choice, however, depends on its choice for producing the RTPs – the Optimum Approach or the Reverse Engineering Approach. The Chapter presents two approaches for the structure of the SOA – the traditional layout and an alternative. The Chapter also presents the reference control set advocated by this book. This control set is a superset of the ISO/IEC 27001, Annex A controls. Thus: a) Organisations that apply this prescription can still claim conformity with ISO/IEC 27001. b) Since this superset also contains controls that are not in ISO/IEC 27001, Annex A, necessary control verification is more effective than verification just against ISO/IEC 27001, Annex A, which can thereby lead to better information security. c) The inclusion of such additional controls does not increase the burden of producing the SOA, since only the excluded ISO/IEC 27001, Annex A controls need to be recorded in the SOA. If an additional reference control is excluded, that exclusion should not be recorded in the SOA.

The ISO/IEC 27001 requirement The cross-checking process ISO/IEC 27001 Clause 6.1.3 c) requires organisations to compare the controls determined in Clause 6.1.3 b) with those in Annex A. The purpose is to verify that no necessary controls have been omitted. This idea is not restricted to ISO/IEC 27001 but is something practiced by many people in everyday life: when people are about to try something new; they often think about it and then ask a friend or research the Internet for ideas. Indeed, there is a British TV quiz show where contestants, unsure of the correct answer to a question, are permitted to “phone a friend” or “ask the audience”. The contestant does not have to use the answer that their friend or the audience provides. Brewer, Nash, and List [EIMS 2005] refer to this as an AIL – an alternatives idea list and cite three examples: ISO/IEC 27001, Annex A; the product realisation requirements of ISO 9001 and a book on marketing entitled “The 22 Immutable Laws of Marketing” by Ries and Trout. The idea, in the context of an ISMS, is to determine the necessary controls (through the process of risk treatment) and then study the AIL, checking to see if any of the ideas in the AIL have been overlooked in producing the RTPs.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

44

Chapter 4 – Statement of Applicability

It is important to appreciate that ISO/IEC 27001, Annex A is an AIL:

a) Most of the controls in ISO/IEC 27001, Annex A are measures that

maintain risk, not measures that modify risk. b) Several controls are the same measure (or groups of measure) described in different risk contexts, which is why there it appears that there are duplications and overlaps in ISO/IEC 27001, Annex A.

Produce a Statement of Applicability ISO/IEC 27001 Clause 6.1.3 d) requires organisations to produce a Statement of Applicability (SOA). The standard specifies what it must contain but not how it should be structured, as discussed below.

Content of the SOA Necessary controls and excluded Annex A controls The SOA must contain the necessary controls and the excluded Annex A controls. The necessary controls are primarily determined by Clause 6.1.3 b) but can also be determined through the cross-checking process (Clause 6.1.3 c)). According to the notes to Clause 6.1.3 b), organisations can design their own controls or identify them from any source. ISO/IEC 27003 refers to any control that is not in ISO/IEC 27001, Annex A as a custom control. Thus, if an organisation designs all its own necessary control or identifies them from a source other than ISO/IEC 27001, Annex A, all its necessary controls will be custom controls. The cross-checking process (Clause 6.1.3 c)) can be performed by mapping the necessary controls to the Annex A controls. Any unmapped Annex A control either exposes an omission in the necessary control set or must be declared as an excluded Annex A control. The term excluded is historic, hailing from the time (pre 2002) when such controls were requirements. A better term in today’s usage would be unnecessary control. Note that if all the necessary controls are custom controls but no Annex A control is excluded, then the SOA will not contain any Annex A controls. This is an important conclusion.

Rationales The SOA must contain the rationales for why the necessary controls are necessary and why any excluded Annex A control has been excluded. The standard neither requires how this is to be documented, nor whether separate rationales are required for each necessary control and excluded Annex A control.

Implementation status Finally, the SOA must state the implementation status for every necessary control.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

45

Chapter 4 – Statement of Applicability

Conformance with ISO/IEC 27001, Clause 8.3 requires the risk treatment plan to be implemented. Therefore. the implementation status of the necessary controls in the SOA should always declare it as being implemented unless it says otherwise in the plan. For example, a plan could state that it is the intention to implement some necessary controls in the future, perhaps when some condition is reached. Nevertheless, the residual risk in the absence of such controls should be acceptable. The better way to do this, however, is to develop a new edition of the plan and not mix design and project management concepts up in the same document.

Tightening the control specifications using custom and obviated controls If an Annex A control specification is used as a necessary control, then that control specification becomes an organisational requirement. There is an Annex A control that specifies that “All relevant legislative … requirements … shall be explicitly identified, documented … for each information system and the organisation”. Organisations that adopt this specification but do not have separate lists of legislative requirements for each of their information systems are nonconformant with the specification of this necessary control. To avoid these situations, organisations should use the mechanism of custom controls and obviations as described in ISO/IEC 27003. To apply this mechanism, write down what you do using similar words to the Annex A control specification, and declare the necessary control as a variant. For example, strike out the reference to all information systems so that the specification reads: “All relevant legislative … for each information system and the organisation”. A variant is shorthand for a custom control that obviates an Annex A control. In the case where all necessary controls are custom controls, the need for explicit declaration of variants and obviations does not arise, as discussed later in this Chapter.

Excluding Annex A controls There are two reasons for excluding Annex A controls: 1. It is obviated by a custom control. 2. The control protects against a non-existent or acceptable risk. In the case where all necessary controls are custom controls, the only excluded Annex A controls are those that protect against non-existent or acceptable risks. For example, there is a group of Annex A controls that concern the outsourcing of software development. If an organisation does not outsource any such development, then these controls are not applicable.

Certification audits Certification auditors invariably construct their audit plans with reference to the Annex A controls and will ask questions specifically related to the Annex A control specifications. Their objective, as specified in ISO/IEC 27006, is to review the “implementation of controls that were determined as necessary by the client for the ISMS (as per the Statement of Applicability).” Thus, the auditor should be using the specifications of necessary controls as given in the SOA not as specified in Annex A. However, without reference or knowledge of what is in the SOA whilst drawing up their audit plans, they can only use the Annex A controls as a planning guide. ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

46

Chapter 4 – Statement of Applicability

It cannot be overstated, ISO/IEC 27001, Annex A controls are not requirements. The requirement is to compare your necessary controls with those in Annex A and include all excluded Annex A controls in the SOA. Auditors should not argue against the rationales for exclusion saying that they are invalid. That is a statement of opinion. However, if there is a nonconformity, it rests with ISO/IEC 27001 Clause 6.1.3 b) and is a potential nonconformity as the organisation might failed to identify and implement a necessary control.

The reference control superset Constitution What in in the reference control superset Included in the reference control superset are: a) all the controls that are in ISO/IEC 27001, Annex A; b) all the controls that are currently being considered for inclusion in the next edition of ISO/IEC 27002; and c) controls necessary to fill in the gaps in the standard event RTPs (see Chapter 3), caused by a lack of detective and reactive controls in the ISO standards.

What is not in the reference control superset There are no sector-specific controls, e.g., those to be found in ISO/IEC 27010, 27011, 27017, 27018 and 27019.

ISO/IEC 27001 conformance ISO/IEC 27001 conformance can be assured with reference control superset because: a) b) c) d)

it contains all the Annex A controls; they are mapped one-to-one with the reference superset controls; the necessary controls specifications are known; and all excluded Annex A controls can be identified.

Therefore, it is possible to fulfil the requirements of ISO/IEC Clauses 6.1.3 c) and 6.1.3 d).

Structure of the reference control superset The controls are arranged in four major sections according to the predominate nature of who, or what implements the control. They therefore classed as:

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

47

Chapter 4 – Statement of Applicability

1. 2. 3. 4.

organisational controls; people controls; physical controls; or technological controls.

Reference superset control attributes Each control has four attributes: 1. an Annex A control reference if the question relates to an Annex A control (otherwise it is blank); 2. the events that the corresponding reference control is likely to appear in; 3. the location(s) (P = preventing the event, D = detecting the event, R = reacting to the consequence(s)) where the corresponding reference control is likely to appear; and 4. the security property (C = confidentiality, I = integrity, A = availability) that the corresponding reference control is likely to assist with.

Performing the cross-checking process Method for the Optimum approach to risk treatment A reliable process for comparing an arbitrary set of necessary controls and the controls in ISO/IEC 27001, Annex A, consists of: a) recasting the Annex A control specifications, the control objectives and some of the guidance text given in ISO/IEC 27002 in the form of questions; b) answering those questions in the knowledge of the RTP stories and the necessary controls. The Annex A control specifications are only a few words in length. In some cases, it is worthwhile consulting the ISO/IEC 27002 guidance text to gain a greater understanding of the purpose of the control. For the method prescribed in this book, the first part of this process has already been done. Appendix C presents a question set derived from the reference control superset together with their control attributes. Use the event, location and security property attributes to help locate the relevant RTP story, and for each question answer ‘‘Yes’, ‘No’ or ‘Similar’. As in the case of applying the Reverse Engineering approach to constructing the RTP stories (Chapter 3), if the answer is similar, replace the question with another to which the answer is ‘Yes’. Use the story text as a guide. This will help to ensure correspondence between the RTP stories and the SOA. If the answer is no, decide whether question relates to measures that you should be using. If the answer is yes, rework the relevant RTP story to include the measure, modify the question if necessary and change the answer to yes. If the answer is yes and the question has an Annex A attribute, make a note of the reason why the measure(s) described by the question are unnecessary. This will become an excluded Annex A control in the SOA for the reasons that you have just recorded.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

48

Chapter 4 – Statement of Applicability

Method for the Reverse Engineering approach to risk treatment Since you have used the answers to the Appendix C question set to construct the RTP stories, you have already performed the cross-check.

Necessary control statement form Whilst the reference superset controls are used in question form (as present in Appendix C), in the RTP stories and the SOA it is necessary to recast them in statement form. As mentioned in Chapter 3, conversion is straightforward, e.g., “Does your organisation subscribe to…” becomes “Our organisation subscribes to…”.

Constructing the SOA The traditional layout The traditional way to layout an SOA is to copy the layout of ISO/IEC 27001, Annex A. An example layout is given in Appendix A, Section A.5.3.1. The example shows how to create entries for: a) a necessary control whose specification is identical to that given in ISO/IEC 27001, Annex A; b) a necessary control whose specification is a variation of that given in ISO/IEC 27001, Annex A; c) a custom control, i.e., a necessary control that is not in ISO/IEC 27001, Annex A; d) an Annex A control that is obviated by a custom control; and e) an Annex A control that is excluded for some other reason. However, using this prescription, you are likely only to have variants, custom controls and excluded Annex A controls: 1. For all questions with ‘Yes’ answers and Annex A references, use the necessary control statement form of the question(s) as a variant specification. Use the RTP identifier as the reason for inclusion. 2. For all questions with ‘Yes’ answers but without Annex A references, declare it as a custom control. Use the necessary control statement form of the question(s) as the specification. Use the RTP identifier as the reason for inclusion. 3. For all questions with ‘No’ answers and Annex A references, declare as an excluded Annex A control, together with your reason for why the measure is unnecessary.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

49

Chapter 4 – Statement of Applicability

Custom controls can be located anywhere in the SOA, but as a separate entry to any Annex A entry. Recommended places are:  at the end of the SOA under a heading of ‘Custom controls’; and  near the entry for the Annex A control referenced in the immediately preceding question in Appendix C.

An alternative, modern layout Since the standard specifies what the SOA must contain but not how it should be structured, alternative layouts are permitted. However, they are unusual. The overall structure in this case is a) b) c) d) e)

Necessary organisational controls Necessary people controls Necessary physical controls Necessary technological controls Excluded Annex A controls.

This prescription refers to this alternative layout as the modern layout. An example is given in Appendix A, Section A.5.3.2 and shows how to create entries for the same five cases as above. However, for this prescription, all necessary controls are regarded as custom controls. Thus, there are only two types of entry: 1. For all questions with ‘Yes’ answers, use the necessary control statement form of the question(s) as the specification. Use the RTP identifier as the reason for inclusion. Include the Annex A reference, if it exists, otherwise declare it as custom control. 2. For all questions with ‘No’ answers and Annex A references, declare as an excluded Annex A control, together with your reason for why the measure is unnecessary.

Common to both layouts Mark the implementation status as implemented (or otherwise if that is not the case but see the above section on “Implementation status”) for all variants and custom controls. Necessary control statements for all questions with ‘No’ answers but without Annex A references should not appear in the SOA. Note that if you wish to reproduce the ISO/IEC 27001, Annex A control specifications in your SOA, you will need a copy of the standard and respect its copyright conditions.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

50

Chapter 4 – Statement of Applicability

Instructions for producing the SOA Optimum approach for RTPs (repeat for all questions in Appendix C) Step 1a: Answer the question, using the event, location, and security property attributes to local the relevant story text. Answer ‘Yes’, ‘Similar’ or ‘No’. Step 1b: If ‘Similar’, modify the question using the story text so that the answer is now ‘Yes’. Step 1c: If ‘No’, ask if the measure described by the question should be part of the RTP. If yes, rework the RTP and change the answer to ‘Yes’. If no, and the question has an Annex A attribute, record the reason why the measure is unnecessary. Reverse engineering approach for RTPs Step 1: No action – task already performed Common to both approaches Step 2: Decide on SOA layout and prepare a blank SOA accordingly. Traditional layout (repeat for all answers to questions in Appendix C) Step 3a: If ‘Yes’ and there is an Annex A reference, copy the necessary control statement form of the question to the referenced Annex A control entry in the SOA. Combine with previous entries if any. Declare as a variant. Record the RTP identifier as the reason for inclusion. Mark as implemented. Step 3b: If ‘Yes’ but there is no Annex A reference, create a SOA entry for a custom control (see “Traditional layout” above), copy there the necessary control statement form of the question, declare as a custom control. Record the RTP identifier as the reason for inclusion. Mark as implemented. Step 3c: If ‘No’ and there is an Annex A reference, find the referenced Annex A control entry in the SOA and mark it as “excluded”. Record the reason for the ‘No’ answer. The reason should be an explanation for why the Annex A control protects against non-existent or acceptable risk. Step 3d: If ‘No’ but there is no Annex A reference, do nothing. The necessary control statement form of the question should not appear in the SOA Modern layout (repeat for all answers to questions in Appendix C) Step 3a: If ‘Yes’, create an entry for the necessary control in the same section of the SOA as the question is in Appendix C (i.e., under ‘organisational control’, or ‘people controls’, etc.). Copy there the necessary control statement form of the question. Record the RTP identifier as the reason for inclusion. Record the Annex A reference(s) if any. Mark as implemented. Step 3b: If ‘No’ and there is an Annex A reference, create an entry in the ‘Excluded Annex A control’ section of the SOA, such that the excluded Annex A controls appear in the correct order (A.5.1.1, A.5.1.2, A.6.1.1, etc.). Record the reason for the ‘No’ answer. The reason should be an explanation for why the Annex A control protects against non-existent or acceptable risk. Step 3c: If ‘No’ but there is no Annex A reference, do nothing. The necessary control statement form of the question should not appear in the SOA.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

51

Chapter 5 – Maintenance and improvements Introduction Having applied the prescriptions given in Chapters 2, 3 and 4, an organisation should have now been able to: a) perform the risk assessment and risk treatment processes required by ISO/IEC 27001 Clauses 6.1.2 and 6.1.3; and b) have generated the required documented information for these clauses, including the Statement of Applicability, and that required by ISO/IEC 27001 Clauses 8.2 and 8.3. To maintain and improve the ISMS, further activities concerning risk assessment, risk treatment and the Statement of Applicability are required. This Chapter discusses:     

reviews and reassessments; extending reference control sets; determining your own scenarios; dealing with future ISO/IEC 27001 transitions; and on-line support.

Reviews and reassessments In creating the documented information for the risk assessment results, in which you would have created a schedule for planned risk assessments. Do keep to the schedule. If it transpires that the schedule is too onerous or unsuitable for some other reason, then change it and record the reason, e.g., in the minutes of a management review meeting. If you consider that the risks have not changed, then the re-assessment should not take very long and record that the risks have not changed in the risk assessment results. Take care to perform reassessments when significant changes are proposed or occur. If in doubt, conduct a risk assessment. If changes are made (or proposed) to the technological components of your risk treatment plans, such changes can invalidate the results of the risk treatment. Whilst this does not constitute a change that needs to be reassessed because of ISO/IEC Clause 8.2, the change can render one or more RTPs and the SOA invalid because a necessary control has changed, and the residual risk results may no longer be correct. Thus, a change to the technological components can induce a nonconformity against Clause 8.3.

Extending reference control sets The reference control superset is already an extension to the ISO/IEC 27001, Annex A control set. Further extensions can be made by the addition of the sector-specific controls from standards such as ISO/IEC 27010, 27011, 27017, 27018 and 27019.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

52

Chapter 5 – Maintenance and improvements

To use such extension in this prescription, transform the sector-specific controls into questions and apply them as if they were in Appendix C.

Determining your own scenarios The event-consequence method can be applied to any pair of events and consequences. Moreover, the events and consequences do not have to concern information security. For example, the event “unfulfilled requirements” with the associated consequences of “loss of revenue”, “unanticipated/ increased costs” and “waste of resource”, is related to quality. There are four reasons to create your own scenarios: 1. It can enhance top management understanding and buy-in when the events and consequences are directly related to their concerns. 2. There are necessary controls that are not easily contained within your current set of risk scenarios. 3. You wish to apply the method to other disciplines, such as quality, environmental protection, food safety, service management, and business continuity. 4. You wish a more detailed examination of some issue, e.g., the security behaviour of a software program, such as a banking application. The event-consequence method can be used as a design tool. It has been applied, for example, for the design of a new network solution for the processing of privacy related research data. The chief designer, a very experienced computer engineer remarked that the method had taught him the importance of detective and reactive measures, something that he had overlooked in the past.

Dealing with future ISO/IEC 27001 transitions It is likely that the next revision of ISO/IEC 27001, the controls in Annex A will be aligned with those in the next edition of ISO/IEC 27002. There will be a relationship between the current Annex A controls and the new Annex A controls. Some controls might be deleted, some controls merged with others and there is likely to be several new controls. The layout might also be radically different. Nevertheless, it is highly likely that the official mappings of the old controls to the new and vice versa will be published. Assuming no material changes are made to ISO/IEC 27001 Clauses 6.1.3 c) and d), the only transition activity that is required will be for organisations to compare their necessary controls with the new controls in Annex A. The comparison with those which are the same, merged or deleted was performed when the SOA was last updated before the new edition of ISO/IEC 27001 is published. There should also be no need to change the layout of the existing SOA or much of its content, just add: a) new entries for the new controls; b) the mappings for the old controls to the new for existing Annex A entries.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

53

Chapter 5 – Maintenance and improvements

The reason for this is that the controls currently in Annex A are not requirements and there is no reason to believe that this will change in the future. The SOA summarises the organisations necessary controls. The publication of a new reference set of controls does not change that. However, the effect of ISO/IEC 27001 Clauses 6.1.3 c) causes organisations to consider the new references controls: do they highlight a necessary control that has been overlooked? They might do, in which case it will be necessary to revise the risk treatment plans and introduce the new controls. However, it is possible that the new Annex A controls map onto existing custom controls. In this case, the simplest action is to obviate the new Annex A control by the existing custom control. An alternative approach would be to recast the custom control as a variant of the new Annex A control. Organisations that have used the prescription and the questions in Appendix C should have less work to do, since all that should be required is the mapping between the new Annex A controls and the questions in Appendix C.

On-line support On-line support is provided for this book by IMS-Smart Limited, as described in https://innov.ims-smart.com/_mirror/Technology/RApSOA.php. Called the “Assistant”, it says “Perform your ISO/IEC 27001 conformant risk assessment, risk treatment and Statement of Applicability in five easy steps:  Answer questions regarding the characteristics of your organisation, your preferences, the impact of the loss of confidentiality, integrity and availability, and the likelihood that certain events will occur.  Answer questions regarding the information security measures that you have in place (or intend to put in place).  Review the risk stories and decide how effective they are about reducing your information security risks to an acceptable level.  Answer some questions about your necessary information security controls (e.g., their implementation status) and excluded ISO/IEC 27001, Annex A controls.  Export the results and incorporate them into your ISMS.”

Register for an evaluation copy (https://innov.imssmart.com/_mirror/Technology/registerDBB03.php) and gain free access to download the risk assessment and risk treatment process descriptions and other templates as described in Appendix A.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

54

Appendix A – Documented information examples A.1 How to use this appendix A.1.1 Introduction This appendix contains examples of the documented information required by ISO/IEC 27001, Clauses 6.1.2, 6.1.3, 8.2 and 8.3:    

Clause 6.1.2: documented information about the risk assessment process Clause 6.1.3: documented information about the risk treatment process Clause 8.2: documented information about the risk assessment results Clause 8.3: documented information about the risk treatment results.

The documented information for the risk treatment results is presented in three parts – an example risk treatment plan (organisations following the prescription given in this book will have twelve of these); an example summary showing all twelve results together; and two examples (extracts) of a SOA. The risk treatment plan example is itself presented in three parts: a template and two completed examples, one in list format and the other in story format. Organisations are permitted to use these examples as given but treat them as a form to complete (as there are sections which require customisation). Alternatively, organisations can use them as examples and as inspiration for their own layouts and content. Rather than retype the examples in this appendix or attempt to copy and paste them from an electronic copy of this book, section A.6 gives instructions on how they can be downloaded from the Internet.

A.2 Risk assessment process

Introduction

This « [RAP1] say what this is (e.g., document, (web) page) » describes our approach to risk assessment. It explains how we identify, analyse, and evaluate risk; our risk criteria; risk ownership; when we schedule risk assessments; and the validity of our results.

Risk identification

We identify information security risks through a consideration of those issues that are relevant to information security and the scope of our management

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

55

Appendix A – Documented information examples

system. Each risk has two components: an event and a consequence. The consequences that are relevant to information security are: Undesirable disclosure of information; Loss of integrity; Inability to carry some or all of one’s business.

Risk analysis

Risk is then the product: likelihood of the occurrence of the event * severity of the potential consequence The dimensions of likelihood are reciprocal time (i.e., 1/time or time-1). We use a logarithmic scale where the number 2 corresponds to once a year. Thus 0 corresponds to once a century, 4, once a week and 7, about every 5 minutes. Likelihood represents the chance or probability of something happening. However, although some event might be extremely unlikely, once it does occur the frequency of recurrence might be extremely high. As information security controls must contend with the frequency of attack, we often use the terms frequency and likelihood interchangeably and refer to them as frequency or likelihood, or FoL for short. We measure consequence in terms of money. Again, we use logarithmic scales, with the number 2 representing £1,000. Thus 0 corresponds to £10 and 5 corresponds to £1,000,000. « [RAP2] offset the scale, if necessary, to ensure that the borderline between acceptable and unacceptable risk intersects the top left and bottom right corners of the risk square, i.e., a risk level of 6. With the number 2 representing £1,000, the number 4 represents £100,000. Since the number 2 also represents a year, a risk level of 6 (= 4 + 2) corresponds to an acceptable risk of losing £100,000 per year. If your limit of acceptable risk is, say, £10,000 per year, to retain the number 6 as the limit of acceptable risk, rewrite this sentence to read “…with the number 2 representing £100. Thus 0 corresponds to £1 and 5 corresponds to £100,000” » As we use logarithmic scales, the product of likelihood and consequence is determined by summing their logarithmic values. Thus, a risk formed by having a likelihood of 3 and a consequence of 2 corresponds to a risk level of 3 + 2 = 5, i.e., a loss of £10,000 per year. « [RAP3] If you have changed the scale factor you must also change this sentence. Thus, if the number 2 represents £100, rewrite this sentence to read “…, i.e., a loss of £1,000 per year.” »

Risk ownership

A risk owner is a “a person or entity with the accountability and authority to manage the risk”. Their task is to approve the risk treatment plan and

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

56

Appendix A – Documented information examples

residual risk for the risks that they own. In our organisation « [RAP4] say who or describe the process you use to identify them. »

Risk evaluation

Having identified and analysed our information security risks, we compare them to our risk acceptance criteria (see below).

Risk criteria

The figure shows a graph of severity versus FoL and highlights the regions of acceptable and unacceptable risk. The orange line is the borderline between the regions of acceptable and unacceptable risk. A risk is deemed acceptable: if it lies on or below the borderline, i.e., it is in the green, yellow or orange regions; and risk treatment consists of a mix of: preventive and detective controls, with a statement declaring the acceptability of any residual risk; detective and reactive controls, with a statement declaring the acceptability of any residual risk; preventive, detective, and reactive controls, with a statement declaring the acceptability of any residual risk. the derivation of residual risk takes proper account of the behaviour of the controls used to treat the risk (see our risk treatment process) « [RAP5] Create a risk square put it here. »

Scheduling risk assessments

We perform risks assessments periodically according to the schedule presented in our risk assessment results. We also perform risk assessment when we are considering change or changes are imposed upon us. These are also identified in our risk assessment results.

Validity of results

Repeated risk assessments are: CONSISTENT, because we apply the same method and criteria each time; VALID, because the measure of risk is dimensionally correct and, as part of the risk treatment process, it is reviewed and approved by the risk owner; COMPARABLE, because our method is mathematically sound.

A.3 Risk treatment process

Introduction

This « [RTP1] say what this is (e.g., document, (web) page) » describes our approach to risk treatment. It explains how we treat risk and formulate a risk treatment plan; how we ensure we have not omitted any necessary controls, formulate a Statement of Applicability and gain approval for the risk treatment plan and residual risks. There is a risk treatment plan (RTP) for each event. However, in the real world, controls do not know which RTP they belong to and they will come

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

57

Appendix A – Documented information examples

into operation as soon as their preconditions for operation are satisfied. Thus, in effect, RTPs operate in parallel.

Treating risk Risk treatment options

We treat risk by applying controls that modify the risk in such a way that it meets our risk acceptance criteria. As risk is the product of likelihood and consequence, the only two parameters that a control can modify are FoL and severity. Controls can: a) act in attempt to prevent the occurrence of the event or detect it in sufficient time for our organisation to deal with it. if successful, these controls reduce FoL; b) react to the consequence and if successful reduce its severity. Moreover, controls may act to reduce the FoL or severity to zero (minus ∞ on a log scale) or some very small value; or reduce it by some factor (e.g., the treated risk is 1/Nth of the untreated risk. We may perform the control ourselves, or outsource it « [RTP2] Note that if your organisation is part of a legal entity, you might add: and in some cases it is already performed by another organisation, although we could augment it. ». We are also aware that in reducing risk for one variety of consequence (e.g., the undesirable disclosure of information) we might be forced to increase it for another (e.g., the inability to carry some or all of one’s business). Thus, there are a wide range of risk treatment options that we can use.

Determination of controls

We take each event in turn and proceed in a story board fashion. We first look towards preventing the event and then to detecting it. We then consider how to react to each of the associated consequences. We finish when we are satisfied that the residual risk is acceptable, and check that by verifying that the modification of FoL and severity necessary to render the risk acceptable is consistent with the control behaviour. We either design the controls or make use of existing commercially available technology to meet our need to modify risk at the point where we invoke the control in the story.

Comparison with Annex A

We recognise that it is possible, through error or oversight, to omit necessary controls from our risk treatment plans. We therefore compare our controls with those in Annex A. We do this by taking each Annex A control in turn (see our Statement of Applicability page) and: For each Annex A control in turn we: 1. Decide whether it applies to us or not. If not, we exclude it on grounds of not applicable and record why. 2. If it is obviated by a custom control (e.g., because the custom control avoids the risk that the Annex A control is intended to mitigate), we exclude it on grounds of being obviated and record why. 3. If it does the same job as a custom control, we declare it as a variant. This excludes the Annex A control and replaces it with our custom

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

58

Appendix A – Documented information examples

control. We explain the reason for doing something different and what we do instead. 4. Otherwise, we declare the Annex A control as a necessary control. 5. For all necessary controls, we: a) cross-reference the control back to the risk treatment plans in which the control is used. b) record the implementation status of the control: i. Implemented ii. In progress iii. Not yet implemented. If we determine that an Annex A control applies but does not feature in our risk treatment plans, we determine where it should go and rework the plan (or plans) accordingly.

Formulating risk treatment plans

We create one risk treatment plan per event. The layout of each plan is: 1. A description of the event; 2. The risks before treatment (presented in a table of likelihoods and consequences, and a corresponding graph); 3. The risk treatment plan story: a) Preventing the event; b) Detecting the event; c) Reacting to the consequence(s); 4. The risks after treatment (presented in a table of likelihoods and consequences, and a corresponding graph) together with: a) Our rationale for why the risk acceptance criteria are met; b) Evidence that the risk owner has approved the plan and has accepted the residual risk. 5. An index to earlier versions of the plan, should they exist. The residual risk calculations are performed by IMS-Smart software which allows us to ensure that, having decided upon the control behaviour, the calculations are consistent with that behaviour.

Risk owner approval

The risk owners meet to review and approve the risk treatment plans and the results are recorded in the minutes of those meetings.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

59

Appendix A – Documented information examples

A.4 Risk assessment results

Historical results and risk assessment schedule 2022 Q1

2022 Q2

2022 Q3

2022 Q4

2021 Q2

2021 Q3

2023 Q4

[RAR1] 20212 Q1

Note: planned ( ) and ad hoc ( ) assessments are in the future, whilst historical results are in the past. Ad hoc assessments are performed when relevant changes within scope of the management system are proposed or occur. Do not remove rows. As the ISMS enters a new year add a new row to the top of the table.

Present results Risk identification and assessment

The following table presents the results of the present information security risk assessment. Having applied the method, the table lists the various events that are of concern to us, together with their likelihood of occurrence;

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

60

Appendix A – Documented information examples

Event

S1 - Theft/loss of mobile devices

S2 - Office break-in

S3 - Acts of God, vandals, and terrorists

S4 - Software failure

Consequence

the potential consequences, their severity, and the overall risk. The same data is presented graphically in the figure below the table. Frequency or likelihood

« [RAR3] Insert your likelihood value here, e.g., Once a month (3) »

Severity

Risk

C

« [RAR2] Insert your severity value here, e.g., £1,000 (2) »

« [RAR4] Insert the sum of likelihood and severity here, e.g., 5 »

A

« Ditto »

« Ditto »

C

« Ditto »

« Ditto »

A

« Ditto »

« Ditto »

C

« Ditto »

« Ditto »

A

« Ditto »

« Ditto »

I

« Ditto »

« Ditto »

A

« Ditto »

« Ditto »

« Ditto »

« Ditto »

« Ditto »

S5 - Hardware failure

« Ditto »

A

« Ditto »

« Ditto »

S6 - Power failure

« Ditto »

A

« Ditto »

« Ditto »

S7 - Internet/ communications failure

« Ditto »

A

« Ditto »

« Ditto »

S8 – Fraud or error

« Ditto »

I

« Ditto »

« Ditto »

C

« Ditto »

« Ditto »

I

« Ditto »

« Ditto »

A

« Ditto »

« Ditto »

S9 - Hacking

« Ditto »

S10 - Web DOS

« Ditto »

A

« Ditto »

« Ditto »

S11 - Disclosure

« Ditto »

C

« Ditto »

« Ditto »

C

« Ditto »

« Ditto »

A

« Ditto »

« Ditto »

S12 - Breach of the law

« Ditto »

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

61

Appendix A – Documented information examples

« [RAR5] Plot your risk assessment results on this graph »

Risk evaluation and prioritisation for treatment

« [RAR6] State which risks are unacceptable and require treatment». The priority order is « [RAR7] list them from the graph, starting with the risk furthest (diagonally) form the orange region»

Risk owners

« [RAP8] Say who the risk owners are. Note that the risk owner might be different for different risks. » The risks were reviewed for consistency, validity, and comparability at « [RAP9] say what meeting » and found to be satisfactory.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

62

Appendix A – Documented information examples

A.5 Risk treatment results A.5.1 A risk treatment plan (template) A.5.1.1 Template

Risk treatment plan S« [RTP1] event number » [« [RTP2] event name »] Event description « [RTP3] Event description »

Risks before treatment Likelihood

Consequence

C1 « [RTP4] Copy data from risk assessment results to here » I1 A1 (1)

Severity

Risk

« [RTP4] Copy data from risk assessment results to here »

« [RTP4] Insert the sum of likelihood and severity here »

« Ditto »

« Ditto »

« Ditto »

« Ditto »

Delete row if consequence does not apply to this event

« [RTP4] Copy the graph too »

Risk treatment plan ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

63

Appendix A – Documented information examples

Preventing the event

« [RTP5] List or storyboard necessary preventive control statements from Appendix B for this event, customised as appropriate, see Chapter 3 »

Detecting the event

« [RTP6] List or storyboard necessary detective control statements from Appendix B for this event, customised as appropriate, see Chapter 3 »

Reacting to the consequences (2) (2)

Just say “Reacting to the consequence” if this event has only one consequence

Undesirable disclosure of information

« [RTP7a] List or storyboard necessary reactive control statements for confidentiality from Appendix B for this event, customised as appropriate, see Chapter 3 »

Loss of integrity

« [RTP7b] List or storyboard necessary reactive control statements for integrity from Appendix B for this event, customised as appropriate, see Chapter 3 »

Inability to carry some or all of one’s business

« [RTP7c] List or storyboard necessary reactive control statements for availability from Appendix B for this event, customised as appropriate, see Chapter 3 »

Risks after treatment Likelihood

« [RTP8a] Insert new likelihood value following application of effectiveness data from table below3»

Consequence

Severity

Risk

C4

« [RTP8b] Insert calculated value3 »

« [RTP8c] Insert calculated value3 »

I4

« Ditto »

« Ditto »

A4

« Ditto »

« Ditto »

(3)

See Chapter 3 for instructions on how to do this

(4)

Delete row if consequence does not apply to this event

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

64

Appendix A – Documented information examples

« [RTP9] Add explanatory text as necessary »

Approval

« [RTP10] Say when this plan was approved and provide a reference to evidence of that approval. »

Previous plans

« [RTP11] Either say that this is the first approved plan, or when and why it was revised, together with a reference to previous plans. »

Effectiveness of risk treatment

The following data have been used to estimate the residual risk: Treatment pair Preventive and detective controls

Reactive controls for: Undesirable disclosure of information5 Reactive controls for: Loss of integrity5

Control behaviour « [RTP12a] Nfactor/ strangulation/e xcess6 »

FoL modification:

«

[RTP12b] Insert value7 »

« [RTP12c] Insert value8 » Limit:

Limit:

« Ditto »

Sev modification: « Ditto »

Limit:

« Ditto »

Sev modification: « Ditto »

Limit:

« Ditto »

Sev modification: « Ditto »

Reactive controls for: Inability to carry out some or all of one’s business5

Risk modification parameters

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

« Ditto »

« Ditto »

« Ditto »

65

Appendix A – Documented information examples (5)

Delete row if consequence does not apply to this event

(6)

Delete as appropriate

(7)

Content of cell only applies if N-factor or strangulation

(8)

Content of cell only applies if excess or strangulation

« Add explanatory text as necessary »

A.5.1.2 Example using listed necessary controls

Risk treatment plan S« [RTP1] number of plan » [« [RTP2] event name »] Event description « [RTP3] Event description »

Risks before treatment Likelihood

Consequence

C1 « [RTP4] Copy data from risk assessment results to here » I1 A1 (1)

Severity

Risk

« [RTP4] Copy data from risk assessment results to here »

« [RTP4] Insert the sum of likelihood and severity here »

« Ditto »

« Ditto »

« Ditto »

« Ditto »

Delete row if consequence does not apply to this event

Copy the graph too ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

66

Appendix A – Documented information examples

Risk treatment plan Preventing the event

« List or storyboard necessary preventive control statements from Appendix B for this event, customised as appropriate, see Chapter 3 »

Detecting the event

« List or storyboard necessary detective control statements from Appendix B for this event, customised as appropriate, see Chapter 3 »

Reacting to the consequences (2)

Just say “Reacting to the consequence” if this event has only one consequence (2)

Undesirable disclosure of information

« List or storyboard necessary reactive control statements for confidentiality from Appendix B for this event, customised as appropriate, see Chapter 3 »

Loss of integrity

« List or storyboard necessary reactive control statements for integrity from Appendix B for this event, customised as appropriate, see Chapter 3 »

Inability to carry some or all of one’s business

« List or storyboard necessary reactive control statements for availability from Appendix B for this event, customised as appropriate, see Chapter 3 »

Risks after treatment Likelihood

Consequence

Severity

Risk

« Insert new likelihood value following application of effectiveness data from table below3»

C4

« Insert calculated value3 »

« Insert calculated value3 »

I4

« Ditto »

« Ditto »

A4

« Ditto »

« Ditto »

(3)

See Chapter 3 for instructions on how to do this

(4)

Delete row if consequence does not apply to this event

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

67

Appendix A – Documented information examples

« Add explanatory text as necessary »

Approval

« Say when this plan was approved and provide a reference to evidence of that approval. »

Previous plans

« Either say that this is the first approved plan, or when and why it was revised, together with a reference to previous plans. »

Effectiveness of risk treatment

The following data have been used to estimate the residual risk: Treatment pair

Control behaviour

Risk modification parameters

Preventive and detective controls

« N-factor/ modification: « strangulation/e Insert value7 xcess6 » »

FoL

Limit:

Reactive controls for: Undesirable disclosure of information5

Limit:

« Ditto »

Sev modification: « Ditto »

Limit:

« Ditto »

Sev modification: « Ditto »

Limit:

« Ditto »

Sev modification: « Ditto »

Reactive controls for: Loss of integrity5 Reactive controls for: Inability to carry out some or all of one’s business5

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

« Insert value8 »

« Ditto »

« Ditto »

« Ditto »

68

Appendix A – Documented information examples (5)

Delete row if consequence does not apply to this event

(6)

Delete as appropriate

(7)

Content of cell only applies if N-factor or strangulation

(8)

Content of cell only applies if excess or strangulation

« Add explanatory text as necessary »

A.5.1.3 Example stories Example stories are given in Appendix B.

A.5.1.4 Summary of results Organisations may wish to produce a summary of all risk treatment results to show how the overall inherent risk is modified.

Risks before treatment

There are 12 risk treatment plans:  S1 – Theft/loss of mobile devices  S2 – Office break-in  S3 – Acts of God, vandals, and terrorists  S4 – Software failure  S5 – Hardware failure  S6 – Power failure  S7 – Internet/communications failure  S8 – Fraud and error  S9 – Hacking  S10 – Web DOS  S11 – Disclosure  S12 – Breach of the law

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

69

Appendix A – Documented information examples

A.5.3 Statement of Applicability A.5.3.1 Traditional layout (extract) In this example, a table is used for each of the 35 sub-headings in ISO/IEC 27001, Annex A. In the table shown below, each row exemplifies how to present: f)

a necessary control whose specification is identical to that given in ISO/IEC 27001, Annex A; g) a necessary control whose specification is a variation of that given in ISO/IEC 27001, Annex A; h) a custom control, i.e., a necessary control that is not in ISO/IEC 27001, Annex A; i) an Annex A control that is obviated by a custom control; and j) an Annex A control that is excluded for some other reason.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

70

« Modified control specification3 »

« References to RTPs which use this control2»

« Control specification1 »

(1)

Copied without alteration from ISO/IEC 27001, Annex A

(2)

See Chapter 4

2

« Implementation Status

« Reason for obviation and reference to the custom control that is performing the obviation»

Not applicable

A.n.m.4 « Control name1 »

« Control specification1 »

Excluded Obviated

A.n.m.3 « Control name1 »

« References to RTPs which use this control2»

« Reason for nonapplicability»

Not

« Control specification2 »

« Custom identifier2 »

« Custom name2 »

Custom control

Control variation

A.n.m.2 « Control name1 »

« References to RTPs which use this control2»

2

« Control specification1 »

Reason for inclusion or exclusion

« Implementation « Implementation status2»

« Control name1 »

Specification

Necessary t l

A.n.m.1

Name

Type

Id

Necessary/excluded

Appendix A – Documented information examples

(3)

The Annex A control specification has been struck through to show that this is not an organisational requirement in this case. The organisational control requirement in in the attribute cell

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

71

Appendix A – Documented information examples

A.5.3.2 Modern layout In this example, five tables would be used one for each of the four control pillars: organisational, people, physical and technological, and a fifth for excluded Annex A controls. The example presents an extract from the technological table. Appendix C presents the questions together with their reference control identifiers. Control specifications are created by: 1. ignoring questions with ‘No’ answers 2. replacing questions with ‘Similar’ answers with your replacement question to which the answer is ‘Yes’ 3. combining the question text for questions with ‘Yes’ answers and replacement questions associated with the same reference control identifier 4. replacing the resultant text for each reference control identifier with its statement form (e.g., “Do you subscribe…?” becomes “We subscribe…”. Copy the Annex A references exactly as given in Appendix C. If the entry is blank, the control entry is a custom control. If the entry is of the form A.x.y.z*, it is a variant of Annex A control A.x.y.z, otherwise it corresponds directly to Annex A control A.x.y.z.

« Cont rol nam e2 »

« Control specification3 »

Status

CIA1, 4

Events

« Implementation status»

« Referen ce control identifier 1 »

Nam e Specification

« References to RTPs which use this control1»

Id

PDR 1, 4

4 Technological controls

Annex A Annex A control map: « List of associated Annex A controls or blank1»

Excluded Annex A controls Control

Rationale

A.n.m.4 « Control name5 »

« Reason for exclusion»

« Control specification5 » (1)

Copied from Appendix C, customised as used in an RTP, see Chapter 4.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

72

Appendix A – Documented information examples (2)

Invent a suitable name

(3)

See text above for creating specifications from questions

(4)

Optional, see Chapter 4

(5)

Copied without alteration from ISO/IEC 27001, Annex A

A.6 The on-line Assistant A.6.1 Introduction The templates presented in this Appendix are also available on-line. Instructions for accessing them are presented in this section.

A.1.2 Assistant registration First register for an Assistant evaluation licence (https://innov.imssmart.com/_mirror/Technology/registerDBB03.php). The evaluation licence is valid for 30 days. However, upon expiry you can register for another evaluation licence, although you will need to provide new credentials. Whilst all the functionality of a full licence is present with an evaluation licence, not all the questions presented in Chapters 2 and 3 are asked. This restricts the usability of an evaluation licence to: a) facilitating download of: i. text, customised for your organisation, for the risk assessment and risk treatment processes; ii. partially completed templates for the risk assessment and risk treatment results, risk treatment plans and the SOA (both layouts) b) demonstrating how the Assistant functions. Registration links to the home page of the Assistant.

A.1.3 Preparation A.1.3.1 Step 1 – Risk questions The first step is to answer the first group of questions on the RISK QUESTIONS PAGE, see Figure A-1. The ‘risk squares’ group of questions allows you to customise the graphs in terms of: 1) whether you wish to show the limit line, i.e., the boundary between acceptable and unacceptable risk, and, if, so, you are offered a choice of colours; 2) the currency symbol (£, €, $ or none); 3) the limit of acceptable risk (this will alter the position of the coloured bands) 4) the band widths. ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

73

Appendix A – Documented information examples

Figure A-1 Risk questions page

A.1.3.2 Step 2 – Control questions Open the CONTROL QUESTIONS PAGE. The evaluation licence limits the control questions to just those that correspond to the S1 event (Theft/loss of mobile devices). In the fully licenced version, all the questions listed in Appendix C will be asked. However, for the purposes of generating the templates, just click SAVE ANSWERS. This action will set the answers to the displayed questions to ‘yes’ and generate the SOA and risk treatment plan stories, albeit with some gaps in the text.

A.1.3.3 Step 3 – Display the SOA Open the DISPLAY SOA PAGE.

A.1.3.4 Step 4 – Open the exporter

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

74

Appendix A – Documented information examples

The content of the exporter page is now ready for copying. Should you access this page prematurely, some of the content (e.g., the SOA) will not be available. However, a reminder of the outstanding tasks (Steps 1 – 3 above) will be displayed.

Figure A-2 Exporter page showing outstanding tasks

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

75

Appendix B – An example RTP story B.1 Optimum approach S2 Office break-in The following text presents an example of the story text for RTP-S2 (Office break-in, as might be constructed using the optimum approach.

Preventing the event

Necessary controls

We share our premises with other companies. Our landlord provides a degree of building security as specified in our contract.

We have a landlord that provides building security services for our offices

There is a general reception area on the ground floor and a security guard.

Access points to secure areas are guarded

Visitors may enter the building during normal office hours, but outside of those times, access is by a programmed proximity card.

Access points to secure areas are protected by physical or electronic locks

We are situated «say where», which is accessed «say how». «Say how visitors and staff gain access and what happens to visitors, e.g., escorted at all times. » We run a paperless office.

Paper documents, and removeable media are removed from surfaces, such as desks, and away if the area is to become unattended.

On vacating the office, PCs are locked but not always switched off, to facilitate 24x7 remote access.

Computer screens are locked after a period of inactivity and require user authentication on reactivation

The server room is kept locked and access is restricted to key holders and in our data centre, access is limited to named individuals.

Doors, windows, cabinets, service hatches and other possible physical entry points are secured with locks, bolts, bars or other means.

Detecting the event

Necessary controls

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

76

Appendix B – An example RTP story

We have passive infrared detectors and door contacts, which will raise an alarm if triggered. The alarm system is manually activated when the last person leaves the office, and deactivated when the first person get in the office.

Rooms are alarmed

If alarm goes off, it sends a signal to a security company who will investigate, and they notify predefined persons over telephone immediately.

Secure areas are patrolled by security personnel.

Reacting to the consequences

Necessary controls

Undesirable disclosure of information We use hard disc encryption on our desktops and servers, combined with

We encrypt data stored on media to prevent unauthorised access to such information.

strong log-on passwords. It might be possible to crack, but we consider that an acceptable risk.

We have the means to ensure that quality passwords are used, and enforce changes as needed.

Inability to carry some or all of one’s business

We have and apply a policy for backing up information and verifying that the backed-up information can be successfully restored.

Theft from the office might result in the loss of the original data but we have offsite backups (which have been tested and therefore we are confident that they will work), and also new equipment may need to be purchased. In the worst case, our business continuity plan (yellow) is invoked (see S3), which would involve transferring the office IT functions to our data centre. The delays and costs involved in recovery are acceptable.

B.2 Reverse engineering approach S2 Office break-in The following text presents an example of the story text for RTP-S2 (Office breakin). The control statements are presented here as a bullet list. Alternatively, they can be presented as plain text, perhaps with paragraph breaks to aid readability. The control statements are the statement forms of all the questions associated with RTP S2, see Appendix C. ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

77

Appendix B – An example RTP story

Preventing the event 1. The physical security measures for offices, rooms and facilities are applied in accordance with a design of our making. 2. We have well defined physical security boundaries (e.g., fences, walls...). 3. These boundaries are physically sound (i.e., one cannot just bypass them by climbing over, walking through or around). 4. These boundaries are alarmed. 5. Doors, windows, cabinets, service hatches and other possible physical entry points are secured with locks, bolts, bars or other means. 6. Access points to secure areas are protected by physical or electronic locks. 7. Access points to secure areas are guarded. 8. We keep logs (physical or electronic) of who is entering and leaving. 9. Authorised personnel are readily identifiable (e.g., with an ID badge). 10. Where appropriate our secure facilities are unobtrusive, without any obvious indication of their purpose. 11. Rooms are electromagnetically shielded. 12. Delivery areas (e.g., loading bays) are physically isolated from secure areas. 13. We have special instructions for personnel working in secure workplaces (such as what they what they are allowed to bring in and take out), supervision and vacating the areas. 14. Computer screens are locked after a period of inactivity and require user authentication on reactivation. 15. Paper documents, and removeable media are removed from surfaces, such as desks, and away if the area is to become unattended. 16. Online maps and telephone directories, showing the locations of secure facilities and contact details of personnel who work there are protected from unauthorised access. 17. Windows are obscured or otherwise located relative to the room layout so that sensitive information cannot be viewed from outside. 18. We have a landlord that provides building security services for our offices. 19. We have the means to determine and manage the information security risks associated with the use of suppliers. 20. We have documented our requirements for managing the information security risks associated with the use of suppliers. 21. All relevant information security requirements are defined in our supplier agreements.

Detecting the event 1. Entry points are alarmed. 2. Rooms are alarmed (e.g., with motion detectors). 3. Entry points and secure areas are monitored using CCTV, or similar.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

78

Appendix B – An example RTP story

4. Secure areas are patrolled or otherwise guarded by security personnel. 5. These intruder detection systems are regularly tested and maintained in good order.

Reacting to the consequences Undesirable disclosure of information 1. When required by our access control rules, authentication is required first. 2. We have rules for the secure configuration and handling of endpoint devices, whether those devices belong to our organisation or not (e.g., BYOD or hotel/Internet cafe equipment). 3. Wireless endpoint connections are encrypted (e.g., by using a VPN particularly when secure wireless connections are unavailable). 4. Authentication techniques are used to verify the claimed identity of users and other entities. 5. We have the means to ensure that quality passwords are used, and enforce changes as needed. 6. We have a process for the allocation, management and protection of authentication information. 7. Personnel are advised on the appropriate handling of authentication information. 8. We encrypt data stored on media to prevent unauthorised access to such information.

Inability to carry out some or all of one’s business 1. We have and apply a policy for backing up information and verifying that the backed-up information can be successfully restored. 2. We ensure that inadvertent data loss is detected before backups are taken. 3. We restore the appropriate backup(s) to recover all essential information and software following a disaster or media failure.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

79

Appendix C – Control questions The following table lists all the control questions and shows their association with the RTPs (event and whether the control is preventive (P), detective (D) or reactive (R), and the consequences (confidentiality (C), integrity (I) and availability (A)), the reference control identifier, and whether the question is associated with an ISO/IEC 27001 Annex A control. If it is, the Annex A column cites the corresponding Annex A control identifier. An asterisk (*) means that it should be declared as a variant (see Chapter 1 (Custom controls, obviations, and variants)) in the SOA. The reference control identifiers can be used in the SOA to identify the controls. #

Question

Annex A Event(s) Type CIA Id

Questions relating to organisational controls

1

Do you have a top management approved “information security policy” that defines the rules for managing information security?

A.5.1.1*

S8, S12

P

CIA O(01)

2

Is this policy reviewed and kept up-to-date?

A.5.1.2*

S8, S12

P

CIA O(02)

3

Are all information security related personnel responsibilities defined and understood?

A.6.1.1

S8

P

CIA O(03)

4

Are roles and responsibilities defined and allocated such that it is not possible for a single individual to breach information security policy without the assistance of another individual?

A.6.1.2*

S8

P

CIA O(04)

5

Does management require all personnel to comply with the organisation’s information security policy, rules, and procedures?

A.7.2.1*

S8

P

CIA O(05)

6

Is management demonstrably committed to its information security policy?

–

S8

P

CIA O(06)

7

Do you have the contact details for the police, other emergency services, the Data Protection Commissioner, and relevant regulatory bodies to hand, ready to use when necessary?

A.6.1.3*

S1, S8, S9, S11

R

CI

8

Does your organisation subscribe to information security forums and/or professional associations A.6.1.4* for up-to-date security information, advice, threats, advisories etc.?

S8

P

CIA O(08)

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

O(07)

80

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

9

Do you have a process or procedure for collecting and analysing information about existing or emerging threats?

–

S3, S8, S9

P

CIA O(09)

10

Do you include information about existing or emerging threats as in your information security risk management processes?

–

S3, S8, S9

P

CIA O(09)

11

Do you determine the applicable information security requirements and specify them as part of a A.6.1.5* project’s requirements specification?

S4

P

CIA O(10)

12

Are information security requirements included in your requirements for new information systems and enhancements to existing systems?

A.14.1.1* S4

P

CIA O(11)

13

Are information security risks addressed as part of your organisation’s project management, regardless of the project discipline or application area?

A.14.1.1* S4

P

CIA O(11)

14

Do you maintain an inventory of assets (information processing facilities, buildings, physical security devices, etc.) and the information they contain?

A.8.1.1*

S1

P

CIA O(12)

15

Are all assets in the inventory assigned to an owner or custodian?

A.8.1.2*

S1

P

CIA O(13)

16

Do you perform asset musters to confirm that all assets listed in the inventories are present and correct, and that there are no – relevant organisational assets that are not included in the inventory?

S1

D

CIA O(14)

17

Do you have rules and/or procedures for the acceptable A.8.1.3* use of information and associated assets?

S8, S11

P

CIA O(15)

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

81

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

18

Do your procedures for handling assets accord with your classification scheme for information?

A.8.2.3*

19

Do you ensure that equipment, information, and software is not taken off site without approval?

20

When people leave the organisation, are they required to return all previously issued physical and electronic assets?

A.8.1.4*

S11

P

CIA O(16)

A.11.2.5* S1

P

CIA O(17)

S8

P

CIA O(18)

21

When people leave the organisation and have been using their own ICT for the organisation’s business, are they – required to transfer such information to the organisation and securely delete it from their ICT?

S8

P

CIA O(19)

22

Do you have and use a classification scheme for information?

A.8.2.1*

S11

P

CIA O(20)

23

Does the scheme give instructions on how to store, transmit, process, share and otherwise handle information of different classifications?

–

S11

P

CIA O(21)

24

Does the scheme cover confidentiality, integrity and availability of information?

–

S11

P

CIA O(21)

25

Does the scheme give instruction on how to determine the classification of information from the information itself?

–

S11

P

CIA O(21)

26

Do you have procedures for labelling information in accordance with your classification scheme?

A.8.2.2*

S11

P

CIA O(22)

27

Do you physically (electronically) label information (e.g., print (display) a heading bearing the classification at the top and bottom of each page (screen)?

–

S11

P

CIA O(23)

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

82

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

28

If not, is information labelled by virtue of where it is stored?

–

S11

P

CIA O(23)

29

Do you have rules for protecting information in transit, irrespective of the destination and mode of transmission?

A.13.2.1* S11

P

CIA O(24)

30

Do your agreements with external parties comply with your rules for A.13.2.2* S11 protecting information in transit?

P

CIA O(25)

31

Do your rules for protecting information in transit include electronic messaging?

A.13.2.3* S11

P

CIA O(26)

32

Are the access control rules based on business and information security requirements?

A.9.1.1*

S9

P

CIA O(27)

33

Are the access control rules reviewed from time to time?

A.9.1.1*

S9

P

CIA O(27)

34

Are users only provided with access to the network and network services in accordance with your access control rules?

A.9.1.2

S8, S9, S11

P

CIA O(28)

35

Are there rules for controlling access to information and associated assets?

–

S8, S9, S11

P

CIA O(29)

36

Are access rights assigned and de-assigned using a formal registration and re-registration process?

A.9.2.1*

S8

P

CIA O(30)

37

Do you have a means to manage the identities of people and nonhuman entities, including creation, changing and deletion?

–

S8

P

CIA O(31)

38

Is the authentication allocation process a formal process?

A.9.2.4*

S9, S11

P

CIA O(32)

39

Are personnel advised on the appropriate handling of authentication information?

A.9.3.1*

S1, S2, S9, S11

PR

CIA O(33)

40

Do you have the means to ensure that quality passwords are used, A.9.4.3* and enforce changes as needed?

S1, S2, S3, S9

PR

CIA O(34)

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

83

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

41

Do you have a process for the allocation, management, and protection of authentication information?

–

S1, S2, S9, S11

PR

CIA O(35)

42

Is your access provisioning process a formal process?

A.9.2.2*

S8

P

CIA O(36)

43

Are users’ access rights reviewed by the owners/custodians of the A.9.2.5* information and associated assets involved?

S8

P

CIA O(37)

44

Are access rights removed upon termination of the user’s engagement, or adjusted upon change?

S8

P

CIA O(38)

45

Do you have a means to grant, review, modify and revoke access – rights to information and associated assets?

S8

P

CIA O(39)

46

Have you documented your requirements for managing the information security risks associated with the use of suppliers?

A.15.1.1

S2, S6, S12

P

CIA O(40)

47

Do you have the means to determine and manage the information security risks associated with the use of suppliers?

–

S2, S6, S12

P

CIA O(41)

48

Are all relevant information security requirements defined in your agreements with suppliers?

A.15.1.2*

S2, S6, S12

P

CIA O(42)

49

Do you supplier agreements cover information security in the ICT supply chain?

A.15.1.3* S12

P

CIA O(43)

50

Do you regularly monitor, review, and evaluate and manage the delivery of information security relevant supplier services and adjust the contractual terms accordingly?

A.15.2.1* S12

D

CIA O(44)

51

Do you audit supplier service delivery?

A.15.2.1* S12

D

CIA O(44)

A.9.2.6*

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

84

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

52

Do the changes to service provision take account of the criticality of the business information, systems and processes involved and reassessment of risks?

A.15.2.2* S12

D

CIA O(45)

53

Do you have a plan and the means for managing the information security aspects of the acquisition, use and exit from cloud services?

–

P

CIA O(46)

54

Have you assigned roles and responsibilities for dealing with information security incidents?

A.16.1.1* S3

D

CIA O(47)

55

Does everyone who should become involved in dealing with an information security incident know what to do?

–

S3

D

CIA O(48)

56

Do you have the means to classify events as incidents and prioritise them for action?

A.16.1.4*

S1, S3, S8

DR

CIA O(49)

57

Do you have an incident handling A.16.1.5* S1, S3 procedure?

R

CA

O(50)

58

Does the procedure give instructions on how to contain the situation; communicate with – relevant interested parties; remedy the situation; and formally close the incident?

S1, S3

R

CA

O(51)

59

Are you able to conduct information security forensics analysis if necessary?

–

S1, S3

R

CA

O(51)

60

Do you apply the lessons learnt to reduce the likelihood of recurrence of similar incidents?

A.16.1.6* S3, S8

R

IA

O(52)

61

Do you conduct a review of the incident and how it was dealt – with, and determine how it can be prevented or better dealt with?

R

IA

O(53)

S7, S9

S3, S8

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

85

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

62

Do you have a procedure for collecting evidence and ensuring that it is complete and has not been tampered with; any copies A.16.1.7* S8 are provably identical to the originals; and any ICT from which evidence was gathered was operating correctly at the time?

R

I

63

Has your organisation determined its requirements for information A.17.1.1* S3 security and the continuity of information security management in adverse situations?

P

CIA O(55)

64

In response to a disruption of normal working, are you able to preserve information security during the transition to abnormal working and resumption of normal working?

A.17.1.2* S3

R

A

O(56)

65

Do you test your disruption response and resumption plans?

A.17.1.3* S3

R

A

O(57)

66

Do you engage in other useful work until power is resumed?

–

S6

R

A

O(58)

67

Do you have sufficient resources to permit the organisation to continue its business whilst the necessary personnel are dealing with the breach, legal proceedings etc.?

–

S12

R

A

O(59)

68

Have the ICT continuity requirements been determined, for example as the outcome of a – business impact analysis as explained in ISO 22301 (business continuity)?

S3

P

CIA O(60)

69

Does your determination of ICT continuity requirements consider the options for before, during and after disruption?

S3

P

CIA O(60)

–

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

O(54)

86

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

Are your ICT continuity plans designed to facilitate the resumption of disrupted activities at a specified minimum acceptable capacity within a time frame beyond which resumption would become unacceptable? 70

Note: these time frames are sometimes referred to respectively as (a) the recovery time objective (RTO) and (b) the maximum tolerable period of disruption (MTPD), see ISO 22301). The RTO hold not exceed the MTPD.

–

S3

P

CIA O(60)

71

Are these interested party requirements explicitly identified, documented and kept up to date for the organisation and each information system?

A.18.1.1* S12

P

CIA O(61)

72

Have you identified the sources of all interested party information security requirements, including legal, statutory, regulatory, and contractual obligations and requirements?

A.18.1.1* S12

P

CIA O(61)

Note: Whilst requirements from A.18.1.1* S12 legal and contractual sources should be fulfilled, the requirements of interested parties that pose a threat to the organisation, such as hackers, should be countered.

P

CIA O(61)

P

CIA O(62)

Have their information security requirements been considered during the determination of your necessary information security controls? 73

74

Does your use of cryptographic controls comply with all relevant legislation, regulations, and agreements?

75

Do you have information security controls to protect your own A.18.1.2* S4, S12 intellectual property and the intellectual property of others that you use or have access to?

P

CIA O(63)

76

Is all the software that you use properly licensed?

P

CIA O(64)

A.18.1.5

–

S12

S4

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

87

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

77

Do you have information security controls to preserve the confidentiality, integrity and availability of documented information that you are required to retain for legal and contractual reasons?

A.18.1.3* S12

P

CIA O(65)

78

Does your ISMS conform to the principles laid down in data protection legislation?

A.18.1.4* S12

P

CIA O(66)

79

Do you have information security controls to preserve the confidentiality, integrity and – availability of personally identifiable information (PII) within the scope of your ISMS?

P

CIA O(67)

A.18.2.1* S9

P

CIA O(68)

81

Is the fulfilment of the requirements of your information security policies audited or otherwise reviewed by management?

A.18.2.2* S4, S8

PD

CIA O(69)

82

Do you regularly audit or review your information systems for compliance with your organisation’s information security policies and standards?

A.18.2.3

S4

P

CIA O(70)

83

Are documented operating procedures made available to all users that need them?

A.12.1.1

S8

P

CIA O(71)

S12

Is your approach to managing information security subject to independent review at planned intervals or when significant charges are proposed or occur? 80

Note: independence can be demonstrated by the freedom of bias and conflict of interest in the outcome of the review, or by freedom of responsibility for information security design.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

88

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

84

Do you have documented information for processes and procedures that: a. must be performed in the same way by several people – b. are performed rarely c. are new, or complex, and present a risk if performed incorrectly?

S8

P

CIA O(72)

S1

R

C

Questions relating to people controls 85

Are you able to remotely delete the content of mobile devices?

86

Are background checks performed on all personnel prior to their engagement, A.7.1.1* commensurate with the sensitivity of the information that they will have access to?

S8

P

CIA P(02)

87

Do personal have documented terms and conditions of engagement that advise them of their information security A.7.1.2* responsibilities and obligate them to comply with the organisation’s information security policy?

S8

P

CIA P(03)

88

Do you have an information security training, education and awareness programme, or equivalent means to maintain personnel awareness of information security, relevant policies and controls?

A.7.2.2*

S8, S11

P

CIA P(04)

89

Do you have the means to discipline personnel for breaches of information security and infringement of policy?

A.7.2.3*

S8

P

CIA P(05)

90

Is there a process for the handover of information security responsibilities when the engagement of personnel ceases or otherwise changes?

A.7.3.1*

S8

P

CIA P(06)

91

Do you regularly review your nondisclosure agreements to ensure A.13.2.4* S8, S11 that they continue to reflect your organisation’s needs?

P

CIA P(07)

–

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

P(01)

89

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

92

Are personnel and relevant interested parties required to enter into appropriate nondisclosure agreements with the organisation?

–

S8, S11

P

CIA P(08)

93

Do you have policies and procedures that specify the conditions and restrictions necessary for secure remote working?

A.6.2.2*

S1, S3

PR

CIA P(09)

94

Do you report security breaches to the relevant authorities and – interested parties as appropriate?

95

Are personnel and users made aware of the importance of the reporting information security events and incidents, and how to do that in a timely manner?

S1, S3, A.16.1.2* S4, S8, S11

D

CIA P(11)

96

Are personnel and users required to report any observed or suspected information security A.16.1.3* S4, S8 weaknesses in systems or services?

D

CIA P(12)

S11, S12 R

C

P(10)

Questions relating to physical controls

97

Do you have well defined physical security boundaries (e.g., fences, walls...)?

A.11.1.1* S2

P

CIA Ph(01)

98

Are these boundaries physically sound (i.e. one cannot just bypass them by climbing over, walking through or around)?

–

S2

P

CIA Ph(02)

99

Are these boundaries alarmed?

–

S2

P

CIA Ph(02)

Do you have a landlord or other organisation that provides – 100 building security services for your offices?

S2

P

CIA Ph(03)

Are access points to secure 101 areas protected by physical or electronic locks?

A.11.1.2* S2

P

CIA Ph(04)

Are delivery areas (e.g., loading 102 bays) physically isolated from secure areas?

A.11.1.6* S2

P

CIA Ph(05)

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

90

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

Are authorised personnel readily 103 identifiable (e.g., with an ID badge)?

–

S2

P

CIA Ph(06)

Do you keep logs (physical or 104 electronic) of who is entering and leaving?

–

S2

P

CIA Ph(06)

Are access points to secure areas guarded?

–

S2

P

CIA Ph(06)

Are the physical security measures for offices, rooms and 106 facilities applied in accordance with a design?

A.11.1.3* S2

P

CIA Ph(07)

Are windows obscured or otherwise located relative to the 107 room layout so that sensitive information cannot be viewed from outside?

–

S2

P

CIA Ph(08)

Are online maps and telephone directories, showing the locations of secure facilities and contact 108 details of personnel who work there protected from unauthorised access?

–

S2

P

CIA Ph(08)

Where appropriate are secure facilities unobtrusive without any 109 obvious indication of their purpose?

–

S2

P

CIA Ph(08)

–

S2

P

CIA Ph(08)

–

S2

P

CIA Ph(09)

105

Are rooms electromagnetically shielded? Note: Sometimes referred to as TEMPEST shielding, such controls should be reserved for protecting information of the very 110 highest classifications, such as information for which disclosure would result in grave consequences to a nation. In such cases, all cable ingress/egress must be similarly protected. Are doors, windows, cabinets, service hatches and other 111 possible physical entry points secured with locks, bolts, bars or other means?

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

91

Appendix C – Control questions

#

Question

112 Are these entry points alarmed?

Annex A Event(s) Type CIA Id –

S2

D

CIA Ph(09)

–

S2

D

CIA Ph(09)

Are entry points and secure areas 114 monitored using CCTV, or – similar?

S2

D

CIA Ph(09)

Are secure areas patrolled or 115 otherwise guarded by security personnel?

–

S2

D

CIA Ph(09)

Are these intruder detection 116 systems regularly tested and maintained in good order?

–

S2

D

CIA Ph(09)

Is the supply of power and a proper ICT environment in your 117 data centre the responsibility of your data centre supplier?

–

S6

P

CIA Ph(10)

Are your physical security measures for protection in the event of natural disasters, 118 accidents and malicious attacks applied in accordance with a design?

A.11.1.4* S3, S6

P

CIA Ph(11)

Do you perform explosive and weapons checks on people who 119 wish to enter buildings and secure areas?

–

S3, S6

P

CIA Ph(12)

Do you have fire detection systems, and where appropriate 120 fire suppression systems in place?

–

S3, S6

P

CIA Ph(12)

Is your ICT protected from electrical surges?

–

S3, S6

P

CIA Ph(12)

122 Note: Water ingress can be from – internal plumbing systems as well as external sources such as overflowing rivers.

S3, S6

P

CIA Ph(12)

113

121

Are rooms alarmed (e.g., with motion detectors)?

Do you have flood detection systems in place and appropriate flood defensive systems to hand?

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

92

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

Do you have special instructions for personnel working in secure workplaces, such as what they 123 may bring in and take out, supervision and vacating the area?

A.11.1.5* S2

Are computer screens locked after a period of inactivity and 124 require user authentication on reactivation?

A.11.2.9*

Are paper documents, and removeable media removed from 125 surfaces, such as desks, and away if the area is to become unattended?

P

CIA Ph(13)

S2, S3, S11

P

CIA Ph(14)

A.11.2.9* S2, S11

P

CIA Ph(14)

A.11.2.1* S11

P

CIA Ph(15)

Are there controls in place to ensure that ICT is operated within 127 A.11.2.1* S5 its specified temperature and humidity ranges?

P

CIA Ph(15)

Are there controls in place to protect ICT from dust, vibration, spillages, electrical and magnetic 128 A.11.2.1* S5 interference and other sources of risk that could result in equipment failure?

P

CIA Ph(15)

Do you have rules for the secure use of ICT offsite, whether that 129 ICT belongs to the organisation or not (e.g., BYOD or hotel/Internet cafe equipment)?

A.11.2.6* S1

P

CIA Ph(16)

Are the rules for handling 130 removable media consistent with your classification scheme?

A.8.3.1*

S1, S11

P

CIA Ph(17)

Are the rules for secure disposal formal (e.g., documented) rules?

A.8.3.2*

S11

P

CIA Ph(18)

126

131

Are computer screens sited or otherwise protected, so that they cannot be viewed by unauthorised people whilst in use? Note: Unauthorised people could be in another building and view the screen with a telescope or be close by and peer over the user’s shoulder

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

93

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

Is media protected against 132 unauthorised access, corruption and misuse whilst in transit?

A.8.3.3

S1

P

CIA Ph(19)

Do you have rules for the secure use, reuse and disposal of 133 removable media (e.g., USB sticks, memory cards, portable disc drives)?

–

S1, S11

P

CIA Ph(20)

S7

D

CIA Ph(21)

A.11.2.2* S6

D

CIA Ph(22)

D

CIA Ph(23)

A.11.2.3* S11

P

CIA Ph(24)

–

S5

D

CIA Ph(25)

Do you run diagnostics (or ask an 139 engineer) to determine the source – of the fault?

S5

D

CIA Ph(25)

A.11.2.4* S5

P

CIA Ph(26)

When disposing of equipment, do you ensure that any sensitive 141 data and licensed software has A.11.2.7* S1 been removed or securely overwritten?

P

CIA Ph(27)

134

Do you receive notifications when – the Internet is not available?

Is your ICT protected from utility failure (e.g., power, 135 telecommunications, water supply, gas, sewage, ventilation and air conditioning)?

Do you use uninterruptable power supplies (UPS) for controlled shut 136 – down of ICT following a power failure?

S6

Are your power and data cables protected from interference, interception and damage? Note: power cables are 137 sometimes used to transmit data. Sometimes it is necessary to maintain data separation when they are transmitted along the same cable, e.g., by using encryption. 138

Do you attempt a safe-mode start?

Do you maintain ICT equipment in accordance with the 140 manufacturer’s recommendations?

Questions relating to technological controls ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

94

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

Do you have rules for the secure configuration and handling of endpoint devices, whether those 142 A.6.2.1* devices belong to the organisation or not (e.g., BYOD or hotel/Internet cafe equipment)? Are users instructed to ensure 143 that unattended equipment is appropriately protected?

S1, S2, S9

PR

CIA T(01)

A.11.2.8* S1

P

CIA T(02)

–

S1, S11

PR

CIA T(03)

–

S1, S2, S9

PR

CIA T(03)

Is remote access software configured to prevent copy and paste, and downloading of data? 144 Note: In this case, sensitive (held on servers) can be accessed via endpoint devices, but not stored on them, or copied and sent anywhere. Are wireless endpoint connections encrypted (e.g., by 145 using a VPN particularly when secure wireless connections are unavailable)? 146

Are privileged access rights restricted and controlled?

A.9.2.3*

S8

P

CIA T(04)

147

Are access rights allocated on a least privilege basis?

–

S8

P

CIA T(05)

Is access to information and associated assets granted in 148 accordance with the organisation’s access control policy?

A.9.4.1

S8

P

CIA T(06)

Is access to software design and testing documentation, source 149 code and development tools strictly controlled?

A.9.4.5*

S4

P

CIA T(07)

When required by your access 150 control rules, is authentication required first?

A.9.4.2*

S1, S2, S3, S8, S9

PR

CIA T(08)

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

95

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

Are authentication techniques used to verify the claimed identity of users and other entities? 151 Note: Authentication techniques include passwords, biometrics, smart cards, digital certificates, and other cryptographic techniques. Do you terminate inactive 152 sessions after a defined period of inactivity?

–

S1, S2, S8, S9

PR

CIA T(09)

–

S9

P

CIA T(09)

D

CIA T(10)

P

CIA T(11)

P

CIA T(11)

Are the capacities of available ICT resources (e.g., CPU memory, disc memory, bandwidth, …) monitored and action taken to ensure that the unavailability of resources does not result in the unavailability of information? Note 1: If ICT is provided by a third party, e.g., a cloud service provider, that third party should perform the capacity management. There are cloud 153 services that facilitate rapid ondemand resource expansion and contraction.

A.12.1.3* S4, S10

Note 2: Capacity monitoring does not have to be performed in real time. Required capacities can be determined in advance and acquired in excess. The greater the excess, the greater the safety margin. With large margins, monitoring can be periodic. Excessive margins, however, can be wasteful. Are users made aware of phishing scams and other social 154 engineering techniques that could A.12.2.1* S9 defeat your technological antimalware measures? Is your ICT protected against the introduction of malware? Note: Whilst malware protection 155 is primarily technological, the technology should be used in conjunction with appropriate user training (e.g., to resist phishing scams).

A.12.2.1* S9

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

96

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

Do you take timely and appropriate action in response to receiving information concerning technical vulnerabilities in the ICT that you are using?

S4, S9, 156 Note: Notifications and actions A.12.6.1* P S10, S11 can be automated, as in the case of software patches and security updates, or from security advisory notices, which often require manual ICT administrator action. Do you use vulnerability scanners 157 to detect vulnerabilities in web – applications?

CIA T(12)

S9

P

CIA T(13)

–

S9

P

CIA T(13)

–

S4

P

CIA T(14)

Do you have retention limits for certain information (e.g., 160 organisational records and PII) and delete the information as it attains its retention limit?

–

S11

P

CIA T(15)

Do you maintain documented 161 information on the configurations that you use?

–

S11

P

CIA T(15)

–

S11

P

CIA T(16)

158

Do you conduct penetration tests? Do you configure your ICT to obviate vulnerabilities such as default passwords and guest accounts?

159

Note 1: This process is sometimes referred to as “hardening”. Note 2: Vendors often publish instructions and guidance on how to do this.

Do you use data masking techniques for certain types of information (e.g., PII)? 162 Note: Data masking techniques include pseudonymisation, anonymisation, encryption, redaction, …

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

97

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

Do you monitor communications channels for anomalous traffic (e.g., transmission of data to unexpected destinations)? 163 Note: Such anomalous traffic can – indicate that your ICT has become part of a botnet, or that a malware script is skimming off sensitive information and disclosing to an attacker.

S11

D

CIA T(17)

Are messages and attachments quarantined before exporting and cross checked to ensure that they 164 – do not contain information that should not be disclosed to the recipient(s)?

S11

D

CIA T(17)

Are digital rights management techniques used to protect the intellectual property rights in 165 information (e.g., photographic images) that can legitimately enter the public domain?

–

S11, S12 P

CIA T(18)

Do you have and apply a policy for backing up information and 166 verifying that the backed-up information can be successfully restored?

S1, S2, A.12.3.1* S3, S4, S5, S9

R

IA

T(19)

Do you ensure that inadvertent 167 data loss is detected before backups are taken?

–

S1, S2, S3, S4, S5, S9

R

IA

T(20)

Do you restore the appropriate backup(s) to recover all essential 168 information and software following a disaster or media failure?

–

S1, S2, S3, S4, S5, S9

R

IA

T(20)

Do your information processing facilities have sufficient 169 redundancy to meet availability requirements?

A.17.2.1

S5, S7, S10

R

A

T(21)

S5, S7, S10

R

A

T(22)

Do you have two or more internet providers and are able to switch 170 between them to maintain – connectivity if one suffers an outage?

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

98

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

Do you have two or more data centres (or cloud service 171 providers) and are able to switch – between them to maintain service if one suffers an outage? 172

Do you use mirrored discs (e.g., RAID 1)?

Do you use mirrored networks or otherwise have redundancy built 173 into your networks, with automatic fail-over and load balancing as appropriate?

S5, S7, S10

R

A

T(22)

–

S5

R

A

T(22)

–

S5, S10

R

A

T(22)

S8, S9

D

CIA T(23)

A.12.4.2* S8, S9

D

CIA T(24)

A.12.4.3* S8, S9

D

CIA T(25)

–

D

CIA T(26)

Do you keep and analyse logs of ICT activity, anomalies, faults and 174 A.12.4.1 other events that may be information security relevant? 175

Do you protect your logs from tampering?

Do your logs include system 176 administrator and system operator activities? Do you monitor networks, systems and applications for anomalous behaviour and take 177 appropriate action as necessary?

S8, S9

Note: Monitoring should always be within applicable laws and regulations. Are all your ICT clocks 178 synchronised to the same time source?

A.12.4.4* S8

R

I

Do you control the use of software that facilitates direct modification of system level data 179 (e.g., operating system registries and database tables) that could result in a breach of the information security policy?

A.9.4.4*

S4

P

CIA T(28)

Is there a procedure for the 180 control of software installation on operational systems?

A.12.5.1

S4

P

CIA T(29)

A.12.6.2* S4

P

CIA T(30)

181

Do you have a software installation policy?

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

T(27)

99

Appendix C – Control questions

#

Question

Is software installed, upgraded, 182 updated, and patched only by authorised personnel?

Annex A Event(s) Type CIA Id

–

S4

P

CIA T(31)

Do you notify users, who can be external to your organisation, e.g., customers, when 183 vulnerabilities in the software and – services that you supply, and advise them on what precautions they should then take?

S9

P

CIA T(32)

A.13.1.1* S9

P

CIA T(33)

Do you manage and control networks to protect the 184 information that resides within its internal applications and systems?

Do you protect the integrity and confidentiality of information passing over public networks and 185 – over wireless networks, e.g., by using VPNs, secure protocols such as SSL, and suchlike?

S3, S9

PR

CIA T(34)

Do you control inter-network – connectivity, e.g., using firewalls?

S3, S9

PR

CIA T(34)

P

CIA T(35)

186

Do you have service level agreements, whether provided in187 house or outsourced, that specify A.13.1.2* S9 your security and management requirements?

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

100

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

Are you satisfied with the security provided by the network service providers that you use?

188

Note 1: To be satisfied, you should know what the network service providers’ security measures are, have evidence that they are in place and working and that they are either adequate for your needs or you have mitigating controls in place.

–

S9

P

CIA T(36)

Do you control which internet 189 sites and IP addresses personnel – may access?

S9

P

CIA T(37)

A.13.1.3* S9

P

CIA T(38)

A.10.1.1* S1

R

C

Note 2: In some cases you are able to specify what the security measures are, but other cases you must accept what the provider has to offer on a take it or leave it basis. In the former case you might have negotiated a right of audit, in the latter case you might rely on third party attestations, e.g., an ISO/IEC 27001 certification.

Do you partition your networks into small domains and thereby 190 provide separation of services, systems and users? Do you apply rules that you have defined for the use of cryptography? Note: Whilst such rules can 191 specify which algorithms to use, they can just simply govern the use of whatever comes with the software products and services that you use. Do your rules cover the 192 management of cryptographic keys?

A.10.1.2*

S1, S11, S12

PR

CIA T(40)

–

S1, S2, S3, S11, S12

PR

CIA T(41)

Do you encrypt data stored on media to prevent unauthorised access to such information? 193 Note: Although often referred to as hard disc encryption, both fixed and removable media can be encrypted

T(39)

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

101

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

Do you ensure that software and systems that you commission or develop internally are designed and implemented within a secure development environment? 194 Note: A secure development A.14.2.1* S4 environment implies, amongst other things, that the integrity of the designs, source code and test data is assured and the developers are security savvy.

P

CIA T(42)

P

CIA T(43)

S11

P

CIA T(44)

Is the information involved in application transactions protected against unauthorised replay, A.14.1.3* S11 197 duplication, disclosure and alteration, mis-routing and incomplete transmission?

P

CIA T(45)

Do your bespoke applications 198 adhere to the OWASP guidelines?

Does your secure development 195 environment cover the entire system development lifecycle?

A.14.2.6* S4

Is the information involved in application services that passes over public networks protected A.14.1.2 196 from unauthorised disclosure, modification, non-repudiation and fraudulent activity?

–

S4

P

CIA T(46)

–

S11

P

CIA T(46)

Do you determine your security requirements when developing or acquiring application software? 199 Note: Even when buying off-theshelf, one should at least confirm that the security afforded by the product is satisfactory within the context that it is to be used. 200

Do your bespoke applications validate their outputs?

–

S4

P

CIA T(46)

201

Do your bespoke applications validate their inputs?

–

S4

P

CIA T(46)

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

102

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

Do you establish and use security architecture and engineering principles in your information security system development activities? 202

Note 1: There is published guidance on such principles.

A.14.2.5* S4

P

CIA T(47)

–

S4

P

CIA T(48)

During development and system acceptance do you run tests explicitly to determine that 204 security features behave as intended do not do anything they are not supposed to do?

A.14.2.8* S4

P

CIA T(49)

Do you have programs and 205 criteria for acceptance testing of new systems and upgrades?

A.14.2.9* S4

P

CIA T(50)

Do you monitor and supervise 206 outsourced system development activities?

A.14.2.7* S4

P

CIA T(51)

P

CIA T(52)

Note 2: A secure architectural objective is to ensure that security controls cannot be bypassed, deactivated, corrupted or otherwise circumvented. Do you develop software in accordance with security coding 203 principles? Note: The OWASP guidelines are an example of such principles.

When outsourcing software development, do you ensure that the development processes used by your supplier (and others in the supply chain) are commensurate or superior to your – 207 own?

S4

Note: Outsourcing implies that the function outsourced is a function that would normally be provided internally by your organisation.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

103

Appendix C – Control questions

#

Question

Annex A Event(s) Type CIA Id

Do you enforce separation between development, testing and production environments? Note 1: Separation can be 208 physical or virtual.

A.12.1.4* S4

P

CIA T(53)

Do you use a systematic approach to controlling changes 209 to information systems and processing facilities that can affect security?

A.12.1.2

S4

P

CIA T(54)

Does your approach cover 210 changes to systems throughout the development lifecycle?

A.14.2.2* S4

P

CIA T(55)

When operating platforms are changed, do you ensure (e.g., by review and testing) that the 211 operation and security of critical business systems are not adversely affected?

A.14.2.3

S4

P

CIA T(56)

Do you discourage modifications 212 to vendor supplied software packages?

A.14.2.4* S4

P

CIA T(57)

Do you ensure that test information if improperly 213 disclosed does not reveal PII or other sensitive information?

A.14.3.1* S4

P

CIA T(58)

Do you ensure that audits or tests that involve operational systems 214 A.12.7.1* S3 do not compromise live operations?

P

CIA T(59)

Note 2: Whilst this principle is usually applied in a software context, it also applies to firmware and hardware.

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

104

Acronyms

Acronyms BS DoS ICT ISO IEC MS MSS PII RA RT RTP ISMS FoL Sev SOA

British Standard Denial of Service Information and Telecommunications Technology International Standards Organisation International Electrochemical Commission Management System Management System Standard Personally Identifiable Information Risk Assessment Risk Treatment Risk Treatment Plan Information Security Management System Frequency or Likelihood Severity Statement of Applicability

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

105

Compendium of definitions

Compendium of definitions Management system: set of interrelated or interacting elements of an organisation to establish policies and objectives and processes to achieve those objectives (source ISO Directives, Part 1, Annex SL) Control: measure that maintains and/or modifies risk (source ISO 31000) Risk: effect of uncertainty on objectives (source ISO 31000) Documented information: information required to be controlled and maintained by an organisation and the medium on which it is contained (source ISO Directives, Part 1, Annex SL) Statement of Applicability: documented information containing (a) the necessary controls; (b) justification for their inclusion; (c) whether the necessary controls are implemented or not; and (d) the justification for excluding any ISO/IEC 27001, Annex A control (source ISO/IEC 27001, Clause 6.1.3 d))

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

106

Bibliography

Bibliography Standards publications ISO/IEC Directives, Part 1, Consolidated ISO Supplement, 2020

ISO 22301:2019, Societal security — Business continuity management systems — Requirements

ISO 31000:2018, Risk management — Principles and guidelines

ISO/IEC 27000: 2020, Information technology—Security techniques— Information security management systems—Overview and vocabulary

ISO/IEC 27001:2013, Information technology — Security techniques — Information security management systems — Requirements

ISO/IEC 27002:2013, Information technology — Security techniques — Code of practice for information security controls

ISO/IEC 27005:2018, Information technology — Security techniques — Information security risk management

ISO/IEC 27007:2017, Information technology — Security techniques — Guidelines for information security management systems auditing

ISO/IEC 27010:2015, Information technology — Security techniques — Information security management for inter-sector and inter-organizational communications

ISO/IEC 27017:2015, Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud computing services

ISO/IEC 27018:2014, Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors ISO/IEC 27019:2017, Information security controls for the energy utility industry

ISO/IEC 27701:2019, Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management — Requirements and guidelines

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

107

Bibliography

Other publications [DBB01] Brewer, DFC An introduction to ISO/IEC 27001:2013, Amazon ISBN-10 1704570824 ISBN-13 978-1704570822 [TIME 2004] Brewer, DFC and List, W (2004) Measuring the effectiveness of an internal control system, Gamma Secure Systems Limited, Wm. List & Co., http://www.gammassl.co.uk/research/time040317.pdf [EIMS 2005] Brewer, DFC, Nash, MJ Nash and List, W (2005) Exploiting an Integrated Management System, Gamma Secure Systems Limited, Wm. List & Co., http://www.gammassl.co.uk/research/MSExploitation.pdf

[Dyn 2016] https://en.wikipedia.org/wiki/2016_Dyn_cyberattack

ISO/IEC 27001:2013 – Mastering Risk Assessment and the Statement of Applicability

108

About the author Dr David Brewer was one of the first consultants to advise the British Government on information security matters, helping to establish the first ever computer security evaluation facilities and evaluation criteria. He was a founder member of the Department of Trade and Industry’s Commercial Computer Security Centre (19871992) and became co-author of the European IT Security Evaluation Criteria (the forerunner of ISO/IEC 15408) and its associated evaluation manual. He was coauthor of the original ISMS standard, BS 7799 Part 2, and Head of the UK delegation to ISO JTC 1 SC27 WG1, which is responsible for the ISO/IEC 27000 family of standards. Recently he was the editor for the revision of ISO/IEC 27004 (Monitoring, measurement, analysis, and evaluation) and a co-author of BS 77993:2017 (Guidelines for information security risk management (revision of BS ISO/IEC 27005:2011)). David has conducted a wide variety of consultancy assignments in information security spanning 38 years in over 23 countries. He is well known for his work in rolling out ISO/IEC 27001 to the whole of the Civil Service in Mauritius (an exemplar of his ISMS implementation methodology), and for his ability to train people to train others. His seminal research papers include: The Chinese Wall Security Policy, published in 1989; and Measuring the Effectiveness of an Internal Control System, published in 2004.