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).

The Frequentis system security policy defines the baseline for secure design, secure coding, and security verification of Frequentis products. The policy is based on the most important system security standards from different countries of the world, such as BSI Grundschutz (Germany), NIS (U.S.), ISM (AUS), etc. It allows for an effective implementation of customer-specific security requirements on top of the standardised baseline.

Also, when several Frequentis products are combined or customised and integrated with third party components into a customer specific solution, the system security policy is applied. The security initiation at the beginning of the project is an important milestone, where the applicable security requirements are determined in agreement with the system security team, a security risk assessment may be carried out if required and the protection zones are defined.

Before delivery, the completeness of the security implementation is verified. After delivery, the system is handed over to the customer. At this time, the system operator takes over the responsibility for keeping the system secure during operation. Passwords and keys are handed over from Frequentis to the customer along with the secure operations guideline. This marks the beginning of the maintenance phase. Since security of a system may deteriorate rapidly as attackers develop new attack vectors, security must be maintained day-to-day.

Every required task for maintaining the security of a system needs to be done by somebody. However, the way in which security tasks are split between system operator, vendors and - if applicable - integrators can be shaped in very different ways. Some system operators have their own full blown operational security team and only would ask for minimal generic security support services such as application patch provisioning and testing of patches to ensure compatibility with the standard products they bought.

Others may operate customised systems instead of standard products or may want to maintain their product releases for an extended life-time. In these cases, dedicated system specific security support services will be required. Again, other system operators may want to transition as much of the security tasks as possible to their vendors. Instead of operating their own operational security team, they want to purchase extended security support services from their vendors, integrators or a third party. Whatever the specific collaboration scenario would be, all involved stakeholders share a common goal - to enable the system operator to prove due care to the regulator or authority at any given time.

A word about legacy systems

Many organisations operate legacy systems which were designed and procured years ago. Although these systems may still provide up-to-date functionality and productivity, it’s the landscape of cyber threats and the solutions for defending systems that have changed. If the security of these systems has not been continuously updated it is advisable to carry out a security health check.