Security configurations in operational technology (OT) networks are increasingly critical yet complex and error-prone when managed manually, often due to intricate certificate management and protocol-specific processes.This paper proposes a novel approach to automate the verification of OT security configurations, minimizing misconfigurations and enhancing the correct application of protection mechanisms. We introduce an AutomationML-based architecture to model OT environments as a digital twin, a data model capturing security configuration parameters exemplified with PROFINET including a proposed configuration for the unspecified entities, and a formal language extending predicate logic for protocol-independent rule verification. Using a Python-Prolog implementation, our automated verification tool processes an AutomationML InstanceHierarchy to detect incomplete and inconsistent configurations that preclude the establishment of secure communications. Applied to PROFINET, our prototype successfully identifies issues like unsupported algorithms or missing certificates, demonstrating applicability while remaining extensible to other protocols.

With the advent of the cryptographic security ex-tensions for PROFINET Security Class 2/3, as specified by PROFIBUS & PROFINET International, there arises a signif-icant difference between the establishment of a conventional (insecure) and a secure application relation (AR). However, to the best of our knowledge, there is no study yet that numeralizes how much delay is induced by the computational and communication overhead of the secure AR establishment. Therefore, we study its performance by runtime measurements using an experimental hardware setup. We answer two research questions: (1) how much additional runtime delay is induced by the currently specified security extensions when performing a secure AR establishment, and (2) what is the impact of currently unspecified options to reduce this delay? In particular, we study the options to use the Extensible Authentication Protocol (EAP) with Transport Layer Security (TLS) for full handshakes and session resumption, version 1.2 and 1.3, certificate-based and pre-shared-key-based (PSK) ciphersuites, as well as EAP-PSK. We gain the insight that the currently specified extensions lead to a best case delay of 17.5 ms and a worst case delay of 288.6 ms for full handshakes and to 7.3 and 9.8 ms for resumed sessions. With the currently unspecified option to use pre-shared-key-based ciphersuites, yet providing perfect forward security, the best case delay for full handshakes is reduced by 25.7 % and the worst case delay by 91.1 %. With the currently unspecified EAP-PSK option, which does not provide PFS, the largest reduction is achieved by 78.4 and 98.7 % related to best and worst case full handshakes. The authors are members of the PROFINET Working Group CBIPG 10 Security.

As cyber-attacks and functional safety requirements increase in Operational Technology (OT), implementing security measures becomes crucial. The IEC/IEEE 60802 draft standard addresses the security convergence in Time-Sensitive Networks (TSN) for industrial automation.We present the standard’s security architecture and its goals to establish end-to-end security with resource access authorization in OT systems. We compare the standard to our abstract technology-independent model for the management of cryptographic credentials during the lifecycles of OT systems. Additionally, we implemented the processes, mechanisms, and protocols needed for IEC/IEEE 60802 and extended the architecture with public key infrastructure (PKI) functionalities to support complete security management processes.

We provide a brief overview of the cryptographic security extensions for PROFINET, as defined and specified by PROFIBUS & PROFINET International (PI). These come in three hierarchically defined Security Classes, called Security Class 1,2 and 3. Security Class 1 provides basic security improvements with moderate implementation impact on PROFINET components. Security Classes 2 and 3, in contrast, introduce an integrated cryptographic protection of PROFINET communication. We first highlight and discuss the security features that the PROFINET specification offers for future PROFINET products. Then, as our main focus, we take a closer look at some of the technical challenges that were faced during the conceptualization and design of Security Class 2 and 3 features. In particular, we elaborate on how secure application relations between PROFINET components are established and how a disruption-free availability of a secure communication channel is guaranteed despite the need to refresh cryptographic keys regularly. The authors are members of the PI Working Group CB/PG10 Security.