The CERT network has disclosed more than 10,000 IT security vulnerabilities, each year and every year, in products worldwide in accordance with the concept of “Common Vulnerability Enumeration (CVE).

And there surely are far more unrecognized or unpublished weak points. So, how can we do something about this situation?

At first glance, the CVE concept provides a complete solution. Every notification is assigned to a type of vulnerability (Common Weakness Enumeration), for example, CVE-20: “Improper Input Validation.” However, it’s hardly possible to strive for an absence of errors in all 1248 entries in the databank [1] as a development goal.

So how can high security quality be achieved? To develop a product with few vulnerabilities, a process for a secure life cycle (Security Development Lifecycle) should be used. The IEC 62443-4-1 standard describes such a process for automation systems. The process consists of eight elements, which will be presented in the following.

IT security requirements

Understanding operating conditions and determining protection requirements

The first step is to understand and describe the relevant terms of use for the product. Is the product operated by trusted personnel in a controlled environment? Or is it as uncontrollable as the card terminals installed in supermarkets?

Which information is processed? Is it just data from the user or is there information from another party – for example, a machine builder or integrator – to be considered? By answering corresponding questions, the need for protection of the product and its functions and data can be determined, and threats can be worked out.

Here, hazards can arise, for example, from the manipulation or readout of data during physical access. If several parties are involved, threats result, among other things, from the disclosure of a machine builder’s control program by the user.

On this basis, the safety requirements that are decisive for further proceedings are formulated. If the product is endangered in its environment, it has to make physical access difficult and such attempts detectable. If information from different parties is to be protected, it proves necessary for the rights management to separate accesses cleanly.

The security objectives also include determining the level of security that is to be achieved and that is based on the attacker’s strength. If greater values are to be secured, more attacks will have to be repelled. As a result, the security requirements should be complete when designing and implementing the security concept so that they can be included.

Evaluation of threats.

Security by design

Build up a resilient concept

The product is now designed in a way that its structure and functions meet the protection objectives and it is able to repel the threats mentioned above. To this end, proven security concepts such as minimizing execution and access rights, multi-level security mechanisms, and reducing weak points should be considered.

Applying reliable design rules prevents many of the above-mentioned types of vulnerabilities. In doing so, the threat analysis must be continued in accordance with the elaborated draft. Here, the threat arising from potential weak points is assessed to determine the danger. Only when it is considered unlikely enough for all possible damages to occur, the residual risk can be accepted. The security of the design is supported by a four eyes principle.

From encrypted communication connections to special chips for storing electronic keys to processors that execute only digitally signed code, many technical means are available. An appropriate rights and role management can be provided in order to manage the information of multiple parties. This way, we have a resilient concept that cannot be undermined that easily.

Aspired level of protection.

Secure implementation

Understanding the craft (of programming)

The neat realization of the design in hardware and software is the second essential element to prevent vulnerabilities. Programming guidelines contain specifications, the observance of which helps to prevent typical errors.

Examples are the rules for 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 hints are often ignored during development, which leads to security gaps in real use.

Although there are programming guidelines that can be used as examples for almost all programming languages. In addition to the four eyes principle, tools which examine the resulting code for adherence to the specifications or typical error patterns can be used to check the implementation (static code analysis).

If the described way of proceeding is followed, the program is characterized by high quality and fewer errors – also with regard to security.

Security tests

Creating trust

The verification of the security properties has to cover several aspects: For each security requirement established in the specification, the respective evidence must be provided by tests. In addition, evidence is required regarding the effectiveness of all security measures specified in the draft.

Furthermore, a manual or automatic check for known vulnerabilities as well as frequently occurring errors and problems must be carried out in order to uncover typical implementation errors or already published inadequacies in used subcomponents.

The state of the art also includes fuzz testing: by sending randomly distorted data, the robustness of the product can be checked. Finally, an expert should perform an attack test (penetration test). Independently of the normal team, the specialist tries to circumvent the safety barriers of the product.

As the expert is quite autonomous, organizational blindness should be avoided. The penetration test can be carried out internally or by a specialized service provider. The described way of proceeding results in a high level of confidence in the product’s security capability.

General course of action for potential vulnerabilities.

Security defect management

Addressing vulnerabilities

Despite the completion of all tests, the following is still true: the absence of evidence (for vulnerabilities) is not evidence of the absence (of vulnerabilities). Products without vulnerabilities do not exist. In this respect, their ongoing monitoring as well as the receipt of safety messages count as an integral part of the product life cycle.

Problems that become public have to be evaluated and may lead to security notes (advisory) and security updates. Therefore, the security quality and resistance of the products must be continuously monitored.

Security updates

Providing patches.

Security vulnerabilities are usually remedied by providing security updates, so-called patches. These have to be tested for side effects and documented in a way that users of the product can decide on their course of action. Updates must of course be made available in such a way that their integrity can be verified. In this way, the security quality and resistance of the products in the field remain stable.

Security documentation

Providing user manuals

For the product to be used securely, users need detailed documentation, for example on the intended conditions of use, 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 to consider for the secure use of the product in terms of its setup or operation, i.e. where to find information about possible vulnerabilities and available updates. If such documentation is available, the user can take full advantage of the product’s security features and qualities.

General overview of the secure life cycle.

Security management

Settling processes and responsibilities

Finally and, in fact, right from the start, processes and responsibilities need to be clarified, staff qualifications need to be ensured, and all processes need to be organized. In the end, it must be ensured that no product can be released that has not passed all security tests and for which not all known security problems have been resolved. This allows users to have full confidence in their supplier.

Secure life cycle

Ensuring quality for the long term

Specific security functions, such as encryption or access control, have not been in the focus of attention so far. The international standard IEC 62443-4-2 describes security functions for components that are required with regard to the interaction of security functions according to 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. Therefore, IEC 62443-4-2 requires a secure life cycle according to IEC 62443-4-1.

A product that is developed and maintained in the secure life cycle is always characterized by high security quality that users can trust in. With the certification of the life cycle process, the product manufacturer supports this trust.

A product certification according to IEC 62443 is based on the secure process and confirms the product properties, but always covers a specific point in time only.

Dr.-Ing. Lutz Jänicke, Corporate Product & Solution Security Officer, Phoenix Contact