NOTE: This article is not only for organizations 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 second episode of a series of 8, covering the 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, this article guides you on how to handle the definition of requirements related to a secure development lifecycle (IEC 62443-4-1) within 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 second episode, we will focus on good practices required to build a secure system right from the beginning, the Secure Design Process.
The term security by design describes practices used to ensure that a product is secure and followed defense in depth principles right from the beginning of the design phase. Processes required for secure design are required to be applied to all stages of product design, from conceptual design to detailed one, and to all levels of product design from the overall architecture to the design of individual components.
Four main topics are addressed for secure design in standard part 62443-4-1. These points are described below.
First, secure design documentation is required to ensure that security for access to assets is comprehensively addressed from the perspective of external and internal interfaces of the product through which attacks can be mounted. Having this process means that interfaces of the product are identified and characterized by the interactions that take place over them (for example, data and control flows), the security mechanisms designed to protect them and the assets that can be compromised if not adequately protected. Viewing interfaces within the setting provided by the product security context allows the secure design to focus on the specific environment in which the product is expected to operate, including both protections offered by the product security context and vulnerabilities resulting from it. An example is presented below. The same question should be answered for each interface in a systematic approach:
Second, Defense in depth design is required. This principle consists of providing multiple layers of security to thwart security threats. Each layer of a defense in depth strategy is designed to protect the assets from attack in the case that all other layers have been compromised. A process shall be employed to implement these multiple layers of defense using a risk based approach based on the threat model.
For exemple, the TCP/IP stack could check for invalid packets, an HTTP server could authenticate input, and then another layer could validate that the input and audit logs are produced for administrative changes. Each layer provides an additional defense mechanism, has a responsibility and provides attack surface reduction for the next layer. Each layer assumes that the layer in front of it can be compromised. The following figure presents this approach in a larger scale.
Third, security design review are required to to ensure that the secure design addresses the requirements and threats defined for the product, and that design best practices have been followed (see last topic). All discovered security-related issues are to be documented and tracked. Having this process means that each version of the design is reviewed to determine:
- whether any product security requirements have not been adequately addressed by the defense in depth strategy
- whether there are threat vectors (paths for threats to follow) that bypass the defense in depth strategy or that are otherwise capable of breaching the defense in depth strategy.
In either case, the threat model is to be updated to reflect security-related issues discovered as a result of the review process.
As a fourth and last topic, secure design best practices are required to ensure that guidance is provided to developers to help them avoid common pitfalls during design that could lead to later security issues. Having this process means that the product supplier has a list of security best practices that is maintained and followed during the development of the secure design for the product. These best practices should be based on commonly accepted security best practices in industry for the type of product being developed. It is completely up to the supplier to determine which practices they consider to be most appropriate for their design practices. These practices are kept current as a result of both changes in the industry and the application of lessons learned by the product supplier.
Examples of best practices below:
- least privilege (granting only the privileges to users/software necessary to perform intended operations);
- using proven secure components/designs where possible;
- economy of mechanism (striving for simple designs);
- using secure design patterns;
- attack surface reduction;
- documenting all trust boundaries as part of the design;
- removing debug ports, headers and traces from circuit boards used during development from production hardware or documenting their presence and the need to protect them from unauthorized access.
Even if 62443 compliance is not an ultimate target, secure design process should be considered as the baseline to be implemented and handled by organization developing secure product.
If you have any questions about secure design processes and/or certification criteria, please do not hesitate to contact our cyber security specialist: Kilian Marty