Why Industrial Cybersecurity Cannot Be Run Like IT Security
Modern cybersecurity programs are still heavily influenced by IT thinking.
That becomes a serious problem the moment an organization operates industrial systems.
Most incident response procedures were designed for laptops, servers, and cloud workloads. In those environments, isolating a machine, blocking network traffic, killing a process, or rebuilding an operating system is acceptable. Business disruption may occur, but it rarely threatens human safety.
Industrial environments are different.
In Operational Technology (OT) and Industrial Control Systems (ICS), computers are not just processing data — they control physical processes. They regulate pressure, temperature, chemical dosing, turbine rotation, conveyor movement, and electrical distribution. When those systems behave unexpectedly, the impact is not just downtime. It can be equipment damage, environmental impact, service outage, or human injury.
Because of that, applying traditional IT incident response procedures inside an industrial environment can actually make the situation worse.
The Dangerous Assumption: “A Cyber Incident = Shut It Down”
In IT security, containment is simple: isolate the compromised system as quickly as possible.
In ICS/OT, that decision may be unsafe.
Many industrial devices:
-
Cannot be quickly rebuilt
-
Cannot be patched rapidly
-
Cannot be powered off safely
-
Are tightly coupled to physical processes
Shutting down a controller, Human Machine Interface (HMI), or protection relay at the wrong moment may stop a production line, damage equipment, or create unsafe process conditions. A cybersecurity action taken without engineering awareness can unintentionally trigger a physical incident.
This is the central reality organizations must understand:
An IT-led response protects data.
An engineering-led response protects operations and safety.
Industrial cybersecurity must prioritize:
-
Human safety
-
Process stability
-
Operational reliability
-
Then cyber containment
Reversing that order is where organizations get into trouble.
Why ICS/OT Incident Response Is Fundamentally Different
Traditional IT incident response focuses on:
-
Confidentiality
-
Data protection
-
Rapid containment
-
Forensic preservation
Industrial incident response focuses on:
-
Safe operation
-
Process continuity
-
Controlled containment
-
Gradual recovery
Taking a server offline in IT is inconvenient.
Taking a PLC offline may stop water treatment, electricity supply, manufacturing, or critical services.
The same security action has completely different consequences.
This is why industrial response cannot be handled solely by IT security teams. Engineers, operators, and control system specialists must be directly involved in both planning and response execution.
Organizations that include plant engineers and operators in incident response exercises consistently recover faster and make safer decisions during real incidents.
Containment Does Not Always Mean Shutdown
One of the biggest misconceptions in industrial cybersecurity is that containment equals immediate isolation.
In reality, if an adversary’s activity is understood and controlled, maintaining monitored operations may be safer than abruptly disconnecting systems.
A controlled environment allows teams to:
-
Observe attacker behavior
-
Prevent unsafe state changes
-
Avoid sudden process interruption
-
Plan safe remediation
Aggressive containment actions — especially automated ones — can unintentionally create a self-inflicted outage.
Industrial response therefore requires coordinated decision-making between:
-
Cybersecurity teams
-
Control engineers
-
Plant operators
-
Management
Cybersecurity alone cannot make the decision.
The New Threat: Living-off-the-Land Attacks in Industrial Environments
Historically, organizations looked for malware inside industrial networks.
That model is now outdated.
Attackers increasingly do not deploy custom malware at all.
Instead, they use what already exists.
These are known as Living-off-the-Land (LotL) attacks.
Rather than exploiting vulnerabilities, adversaries:
-
Use stolen credentials
-
Access trusted remote connections
-
Operate legitimate engineering tools
-
Issue real control commands
Once inside the OT network, attackers may interact directly with physical processes using normal engineering workflows. From a software perspective, nothing appears malicious because authorized tools are being used.
Examples of attacker behavior include:
-
Modifying controller logic
-
Changing process parameters
-
Issuing control commands via industrial protocols
-
Manipulating HMIs
-
Using scripting tools such as PowerShell from trusted systems
Traditional anti-malware solutions often fail to detect these actions because no malicious executable is present. The attacker is operating as an authorized user.
This is why many recent industrial incidents were not detected until operational impact occurred.
Why Attackers Move from IT to OT
Industrial attacks rarely start in the plant network.
They start in corporate IT.
The common pathway looks like this:
-
Compromise employee credentials
-
Access VPN or remote access systems
-
Move through shared identity infrastructure
-
Reach the OT environment
-
Use legitimate engineering tools
If IT and OT share identity services, remote access, or trust relationships, the attacker does not need to hack the control system. They simply log in.
This is precisely why ICS security cannot be treated as an isolated technical problem. It is an enterprise risk management issue.
Defensive Priorities Organizations Must Implement
To reduce risk from modern ICS/OT attacks, organizations should prioritize the following controls:
1. Network Segmentation Based on the Purdue Model
Proper separation between enterprise IT and control networks allows threats to be contained without shutting down operations.
2. Secure and Monitored Remote Access
All vendor and engineering access must be:
-
Authenticated
-
Logged
-
Monitored
-
Time-restricted
Uncontrolled remote access is one of the most common OT breach paths.
3. Industrial Protocol Visibility
Security teams must see control commands, not just network traffic. Monitoring industrial protocols helps detect unauthorized operational changes.
4. Engineering Change Monitoring
Controller logic, configurations, and setpoints must be baselined and monitored for unexpected modification.
5. Joint Incident Response Exercises
Tabletop and live simulations involving:
-
Engineers
-
Operators
-
SOC analysts
-
Leadership
These exercises dramatically improve real-world response performance.
Why Purpose-Built ICS/OT Incident Response Is Necessary
Industrial organizations often assume their existing incident response plan covers OT environments. In most cases, it does not.
An effective industrial response plan must include:
-
Process safety considerations
-
Engineering decision workflows
-
Operational fallback procedures
-
Controlled containment strategies
-
Coordinated communication channels
Without this, a cyber event can escalate into an operational crisis not because of the attacker, but because of the response.
Final Thoughts
Cyber incidents are no longer purely digital events.
They now have physical consequences.
As industrial systems become more connected, the boundary between cybersecurity and operational safety continues to disappear. Organizations that continue to manage ICS environments with IT-centric response models are exposing themselves to avoidable risk.
Effective industrial cybersecurity is not just about detecting attackers.
It is about responding without breaking the process you are trying to protect.
At Jypra Group, we believe industrial incident response must be engineering-aware, safety-driven, and operationally informed. The objective is not only to stop an intrusion — it is to ensure the organization can continue operating safely while doing so.
Because in ICS/OT environments, the worst incident is not always the attack.
Sometimes, it is the reaction.
