How we build your rules and playbooks
Generic alarms don’t know your plant. So we write down what normal is for your plant, build every rule against that, give it a playbook that names who does what, and test it before it goes live.
Walk-through and passive inventory
We walk the plant with the people who run it. Then we list every asset, connection and account from what your tools already see. Read-only and passive: nothing touches live control.
Example: Werk Niederrhein, our demo plant
- assets on the plan
- 16
- zones
- 4
- allowed flows
- 6
- process values
- 12
- IT hosts
- 8
- accounts
- 7
Read from: OT monitoring, firewall, VPN, directory, EDR
Zones and conduits
We group the assets into zones by Purdue level and write down the conduits between them (IEC 62443). Every connection is checked against this model.
Example: Werk Niederrhein, our demo plant
- L4 · EnterpriseOffice laptopVPN gatewayWarehouse system
- L3 · OperationsEngineering WSSCADA serverHistorianOT firewall
- L2 · ControlHMI MixingHMI Packaging
- L1 · FieldPLC Mixer 1PLC Mixer 2PLC FillingPLC PackerPLC PalletiserPLC BoilerPLC Water treatment
Conduits: 6 allowed flows, through the OT firewall
What normal is for your plant
With your engineers we agree what normal looks like: who may write to which controller, when the maintenance window is, how vendors get in, the normal range of key process values.
Example: Werk Niederrhein, our demo plant
- Writes to controllers
- Only from the engineering workstation, only in the maintenance window
- Maintenance window
- Saturday 06:00–14:00
- Vendor access
- Over VPN, only in the maintenance window
- Filling setpoint
- 995–1005 ml
A rule against that model
Each rule looks for one thing that should not happen in your plant. Here is one as the app shows it: in plain language, why it matters and what it means for NIS2.
HighRule R-003MITRE ATT&CK for ICS: T0836 · Modify ParameterOT write from a host that is not an engineering workstation
Impair Process Control- Fires when
- A controller receives a write (setpoint, configuration or program) from a host the plant model does not list as an engineering workstation.
- Why
- Only engineering workstations should change controllers; anything else is either a misconfiguration or an attack.
- NIS2
- Likely significant: a manipulated process can affect safety and service. Prepare the 24 h early warning.Confidence of this rule alone: 25 of 30
In the demoOT write to plc-03 from laptop-office-01Shown in plain language, as in the app. The rule’s code is our own and stays with us.
Its playbook: who does what
Every rule comes with a playbook. Each step names who acts and who is only informed. In the case, Lagebild asks those people and records their answers.
Playbook · R-003
- Confirm (10 min): Is the line running normally, and was anyone changing setpoints or programs just now?Shift lead(acts and answers)
- Check the controller (30 min): Compare with the last known good version and restore it if it differs. Safety first.OT engineer(acts and answers)
- Contain (30 min): Block the writing host at the firewall or switch port, without stopping production.OT engineer(acts and answers)
- Preserve: Keep the network capture and the logs; do not reboot anything yet.
- Inform the plant manager: What changed on the line, and whether production or quality is affected.Plant manager(informed)
- Inform the CISO: Likely significant under NIS2: the 24 h early warning runs from now.Information security officer (CISO)(informed)
Roles become people: your team list says who has which role and how to reach them.
Tested before go-live
We replay attack scenarios through the real pipeline: the simulator plays the plant, the rules run, cases open. Each scenario must give exactly one case with the right rules. A whole normal weekday must give none.
Replay before go-live
- Office laptop writes to PLC FillingR-003 · R-005 · R-008 · R-009Expected:1 case
- Vendor logs in outside the maintenance windowR-006 · R-009Expected:1 case
- Unknown device talks to the boiler controllerR-007Expected:1 case
- Phishing click, VPN, then the engineering workstationR-001 · R-002 · R-005 · R-008Expected:1 case
- A normal weekdayExpected:0 cases
After go-live, the NIS2 score learns from the cases your team closes as false positives.
Who decides NIS2, and the clock
Every case gets a NIS2 score from 0 to 100. Who decides is set per customer, usually your CISO or the SOC. Lagebild drafts each report; your side checks it and submits it.
NIS2 score
- ≥ 90The NIS2 case opens
- 60–89A person decides
- < 60Noise: kept, never reported
Office laptop writes to PLC Filling: R-003 with three more rules, score 99. The NIS2 case opens.
The clock
- 24 hEarly warning
- 72 hIncident notification
- 1 monthFinal report
Reviewed every quarter
Plants change: new machines, new vendors, new windows. With Managed OT Security we review rules, playbooks and the plant model with you every quarter.
- Which cases were false positives, and why
- New assets, flows, vendors and windows in the plant model
- Rules and playbooks: adjusted, added or retired
- Who is on the team list, and who decides NIS2
The rule pack at a glance
The rules we start from, each tuned to your plant model in the Check. Every one has a playbook like the one above.
| Rule | What it watches for | Why it matters in OT and for NIS2 | Severity | Who acts first |
|---|---|---|---|---|
| R-001Phishing, then VPN | A VPN login by an account that clicked a phishing link in the last 6 hours | Stolen logins are a common way in. Possibly significant if it leads into OT. | High | SOC analyst |
| R-002Office to engineering workstation | A remote session (RDP or SMB) from an office or IT host to an engineering workstation | That workstation can change PLC programs: a classic step into OT. | High | Shift lead |
| R-003Write from the wrong host | A controller written from a host that is not an engineering workstation | Misconfiguration or attack. Likely significant under NIS2. | High | Shift lead |
| R-004VPN at night | A VPN login between 22:00 and 05:00 site time | Rare at night and a common start of an attack. Not reportable on its own. | Medium | SOC analyst |
| R-005Write outside maintenance | A controller changed outside the agreed maintenance window | Changes to running production are planned; this one needs an explanation. | Medium | Shift lead |
| R-006Vendor outside maintenance | A vendor’s remote-maintenance account logs in while no maintenance is agreed | Vendor access is a frequent way into plants. Check with the vendor straight away. | High | Vendor |
| R-007Unknown device | An address that is not in the inventory talks to a controller or field device | New devices should never appear unannounced. Possibly significant. | High | Shift lead |
| R-008Process value out of range | A process value leaves its normal operating range | Together with a write: a physical effect on the process. If it is an attack, significant. | Critical | Shift lead |
| R-009Connection not in the model | Two known hosts speak an industrial protocol the plant model does not allow | A new path into the control system. Not reportable on its own. | Medium | OT engineer |
Plant walk-through our focused Gemba walk
It all starts on site. We go where the work happens, with the people who run the line, and look only at what NIS2 asks about: remote and vendor access, who can change controllers, backups, the network zones and how an incident would be handled.
- Who joins
- Shift lead, OT engineer, maintenance and your CISO
- How long
- Half a day on site, as part of the Check
- What comes out
- The inventory, the zones model and the list of what is normal: the base of your first rules and playbooks
Want rules that know your plant?
30 minutes, free. You leave with your three biggest gaps.