by Christophe Ponsard and Jean-François Daune (CETIC)
Digital products have become ubiquitous across all domains for everyday activities of both citizens and companies. Providing secure products is required to ensure the organisations relying on them have a minimal attack surface. This article highlights specific needs and our ongoing work to conduct a cyber security risk analysis for a digital product, which is also increasingly required by regulations such as the EU The Network and Information Security Directive (NIS2) or the upcoming Cyber Resilience Act.
Conducting regular cyber security risk analysis inside an organisation is strongly recommended to stay resilient against a quickly evolving threat landscape. It is a mandatory step in many standards and related certifications across many sectors such as ISO27002 (Information Technology - IT), IEC 62443 (Operational Technology - OT) and SAE 21434 (automotive). Those approaches are however performed at a full organisation level and do not focus on the point of view of the editor providing a digital solution. However, securing the supply chain is now part of regulations such as the NIS2 and specific security requirements will also apply to digital products with the upcoming Cyber Resilience Act (CRA).
When investigating available methods for conducting a risk analysis targeting a digital product, two main limitations emerged. First, many methods are focusing on protecting the organisation’s business assets through a large set of supporting IT assets. These methods do not take the point of view of a digital product, although they identify potential threats related to their configuration, (mis)use, update and, more recently, development. This typically relies on the ISO27005 iterative risk-oriented approach with methods such as EBIOS (France) [L1], IT-SRM (EU) [L2] or MONARC (Luxembourg) [L3] that we investigated and were also reviewed by ENISA [1]. Second, product-oriented methods focus more on checking the implementation with respect to the security specification by examining the security maturity across the lifecycle and (pen) testing the product (e.g. assurance levels in the common criteria). However, they just assume a prior risk assessment to show the security objectives are addressing identified threats. Those methods can also be cumbersome and have difficulties coping with product evolution, although more incremental processes are being investigated [2].
A product-oriented risk analysis requires a mix of approaches with the product as central asset. It must deal with different aspects such as the interaction with the outer ecosystem, the security guarantee to provide on specific information/processes (including the product itself in integrity and for intellectual property), the inner product architecture, the resulting attack surface through its interfaces, the internal development process and the product dependencies (e.g. through Software Bill of Materials). Additional requirements are to rely as much as possible on available methods and tools in order to be efficient and to stay compliant with existing standards. An architecture modelling foundation also enables a precise description, in-depth analysis (e.g. using recommended threat modelling) and automation for generating artefacts or identifying security measures.
After an in-depth review of the methods mentioned above, we decided to adopt IT-SRM as our core method for several reasons. First, as IT systems are our main focus, it is 27001 compliant but it can also be considered as the basis for specialised domains such as OT or medical software. Second, it is very well documented including catalogues borrowed from other methods such as EBIOS. Finally, it quite systematically supports the review of the required security properties over technical assets to produce risk estimates and, from there, to decide about additional security measures. The method does not provide tool support but can easily be automated using spreadsheets and modelling tools as depicted in Figure 1, which is freely inspired by a real case study.
Figure 1: Current ISRM tool support with spreadsheet (right) and Threagile architecture modelling (left).
The next step of our work is to improve tool support to better capture the product architecture and guide the analysis, e.g. inside the Open Source MONARC risk analysis tool based on our previous work [3]. For this, we are also investigating how to enrich the component classification, related risks and countermeasures. Finally, our work is currently being validated on different use cases, e.g. a medical ERP [L4], in the scope of a grand challenge on risk analysis for penetration testing proposed by the Belgian CyberWal platform and driven by industrial needs.
Links:
[L1] https://commission.europa.eu/publications/security-standards-applying-all-european-commission-information-systems_en
[L2] https://cyber.gouv.fr/en/publications/ebios-risk-manager-method
[L3] https://www.monarc.lu
[L4] https://business.esa.int/news/b-life-%E2%80%93-life-saving-labs-lightning-speed
References:
[1] C. Lambrinoudakis et al, “Interoperable EU risk management framework,” ENISA Report, 2022.
[2] S. Dupont et al, “Product incremental security risk assessment using DevSecOps practices,” SecAssure@ESORICS 2022.
[3] C. Ponsard et al, “Improving cyber security risk assessment by combined use of i* and infrastructure models,” IStar conference, 2021.
Please contact:
Christophe Ponsard, CETIC, Belgium
