Listen to this Post
Introduction:
For 60 years, Programmable Logic Controllers (PLCs) were physical boxes bolted to DIN rails, creating a hard boundary between IT and OT. Now, Siemens and Phoenix Contact have launched software-defined PLCs running as Docker containers on Linux, turning industrial control systems into deployable code – and opening a Pandora’s box of new attack surfaces, container escape risks, and real-time网络安全 challenges.
Learning Objectives:
- Understand the architectural differences between Siemens S7-1500V and Phoenix Contact Virtual PLCnext Control from a cybersecurity perspective.
- Learn how to harden containerized PLC deployments on Linux/Windows using real commands and security configurations.
- Identify mitigation strategies for virtual PLC-specific threats including real-time kernel exploits, insecure OPC UA exposures, and CI/CD pipeline poisoning.
You Should Know:
- Containerized PLCs: The New Attack Surface You Can’t Ignore
Both Siemens and Phoenix Contact run their virtual PLCs as containers (Docker/OCI) on standard Linux or Windows Hyper-V. This means traditional OT air-gaps disappear, and every container becomes a potential pivot point. Attackers who compromise a corporate edge node could spin up a malicious vPLC instance, manipulate industrial processes, or use Profinet to brick field devices.
Step-by-step guide to inspect and harden a containerized PLC environment:
First, identify running containers on your industrial edge device (Linux):
List all containers, including stopped ones
docker ps -a
Inspect the vPLC container for exposed ports and volumes
docker inspect <vplc_container_id> | grep -A 10 "Ports|Volumes"
Check for privileged mode (security risk)
docker inspect --format='{{.HostConfig.Privileged}}' <vplc_container_id>
For Windows (Hyper-V + Docker):
List containers in Windows Docker
docker ps -a --format "table {{.ID}}\t{{.Image}}\t{{.Status}}"
Get network isolation settings
Get-VMNetworkAdapter -VMName vplc | FL
Hardening actions:
- Never run vPLC containers in privileged mode. Set `–privileged=false` and add only required Linux capabilities (e.g., `–cap-add=NET_ADMIN` for Profinet).
- Use read-only root filesystems: `–read-only –tmpfs /tmp:rw,noexec,nosuid,size=64m`
– Implement SELinux or AppArmor profiles. Example for AppArmor:sudo aa-genprof docker Generate profile, then enforce sudo aa-enforce docker
2. Real-Time Linux Kernel: Performance vs. Security Trade-offs
Virtual PLCs rely on the Linux PREEMPT_RT patch to achieve deterministic 1ms cycle times. However, real-time kernels introduce unique risks – they bypass many standard kernel security mechanisms (like some locks and interrupt shielding) to guarantee latency. A malicious user process could abuse real-time scheduling to cause a denial-of-service (DoS) on your entire control loop.
Step-by-step guide to audit real-time kernel security and isolate RT processes:
Check if your kernel is PREEMPT_RT:
On Linux uname -v | grep PREEMPT_RT Or cat /proc/sys/kernel/sched_rt_runtime_us
Limit real-time CPU usage to prevent starvation (default is 950,000 µs per 1,000,000 µs):
Set max RT runtime to 90% echo 900000 > /proc/sys/kernel/sched_rt_runtime_us Make persistent echo "kernel.sched_rt_runtime_us=900000" >> /etc/sysctl.conf
Assign vPLC container to isolated CPU cores to prevent cross-core attacks:
Start container with CPU pinning docker run --cpuset-cpus="0,1" --cpu-shares=1024 my_vplc_image Verify with taskset taskset -p <docker_pid>
For Windows (real-time with Hyper-V):
Set VM processor affinity to dedicated cores Set-VMProcessor -VMName vPLC_VM -ProcessorCount 2 -Reserve 100 -Maximum 100 Enable nested virtualization only if needed (increases attack surface) Set-VMProcessor -VMName vPLC_VM -ExposeVirtualizationExtensions $false
- Profinet, OPC UA, and Modbus: Securing East-West Traffic in a Virtualized World
Both virtual PLCs communicate with I/O devices via Profinet RT (real-time) and Modbus TCP/IP. When the PLC is a container, all traffic leaves the host network stack – meaning unencrypted Profinet frames can be sniffed, spoofed, or replayed. OPC UA (often used alongside) has encryption options but is frequently misconfigured.
Step-by-step guide to enforce network security for containerized industrial protocols:
Create a dedicated Docker MACVLAN network for Profinet to isolate from corporate LAN:
Create macvlan for Profinet RT (requires physical interface eth1) docker network create -d macvlan \ --subnet=192.168.10.0/24 \ --gateway=192.168.10.1 \ -o parent=eth1 \ profinet_net
Run vPLC container attached to this network:
docker run --network profinet_net --ip=192.168.10.50 my_vplc
For OPC UA, enforce TLS encryption and certificate validation (example using `opcua-commander` tool):
Install opcua-client pip install opcua-client Test insecure connection (should fail if properly configured) opcua-client --endpoint opc.tcp://<vPLC_IP>:4840 Require TLS with mutual authentication On vPLC host, generate certs: openssl req -x509 -newkey rsa:4096 -keyout server.key -out server.crt -days 365 -nodes Configure vPLC container to mount certs docker run -v $(pwd)/certs:/etc/opcua/certs:ro my_vplc
Modbus TCP/IP mitigation – restrict to specific allowed IPs using iptables on the host:
Allow only specific HMI to access Modbus port 502 iptables -A INPUT -p tcp --dport 502 -s 10.10.10.100 -j ACCEPT iptables -A INPUT -p tcp --dport 502 -j DROP Save rules iptables-save > /etc/iptables/rules.v4
- CI/CD Pipeline Poisoning: The Supply Chain Risk of DevOps for PLCs
Siemens encourages full DevOps pipelines (Edge Hub → Edge Management → Edge Runtime). Attackers can inject malicious code into TIA Portal projects, Docker images, or Helm charts. Since virtual PLCs are software-based, a poisoned container image could be deployed across thousands of edge nodes.
Step-by-step guide to secure your industrial CI/CD pipeline:
Sign your vPLC container images (using Docker Content Trust):
Enable DCT export DOCKER_CONTENT_TRUST=1 Build and push signed image docker build -t myregistry/vplc:1.0 . docker push myregistry/vplc:1.0 Verify signature on deployment docker trust inspect --pretty myregistry/vplc:1.0
Use admission controllers (e.g., OPA Gatekeeper) to enforce Kubernetes policies if using K8s for edge orchestration:
deny-privileged-container.yaml apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sRequiredLabels metadata: name: require-signed-image spec: match: kinds: - apiGroups: [""] kinds: ["Pod"] parameters: labels: - key: "trusted-image" allowedRegex: "^signed-by-siemens|phoenix$"
For TIA Portal projects, implement pre-commit hooks to scan for malicious blocks:
Example using awlcheck (open-source Siemens SCL parser) awlcheck --strict project_folder/PLC_1/Program\ blocks/ --output json | jq '.warnings'
5. Virtual Safety PLCs: When Fail-Safe Becomes Fail-Insecure
Both vendors plan (or already have) virtual safety PLCs (e.g., Siemens S7-1517VF). Safety systems require SIL 3 certification – but a container escape or hypervisor breakout could circumvent safety circuits. Attackers could reset safety timers, suppress emergency stops, or replay safety-related PROFIsafe telegrams.
Step-by-step guide to harden virtual safety PLC isolation:
Use dedicated real-time KVM (not standard Docker) for safety containers:
Install real-time KVM apt-get install qemu-kvm libvirt-daemon-system libvirt-clients Create isolated network for safety virsh net-define safety-net.xml virsh net-start safety-net
Set up Intel TME (Total Memory Encryption) to protect safety PLC memory from host root access:
Check if TME/AMD SEV supported lscpu | grep -i "virtualization" Enable in libvirt domain XML virsh edit safety_vplc Add: <launchSecurity type='sev'>
For Windows Hyper-V, enable Shielded VMs with TPM:
New-VM -Name SafetyPLC -Generation 2 -MemoryStartupBytes 2GB Enable-VMTPM -VMName SafetyPLC Set-VMKeyProtector -VMName SafetyPLC -NewLocalKeyProtector
What Undercode Say:
- Virtual PLCs are essentially Linux containers with industrial protocols – treat them as you would any cloud workload: vulnerability scan images, enforce least privilege, and segment networks.
- The same DevOps tools that accelerate deployment (Docker, Kubernetes, CI/CD) also introduce supply chain risks – sign images, scan for CVEs (e.g.,
trivy image siemens/vplc), and monitor runtime with Falco. - Real-time kernels demand extra vigilance – they prioritize latency over security. Use CPU pinning, sched_rt_runtime_us limits, and avoid exposing RT interfaces to untrusted containers.
Prediction:
By 2028, virtual PLCs will run on more than 30% of new greenfield industrial sites, but a major incident – such as a container escape that shuts down a power grid or a poisoned TIA project that deploys ransomware to 10,000 vPLCs – will force the industry to rewrite OT security standards. Expect ISO 62443 to add an annex specifically for containerized controllers, mandating signed images, real-time kernel lockdowns, and mandatory network microsegmentation. The battle between Siemens and Phoenix Contact will be won not by performance, but by who builds the most robust, attack-resilient virtual runtime.
▶️ Related Video (64% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Jacob Biedulski – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
