4 big mistakes to avoid in OT incident response

When it comes to incident response, many organizations assume that the training and preparation they have done for the IT side of their networks extends to their operational technology/industrial control systems environments. While they may appear to share many similarities, OT security requires different protocols, objectives, analysis, forensics, and other security methods. What works successfully in an IT network may be problematic for conducting incident response (IR) in an OT/ICS environment, where availability and safety of operations must be maintained.

Organizations must understand the key differences to navigate around gaps and pitfalls that could prevent a successful OT/ICS IR scenario.

These are the most common areas we see organizations need some help with during our incident response simulation assessments.

Shutting Down First, Asking Questions Later

In an IT environment, isolating or shutting down the system to prevent further infection is a normal and relatively common practice. In an OT environment, isolation or shutting down a system has much more substantial ramifications.

For example, in the Colonial Pipeline attack, they responded to an attack in the IT systems. To ensure it did not spread to OT systems, they shut those down as well, even though the ransomware did not reach the OT level. The move was in line with their culture of safety. But a shutdown of OT systems has a higher cost per minute of downtime and requires longer to get running again. An IT server can be taken offline and a new one created and stood up in about a day if the entire IT department works on it. In Colonial’s case, it took five days after the ransom was paid to stand the pipeline’s OT network backup to regular operations.

Stopping the Attack and Starting Remediation Too Early

IT security personnel in a security operations center (SOC) traditionally do not have intimate knowledge of the OT systems, and OT equipment is much more sensitive to data transfer. The SOC team members may get an alert of something happening in the OT system, and if they jump to conduct a scan for vulnerabilities, they can easily overwhelm the system, denial-of-service style. That means it will cease to function and cause a massive loss in productivity. It also requires the OT engineer to go in and fix the mess, which can be an unnecessary source of additional frustration during an already stressful time.

To read the complete article, visit Dark Reading.