Critical Infrastructure Attacks: Engineering Principles for Systems That Must Never Fail

Sweden's National Cybersecurity Centre (NCSC-SE) attributed a destructive cyberattack attempt against a Swedish thermal power plant to Sandworm, the GRU-linked APT group that previously executed the 2015 and 2016 Ukraine power grid attacks and deployed the NotPetya malware. The attackers gained initial access through a compromised contractor with remote access to the plant's operational technology (OT) network, then attempted to manipulate industrial control system (ICS) parameters to cause physical damage to plant equipment. The attack was detected and stopped before physical damage occurred, but it exposed the fundamental vulnerability of OT environments that have been connected to IT networks in the name of operational efficiency: the IT/OT convergence that enables remote monitoring also creates pathways for attackers to reach systems where digital commands translate into physical consequences.

What Happened and Why It Matters

The attempted attack on the Swedish thermal plant is part of a documented campaign by state-sponsored threat actors to pre-position in the critical infrastructure of NATO member states — establishing persistent access that could be activated during a geopolitical crisis to disrupt heating, electricity, water, or transportation services. Sandworm's track record makes this threat credible: their 2015 attack on Ukraine's Ukrenergo power grid caused a six-hour blackout affecting 225,000 customers; their 2016 attack deployed custom ICS-targeting malware (Industroyer/Crashoverride) designed to directly manipulate substation control systems.

For engineering teams building software that interfaces with or controls industrial processes — SCADA systems, building management systems, smart grid components, water treatment monitoring, manufacturing execution systems — this is not an abstract threat. The attack surface of industrial control systems is expanding as organisations connect legacy OT equipment to IT networks for remote monitoring and data analytics. Every new connection is a potential attack path. The engineering discipline of OT security is about designing those connections in ways that preserve functionality benefits while containing the blast radius if the IT network is compromised.

IT Security vs OT Security: The Critical Difference

IT security and OT security share many concepts but differ fundamentally in their priorities, constraints, and acceptable risk profiles:

• Priority hierarchy is inverted — IT security prioritises confidentiality first (CIA triad). OT security prioritises availability first (AIC: Availability, Integrity, Confidentiality). A brief email outage is inconvenient. A brief outage of a thermal plant's boiler control system can cause equipment damage, environmental releases, or physical harm. Patching an OT system requires scheduled downtime that can take months to coordinate — a completely different calculus from IT patch management.
• Extremely long system lifecycles — OT systems routinely operate for 20-30 years. A SCADA system running Windows XP with no patches is not unusual — the software may be certified for a specific OS version and cannot be easily migrated. Security engineers must design compensating controls around systems that cannot change.
• Safety and physical process constraints — OT systems connect to physical processes that have safety envelopes — temperature ranges, pressure limits, flow rates. Cybersecurity controls that could interfere with safety systems are not permissible. Security must never come at the cost of safety.
• The IT/OT convergence attack surface — Historical OT security relied on physical and logical isolation — air gaps and proprietary protocols (Modbus, DNP3, PROFINET). IT/OT convergence has eroded these boundaries, creating IT-to-OT pathways that can be traversed by attackers who first compromise the IT network — which is significantly easier to attack than a well-designed OT network.

Engineering Principles for Critical Infrastructure Systems

The following engineering principles apply to any team building or securing systems where software failure has physical consequences:

• Design zones and conduits, not flat networks — The IEC 62443 standard defines a "zones and conduits" architecture that segments OT networks into security zones based on criticality, with explicitly designed conduits between zones. The most critical zone — where PLCs and RTUs connect directly to physical processes — should have the strictest access controls and most limited connectivity. No zone should have direct connectivity to the corporate IT network or the internet.
• Implement network DMZs at IT/OT boundaries — Where data must flow between IT and OT networks, implement a DMZ with dual firewalls, data diodes (hardware-enforced one-way data flow), or unidirectional security gateways. A data diode physically prevents data from flowing from IT to OT — it is the gold standard for protecting process control networks.
• Minimise remote access and make it hardware-authenticated — Every remote access session to OT systems should require hardware MFA (FIDO2 or certificate-based), should be recorded, should be time-limited, and should go through a jump host in the DMZ with session recording — not directly to control system components.
• Design for safe failure modes, not just failure prevention — In OT environments, you cannot assume security controls will prevent every attack. Design control systems so that a compromised network connection results in a safe state. Hardware safety interlocks that enforce physical process limits provide a last line of defence that a software attack cannot override.

What Engineering Teams Should Do

If you are building software that monitors, controls, or interfaces with industrial or infrastructure systems, OT security is not optional — it is an engineering discipline as fundamental as the control algorithms themselves. The convergence of IT and OT has made software engineers responsible for systems where incorrect behaviour has physical consequences. The engineering principles are different, the threat models are different, and the testing requirements are different.

Pillai Infotech has engineers with experience in industrial automation, SCADA systems, and building management systems who understand both the software engineering and the security engineering required for OT environments. Our cybersecurity engineers can assess your OT security architecture against IEC 62443 standards and design compensating controls for systems that cannot be patched. For teams building custom industrial software, our software development practice includes OT-specific threat modelling and security testing as part of every industrial project.

Frequently Asked Questions