In this era of increasing digitalization, manufacturers and OEMs have moved into the cross hairs of cyber attackers. Industrial companies understand the importance of both cyber security and safety. All too often, they pursue the two as separate and distinct goals, however. Companies who follow this approach thinking that they will eliminate vulnerabilities actually run the risk of introducing vulnerabilities in their operations. You cannot have security without safety or safety without security. The two go hand in hand.
Security aims to protect assets against (intentional or unintentional) attacks on
through preventive and reactive (technical and/or organizational) measures. Security requires alertness.
Safety, on the other hand, can be defined as freedom from unacceptable risk related to physical harm to humans and equipment, and negative impact to the environment. Safety requires prevention. Functional safety, for example, involves preventing dangerous situations by limiting the motion of the machine using safety rated drives and controllers. Functional safety does not encompass all the safety factors, however, and safety is only effective when it is implemented with security. Let’s take a closer look.
Security and safety are different
In safety we are used to transparency of methods, measures and effects whereas in security confidentiality is a powerful weapon. Safety is looked upon as a rather static field whereas security is considered highly dynamic when it comes to addressing system vulnerabilities. Finally, foreseeable misuse is really only an issue for safety systems. When personnel misuse the product or system, however, it’s generally because they want to speed up or simplify the manufacturing process, not with criminal intent.
The list of differences does raise the question: how can these two disciplines with different experts, methods, processes, timelines, laws, and technical regulation be integrated? Let’s start by considering the preconditions involved in both safety and security.
Developing a safety strategy typically begins with a safety integrity level (SIL) assessment, as defined by the ISO12100 standard. This standard basically says that the risk related to a specific hazard is a function of the severity of harm. What is the probability that a person is in a hazardous area or that the hazard occurs or that you can avoid or limit the harm? These preconditions determine the reduction measures used. It’s important to note that the SIL level determined after the assessment is not actually a measure of the risk involved — it is a measure for the risk reduction.
The higher the SIL, the higher the level of risk reduction required. Unfortunately, both discussions consider only safety related to the SIL related system. We often forget that functional safety is only a subpart of overall industrial safety.
Security also has preconditions, although they differ from those of safety. It starts with determining the type of attack. Is it likely to be a random, unintended malware attack or the organization prepare for a sophisticated, targeted attack?
Next who or what is the target? Following the CIA principles, attacks don’t necessarily target system integrity. Attacking confidentiality or availability can do just as much damage.
What is the level of competence of the attacker? Is it a state-organized cyberattack or is it a young programmer testing his skills? Where does the attack originate from? Is the attacker an insider, an outsider, or an outsider with inside knowledge?
Do we have an attack over technology or do we have an attack over the human factor (plugging in a corrupted USB stick, for example), as well? What are the chances of limiting the damage if we identify an attack? What kind of countermeasures do we have at our disposal in such a case?
Both safety and security involve complex preconditions, but those preconditions are often disregarded. The discussion of safety and security often focuses on the SIL and the system but the preconditions above also have to come into play.
The pitfalls of safety-related security
Some safety engineers claim that they only look at security related to safety but is there really anything like safety-related security? When looking at a machine or a plant, we can identify examples of indirect safety relations that depend on system performance. For example, if a power supply system does not perform, it creates an indirect safety issue.
We also have direct safety relations, such as electrical safety and functional safety. As you can see, functionality safety is only a subset of overall safety. Therefore, the security countermeasures of a plant should be derived from a so-called threat-risk assessment and not from the existence of the safety function only. We need to protect the whole plant, not only a part of it.
Security risk assessment addresses possible safety issues based on the CIA principles described above. In case of a possible attack scenario, it is also feasible to have a specific safety relation to it. This approach involves a more holistic view of safety and security.
The security environment
To take these factors into account, we need to define a security environment. The security environment should be understood as the sum of all security countermeasures that derive from the threat risk assessment. It is a collection of all measures and safety related systems in the operational environment. The security environment should consider all the measures from the risk assessment.
The security environment should be built up of nested layers of security (see figure 1). This “defense-by-design” approach typically incorporates:
- Physical security features such as coded locks and biometric recognition devices
- A network security system that protects production networks and industrial communications by means of firewalls and VPMs.
An integrated system that protects terminals and automation systems by either antivirus software or wireless methods that only grant access to white-listed programs.
Your security environment should prevent any attacks on your operational environments (see figure 2). The security countermeasures are to be provided in functional units of the technical system or they can be part of any system, process, or people. Any safety investigation is based on the assumption that there are effective security countermeasures in place.
The truth about vulnerability
In general, vulnerability means that there is an attack path through or in the system which relates to a threat scenario. Vulnerability should not be understood as an error of the technical system. Given enough effort, energy, money, etc., an attack path can be found in almost any system. It does not imply that the developers made an error.
Paradoxically, a vulnerability can mean that a safety system generally strong against component errors could lead to a dangerous state because its strength is at the same time its weakness in terms of system availability. A machine might have a lot of diagnostics and safety measures that could be used to make it fault out. The target of the attacker would be to compromise the availability of the production system unless a ransom is paid, perhaps. This is an example of a strong feature that can result in a weakness, as well.
Co-engineering is the key
We start by taking into account all of the preconditions and parameters discussed above. We conduct a safety risk assessment, identify appropriate safety measures, and build a safety design. We also conduct a threat-risk assessment related to the CIA principles, taking into consideration safety as well (see figure 3). The latter is one of the most important points. We can’t identify security countermeasures until we take safety into account. At this point, we design the security environment and implement safety and security together.
Regarding the implementation level, many things such as design, classical safety elements, performance criteria, etc. have to be brought together in the final system. Security preconditions need to be holistically considered and the safety realizations investigated in relation to the security domain context. The latter needs to be supported by a safety expert and the decisions for the system realization are made through the risk assessment and the integrated process.
So at the end, both safety and security deliver specific requirements to the system. They cannot be considered separately. Safety methods do not provide protection against intelligent attacks. Safety-related security is not sufficient to protect the plant. Safety cannot protect its integrity if the security methods fail. The final conclusion from all of that is the secure environment is a necessity for the automation solution; otherwise functionality and availability cannot be guaranteed.Have an Inquiry for Siemens about this article? Click Here >>