DISCAIMER: this article is not only for organization that have already been hacked… The IEC 62443 is a generic standard recognized as applicable across critical sectors such as manufacturing, energy, transportation, healthcare and many others.
This article is the first episode of a series of 8, covering main practices to be implemented by any organization aiming to meet the State-of-the-Art in Cyber Security for industrial and automation control systems. Based on a pragmatic approach to the standard part IEC 62443-4-1 defining requirements related to a secure development lifecycle, this article gives you a guidance on how to handle such activities across your current organization processes.
In order to systematically develop secure products, security must be emphasized throughout the whole software lifecycle, such that the results are secure by design. Thus, every phase of a common software lifecycle has to be enhanced with security practices. This leads to a secure development lifecycle as illustrated below. In this first episode, we will focus on the practice required to define a security target: The Threat Analysis
Threat Analysis practice consists in a process to be implemented by organization to fulfill the following requirements extracted from the IEC 62443-4-1:
- A threat model with the system’s architectural elements, assets, security context, attack vectors, and trust boundaries shall be specified.
- Threats shall be identified, including the assessment of their unmitigated and residual risk.
- Countermeasures that contribute to the component requirements (CRs) and their enhancements (CR-REs) shall be defined .
- The traceability of work products, from threats to countermeasure requirements and test cases shall be ensured.
Some additional requirements can be formalized in order to ensure an efficient approach for threat analysis:
- The threat analysis process shall be integrated into the existing development process (ex. V-model or others) and agile approach.
- The effort for threat analysis during product development shall be as low as possible (reasonable and manageable).
- The threat analysis process shall be accepted by all stakeholders.
- Stakeholders should be supported by software tools to ensure a consistent approach and avoid errors
Using the results of such analysis, a secure design can be created which specifically targets the identified threats with appropriate countermeasures on an architectural level. This last topic will be the subject to the next episode (Ep.2). You find below a description of the 5-steps approach:
Step 1 – Context Specification
Through this first step, the system architecture and its security context are specified in a threat model. The system architecture is specified as a data flow diagram that contains the components interacting with the system’s environment, their assets, their interaction path, and the used communication technologies. In addition, trust boundaries are specified to identify different zones of trust. To build this threat model, several tools can support the management of the information in a structured way. For example, Microsoft provides a Threat Modeling Tool (MS-TMT) which is available for free. It supports threat analysis by providing so-called threat model templates that define usable types of model elements.
Step 2 – Threats Identification and Assessment
In this second step, threats to the system specified in Step 1 must be identified and analyzed based on a predefined methodology which could be different depending on the system context and application sectors. The STRIDE methodology is an example between many. It defines an approach allowing the identification of threats related to following aspects: Spoofing, Tampering, Repudiation, Information disclosure, Denial-of-service and Elevation of privileges. Tools can support your processes by automatizing threat generation based on system definition.
For risk assessment, organizations determine threat severity based on standardized or self-defined levels. In addition, they determine threat likelihood by combining four additional metrics derived from the IEC 62443 security level definition and for example from the well-known Common Vulnerability Scoring System (CVSS – https://www.first.org/cvss/calculator/3.0). These are required skills, required resources, required privileges, and attack vector. The result of Step 2 is a list of threats with their unmitigated risk as required by IEC 62443.
Step 3 – Countermeasures and Security Requirements Definition
In the third step, countermeasures that mitigate the threats identified in Step 2 are defined . For traceability, each countermeasure requirement is linked to the threats it mitigates and to the IEC 62443 CRs/CR-REs it contributes to.
Step 4 – Assessment of Residual Risks
In the fourth step, the residual risk (after implementation of countermeasures) of each threat is determined . This risk is evaluated using the same assessment approach as for the unmitigated risk in Step 2. If the residual risk is considered as not acceptable, additional countermeasures have to be defined by returning to Step 3. After Step 4, the results are a list of threats with unmitigated and residual risk and a list of countermeasures mitigating those threats and contributing to the standard’s CRs/CR-REs
Step 5 – Specification and Implementation of Countermeasures
Finally, this fifth step consists in the design and the implementation of countermeasures in accordance with the existing development process.
After Step 5, whenever the system is changed such that the threat model is no longer in sync with the development state (e.g., at the start of a new sprint), the threat analysis process must be repeated from Step 1. The threat model is updated to reflect the system changes, newly introduced threats are analysed, countermeasure requirements are revised/added, and the risks are updated.
Even if 62443 compliance is not a target, threat analysis should be considered as one of the main best practices to be initiated and handled by organization dealing with several types of assets. It facilitates the understanding of cyber security related aspects by all stakeholders and minimize cyber risks by ensuring a pragmatic approach supporting the identification of those risks at an early stage of the concept.
If you have any questions about threat analysis approaches and/or certification criteria, please do not hesitate to contact our cyber security specialist: Kilian Marty