Technology
The path to a product with few vulnerabilities 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. This article presents that process consisting of eight elements for successful implementation. 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
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 SOURCE: PHOENIX CONTACT
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
Evaluation of threats.
28
in d u s t r ial et h er ne t b o o k
02.2021
