Building the first OT asset inventory
Nobody knows how many controllers the plant has or which software versions they run; the list is in spreadsheets and out of date.
- Data in
- Passive network monitoring · Active collection (where suitable)
- What it does
- Several sources merge into one record per asset with hardware, software, port and service details.
- Outcome
- A current inventory, the foundation for every security task that follows.
Catching unauthorised changes
After maintenance a new port stays open on a controller, or a temporary user is forgotten.
- Data in
- Baseline configuration · Current configuration
- What it does
- The current state is compared with the baseline, and deviations in ports, users, policies and services are flagged.
- Outcome
- The change is noticed when it happens, not after something breaks.
NERC CIP and IEC 62443 evidence
Before every audit, inventory, configuration and patch evidence is compiled by hand.
- Data in
- Asset and configuration records
- What it does
- Out-of-the-box policies and report templates map the records to the relevant requirement and framework.
- Outcome
- Audit-ready, framework-mapped reports and a repeatable evidence process.
Prioritising patches in OT
Hundreds of advisories exist, but it is unclear which ones really affect your devices, and patch windows are limited.
- Data in
- Asset inventory · NIST vulnerability database and ICS-CERT
- What it does
- Vulnerabilities are matched to your real software and hardware versions and ranked by risk.
- Outcome
- Limited patch windows go to the highest-risk assets.
Sending OT data to the SOC
The security team sees the IT side, but OT logs and events never reach the SIEM.
- Data in
- Syslog and log files · Asset context
- What it does
- Logs become events, are tied to the asset record and are forwarded to SIEM/SOAR.
- Outcome
- The SOC sees which OT asset an event happened on and how critical that system is.
