IT security management
Efficient IT security management
If IT security management is to be set up in production, threats and risks must be assessed and economic countermeasures taken. For the operator, technical and commercial considerations must go hand in hand. The security provider must document and maintain the desired level of security.
The assets to be protected must first be identified as the basis for implementing IT security management. These range from the availability of production facilities to specific know-how and material assets. Once the relevant threats have been identified, the risks can be assessed and countermeasures planned. According to the IT baseline protection glossary, a threat is a "circumstance or event that can cause damage". The recording of threats can be very extensive. Catalogs such as the threat catalog from IT baseline protection provide good support. Special catalogs exist for certain scenarios, for example from the "Open Web Application Security Project". To begin the threat analysis, the focus should be on the greatest potential damage. This could be a production outage.
The operator knows his application conditions and can therefore specify the possible level of damage and an economic assessment for the risk assessment. They can forego unprofitable activities and accept a risk instead. It is important that the threats and risks are transparent and complete as a basis for decision-making. The provider of a product or solution must base its threat and risk analysis on assumptions. These should reflect the conditions of use as closely as possible. For the provider, only those threats that directly affect their offering are relevant. They then describe the intended use in their security documentation so that the buyer, the operator or another stakeholder in the value chain can assess the suitability of the solution for their purposes.
The provider now also carries out its risk assessment and implements the activities. It is bound by its promised security features and cannot tacitly approve risks because, for example, the costs incurred do not appear reasonable. In such a case, the provider would either have to restrict the intended use or document the remaining threat and, if necessary, propose compensatory measures. The buyer can then make a decision on this basis.
Security level is only indirectly dependent on the individual devices
If the provider wishes to carry out a technical risk assessment, they must have a technical understanding of the extent of the damage. The "Common Vulnerability Scoring System" (CVSSv3) recommends a breakdown, the highest level of which is described as "critical". In the event of data loss, for example, the impact could range from "unimportant data lost" to "important data lost and unrecoverable". To assess the likelihood of risks occurring, the factors required expertise and resources as well as the route of attack and necessary preconditions are often taken as a basis. Ultimately, both the extent of the damage and the probability of occurrence are based on an expert assessment that depends on the intended operating conditions.
One area of tension in threat and risk analysis is the interaction of individual aspects in the system. Secure components are required to build a secure system. However, the achievable security level depends only indirectly on the security properties of the devices. For example, insecure components can be operated in a secure system if they are isolated by upstream measures and can only be addressed by other secure systems.
The risk assessment for a component or system can change quickly if a vulnerability is found. The cause often lies in an implementation error. The aforementioned CVSS has become established for assessing the severity of a vulnerability. Similar to the normal technical risk analysis, the exploitability of the error is assessed on the basis of the attack vector and the attack paths. In addition, an assessment is made of the impact in terms of confidentiality, integrity and availability ("base score"). As a result, the user only receives a number between 0 and 10 for assessment.
Different assessment of vulnerabilities
In this case, a vulnerability in a component does not necessarily have to result in the same assessment at system level. From the operator's point of view, it is quite possible that the assessment of a vulnerability will lead to different results because the provider assumes an assumed usage scenario, but the operator has different protection goals. The CVSS therefore also includes an assessment of the real application conditions ("environmental score"). In principle, however, vulnerabilities should be tracked through the supply chain, the risks assessed and countermeasures initiated.
Phoenix Contact supports its customers along the entire process chain with standardized security. Individual service offers form the basis for the implementation of security concepts during the inventory and threat analysis of existing or planned systems. Security components such as firewalls and secure control systems also contribute to the development of secure networks. From the secure development process to the continuous vulnerability management of the Phoenix Contact PSIRT (Product Security Incident Response Team), security is anchored in the complete life cycle of the products and solutions. Experience and depth of added value support users in achieving their security quality goals.
Dr.-Ing. Lutz Jänicke, Product & Solution Security Officer, Corporate Technology & Value Chain, Phoenix Contact / am














