Safety & Security
There is no safety without security. At the same time, some established IT security best practises contradict safety requirements. For example, security best practices require the deployment of critical system updates as soon as they are available, and this can conflict with software-assurance regulations. In addition, further challenges are waiting along the way: strong passwords and the application of a password lockout policy doesn’t support quick access in case of an emergency; antivirus software might suddenly - after an update - stop execution of a critical process. Such conflicts put the responsible organisations into a difficult situation since safety depends on security and both need to be managed adequately as part of due care of infrastructure operation.
The problem of integrating safety and security requirements into one common solution is a general concern of operational technology (OT). Hence, besides the well-known best practises of IT security, in some respects different concepts and best practises for securing operational technology evolved. IT security focuses on protecting data, OT security is concerned with protecting operational processes.
System architecture supporting safety and security
In safety-critical environments Frequentis suggests the introduction of protection zones to apply the appropriate IT and OT security concepts to the correct places. Protection zones are defined as a collection of hardware, software and personnel with a common trust level.
Frequentis systems usually comprise three different protection zones with adequate isolation between them: The internal zone with no direct connections to other systems, the shared zone with connections to other “trusted” networks, and the public zone with connections to a non-trusted environment (e.g. public network). When the Frequentis subsystem is integrated into the overall system on site, it is - on one hand - important to respect the protection zones and - on the other hand - to care for the overall system security. A subsystem’s security is depending on the overall system security.
To integrate safety with security, different operational practises can then be applied specifically for each protection zone to focus on safety (internal zone) or on high connectivity (public zone). Examples are: Frequent patching in the public zone versus safety assured software revisions in the internal zone; strict account lockout policy in the public zone (fail secure) versus access monitoring without automatic lockout in the internal zone (fail safe).
This architecture allows balancing of safety and security in an adequate and specific way based on a risk-based approach (in contrast to a purely compliance-based approach).