identifier: Interoperable EU Risk Management Framework

publisher: Europeiska unionens cybersäkerhetsbyrå

sprak: en

title: Interoperable EU Risk Management Framework

serie: rapporter

text: D1 | 1.0 - DRAFT | Updated Report, December 2022

type: stycke

text: ABOUT ENISA

type: rubrik

text: The European Union Agency for Cybersecurity, ENISA, is the Union’s agency dedicated to achieving a high common level of cybersecurity across Europe. Established in 2004 and strengthened by the EU Cybersecurity Act, the European Union Agency for Cybersecurity contributes to EU cyber policy, enhances the trustworthiness of ICT products, services and processes with cybersecurity certification schemes, cooperates with Member States and EU bodies, and helps Europe prepare for the cyber challenges of tomorrow. Through knowledge sharing, capacity building and awareness raising, the Agency works together with its key stakeholders to strengthen trust in the connected economy, to boost resilience of the Union’s infrastructure, and, ultimately, to keep Europe’s society and citizens digitally secure. More information about ENISA and its work can be found here: www.enisa.europa.eu. CONTACT To contact the authors, please use CBU@ENISA.EUROPA.EU For media enquiries about this paper, please use PRESS@ENISA.EUROPA.EU AUTHORS Costas Lambrinoudakis, Stefanos Gritzalis, Christos Xenakis, Sokratis Katsikas, Maria Karyda, Aggeliki Tsochou of University of Piraeus Kostas Papadatos, Konstantinos Rantos, Yiannis Pavlosoglou, Stelios Gasparinatos, Anastasios Pantazis of CyberNoesis Alexandros Zacharis of ENISA LEGAL NOTICE Notice must be taken that this publication represents the views and interpretations of ENISA, unless stated otherwise. This publication should not be construed to be a legal action of ENISA or the ENISA bodies unless adopted pursuant to the

text: Regulation (EU) No 2019/881

text: . This publication does not necessarily represent state-of the-art and ENISA may update it from time to time. Third-party sources are quoted as appropriate. ENISA is not responsible for the content of the external sources including external websites referenced in this publication. This publication is intended for information purposes only. It must be accessible free of charge. Neither ENISA nor any person acting on its behalf is responsible for the use that might be made of the information contained in this publication. COPYRIGHT NOTICE © European Union Agency for Cybersecurity (ENISA), 2022 Reproduction is authorised provided the source is acknowledged.

text: INTEROPERABLE EU RISK MANAGEMENT FRAMEWORK

text: Copyright for the image on the cover: © Shutterstock For any use or reproduction of photos or other material that is not under the ENISA copyright, permission must be sought directly from the copyright holders. ISBN 978-92-9204-553-1 DOI:10.2824/07253 Catalogue Nr: TP-01-22-004-EN-N

text: TABLE OF CONTENTS

text: 1. INTRODUCTION 6 1.1 PURPOSE AND SCOPE 6 1.2 DEFINITION OF ACRONYMS 6 2. METHOD OF WORK 7 2.1 FEATURES OF INTEROPERABILITY 7 2.2 INTEROPERABILITY EVALUATION MODEL 10 2.2.1 Methodology and levels of interoperability 10 2.2.2 Scoring model for potential interoperability 11 3. RESULTS 13 3.1 ANALYSIS OF LEVEL OF INTEROPERABILITY FOR EACH RISK MANAGEMENT FRAMEWORK AND FEATURE 13 4. INTEGRATION OF INTEROPERABILITY IN THE RM PROCESSES BASED ON ITSRM2 27 4.1 PROCESS P1 SYSTEM SECURITY CHARACTERISATION 28 4.1.1 Description of process 28 4.2 PROCESSES P2 PRIMARY ASSETS AND P3 SUPPORTING ASSETS 28 4.2.1 Description of processes 28 4.2.2 Recommendations and integration of interoperability features 28 4.3 PROCESS P4 SYSTEM MODELLING 28 4.3.1 Description of process 28 4.3.2 Recommendations and integration of interoperability features 29 4.4 PROCESS P5 RISK IDENTIFICATION 29 4.4.1 Description of process 29 4.4.2 Recommendations and integration of interoperability features 29 4.5 PROCESS P6 RISK ANALYSIS AND EVALUATION 30 4.5.1 Description of process 30 4.5.2 Recommendations and integration of interoperability features 30 4.6 PROCESS P7 RISK TREATMENT 31

text: 4.6.1 Description of process 31 4.6.2 Recommendations and integration of interoperability features 31 5. SYNOPSIS 32 6. UPDATES ON THE PROMINENT RISK MANAGEMENT FRAMEWORKS AND METHODOLOGIES 33 6.1 MONARC 33 6.2 EU ITSRM , IT SECURITY RISK MANAGEMENT METHODOLOGY V1.2 33 6.3 THE AML/CFT NATIONAL RISK ASSESSMENT METHODOLOGY 34 6.4 THE AML/CFT NATIONAL RISK ASSESSMENT METHODOLOGY 34 6.5 CIRCULAR CSSF 20/750 34 6.6 SERIMA 35 6.7 ISO/IEC 27005:2018 35 6.8 NIST SP 800-37 REV. 2 35 6.9 NIST SP 800–30 REV.1 35 6.10NIST SP 800–39 36 6.11BSI STANDARD 200-2 36 6.12OCTAVE-S 36 6.13OCTAVE ALLEGRO 36 6.14OCTAVE FORTE (OCTAVE FOR THE ENTERPRISE) 36 6.15ETSI TS 102 165-1, THREAT VULNERABILITY AND RISK ANALYSIS (TVRA) 36 6.16EBIOS RISK MANAGER (EXPRESSION DES BESOINS ET IDENTIFICATION DES OBJECTIFS DE SECURITE- EXPRESSION OF NEEDS AND IDENTIFICATION OF SECURITY OBJECTIVES) 36 6.17MAGERIT V.3: ANALYSIS AND RISK MANAGEMENT INFORMATION SYSTEMS 36 6.18MEHARI 37 6.19GUIDELINES ON CYBER SECURITY ONBOARD SHIPS 37 7. BIBLIOGRAPHY/REFERENCES 38

text: EXECUTIVE SUMMARY

text: This report is an update of the report “Interoperable EU Risk Management Framework” published by ENISA in January 2022. The “Interoperable EU Risk Management Framework” proposes a methodology for assessing the potential interoperability of risk management (RM) frameworks and methods and presents related results. The methods included in this report have been selected as prominent, based on their interoperability features, after evaluating an extended list of risk management frameworks and methods (included in the Compendium of Risk Management Frameworks with Potential Interoperability, ENISA, January 2002) which has been published as Supplement to the Interoperable EU Risk Management. The “Interoperable EU Risk Management Framework” describes and evaluates the interoperability features for prominent risk management frameworks and methods, by employing a four-level scale to evaluate their interoperability level. The features assessed to evaluate the interoperability level include the approach used by the RM method (i.e. to whether it is assetbased or scenario-based), whether risk assessment is quantitative or qualitative, as well as other characteristics such as the use of asset taxonomies, valuation methods, the cataloguing of threats and vulnerabilities, the method of risk calculation etc. It also provides an overview of possible collaborative combinations between them. The update of “Interoperable EU Risk Management Framework” was based on desktop research and analysis, which resulted in: • Identifying new risk management methods, which were evaluated with regard to their interoperability potential and included in the ““Interoperable EU Risk Management Framework”. These are the following: o SERIMA o CIRCULAR CSSF 20/750 • Updating the features and evaluation of the following RM methods which were already included in the Framework: o MONARC o ITSRM² o THE OPEN GROUP STANDARD, RISK ANALYSIS Finally, no updates were identified for the following: o ISO/IEC 27005:2018 o NIST SP 800-37 o NIST SP 800-30 o NIST SP 800-39 o BSI STANDARD 200-2 o OCTAVE-S o OCTAVE ALLEGRO o OCTAVE FORTE o ETSI TS 102 165-1(TVRA) o EBIOS Risk Manager o MAGERIT v.3 o MEHARI o GUIDELINES ON CYBER SECURITY ONBOARD SHIPS

text: 1. INTRODUCTION

text: 1.1 PURPOSE AND SCOPE This report presents an updated analysis of the interoperability features of prominent RM frameworks and methodologies, as this was initially presented in the Interoperable EU Risk Management Framework published by ΕNISA in January 2022, along with the method followed to determine their interoperability potential. A presentation and brief description of the RM methods is provided in the “Compendium of Risk Management Frameworks” . The updated version of the Interoperable EU Risk Management Framework presented in this report includes a) new RM methods, and b) newer versions of already identified RM frameworks and methods. A detailed evaluation regarding the potential for interoperability of the RM frameworks, based on their features and an evaluation model, is also included. The corresponding results show the potential for forming a coherent RM framework through various possible combinations of the features of the aforementioned frameworks. The detailed analysis of the RM frameworks and methodologies, the methodology used to evaluate them and the results of this process, aim at the provision of a clear outcome in regard to potentially forming a coherent RM framework that could support information risk management in different organisations and sectors across EU. The methodology for evaluating the interoperability potential of different RM methods upon which the Interoperable Framework is based, was the result of meticulous research and analysis carried out by professionals involved in both the academic sector and organisations that engage in RM-related activities and research, informed by the comments, recommendations and insights provided by key stakeholders. The output of this work is a method for evaluating the potential for interoperability of different RM frameworks and tools, along with the results of this evaluation, for a list of prominent RM methods. 1.2 DEFINITION OF ACRONYMS The acronyms used in this document and recurring definitions are listed below.

text: Acronym Definition

text: RM Risk Management

text: MS Member States

text: ITSRM IT Security Risk Management Methodology

text: AB Asset based

text: SB Scenario based

text: QT Quantitative

text: QL Qualitative

text: 2. METHOD OF WORK

text: The methodology for assessing the interoperability of risk management frameworks and methodologies, mainly draws on assessment models. Gilsinn and Schierholz (2010) developed an assessment model for information assurance for a given information technology, which comprises seven features (e.g. access control, resource availability) that are relevant to information assurance. Using those features the assessment model classifies a given technology into four levels of increasing security (i.e. protection against casual or coincidental violation, protection against intentional violation using simple means, protection against intentional violation using sophisticated means, protection against intentional violation using sophisticated means with extended resources). In another example, ENISA (2016) developed an assessment model to assess the readiness of information technology (and specifically privacy-enhancing technologies). The model identifies nine features that are relevant to the quality and readiness of an information technology (i.e., Protection, Trust assumptions, Side effects, Reliability, Performance efficiency, Operability, Maintainability, Transferability and Scope). Each technology receives a grade for each feature using a five-level scale (very poor, poor, satisfactory, good, very good). Depending on the assessment of each feature, the model classifies a given privacy-enhancing technology into one of six levels (Idea, Research, Proof-of-concept, Pilot, Product, Outdated). In this chapter we describe the features that we identified as relevant for the assessment of the interoperability features of risk management frameworks and methodologies. Further, for the functional features we describe a four-level scale to evaluate the interoperability level of each RM framework. Finally, we propose a three-level scale for the potential interoperability for each framework and for combined features. 2.1 FEATURES OF INTEROPERABILITY The risk management area is characterised by a plethora of frameworks, methodologies and methods, each of them with their own characteristics and following their own approach in managing risks. During the risk management lifecycle, practitioners might want to reuse information provided by other methodologies or consider comparing results among frameworks. This typically requires the methodologies to be able to share information and therefore provide capabilities for interoperability. There is no single definition of interoperability in the literature, as this is a generic term that can be applied to many sectors and disciplines. As such, it strongly depends on the context in which it is applied, satisfying its peculiarities and specific demands. In the ICT sector, interoperability is considered as the ability of two or more systems or components to exchange information and to use the information that has been exchanged. ISO/IEC 2382 defines interoperability as the capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units. The IEEE Standard Computer Dictionary also places emphasis on the required effort thus defining interoperability as the ability of a system or a product to work with other systems or products without special effort on the part of the customer. This definition is also adopted by ISO 23903 regarding interoperability in the health sector. The European Interoperability Framework defines interoperability as “the ability of organisations to interact towards mutually beneficial goals, involving the sharing of information and knowledge

text: between these organisations, through the business processes they support, by means of the exchange of data between their ICT systems. Considering the above definitions as well as the structure of management frameworks for cyber risks and the targets of their individual functional characteristics, the interoperability of risk management frameworks and methodologies can be defined as the ability of a risk management component or methods to reuse information provided by the risk management components or methods of other frameworks with equal ease and with the same interfaces, towards the same goals. A risk management framework or methodology should address at least the following phases (ISO 27005, EU ITSRM) which can be considered as its main functional components: • Risk Identification (Assets, Threats and Vulnerabilities) • Risk Assessment (Risk Calculation and Evaluation), • Risk Treatment (Selection and Implementation of Security Controls, and Calculation of Residual Risk), • Risk Monitoring (Assess effectiveness of measures and monitor risks). From the above functional components, Risk Monitoring is a process that, although essential for efficient risk management, is independent of the rest of the phases and can typically be conducted using any assessment methodology, process or tool. As such, it is considered outside the scope of this report which focuses on the other three phases instead, i.e. Risk Identification, Risk Assessment and Risk Treatment. Overall, there are many characteristics (governance, compliance, privacy) that constitute integral parts of risk frameworks but not all of them affect interoperability. Considering the aforementioned definition and the above functional components, we could argue that interoperability in risk management can be achieved if these components can be addressed by the components of other frameworks, with similar effectiveness and ease. This essentially means that interoperability can be achieved at various levels, and we will consider the functional and non-functional characteristics of the evaluated frameworks. As such, regarding the functional characteristics, the interoperability between risk management frameworks can be evaluated against the following levels: Generic aspects, Risk Identification, Risk Assessment and Risk Treatment, which are further analysed to a set of features that typically stem from the above functional components. • Generic aspects: At this aspect we consider some generic features of the frameworks, which are: o Asset based or Scenario based: this indicates whether a risk management framework or methodology adopts an asset-based approach or is guided by a risk scenario. These approaches could be combined. Therefore, our analysis includes frameworks or methodologies that distinctly follow either an assetbased or a scenario-based approach, as well as methodologies that adopt both or a combination of these approaches. o Quantitative or Qualitative: this indicates whether the risk management framework or methodology adopts a risk assessment method that is based on quantitative or qualitative criteria. This does not exclude a third category that is used for risk assessment, the semi-quantitative method, in which case the method examined is categorised as either quantitative or qualitative, whichever is closer. • Risk Identification: risk management frameworks are considered interoperable if they can use each other’s asset taxonomy and valuation, threat and vulnerability catalogues, with equivalent results and without negatively affecting subsequent steps. At this level we consider the following features: o Asset Taxonomy: it indicates whether the framework or methodology requires the use of a specific asset taxonomy.

text: o Asset Valuation: it indicates whether the framework or methodology requires the use of a specific asset valuation method. o Threat catalogues: these indicate whether the framework or methodology requires the use of a specific set of threats. o Vulnerability catalogues: these indicate whether the framework or methodology requires the use of a specific catalogue of vulnerabilities. • Risk Assessment: risk management frameworks are considered interoperable if they use the same methodology for risk assessment, or their methods can provide results that can be easily mapped to the results of other frameworks. At this level we consider the following features: o Risk Calculation method: it provides information about the method used for risk calculation. e.g. Risk = Impact x Likelihood; Risk = Impact x Threat Likelihood x Vulnerability Level. • Risk Treatment: risk management frameworks are considered interoperable if they result in the same set of measures or a set of measures with an equal contribution to reducing levels of risk. At this level we consider the following features: o Measures catalogue: it indicates whether the framework or methodology requires the use of a specific catalogue of measures. If so, it also considers whether the two catalogues can be mapped to each other. o Residual Risk Calculation: it considers the chosen measures to evaluate the remaining levels of risk. This process is typically affected by both the risk calculation method and the impact of the chosen security measure(s) on a risk scenario. Non-functional characteristics that can also be used for assessing the interoperability of risk management frameworks include: • Supported languages: An English version of the methodology is an advantage. • Compliance with other risk-related frameworks (e.g. ISO 27005). Such compliance is likely to promote interoperability among frameworks. • Risk Management Life-Cycle Coverage: the level of coverage of the above functional components of a risk management framework. • Licensing costs that might hinder interoperability. The overall interoperability potential of risk management frameworks and methodologies will be evaluated using a weighted approach on some of the above aspects of interoperability since some of them might prohibit the interoperability of the frameworks, while others might simply hinder it. For example, language issues are considered an obstacle that can be bypassed, while different approaches in risk calculation will not allow the two frameworks to use components of the other’s method. Similarly, some of the above features are considered to be exclusive, i.e. if the feature is not satisfied then interoperability cannot be achieved at any of the aforementioned levels. Such exclusive features are the ‘Asset based or Scenario-based’ and ‘Quantitative or Qualitative’ based features. A framework or methodology that does not require, define or dictate specific methods for the above functional components is obviously considered highly interoperable. Such frameworks can accommodate risk management components from various methods. For example, the NIST 800-37 risk management framework can typically use any threats, vulnerabilities and catalogue of measures, and can accommodate any method for calculating the risk. In this respect, it is considered a highly interoperable framework. Similarly, BSI Standard 200-2 (IT-Grunschutz Methodology) integrates components from the IT-Grundschutz Compendium, and specifically accommodates the asset typology, the threat list and the catalogue of controls. If a methodology has strict requirements regarding the above functional components, its interoperability is bound to be restricted. For example, if risk assessment is tightly coupled with a specific threat or vulnerability catalogue, its ability to adopt an alternative catalogue provided by another method, is restricted. On the other hand, risk management methodologies that do require following specific, predefined characteristics (e.g. an asset taxonomy or a calculation method) could provide a

text: high potential for interoperability if these characteristics are described in detail so that other methodologies or frameworks can accommodate them. 2.2 INTEROPERABILITY EVALUATION MODEL 2.2.1 Methodology and levels of interoperability For the evaluation of potential interoperability among risk management frameworks and methodologies, we initially consider the inherent level of interoperability of the framework or methodology regarding functional features. This shows whether a specific framework allows interoperability with other frameworks with regards to these specific features. Regarding the features that contribute to the interoperability of the identification, estimation and treatment of risk, a four-level scale was used: • Non Applicable: the framework or methodology does not use or support this feature. • Low Level of Interoperability: the framework or methodology requires a proprietary solution for this feature, provided by the framework itself. • Medium Level of Interoperability: the framework or methodology provides details but are not compulsory, and therefore the proposed solution is modifiable. • High Level of Interoperability: the framework or methodology uses this feature, but it either does not provide any suggestions or it can adopt the features of a third framework, e.g. a standardised or a proprietary solution. We have applied this evaluation methodology for the functional requirements and specifically for the following features: • Risk Identification o Asset Taxonomy o Asset Evaluation o Threat Catalogues o Vulnerability Catalogues • Risk Calculation • Risk Treatment o Measure Catalogues o Calculation of Residual Risk To evaluate the potential interoperability of each risk management framework or methodology, we first determine the level of interoperability of the Risk Identification, Risk Calculation and Risk Treatment functional components. More specifically, the following Table provides the main parameters that are evaluated for each functional characteristic of the risk management framework or methodology. Table 1: Parameters evaluated for each functional characteristic

text: Characteristics Parameters to Check

text: Does the framework or methodology use or describe specific categories of assets? Asset Is the taxonomy used modifiable?

text: Taxonomy

text: Can the analyst introduce new categories of assets or import taxonomies from other sources? Does the framework or methodology use or describe specific guidelines for the valuation of assets (i.e. scale and criteria for assessment of asset value and impact)?

text: Asset

text: Valuation Are the proposed scales or criteria modifiable?

text: Can the analyst introduce new scales or criteria?

text: Characteristics Parameters to Check

text: Does the framework or methodology use or describe specific threat catalogues and/or threat categories? Threat Are the proposed threat catalogues and/or threat categories modifiable?

text: Catalogues

text: Can the analyst introduce new threats and/or threat categories and import them from other sources?

text: Does the framework or methodology describe specific vulnerability catalogues and/or categories of vulnerabilities? Vulnerability Are the proposed vulnerability catalogues and/or categories of vulnerabilities Catalogues modifiable? Can the analyst introduce new vulnerabilities and/or categories of vulnerabilities and import them from other sources? Does the framework or methodology describe specific guidelines for the calculation of risk (i.e. formulas, scale, matrix)?

text: Risk

text: Is the proposed calculation method modifiable?

text: Calculation

text: Can the analyst introduce or import (from other sources) new methods of calculation? Does the framework or methodology describe specific control catalogues and/or Measure categories of controls? Catalogues & Are the proposed control catalogues and/or categories of controls modifiable? Calculation of Can the analyst introduce new controls and/or categories of controls and import Residual Risk them from other sources? Is the Calculation of Residual Risk (either on a Calculation of Residual Risk formula or on an Impact of Measures formula) modifiable?

text: Based on the information collected and on how the aforementioned parameters were satisfied or not, we estimate the level of interoperability (No interoperability, Low, Medium or High level of interoperability) for each functional component (Risk Identification, Risk Assessment, Risk Treatment) for each risk management framework or methodology. The higher the level of interoperability that a functional component holds, the more likely it is that the framework is interoperable with other frameworks regarding a specific feature or functionality (i.e. combined features). As an example, a risk assessment framework regarding the feature ‘Vulnerability Catalogues’, will be evaluated as shown next. • Non applicable, if the framework does not use vulnerabilities in the calculation of risk, hence interoperability with another framework, such as using another framework’s catalogues as provided, is not applicable. • Low Level of Interoperability, if the framework or methodology uses a proprietary vulnerability catalogue that cannot be modified or replaced by another one. • Medium Level of Interoperability: if the framework or methodology uses a proprietary catalogue of vulnerabilities that can be modified. • High Level of Interoperability: if the framework uses a proprietary vulnerability catalogue that can be modified and that can also accommodate other catalogues, and also where the framework or methodology might not use a proprietary vulnerability catalogue but can accommodate any other catalogue. 2.2.2 Scoring model for potential interoperability After assessing the level of interoperability that each framework holds for each functional feature, we also evaluated the collective potential for interoperability for features that when combined result in specific functional components (e.g. risk identification). Specifically, for risk identification, we combined the assessment of the levels of interoperability regarding the

text: features of Asset Taxonomy, Asset Valuation, Threat Catalogues and Vulnerability Catalogues. Then to calculate the potential interoperability of the Risk Identification functional component of a given risk management framework or methodology, we applied the following weighting factors: • Asset Taxonomy, Weighting factor: 30% • Asset Valuation, Weighting factor: 50% • Threat Catalogues, Weighting factor: 10% • Vulnerability Catalogues, Weighting factor: 10% Thus, the interoperability potential for the Risk Identification functional component will be: • 30% * Interoperability Level for Asset Taxonomy + • 50% * Interoperability Level for Asset Valuation + • 10% * Interoperability Level for Threat Catalogues + • 10% * Interoperability Level for Vulnerability Catalogues. The above weights reflect the importance of each functional feature for the potential interoperability of the framework or methodology in relation to the rest of the functional features, as evaluated by the security experts who compose the project team (i.e. practical and research knowledge). The potential interoperability of a given framework in terms of Risk Assessment and of the Risk Treatment process, is equal to their assessed levels of interoperability. The fact that the potential interoperability for the Risk Identification, Risk Assessment and Risk Treatment process is presented separately, serves someone’s need to interact with a framework only within one of the three distinct functional components. For example, it is possible that a framework could have a high potential for interoperability for risk identification but not for the risk treatment process. Finally, the overall potential interoperability of a Risk Management framework is calculated as the average of the interoperability potentials calculated for the Risk Identification, Risk Calculation and Risk Treatment functional components of the framework.

text: 3. RESULTS

text: 3.1 ANALYSIS OF LEVEL OF INTEROPERABILITY FOR EACH RISK MANAGEMENT FRAMEWORK AND FEATURE The following table presents the application of the methodology for the evaluation of identified risk assessment frameworks and methodologies. Each framework or methodology is assessed regarding all features and the resulting scores. Justifications are given in the following figures. Note that not all available risk management solutions are analysed in this chapter which instead focuses on well-established and recognised frameworks and methodologies that exhibit the characteristics of a risk management solution, and that have also been identified, after an initial screening, to have the potential to interoperate with other frameworks or methodologies. Thus, a total of 18 methodologies of various types were analysed. Eleven of them are assetbased while four are considered as scenario-based, while the remaining three bear both assetbased and scenario-based characteristics. Figure 1: Asset-based Scenario-based Similarly, the subset of methods of analyse included both quantitative (only 2 out of 18) and qualitative (11 out of 18) methodologies, while 5 of them have the characteristics of both categories. Figure 2: Quantitative vs Qualitative

text: Regarding the potential interoperability of the methods that were analysed, all of them appear to be highly interoperable on threats and measures, hence allowing the adoption of additional catalogues provided by other methods or the alteration of their existing ones. Three of the methodologies analysed do not consider vulnerabilities in their approach to risk assessment. Moreover, 11 of the 18 methodologies are considered highly interoperable with respect to their approach to risk calculation and therefore more open to the adoption of alternatives, while 7 out of the 18 methodologies allow modification of the proposed method of risk calculation, typically in term of the scales that are used. The levels of interoperability of the methodologies analysed are summarised in the following table. Figure 3: Levels of Interoperability

text: FUNCTIONAL Generic Aspects NON-FUNCTIONAL Risk Risk Identification Risk Treatment Assessment io n L) es d ed ar io s ho &

text: Frameworks gu

text: y es et ue lat ge relat cen T) / n and ch (Q m alo Q io gu og / S B) oa at alcu gua ks no at n m Methodologies B) e ( alo tal C risk- or (S lu io an A tiv ppr axo er w a va ies c d l d ( ta T s cat ulat ilit te nti ive res ca oth ame ase based or ts fr reat ab ual Risk b ua tat Asset Asset er or Q Th easu ln Supp uali M Q Vu Risk Calc Resid Asset Supp

text: Matrix is used ANNEX D Measures for risk provides catalogues are calculation with ANNEX B, vulnerabilities not included. modifiable It supports 2 main Provides criteria ANNEX C and methods scales. This standard categories: primary and scale provides for

text: suggestions to examples of vulnerability relies on ISO QT, QL and supporting ANNEX E Significant evaluate assets typical threats. assessment 27002 or other assets(ANNEX B) provides Both can be methods to import compatibility provides info on but scale examples for 1.ISO/IEC used to apply New threats New measures with other ΑΒ primary and depends on risk EN, FR 27005:2018 the methods and threat vulnerabilities catalogues. frameworks supporting assets. organization. assessment described in categories can and and

text: the document New criteria can be added. vulnerabilities Flexibility in RR standards New assets can be Other be imported. catalogues calculation. No imported Interoperability calculation can be specific one Interoperability level: 3 methods can Interoperability imported. given. level: 3 be used. level:2 Interoperability Interoperability Interoperability level: 3 level: 3 level: 3

text: No specific No specific No catalogue No catalogue

text: categories of assets asset valuation No specific provided. No catalogue provided. provided. criteria given. threat catalogue Extensive provided. Extensive As a generic given. references to Extensive As a framework, it As a framework, references to method, it other NIST references to other NIST can can accommodate it can Extensive other NIST SPs, 2.NIST SP 800- SPs, NIST SPs, NIST AB QL any asset accommodate references to EN accommodat 37 CSF, NIST CSF, CSF, e any risk taxonomy. any evaluation other NIST SPs, frameworks such frameworks frameworks Extensive method. NIST CSF, assessment such as COBIT as COBIT as such as method references to other Extensive frameworks source of COBIT as as source of NIST SPs, NIST references to such as COBIT techniques and source of techniques and CSF, frameworks other NIST SPs, as source of catalogues. RR techniques catalogues. such as COBIT as NIST CSF,

text: Frameworks gu

text: source of frameworks techniques and and Interoperability calculation is

text: techniques and such as COBIT catalogues. catalogues. level: 3 flexible.

text: catalogues. as source of Interoperability techniques and Interoperability level: 3 catalogues. Interoperability Interoperability level: 3 level: 3 level: 3 Interoperability

text: level: 3

text: Appendix F

text: Specific provides a No measures Appendix H modifiable series of catalogue provides a threat tables that can provided. No asset taxonomy series of tables catalogues be used to The risk is a Provides provided. for calculating provided. identify combination of references to adverse As a generic Appendix D vulnerabilities. likelihood and other sources method it can impacts. provides a Provided impact. The implying the NIST RMF, 3.NIST SP 800- accommodate any series of tables vulnerabilities risk calculation support of other SB QT, QL The criteria EN ISO/IEC 30 asset taxonomy. for identifying catalogues method can be catalogues. RR provided can be standards modified but threat sources. can be modified. calculation is

text: new ones can’t New threat modified and flexible. No Interoperability Interoperability be imported. categories can expanded with calculation is level: 2 level: 0 be imported. new provided.

text: Interoperability vulnerabilities. level: 2 Interoperability Interoperability

text: level: 3 Interoperability level: 3

text: level: 3

text: No catalogues NIST SP800- No catalogues No catalogues 39 provides a provided. Control NIST SP800-39 NIST SP800-39 provided. New provided. New structured, yet 4.NIST SP 800- provides a provides a vulnerabilities categories are NIST RMF, AB QL threat flexible listed in EN 39 structured, yet structured, yet catalogues ISO 27005 catalogues can approach for flexible approach for flexible can be Grundschutz be imported. managing Compendium. managing approach for imported.

text: information security managing information Residual risk

text: Frameworks gu

text: risk that is information Interoperability Interoperability security risk calculation is

text: intentionally broad- security risk that level:3 level:3 that is flexible.

text: based. New asset is intentionally intentionally Interoperability categories can be broad-based. broad-based. level:3 imported. New asset New

text: valuation calculation Interoperability criteria can be methods can level:3 imported. be imported.

text: Interoperability Interoperability

text: level:3 level:3

text: Threats, modules Risks are only and safeguards conceptually listed in the IT- Assets are assessed Assets are Threats, Threats, Grundschutz classified taking into classified according modules and modules and Catalogues. New according to the consideration to the IT- safeguards safeguards measures IT-Grundschutz existing Grundschutz listed in the IT- listed in the IT- categories can be Compendium safeguards and Compendium Grundschutz Grundschutz imported. RR is (2021). Non their reliability 5. BSI (2021). New assets Catalogues. flexible. It is AB/S modifiable Catalogues. and STANDARD 200- QL can be imported New eliminated by EN ISO 27001 scales (Low, New threats can effectiveness. 2 B according to IT- be imported. vulnerabilities working out and Medium, High) Therefore, Grundschutz can be implementing for CIA there is no Compendium imported. supplementary properties. specific scale security measures Interoperability Interoperability Interoperability for measuring Interoperability to counteract a level:3 level:3 level:3 risk. level: 1 threat.

text: Interoperability Interoperability level:3 level:3

text: AB/S A default list of Volume 1 Under each Protection Low to High Protection 6.OCTAVE-S QL asset categories is provides threat profile, a Strategy risk based on Strategy EN B

text: provided, but a worksheets and custom list of worksheet high level worksheet

text: Frameworks gu

text: custom list can be examples. The threat provides criteria. Criteria provides

text: added. Existing list criteria can be categories can expandable can be expandable

text: can be modified. modified to the be added. categories of modified. categories of

text: organization’s Existing potential Addition of new potential Interoperability needs with new catalogues can vulnerabilities. ones is safeguards. level: 3 impact areas be modified. (12.Vulnerabilit supported. Impact evaluation

text: able to be y criteria worksheet Interoperability Interoperability imported. management). allow for level: 3 level: 3 additional impact Interoperability Interoperability types to be level: 3 level: 3 considered. No

text: specific RR

text: calculation

text: formula.

text: Interoperability

text: level: 3

text: Provides

text: expandable The method worksheets and Provides Provides Provides focuses mainly on examples but Provides worksheets modifiable, worksheets and information assets. no specific worksheets and and examples expandable examples but no Other assets are scales apart examples but but no worksheets extensive linked to information from low- no extensive extensive and examples catalogues. assets via medium-high on catalogues. catalogues. that can be Example of RR 7.OCTAVE worksheets and are AB QL impact levels. New threat calculation using EN HIPAA ALLEGRO indirectly protected suited per use New risk scores No specific way catalogues can case by measures aimed vulnerabilities to calculate be imported. suggested by the for information catalogues levels or RMF. RR assets. Interoperability can be importance of calculation is level:3 imported. Interoperability Interoperability assets. It flexible since level: 3 level:3 depends on the Interoperability organizations can

text: organization level:3 choose their own

text: and the biases approach towards

text: Frameworks gu

text: of the security risk matrix and

text: team. risk scores.

text: Interoperability Interoperability

text: level:3 level:3

text: No measures

text: catalogue

text: There are at least provided.

text: four primary Examples for Samples of risk No threats categories in which identifying appetite catalogues No Risk is assets can be resilience statements are provided. vulnerabilities calculated in COSO, ISO classified (People, requirements of provided. One of Documents catalogues terms of impact 31000, NIST Information, assets are the samples propose provided. New and likelihood. CSF, NIST Technology, provided. CIA focuses on 8.OCTAVE STRIDE, vulnerabilities As an SP 800-39, Facilities). Each of criteria is used categories AB QL PASTA and catalogues alternative EN FORTE these categories for asset NIST SP (Revenue, Safety, hTMM as can be FAIR method is 800-37, can be considered evaluation. etc) and the other source of extra imported. proposed. CERT-RMM, from an internal or New criteria can on likelihood catalogues. FAIR external asset be imported. Interoperability Interoperability range. So there is

text: perspective. Interoperability level: 3 level: 3 flexibility. Interoperability level: 3 Interoperability level: 3

text: level: 2

text: Interoperability

text: level: 3

text: Only conceptual High-level Threats are Risk = linked to CIAAA Occurrence No measures with three high-level description (low No (CIA+ likelihood * catalogues types of assets: - value 1, vulnerabilities Authenticity + Impact value. provided. New 9.ETSI TS 102 physical assets, medium - value catalogues AB QL Accountability) Likelihood measures can be EN ISO 25408 165-1(TVRA) human assets, 2, high - value provided. New The following levels result imported. RR logical assets. 3). New criteria ones can be threat groups from calculation Provided taxonomy can be imported. are provided: vulnerability method is flexible. can be modified. imported.

text: Interception ratings and

text: Frameworks gu

text: Interoperability Interoperability (eavesdropping) Interoperability threat levels. Interoperability

text: level:2 level:3 , Unauthorized level:3 Impact values level:3

text: access, result from

text: Masquerade, "asset impact

text: Forgery, Loss "and "attack

text: or corruption of intensity".

text: information, Three levels of

text: Repudiation risk: minor,

text: and Denial of major, critical

text: service. As long risk. ANNEX G

text: as new threat provides a

text: catalogues are excel sheet to

text: mapped to calculate risk

text: CIIAA they can and the

text: be imported. calculation

text: process is

text: analysed in

text: Interoperability step 6 of the

text: level: 3 document.

text: Some

text: calculations

text: parameters in

text: step 6 can be

text: ignored if

text: organization

text: decides to.

text: Interoperability

text: ISO 31000, The value of MONARC MONARC The following It incorporates Monarch identifies ISO 27005:2 the CIA criteria provides a pre- provides a pre- formula is ISO/IEC EN, FR, 10.MONARC AB QL primary and 013, ISO is automatically determined determined always used to 27002:2022 NL, DE secondary assets. 27001, NIST inferred based threat list that vulnerabilities calculate the controls. It can Assets are SP 800 on the may be list that may level of risk: import referential

text: Frameworks gu

text: modifiable and consequences evaluated and be evaluated Threat x from standards

text: expandable. of the ROLFP. modified. and modified. Vulnerability x like ISO 27005 to

text: Impact level Existing list can Existing list Impact = Risk. use them as Interoperability ranges from 0, be modified and can be Scales can be safeguards. RR Level: 2 non-existing expanded with modified and modified calculation is

text: impact, to 4, new threats. expanded with flexible. Interoperability unbearable new Interoperability Level: 3 Interoperability information vulnerabilities. Level: 3 Level: 3 leaks, for each Interoperability of the Level: 3 categories. It is

text: possible to

text: customize

text: valuation scales

text: and redefine

text: impact and

text: consequences.

text: Interoperability

text: Level: 3

text: There are no No strict No strict It supports two vulnerabilities requirements Examples of requirements on asset types: catalogues on the levels of assets and their the levels of business provided. New impact and feared event General impact and ISO (information & ones can’t be likelihood impact levels. examples, new likelihood 31000:2018, processes) and imported. parameters. A 11.EBIOS Risk AB/S Criteria/scales ones can be parameters. New FR, EN, ISO 27000, QL/QT supporting assets Vulnerabilities severity scale Manager (RM) B are modifiable added manually measures SP, DE ISO 13335, (assets that support are identified (G1-G4) is and expandable catalogues can be ISO 27002, business assets). Interoperability when used. Other with new ones. imported. RR 27005 The value of impact Level: 3 assessing the mentioned calculation is is assessed Interoperability conformity to methods use 4 flexible. according to a Level: 3 the security or 5 levels

text: severity scale that baseline that scales.

text: takes into

text: Frameworks gu

text: makes it possible to account the Interoperability Interoperability

text: rank feared events security best Level: 2 Level: 3

text: practices and Interoperability the sectorial Level: 3 regulations

text: Interoperability

text: Level: 2

text: Volume 3 of

text: Chapter 4 of Magerit v3 includes Chapter 6 of Book book 2 analyzes Threats and techniques that 2 includes a list of the valuation vulnerabilities can be used suitable Chapter 2 in Book 2 criteria. The are included in Threats are both in a safeguards Magerit provides a value for eac0h chapter 5 of included in qualitative and list of asset types. dimension is 0, Book 2. There New safeguards chapter 5 of quantitively Each asset can be minimal, to 10, is no clear can be imported. Book 2. New way through ISO/IEC associated with very high. distinction in Impact and threat and mathematical 27001:2005, more than 1 type. the safeguard Criteria can be threat formulas to ISO/IEC 12. catalogues. valuation is done New assets can be modified. Both catalogues can perform assess SP/Partial 15408:2005, AB QT/QL via methods MAGERIT v.3 imported. New quantitative and be imported. Vulnerabilities asset value, EN ISO/IEC provided in asset types cannot qualitative are not used safeguard 17799:2005, Volume 3. Table ISO/IEC be imported. methods are anymore. They efficiency and or algorithmic provided. New Interoperability were used in risk 13335:2004 Interoperability analysis can be dimensions can Level: 3 Magerit v1.0) management in Level: 2 used. be added. general. Interoperability Volume 3 Interoperability Interoperability Level: 0 includes all the Level: 3 Level: 3 mentioned

text: methods for

text: calculating

text: risks so new

text: Frameworks gu

text: ones new can’t

text: be imported.

text: Interoperability

text: Level: 2

text: Recommends

text: assessing value

text: based on

text: Business Impact Risk=Threat x

text: Consequence Analysis.

text: Impact Scales Vulnerabilities Threat

text: Primary, Secondary include are only Catalogue from involves assets and Business and considered as NIST SP800assessment of Catalogue of Data Protection Catalogue from an 53r4. New frequency, Supporting assets. Impact Scales Magerit/Pilar. independent safeguards and power of Existing catalogue Proposes a New threats functional safeguards Magerit / adversary, is modifiable but scale 1-10. and threat component catalogues can be easiness. Risk PILAR / 13.ITSRM² AB QT, QL catalogues can imported. Strict EN new types can’t be and are not matrixes can NIST Different be imported. method for RR added. used be customised, SP800-53r4 options are calculation so no elsewhere. but formula provided. Interoperability flexibility. Evaluate based Level: 3 remains the

text: Interoperability same. on impact, by Level:2 Interoperability hypothesis if Level: 0 Interoperability something (like Level: 3 data) processed Interoperability

text: is not known in Level: 2

text: advance.

text: Interoperability

text: Level: 2

text: Frameworks gu

text: Mehari covers

text: threat Risk is categories and At least one of Vulnerabilities calculated by types (Appendix Primary (needs for the catalogue evaluating There is a list of C1), as well as activity), Secondary consequence provided in likelihood and FR, actor security services (media, criteria should Appendix B. impact on a EN(Full classifications offered (Appendix ISO/IEC dependencies). be defined for New scale from level set) SP, (Appendix C2). G2). There are 27005:2011, Provides asset each asset vulnerabilities 1 to level 4. It is IT, DE, A list of event standard scales ISO/IEC AB/S catalogue. New (Confidentiality, and mandatory for PL, RO, 14.MEHARI QL types is given for impact, 27001:2013, B assets and asset Integrity, vulnerabilities measure NL, along with their likelihood, ISO/IEC categories can be Availability). catalogues efficiencies and PT(Overvi descriptions. reduction factors 27002:2013, imported. Impact & can be impact of ew)and New threats so RR calculation ISO 31000 Intrinsic Impact imported. threats to be others like and threat is not flexible. Interoperability FA calculated. Level: 3 Interoperability categories can Interoperability Interoperability Level: 1 be imported. Level: 3 Interoperability Level: 3 Level: 1 Interoperability

text: Level: 3

text: No

text: vulnerabilities Monte Carlo or No threats No asset catalogues other No safeguards catalogues valuation provided. Only stochastic catalogues No asset taxonomy provided. Only 15.THE OPEN provided. New generic methods to provided. Only provided. generic GROUP criteria can be categories. calculate generic categories. New STANDARD, QT imported. New results. New categories. RR EN ISO 27005 SB threat RISK ANALYSIS, vulnerabilities risk calculation calculation is catalogues can Interoperability catalogues methods can flexible. V2.0.1 be imported. Level: 0 can be be imported. Interoperability Interoperability Interoperability imported. Level: 3 Interoperability Level: 3 Level: 3 Interoperability Level: 3

text: Level: 3

text: Frameworks gu

text: Threat is the It includes both Examples of product of the Annex 1 provides a the asset's total potentially Risk is Sections 7 and 8 threat actor’s list of onboard cost and the vulnerable calculated by provide protection capability, systems, equipment cost of onboard evaluating and detection opportunity and 16.GUIDELINES and technologies maintaining it. systems are likelihood and measures. New intent to cause ON CYBER with potential Provides provided. New impact. Criteria safeguards can AB/S harm. New SECURITY QT vulnerability. New modifiable and vulnerability can be be imported. RR EN threat ONBOARD B expandable modified. asset categories catalogues can catalogues calculation is SHIPS can be imported. criteria. can be flexible. be imported.

text: imported. Interoperability Interoperability Interoperability Level: 3 Interoperability Interoperability Level: 2 Level: 3

text: Interoperability Level: 3 Level: 3 Level: 3

text: Risk is Provides an Provides an calculated by indicative indicative evaluating taxonomy of taxonomy of No asset likelihood and threats. Threats vulnerabilities valuation impact on a No asset taxonomy are targeted which can provided. New scale from level No safeguards provided. specifically to enable criteria can be 1 to level 5 for catalogues 17. The AML/CFT cybersecurity specifically QL imported. probability, provided. EN AB events that can threats related methodology impact and enable money to money Interoperability Interoperability risk. New risk laundering and laundering and Level: 3 Level: 0 calculation Interoperability terrorist terrorist methods can Level: 3 financing. financing. be imported.

text: Interoperability Interoperability Interoperability Level: 1 Level: 1 Level: 3

text: Frameworks gu

text: No

text: No asset No threats vulnerabilities No safeguards

text: valuation catalogues catalogues There is no catalogues

text: No asset taxonomy provided. New provided. New provided. New specific scale provided, only

text: QT, QL provided. criteria can be threat vulnerabilities for measuring generic 18. Circular CSSF AB/S Both can be imported. catalogues can catalogues risk. categories of EN, FR 20/750 B used be imported. can be safeguards.

text: Interoperability Interoperability imported. Interoperability level:3 Interoperability Level: 0 Interoperability Level: 3 Level: 3 Interoperability Level: 3

text: Level: 3

text: 4. INTEGRATION OF INTEROPERABILITY IN THE RM PROCESSES BASED ON ITSRM2

text: Based on the analysis of RM frameworks and methodologies performed in in accompanying “Compendium of Risk Management Frameworks”3, two RM frameworks provide a thorough description of the typical RM processes, covering the overall RM lifecycle. These are ISO 27005 and ITSRM . In this Chapter we provide recommendations regarding interoperability for the ENISA Work Programme for 2022 and thereafter in the area of Risk Management (RM), using ITSRM2 as a reference framework. The rationale behind this choice is that ITSRM2 is process-oriented and offers a detailed presentation of the inputs and outputs for each RM process, providing us with the grounding needed to discuss the recommendations for opportunities in interoperability. Figure 4 presents the ITSRM2 RM processes. Figure 4: The ITSRM2 processes Before initiating the analysis for each RM process, one high-level recommendation for the facilitation of interoperability concerns the terminology. In particular, the problem exists in two cases: 1) using the same (English) term with different meanings, or 2) translating a term,

text: usually from the language in which the RM framework was developed, into other languages. In both cases, interoperability is hindered. Therefore, we recommend working towards a: Common terminology and translation of terms in the languages of MS and supporting their integration into the RM frameworks. Next, we identify recommendations across the RM processes based on ITSRM2. 4.1 PROCESS P1 SYSTEM SECURITY CHARACTERISATION 4.1.1 Description of process The purpose of the System Security Characterisation process is to gather initial information concerning the system and its context, which will be used for the rest of the RM processes. The output of this process includes a high-level description of the system and the organisation, the contact points for security roles, any constraints for security requirements and any mandatory security measures that result from these requirements. This process is mapped with the ISO 27005 step Context Establishment. For the purposes of identifying interoperability opportunities and features, this process is considered outside the scope of our analysis, as described in accompanying “Compendium of Risk Management Frameworks”4. 4.2 PROCESSES P2 PRIMARY ASSETS AND P3 SUPPORTING ASSETS 4.2.1 Description of processes The objective of the P2 Primary Assets process is to identify the Data and Functions (considered as Primary Assets) that are crucial for the organisation to achieve its business objectives, determine their value (from a business perspective) as well as their attractiveness for potential adversaries (combination of the power and interest of potential adversaries that can be motivated by threatening the Primary Asset). For this process the methodology offers a business impact scale, a catalogue of potential adversaries and a scale of levels of interest for potential adversaries. Finally, the objective of P3 Supporting Assets is to identify and register the Supporting Assets employed (inventory of hardware and software, a high-level design, an architectural diagram etc.) for the management of the primary assets (Data and Functions provided by the target system). This process is part of the Risk Identification step of ISO 27005. 4.2.2 Recommendations and integration of interoperability features To achieve interoperability among different RM frameworks, we need to enable the use of each other’s asset taxonomy and valuation algorithm with equivalent results and without negatively affecting subsequent steps. Therefore, we need to ensure that: • the asset taxonomy used by an RM framework is modifiable; • the analyst can introduce new categories of assets or import taxonomies from other sources; the RM framework uses or describes specific guidelines for the evaluation of assets (i.e. scale and criteria for assessment of asset value and impact) which are modifiable or the analyst can introduce new scales or criteria. 4.3 PROCESS P4 SYSTEM MODELLING 4.3.1 Description of process The purpose of P4 System Modelling is to develop a model of a system in terms of associations between primary and supporting assets, data flows, and system architecture. This process is part of the Risk Identification step of ISO 27005.

text: 4.3.2 Recommendations and integration of interoperability features To find the potential for interoperability in this process, it is advisable to work towards promoting standard representation techniques of the system model (e.g. all supporting assets required for the processing of primary assets, software architecture, logical model) to allow process P5 to use it regardless of the RM framework applied. 4.4 PROCESS P5 RISK IDENTIFICATION 4.4.1 Description of process The objective of the P5 Risk Identification task is to build the risk scenarios that will be analysed. The risk scenarios are used to represent the risks for the organisation and the Primary assets regarding the consequences of potential threats in relation to the confidentiality, integrity and availability of the Supporting Assets. To identify the threats that the Primary and Supporting assets of a specific information system are facing, this task will use the system model (output of P4). More specifically, the system model will provide useful information in order to identify which threats are most likely to occur for each triplet ‘Primary Asset / Security Dimension (CIA) / Supporting Asset’. Another important parameter during the risk identification process is the identification of the vulnerabilities exhibited by the Supporting assets which can be explored by the relevant threats to harm the confidentiality or integrity or availability of a Primary asset. The output of the process P5 Risk Identification will be a list of risk scenarios that will be evaluated in P6 Risk Analysis and Evaluation. This process is part of the Risk Identification step of ISO 27005. 4.4.2 Recommendations and integration of interoperability features Interoperability requires that, for the same system, two different RM frameworks should produce comparable risk scenarios or, for different systems, the risk scenarios produced by different RM frameworks are comparable. To achieve interoperability among different RM frameworks during the risk identification process, it is necessary to work towards the following. • Common threat repositories that will feed the applicable (common) threats to the risk identification process of different RM frameworks. These repositories should: o classify threats in categories, depending on commonly accepted threat types (e.g. physical threats, malware, denial of service, failures etc.); o classify threats according to the sector to which they are applicable (e.g. threats for health organisations, threats for financial institutions etc.); o support a hierarchical structure for each threat category, starting from a high level threat description and continuing with lower-level technical details (instances) of each threat; this hierarchical structure will facilitate the interoperability of frameworks working with high-level threats (low-threat granularity) with frameworks considering threats at a much lower technical level (high threat granularity). • Risk scenarios should take into consideration both the business perspective and the system perspective. They should also support the association of threats with Supporting assets (i.e. which threat is applicable to which Supporting asset). • Common vulnerability repositories that will feed the applicable (common) vulnerabilities to the risk identification process of different RM frameworks. These repositories should also support the association of vulnerabilities and Supporting assets (i.e. which vulnerability is applicable to which Supporting asset). The existence of the common repositories for threats and vulnerabilities will also support global awareness about new threats and vulnerabilities, allowing all RM frameworks to take them into account automatically.

text: 4.5 PROCESS P6 RISK ANALYSIS AND EVALUATION 4.5.1 Description of process The objective of the P6 Risk Analysis and Evaluation process is the computation of the residual risk level for each risk identified in P5 Risk Identification, based on the list of Security Measures identified to mitigate these risks. The P6 Risk Analysis and Evaluation process uses as input the Primary asset inventory (from P2), the risk scenarios (from P5), the catalogue of threats (provided by the methodology), the risk scale (provided by the methodology), the treatment register (from P7, if it exists from past RMs), and the security measures register (from P7, if it exists from past RMs). The output of the P6 Risk Analysis and Evaluation process is the risk register which guides decisions on the treatment of risk. For the analysis of risk, the analyst takes into consideration the likelihood of threats (based on types of threats and potential adversaries, provided by the methodology) and the consequences of a potential incident. A risk matrix is provided by the methodology, which calculates the inherent level of risk by combining the likelihood with the levels of consequences. The residual risk level is calculated after considering existing or planned security measures to mitigate the risk. Finally, the risk evaluation process provides an ordered list of risks from the highest to the lowest levels of risk. This stage is mapped with the ISO 27005 Risk Analysis and Risk Evaluation processes. 4.5.2 Recommendations and integration of interoperability features Based on the analysis performed in Chapters 2 and 3, we can identify two types of potential for interoperability. Firstly, the potential for enabling interoperability when an RM analyst performs RM using the same RM framework but in systems that function for organisations in different sectors. Secondly, the potential for enabling interoperability when an RM analyst performs RM using different RM frameworks in systems either in the same or different sectors. For both options, the key stakeholders and specialists noted that it is important to work in the future in the direction of creating guidelines for the interpretation and alignment of RM results, so that the various RM outputs can be compared with each other (i.e. from different RM methodologies or from the same RM methodology in different sectors). The components of the P6 Risk Analysis and Evaluation process, which draw attention for the above purposes are: - the threat likelihood scale component - the risk scale component - the risk matrix component. Based on the analysis performed in Chapters 2 and 3 and comments from key stakeholders, future work should focus on allowing interpretation of the outputs from risk analysis that result from different RMs so that risk levels are comparable. Such provisions can be very beneficial for organisations in Member States that aim to collaborate or exchange information and services. In such circumstances, auditors or security specialists are troubled when comparing various RM results and trying to evaluate whether risk levels are equivalent (e.g. a risk level 18 using ITSRM2 compared with a risk level 4 using TVRA). Therefore, to achieve interoperability it is necessary to work towards the following. • Common or Comparative Risk Scales that will be used by analysts to evaluate the risk scenarios produced by the risk identification process. o The risk scales could be qualitative or quantitative. However, there should be guidelines on the way analysts can interpret the results of each RM framework as a comparison to another RM framework o It would be useful to identify (if possible) reference values for each organisational size, sector, region or nation, etc.

text: 4.6 PROCESS P7 RISK TREATMENT 4.6.1 Description of process The objective of P7 Risk Treatment is the selection of the risk treatment options that are most appropriate for handling the risks identified taking into consideration the constraints on the organisation. Risk mitigation, avoidance, sharing or acceptance are considered as potential options for treatment. The process takes the results from the previous processes as input and the catalogue of security measures provided by the framework. The process results in a risk treatment register that gathers all the information related to the risk treatment options and applicable security measures if mitigation is chosen. The process is mapped with the Risk Treatment step of ISO 27005. 4.6.2 Recommendations and integration of interoperability features Achieving interoperability among different RM frameworks during the risk treatment process is important especially given that RM is a continuous and repetitive process. Therefore, it is common that organisations might perform RM using different methodologies in due course. Further, it is important because organisations may select collaborators based on their appetite for risk management and treatment as well as status, since collaboration commonly involves the exchange of information and the interconnection of systems. Therefore, organisations desire to be able to compare the results of risk treatment produced for the same system by two different RM frameworks or the results produced by different RM frameworks for different systems. For this, it is necessary to work towards the following objectives. • Baseline security measures and the levels of risk maturity associated with various categories of risk and levels of risk maturity. Organisations could initially aim to achieve the minimum level of baseline security and further improve risk maturity by carrying out risk assessments and identifying further risks and appropriate controls. • Guidelines for comparing risk appetite. Top management selects among the available risk treatment options, thus selecting risk mitigation, risk acceptance, risk avoidance or risk sharing. The decisions concerning risk treatment are related to the risk appetite of top management and could be a valuable criterion that organisations might use for selecting collaborators and developing service level agreements. Assuming there are comparative scales for risk, it would be useful to work towards guidelines for evaluating and comparing risk management appetites.

text: 5. SYNOPSIS

text: The RM frameworks and methodologies presented in this report have undergone an in-depth analysis regarding certain attributes and characteristics which was essential in determining the corresponding levels of their potential interoperability. To this end, a scoring model was followed which produced the sought-after results. Each framework’s features initially achieved an interoperability score, which in turn was used to evaluate the overall potential interoperability from the features’ categories. Chapter 3 presents the interoperability features of the prominent RM methods and frameworks including the ones identified through the current work as well as updates to the ones identified in the previous version of the Report. (Chapter 6 includes a list of all RM frameworks and methods identified and updates made), while Chapter 4 presents recommendations for incorporating compatibility into the RM processes following ITSRM2. Conclusively, there are a number of scenario-based methods that do not support all the characteristics that we used in our evaluation process, e.g. asset identification or evaluation, and therefore the overall score is not directly comparable to the scores of others. It should also be noted that, due to the differing scopes and objectives of the RM frameworks and methodologies, a direct comparison of their score for potential interoperability might lead to erroneous conclusions. RM Frameworks (inc. ISO 27005, NIST SP 800 – 30/37/39) provide broad directions and guidelines and pose less constraints on the steps or processes to follow during RM. Well-structured methodologies, on the other hand (such as EBIOS RM, Magerit, and Monarc), prescribe in a higher level of detail the steps to be followed and support all phases of an RM process. Finally, we should mention that RM frameworks, being essentially the guidelines for performing an assessment, can be integrated seamlessly with the processes derived from corresponding methodologies that have achieved the required evaluation of interoperability. For example, NIST 800-37 is a framework that only acts as an umbrella for risk management functional components and does not provide any details for each of them. As such, it has the capacity to accommodate any risk management functional component and, therefore, is highly interoperable but it cannot be used by its own as a methodology for managing levels of risk.

text: 6. UPDATES ON THE PROMINENT RISK MANAGEMENT FRAMEWORKS AND METHODOLOGIES

text: This section describes the updates to the most prominent, currently in use RM frameworks and methods, as they have been identified in the report Interoperable EU Risk Management Framework. 6.1 MONARC (https://www.monarc.lu/, Cyber Security Agency, Luxemburg) MONARC (Méthode Optimisée d’analyse des risques CASES - Method for an Optimised Analysis of Risks by CASES) (CASES, 2013) is a tool and a method allowing precise and repeatable risk assessments to take place. It was created in 2013 by the Cyberworld Awareness Security Enhancement Services (CASES) department of the Cybersecurity Agency for the Luxembourg Economy and Municipalities in Luxembourg. Since the publication of the report Interoperable EU Risk Management Framework, MONARC has incorporated an update of the risk treatment phase via the addition of security controls catalogue which are aligned with ISO/IEC 27002:2022 controls. This demonstrates the interoperability potential of MONARC, given that new features can be incorporated into specific RM stages. Moreover, in the previous version, the provided control catalogue is not obligatory, and it is possible to import referential catalogues from other sources (e.g., standards). 6.2 EU ITSRM , IT SECURITY RISK MANAGEMENT METHODOLOGY V1.2 (https://ec.europa.eu/info/publications/security-standards-applying-all-european-commissioninformation-systems_en, EU, DG DIGIT) The second version of ITSRM² IT Security Risk Management Methodology (2020, version 2.0) (European Commission Directorate-General for Communication, Security standards applying to all European Commission information systems) is a methodology provided by DG DIGIT and the European Commission, as part of a set of standards for information security which were updated in November 2021. The methodology comprises phases and steps that are mapped onto ISO 27005, including Context Establishment, Risk assessment and Risk Treatment. The main changes in the methodology include: • flagging of personal data in the inventory of primary assets, • asset valuation is extended to consider impact on data subject for personal data, and not only impact on business (i.e., Impact Scales were divided into Business Impact Scale and Data Protection Impact Scale) • Measures catalogues included all measures from NIST SP800-53r4, but categorised as 1) Mitigating measures, 2) Supporting Measures, and 3) Corporate Measures.

text: 6.3 THE AML/CFT NATIONAL RISK ASSESSMENT METHODOLOGY (https://pubs.opengroup.org/security/o-ra/, The Open Group) A new version of the methodology provided by the Open Group Standard for Risk Analysis (The Open Group, 2021) was published (version 2.0.1). The document is associated with the updated version of the Risk Taxonomy Standard (Risk Taxonomy (O-RT) Standard, Version 3.0.1, the Open Group Standard (C20B, November 2021)). The main updates in the version 2.0.1 are: • The “Confidence Level in the Most Likely Value” as a parameter to model estimates is discontinued and replaced by the choice of distribution that would determine it • The quantitative example that utilized a qualitative scale has been removed • Open FAIR terms and definitions have been clarified • The Loss Scenario is decomposed and explained utilizing accompanying figures, including guidance on selecting the distribution to use and Risk Factor to model 6.4 THE AML/CFT NATIONAL RISK ASSESSMENT METHODOLOGY (https://www.rahandusministeerium.ee/et/system/files_force/document_files/l2._nra_methodolog y_report.pdf?download=1, Ministry of Finance of the Republic of Estonia) The AML/CFT methodology is developed by the Ministry of Finance of the Republic of Estonia. The purpose of this RM framework is to identify, assess and understand the risks, threats and vulnerabilities of money laundering and terrorist financing. Although, the specific threats are not necessarily cybersecurity risks, the methodology is strongly oriented towards the realization of the threats through the cyberspace and computer systems infrastructures. The risk management process includes risk identification, risk analysis, risk evaluation & reassessment. Risk identification includes among others, understanding the threats and vulnerabilities; risk analysis includes among others risk and vulnerability rating; and risk evaluation and re-assessment includes action planning and re-assessment of risks. The methodology provides an indicative taxonomy of threats and vulnerabilities, as well as rating guidelines related to a five-level scale for threat probability and vulnerability level and a fivelevel scaling for risk rating. For example a level 1 risk is associated with “insignificant impact on national security systems”, a level 4 risk is associated with “high cybercrime attacks on computer infrastructure and databases, involving losses in confidential information”, and a level 5 risk with “Significant cybercrime attacks on computer infrastructure and databases, involving disclosure of National Secrets (classified information), increased damage on national operation level on information, computer and telecommunication system”. For the risk evaluation & reassessment stage, three strategies are proposed for action planning: risk acceptance, risk avoidance and risk mitigation. 6.5 CIRCULAR CSSF 20/750 (https://www.cssf.lu/wp-content/uploads/cssf20_750eng.pdf, Commission de Surveillance du Secteur Financier (CSSF) of Luxemburg) Circular CSSF 20/750 is developed by the Commission de Surveillance du Secteur Financier (CSSF) of Luxemburg and provides guidelines on information and computer technology (ICT) and security risk management, which are specifically targeted to the financial sector. The guidelines explain at high-level how financial institutions should manage the ICT and security risks that they are exposed to. The RM framework includes the following main steps: • Organization and objectives

text: • Identification of functions, processes and assets • Classification and risk assessment • Risk mitigation • Reporting • Audit The Guidelines state that the ICT and security risk management framework should include processes in place to: • determine the risk appetite for ICT and security risks, in accordance with the risk appetite of the financial institution • identify and assess the ICT and security risks to which a financial institution is exposed • define mitigation measures, including controls, to mitigate ICT and security risks • monitor the effectiveness of these measures as well as the number of reported incidents, including for PSPs the incidents reported in accordance with Article 96 of PSD2 affecting • the ICT-related activities, and take action to correct the measures where necessary report to the management body on the ICT and security risks and controls • identify and assess whether there are any ICT and security risks resulting from any major • change in ICT system or ICT services, processes or procedures, and/or after any significant operational or security incident. The Guidelines also define certain security areas that financial institutions should address with safeguards, including information security policy, logical security, physical security, ICT operations security, security monitoring, etc. 6.6 SERIMA The Luxemburg Institute of Science and Technology developed a prototype and created a regulation platform called SERIMA (SEcurity RIsk Management), which allows telecommunication operators to carry out risk analyses, particularly in the telecommunications sector. This initiative is expected to assist operators in having a common methodology for carrying out risk analyses and report incidents according to the regulations in force. Therefore, tackling differences in format, methodology, data reconciliation or data comparison and analysis. SERIMA is not analysed further in this report, due to lack of publicly available information. 6.7 ISO/IEC 27005:2018 (https://www.iso.org/standard/75281.html, International Organization for Standardization) No updates. 6.8 NIST SP 800-37 REV. 2 (https://www.nist.gov/cyberframework/risk-management-framework, USA) No updates. 6.9 NIST SP 800–30 REV.1 (https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final, USA) No updates.

text: 6.10 NIST SP 800–39 (https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final, USA) No updates. 6.11 BSI STANDARD 200-2 (https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Grundschutz/International/bsistandard-2002_en_pdf.html) No updates. 6.12 OCTAVE-S (https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=6795, Carnegie Mellon University / Software Engineering Institute - USA) No updates. 6.13 OCTAVE ALLEGRO (https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=8419, Carnegie Mellon University / Software Engineering Institute - USA) No updates. 6.14 OCTAVE FORTE (OCTAVE FOR THE ENTERPRISE) (https://search.cmu.edu/?q=octave+fort&siteSearch=&site=&ie=UTF-8, Carnegie Mellon University / Software Engineering Institute - USA) No updates. 6.15 ETSI TS 102 165-1, THREAT VULNERABILITY AND RISK ANALYSIS (TVRA) (https://www.etsi.org/deliver/etsi_ts/102100_102199/10216501/05.02.03_60/ts_10216501v0502 03p.pdf, ETSI Technical Committee Cyber Security) No updates. 6.16 EBIOS RISK MANAGER (EXPRESSION DES BESOINS ET IDENTIFICATION DES OBJECTIFS DE SECURITE - EXPRESSION OF NEEDS AND IDENTIFICATION OF SECURITY OBJECTIVES) (https://www.ssi.gouv.fr/en/guide/ebios-risk-manager-the-method/, ANSSI, France) No updates. 6.17 MAGERIT V.3: ANALYSIS AND RISK MANAGEMENT INFORMATION SYSTEMS (https://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metodolog/pae_ Magerit.html?idioma=en, Spanish Ministry for Public Administrations, Spain) No updates.

text: 6.18 MEHARI (https://clusif.fr/management-des-risques-cooperation-de-mehari-et-ebios-risk-manager/ https://clusif.fr/module-mehari-manager-bc/, CLUSIF, France) No updates. 6.19 GUIDELINES ON CYBER SECURITY ONBOARD SHIPS (https://wwwcdn.imo.org/localresources/en/OurWork/Security/Documents/ANNEX%20Guideline s%20on%20Cyber%20Security%20Onboard%20Ships%20v.4.pdf, BIMCO, CLIA, ICS, INTERCARGO, INTERMANAGER, INTERTANKO, OCIMF, IUMI and WORLD SHIPPING COUNCIL) No updates.

text: 7. BIBLIOGRAPHY/ REFERENCES

text: Higgins, J. and Thomas, J., Cochrane Handbook for Systematic Reviews of Interventions, 2021, Version 6.2. Weidt, F. and Silva, R., Systematic Literature Review in Computer Science-A Practical Guide, Relatórios Técnicos do DCC/UFJF, vol. 1, no. 0, pp. 1–7, 2016, doi: 10.1027/1016- 9040.11.3.244 ISO/IEC 2382-1:1993 Information Technology – Vocabulary – Part 1: Fundamental terms. International Organization for Standardization (ISO). [Online]. Available: http://www.iso.org/iso/catalogue_detail.htm?csnumber=7229 Standard Computer Dictionary IEEE, A Compilation of IEEE Standard Computer Glossaries. IEEE, New York, NY, 1990 https://www.standardsuniversity.org/article/standards-glossary/#I ISO 23903:2021 Health informatics — Interoperability and integration reference architecture — Model and framework ISO/IEC 27000:2018 Information technology — Security techniques — Information security management systems — Overview and vocabulary ISO/IEC 27005:2018 Information technology — Security techniques — Information security risk management European Commission Directorate-General for Communication Security standards applying to all European Commission information systems. EU ITSRM, IT SECURITY RISK MANAGEMENT METHODOLOGY V1.2. [Online] Available at: https://ec.europa.eu/info/publications/security-standards-applying-alleuropeancommission-information-systems_en Lazarinis, F., Green, S., Pearson, E. (Eds.), (2011). Handbook of Research on E-Learning Standards and Interoperability: Frameworks and Issues. IGI Global. https://doi.org/10.4018/978- 1-61692-789-9 Gilsinn, J. and Schierholz, R. (2010), Security Assurance Levels: A Vector Approach to Describing Security Requirements, Other, National Institute of Standards and Technology, Gaithersburg, MD, (accessed June 29, 2022) ENISA (2016) Readiness Analysis for the Adoption and Evolution of Privacy Enhancing Technologies, https://www.enisa.europa.eu/publications/pets (accessed June 29, 2022)

text: ENISA (2021) Interoperable EU Risk Management Framework, https://www.enisa.europa.eu/publications/interoperable-eu-risk-management-framework (accessed June 29, 2022

text: -N -EN -004 -22 -01 TP ABOUT ENISA The European Union Agency for Cybersecurity, ENISA, is the Union’s agency dedicated to achieving a high common level of cybersecurity across Europe. Established in 2004 and strengthened by the EU Cybersecurity Act, the European Union Agency for Cybersecurity contributes to EU cyber policy, enhances the trustworthiness of ICT products, services and processes with cybersecurity certification schemes, cooperates with Member States and EU bodies, and helps Europe prepare for the cyber challenges of tomorrow. Through knowledge sharing, capacity building and awareness raising, the Agency works together with its key stakeholders to strengthen trust in the connected economy, to boost resilience of the Union’s infrastructure, and, ultimately, to keep Europe’s society and citizens digitally secure. More information about ENISA and its work can be found here: www.enisa.europa.eu. ISBN 978-92-9204-553-1 DOI: 10.2824/07253