Intrusions into OT networks don't announce themselves; they settle in and wait, and the industry's ugly secret is that dwell time is measured in months. Seventy-two hours at Cedar Ridge Utility's security desk: passive behavioral monitoring that has spent 30 days learning what every SCADA conversation normally looks like notices an engineering workstation quietly polling 14 field RTUs it has no business talking to, at 2 AM, through a vendor remote-access path. Watch the difference between compliance and defense: flag in hours, contain without touching operations, run the CIP-008 clock properly, and close the attack path the threat model had already ranked #3. The grid never notices. That's the whole point.
| Without | With GridCORTEX | Δ |
|---|
| Without | With GridCORTEX | Δ |
|---|
The scenario is 72 hours at the security desk of Cedar Ridge Utility, a fictional power company. The stakes: intruders who get into the networks that run physical grid equipment, called operational technology or OT networks, typically go undetected for months. The industry calls that period dwell time. Cedar Ridge watches its OT network with passive listening only: sensors that read traffic but can never send anything. Over 30 days, the system has learned what normal looks like for 2,340 devices: who talks to whom, when, how often, and with what kinds of commands. At hour 2, at 02:10 on the wall clock, an engineering workstation called ENG-WS-07 starts polling 14 remote terminal units, the small field computers that report readings from substations and power lines. No alarm matches a known attack. The system flags it anyway, for one simple reason: in 30 days of history, this workstation has never talked to field equipment at all, and never at 2 AM.
Four decisions go to the chief information security officer. At hour 4.2, the first asks permission to watch harder, at 91 percent confidence: record the full sessions, pull the vendor's remote-access logs, and map how critical the 14 devices are. Watch first, act second. The watching pays off: the polling is slow, systematic, and shaped like someone drawing a map of the grid's control network, and the vendor's own calendar shows no maintenance scheduled. At hour 5.8, the second decision proposes containment at 97 percent confidence, computed so it costs grid operations nothing: cut the one workstation off at the network switch, suspend the vendor's remote entrance, and change the affected passwords and keys, while every link the control room depends on stays untouched and the forensic evidence is preserved first. Approved, the intruder is locked out at hour 6.2. Total dwell time: 4.2 hours from first odd traffic to containment, against an industry norm measured in months.
The back half is about the program, not the packets. Forensic review confirms the intruder only looked: no control commands sent, no settings changed. At hour 12, the third decision runs the required federal incident paperwork under rule CIP-008, which sets a reporting clock for grid cyber incidents: a classification worksheet, a draft notification to the industry's threat-sharing center, a sealed evidence chain, and a plain-language briefing for the operations team, all signed by the security chief with hours to spare by hour 16. At hour 24 comes the uncomfortable detail: the utility's own threat model had ranked this exact entry route, the vendor remote-access path, third out of ten likely attack paths last quarter. It was flagged, but never funded. At hour 30, the fourth decision closes it for good: require a second proof of identity on every vendor login, force all vendor access through one controlled gateway computer, add a standing alert for any workstation talking to field devices, and add the scenario to the next practice exercise. The simulation ends after 48 quiet hours: zero operational impact, one page for the board. The grid never noticed. That is the point.
The same intrusion arrives through an authorized vendor doorway, so the firewall logs look healthy and every tool that matches known attack patterns stays silent; there is nothing known to match. The 2 AM polling becomes a patient, unobserved mapping of the network that controls grid switches. Following the industry pattern, the access persists for months, about 118 days on the outcome chart, and discovery finally comes from an audit or a tip from the vendor, never from the network itself. By then the response is an emergency: grid control links yanked offline with real operational disruption, outside response consultants at retainer rates, regulators asking how months went unnoticed, and a bill of $2.3 million or more. The failure is structural: pattern-matching tools catch what has been seen before, and long dwell times live in what has not.
The core capability is behavioral anomaly detection (use case 13.2): the system learns each device's normal conversations, so one workstation's brand-new 2 AM habit stands out from a thousand routine alerts, and correlation stitches three minor oddities into one incident at 97 percent confidence. Containment is computed against the live state of the grid, so the response costs operations nothing: one workstation and a set of credentials, and the control room never blinks. An incident-response copilot runs the federal CIP-008 reporting clock correctly (use case 13.3), and the threat model turns the incident into a permanently closed attack path (use case 13.1). Every step keeps a human in charge: the monitoring only listens, and the security chief and operations leadership approve all four actions. The numbers: 4.2 hours of dwell, zero operational impact, $140,000 total response cost.
| Measure | Without GridCORTEX | With GridCORTEX | Delta |
|---|---|---|---|
| Dwell timehow long an intruder roams inside before being found and locked out | months: discovered by accident | 4.2 hours, by the network itself | the entire difference |
| Detectionwhat finally raised the alarm | signatures silent: nothing known matched | behavioral: "this is not normal" | knowing normal beats matching known attacks |
| Containmentwhat had to be shut off to lock the intruder out | emergency OT isolation, ops pays | workstation + credentials only | grid operations never felt it |
| Scopewhat the intruder actually did, and how soon the utility knew for sure | unknown for weeks | reads only: confirmed by forensics | certainty, fast |
| CIP-008the federal rule setting the deadline and paperwork for reporting grid cyber incidents | reconstructed under scrutiny | clock met, evidence sealed | clean file |
| The 14 RTUsthe small field computers the workstation was probing; they report readings from substations and lines | mapped by someone else | back to boring | as it should be |
| Response costeverything the incident cost, including outside responders and disruption | $2.3M+: IR retainer, downtime, scrutiny | $140K all-in | 94 percent cheaper |
| Operational impactwhether the response disturbed the systems that actually run the grid | forced OT link isolation, hours | zero | the control desks never knew |
| Regulatory posturehow the utility looks to its regulator after the incident | explaining months of dwell | self-detected, self-reported | the good side of the table |
| Attack path #3the vendor remote-access route the utility's own threat model ranked third most likely; MFA means a second proof of identity at login, and a jump host is one controlled gateway all vendors must pass through | still open (flagged, unfunded) | closed: MFA, jump-host, rule | the model earned its keep |
| Vendor accesshow outside vendors reach utility systems remotely | unchanged until the audit | hardened fleet-wide | every account, not just one |
| Board storywhat leadership has to be told when it is over | a very long meeting | one boring page | priceless |
The safety effect is indirect, and the mechanism is worth stating rather than dressing up. Closing an attack path in a planned change window avoids the alternative, which is an incident where technicians are dispatched at odd hours to isolate or verify devices under time pressure. Rushed field work in an energized environment is where people get hurt, and this use case is trying to keep that work planned.
Counted in units you already track:
Workshop and diagram maintenance hours come back to the control engineers and the security architect, and the architect's remaining time shifts from drawing the environment to deciding what to do about it.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Security and engineering labor | workshop and diagram maintenance hours avoided x your loaded architect and control engineer rates |
| Outside assessment spend | assessment days you shift from discovery to validation x your contracted day rate, counted only where you actually reduce the scope you buy |
| Mitigation prioritization | the cost of controls you defer or drop because the model shows they close no reachable path, valued at your own project cost estimates. This can be larger than the labor line and it is entirely your number. |
| Incident avoidance | your own estimated cost of an OT security incident x the share of incidents you believe path closure prevents. You set that share. We will not. |
You pay for the scoped engagement that builds and runs this, for read only integration into your asset inventory, firewall and network configurations, and remote access records, and for your own architects' and control engineers' time to validate the first model. The validation is not optional and it is the dominant cost in year one, because a threat model your engineers do not believe is a document nobody acts on.
Payback is usually carried by outside assessment spend and by the engineer and architect hours that workshops consume, both of which are on invoices and timesheets you already have. The deferred mitigation spend is often larger but it is a judgment call, so build the case on the first two.
The direct safety effect is modest and specific rather than dramatic. Detecting unauthorized or abnormal command activity from the network removes the reason for the alternative, which is dispatching technicians to substations, often at night, to verify device state by hand. Every one of those verification trips is a drive and an energized area entry that existed only because nobody could see the traffic.
Counted in units you already track:
Log review hours come back to the security operations team and the interruption hours come back to the control engineers who currently act as the human baseline.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Security operations labor | log review and triage hours avoided x your loaded analyst rate, including any shift differential you pay |
| Control engineer interruption | verification hours avoided x your loaded control engineer rate |
| Field verification | verification truck rolls avoided x your fully loaded truck roll cost, including overtime and callout premium where the trip was after hours |
| Incident containment | your own cost per hour of degraded or isolated operation x the containment hours you believe earlier detection saves. That number is your assumption about dwell time, not ours. |
| Tooling | license and maintenance spend on point monitoring tools you actually retire. Count nothing here unless you truly turn something off. |
You pay for the scoped engagement that builds and runs this, for passive collection hardware and the network taps or mirror ports to feed it, for the installation work at each monitored site, and for the integration into your security operations platform. You also pay your own analysts and engineers for tuning during the baseline learning window, and that tuning is where the false positive rate is decided. Underfund it and you will get an alert queue nobody reads.
Payback is normally carried by avoided log review hours, avoided engineer interruption, and avoided field verification truck rolls, all of which you can audit. Treat avoided incident cost as upside, because it rests on a dwell time assumption you cannot verify until you have the monitoring in place.
The mechanism is coordination, not protective equipment, and it is honest to say so. During an OT incident, the dangerous pattern is uncoordinated action: an operator isolating equipment while a technician is en route to the same asset, or a device being restored while someone is working on it. A single live timeline and checklist that operations can see keeps isolation and restoration deliberate rather than parallel and improvised.
Counted in units you already track:
Bridge line hours, evidence gathering hours, and post incident reporting hours come back to the OT security team, and the compliance staff stop rebuilding a timeline that should have been captured while it happened.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Responder labor | activation hours avoided x your loaded responder rates, including overtime and callout premiums for off hours events |
| Reporting and legal review | post incident report and notification drafting hours avoided x your loaded compliance analyst and counsel rates |
| Incident response retainer | retainer hours avoided x your contracted hourly rate, if you keep an outside IR firm on call |
| Operational impact | your own cost per hour of degraded, isolated, or manually operated systems x the hours you believe faster coordinated containment saves. Your operations team sets that hourly cost, not us. |
| Exercise preparation | tabletop preparation hours avoided x your loaded rates for the staff who currently build the scenario and the evidence |
You pay for the scoped engagement that builds and runs this, for integration into your incident tracker, historian, SCADA logs, and document store, and for the work of encoding your own playbooks and notification templates into the workflow. That encoding is your security and compliance team's time and it is the honest bulk of the implementation. It is worth doing once, and it is not something we can do for you, because the playbook has to be the one your people will actually follow.
Payback is carried by responder hours and by post incident reporting and notification hours, both of which you can pull from past events. Avoided operational impact is the larger number and the softer one, so treat it as upside in the case you present.
What is this, exactly? It is AI software: intelligent agents and models built and delivered by SoftServe, running on NVIDIA accelerated computing. It is not a hardware appliance and it does not replace the systems you run today. It deploys in your own cloud or on your premises, connects read-only to your existing systems, and recommends; your people approve every action, starting in shadow mode until it earns trust.
An analysis service for the security team that models your operational technology environment, maps the attack paths an adversary could actually use, and returns a mitigation list ranked by real risk reduction. The demo above uses synthetic data; everything below describes what the real deployment needs from your organization.
| Your system | Typical products | How we connect |
|---|---|---|
| Cyber and OT security | Claroty, Nozomi, Dragos, Splunk | scheduled file export (CSV or CIM XML) |
| Document and knowledge stores | network diagrams, NERC CIP documentation, firewall rule exports | document upload |
| Energy Management System (EMS) / transmission SCADA | GE e-terra, AspenTech OSI monarch | document upload |
| SCADA historian | AVEVA PI System, AspenTech eDNA | historian mirror (one-way feed) |
This data describes how to attack your grid, so the default deployment is fully isolated: an on-premises NVIDIA server with no internet connection. All inputs are exports and documents; nothing connects to live control systems, access is need-to-know, and handling follows your BES Cyber System Information rules.
The Approve button you just clicked in the demo above is the real workflow. This is what it looks like on the screen of the OT security architect in the GridCORTEX console:
Accepting opens the ranked mitigations as draft change tickets in the security team's own tracking system, in pending status. Your engineers implement them under existing change control with their own tools; GridCORTEX touches no OT configuration.
The model builds automatically from connected security and configuration feeds. An asset or vendor connection the scanners cannot see can be added through a short console form.
Topology and configuration data refresh on the cadence your security team approves, typically nightly; each finding shows the as-of timestamp of the data behind it.
The threat model lives in the GridCORTEX console, restricted to the security team; a new high-severity path emails the CISO's team. The console runs in a browser beside your existing screens on day one; embedding into your own systems is a roadmap step once the read-only phase has earned trust. Approve, Modify, and Decline are all captured in an audit trail your compliance team can pull, and GridCORTEX never blocks or overrides anything in the systems you run today.
The fair question from any CISO: "We have a SIEM, an OT security vendor, firewalls between every Purdue level, and a clean CIP audit, what's new here?" Here's the honest answer.
When someone asks "what did it actually calculate?", this is the list. In the simulation these factors drive the storyline; in a pilot they are computed from your passive network captures and logs, read-only, always.
Presenter's one-liner: "The network already knew what normal looked like, so the workstation that started polling fourteen RTUs at 2 AM stood out like a shout in a library. Flagged in four hours, contained without touching a single EMS link, CIP-008 clock run properly, and the attack path the threat model had ranked #3 got closed for good. The grid never noticed. In this business, the best incident story is no story."