Back
Beyond Visibility: What Effective OT Defense Looks Like
Featuring insights from DirectDefense’s fireside chat with Christopher Walcutt and Charly Bun
Watch the Full Webinar
OT environments were never designed to operate like traditional IT environments. Many of the systems and protocols still in use today were built decades ago, before cybersecurity, remote access, cloud connectivity, and today’s threat landscape were part of the equation.
The technology may not have changed dramatically, but everything around it has.
In a recent fireside chat, DirectDefense Chief Security Officer Christopher Walcutt and Senior Director of MSSP Charly Bun brought together the OT and SOC/MDR perspectives to discuss what they’re seeing across industrial environments, where organizations continue to struggle, and what it takes to defend OT today.
Here are five key takeaways from the conversation.
1. OT Technology Hasn’t Kept Pace With the Threat Landscape
Industrial environments can contain equipment that has been operating for 15, 20, or even 25 years. Many protocols used to communicate with these systems, such as Modbus, DNP3, and vendor-specific protocols like Siemens S7, were created without the security capabilities organizations expect today.
At the same time, OT environments have become more connected. Cloud platforms, remote access, third-party vendors, IP-connected physical security systems, and IT/OT convergence have created new pathways into technology that was never designed for this level of connectivity.
Third-party access is a particular concern. Specialized equipment often requires support from manufacturers or integrators, sometimes through remotely accessible devices or jump hosts.
Organizations need to know who can access their OT environment, how they’re connecting, what they can do, and whether that activity can be monitored and controlled.
2. Visibility Isn’t the Same as Detection
OT visibility platforms can provide valuable insight into industrial assets and communications. But seeing an asset or generating an alert doesn’t tell you whether something malicious is happening.
Effective detection requires context and a baseline of normal activity.
Two facilities owned by the same organization can use similar equipment but operate very differently. Security teams need to understand normal communications, maintenance activity, engineering changes, operating states, and the physical processes those systems control.
Consider a stop command sent to a turbine. The command itself may be legitimate. But what if it happens at 2 a.m., originates from an account that rarely performs that action, or follows suspicious authentication activity on the IT side?
That’s where the SOC becomes important. Analysts need to correlate OT telemetry with identity, endpoint, firewall, remote access, and other IT signals to understand the intent behind an action.
Visibility tells you something happened. Context helps determine whether it matters.
3. OT Incident Response Has to Protect the Process
When a SOC identifies a compromised IT endpoint, isolating it may be an obvious first step. That approach doesn’t always translate to OT.
Taking a PLC offline could stop a manufacturing line, interrupt power generation, affect a water process, or create a safety issue. Before taking action, responders need to understand what the technology is actually controlling.
An OT incident response plan should answer questions such as:
- Who has the authority to isolate critical equipment?
- Can the process continue manually if systems become unavailable?
- How will engineering teams and the SOC communicate during an incident?
- Are PLC logic and critical configurations backed up?
- How will the organization safely return the process to normal?
That also changes how a SOC handles escalation. Plant operators and engineers may not be monitoring tickets or email around the clock. Organizations need defined call trees and escalation procedures that connect the SOC with the people who can make operational decisions.
Those processes should be established and tested before an incident occurs.
4. If You Can’t Patch It, Protect Around It
Vulnerability management becomes more complicated when critical OT systems can’t be patched because of uptime requirements, vendor restrictions, maintenance schedules, or concerns about disrupting operations.
In those situations, defense in depth becomes critical.
If a device can’t adequately protect itself, teams need to understand exactly what it does, what it needs to communicate with, and what access can be restricted around it.
Network segmentation, tightly controlled remote access, monitoring, and other compensating controls can reduce exposure until a system can safely be patched or upgraded.
The same principle applies to testing. OT security testing has to account for the age and sensitivity of the systems involved. Depending on the environment, testing may range from passive, low-touch approaches to more active testing performed during approved maintenance windows.
The objective isn’t simply to find vulnerabilities. It’s to validate defenses without creating a larger operational problem.
5. Get the Foundation Right Before Adding More Technology
One of the final questions during the fireside chat was what an OT operator should do before deploying an OT visibility or monitoring platform.
The discussion came back to four stages:
Governance → Segmentation → Visibility → SOC Integration
Segmentation helps organizations understand how systems communicate and creates the architecture needed to safely collect OT traffic. Visibility can then help establish an asset inventory, identify critical systems, and baseline normal behavior.
From there, SOC integration turns that visibility into an operational capability.
That means building detections, correlating IT and OT activity, documenting critical assets and processes, establishing escalation procedures, and making sure responders know what actions they can safely take.
Organizations should also know whether they can recover critical OT systems. That means looking beyond traditional backups to PLC logic, device configurations, engineering workstation configurations, and other information necessary to restore the physical process.
The technology matters. But without the people, processes, and operational context to act on what it shows you, another dashboard doesn’t necessarily make the environment more secure.
What Effective OT Defense Looks Like
Defending OT requires understanding the physical process first and building security around it.
Know what’s in the environment. Understand which systems are critical and how they communicate. Control remote and third-party access. Establish what normal looks like. Build detections that account for both IT and OT activity. And make sure the SOC knows who to call and what can safely be done when something goes wrong.
Most importantly, validate those assumptions before an actual incident does it for you.
Watch the Full Fireside Chat
Hear more from Christopher Walcutt and Charly Bun about what DirectDefense is seeing across OT environments and the practical steps organizations can take to improve detection, response, and resilience.
08.27.26