Figure 2: Evaluation of threats. © Phoenix Contact

From encrypted communication links to special chips for storing electronic keys to processors that only execute digitally signed code, many technical means are available. Appropriate rights and role management can be provided to manage the information of several parties. This provides a robust concept that cannot be easily undermined.

3. secure implementation: understanding the (programming) craft

The clean realization of the design in hardware and software is the second essential element in preventing vulnerabilities. Programming guidelines contain specifications which, if followed, help to prevent typical errors. Examples include the regulations on the correct handling of the length of character strings or the use of special characters. The correct handling of error messages is also very important. True to the motto "If everything goes according to plan, no errors will occur", these instructions are often ignored during development, so that they lead to security gaps in real use. There are programming guidelines that can be used as examples for almost all programming languages. In addition to the dual control principle, tools can also be used to check the implementation, which examine the resulting code for compliance with the guidelines or typical error patterns (static code analysis). If the procedure described is followed, the program is characterized by high quality and fewer errors - also in terms of security.

4. security tests: creating trust

The verification of the safety properties must cover several aspects: For each safety requirement established in the specification, the respective proofs must be provided by tests. In addition, proof of the effectiveness of all security measures defined in the design is required. Furthermore, a manual or automatic check for known vulnerabilities as well as frequently occurring errors and problems must be carried out in order to detect typical implementation errors or already published inadequacies in used subcomponents.

Fuzzing tests are also state of the art: the robustness of the product can be checked by sending randomly falsified data. Finally, an expert should carry out an attack test (penetration test). Independent of the normal team, the expert attempts to overcome the product's security barriers. Due to its autonomy, operational blindness should be avoided. The penetration test can be carried out internally or by a specialized service provider. The procedure described results in a high level of confidence in the security capability of the product.

5. security defect management: addressing vulnerabilities

Figure 3: Basic procedure for potential weak points. © Phoenix Contact

Despite the realization of all tests, the absence of evidence (of vulnerabilities) is not evidence of absence (of vulnerabilities). There is no such thing as a vulnerability-free product. In this respect, ongoing monitoring and the receipt of security reports are an integral part of the product life cycle. Problems that are made public must be evaluated and may lead to security advisories and security updates. The security quality and resilience of the products must therefore be continuously monitored (Fig. 3).

6. security updates: provide patches

Security vulnerabilities are usually rectified by providing security updates, known as patches. These must be tested for side effects and documented in such a way that the user of the product can decide how to proceed. It goes without saying that updates must be made available in such a way that their integrity can be checked. In this way, the security quality and resilience of the products in the field are maintained.

7. security documentation: keep manuals available

To ensure that the product can be used securely, the user requires detailed documentation, for example on the intended operating conditions, the security functions, network connections and integration into central systems, for example for user management or security monitoring. The user is also informed about what they need to consider for the safe use of the product in terms of its setup or operation, for example where information on possible vulnerabilities and available updates can be found. If such documentation is available, the user can take full advantage of the product's security features and qualities.

8. security management: clarifying processes and responsibilities

Figure 4: Overview of the safe life cycle. © Phoenix Contact

Finally - and in reality right from the start - processes and responsibilities must be clarified, employee qualifications must be ensured and all processes must be organized. Ultimately, it must be ensured that no product can be released unless it has passed all security tests and all known security problems have been resolved. This allows users to have full confidence in their supplier (Fig. 4).

Safe life cycle: ensuring quality in the long term

Specific security functions, such as encryption or access control, have not been the focus to date. The international standard IEC 62443-4-2 describes security functions for components that are required with regard to the interaction of security functions in accordance with IEC 62443-3-3. However, the mere presence of these functions is of little help and creates a false sense of security if the function or the entire product is implemented incorrectly. IEC 62443-4-2 therefore requires a secure life cycle in accordance with IEC 62443-4-1.

A product that is developed and maintained in a secure life cycle is always characterized by a high level of security quality that users can trust. By certifying its life cycle process, the product manufacturer underpins this trust. Product certification in accordance with IEC 62443 builds on the secure process and confirms the product properties, but only covers a specific point in time.

Dr.-Ing. Lutz Jänicke is Corporate Product & Solution Security Officer at Phoenix Contact in Blomberg

Literature
[1] https://cwe.mitre.org/data/index.html