NEO SENTINEL — Industrial Cybersecurity for Control-System Subsystems
An OT-native cybersecurity scope for DCS, SIS, CEMS, DAS and packaged control subsystems — six engineered defence domains delivered against IEC 62443, and proven at acceptance with signed evidence rather than statements of intent. NEO SENTINEL is our own asset-monitoring, secure-configuration and maintenance platform at the centre of it.
The Problem: Subsystems Inherit the Plant’s Risk but Not Its Security Budget
Analyser shelters, CEMS and DAS packages, compressor and boiler control skids — these arrive as vendor-supplied subsystems, get patched into the plant network, and then sit there for fifteen years. They exchange data with enterprise IT, they are accessed remotely by the vendor, and they very often run unmanaged local accounts on unpatched operating systems.
Six risk drivers show up on almost every subsystem we assess:
| Risk driver | Why it matters on a control subsystem |
|---|---|
| IT/OT interconnection | The subsystem exchanges data with enterprise IT. Without a controlled DMZ, any enterprise incident can reach control assets. |
| Uncontrolled remote access | Vendor and engineering access without gateway, MFA and audit is the most common breach entry path in industrial systems. |
| Malware and USB exposure | Signature-based antivirus alone cannot stop zero-day or USB-borne malware on OT hosts. |
| Unpatched vulnerabilities | OS patches cannot be applied blindly during operation — unmanaged, they accumulate into exploitable debt. |
| Unmanaged accounts | Local accounts with weak or shared passwords defeat every other control and cannot be audited. |
| No visibility, untested recovery | Without monitoring, incidents are found late. Without restore tests, backups fail exactly when needed. |
Positioning: OT-Native, Not IT-Generic
The difference between an IT security scope and an OT security scope is not the technology list — it is what happens when a control decision conflicts with a security decision. We engineer inside Level 2 and Level 3 control networks as our day job, so the controls are designed around plant operation rather than against it: patching is scheduled by network level with restart under manual control, monitoring collects passively first, and no control is accepted until it has been demonstrated on the running configuration.
Standards Alignment
| Reference | How it is used |
|---|---|
| IEC 62443 (SL2 target) | Zone and conduit design, security-level target for the subsystem boundary |
| Purdue / ISA-99 layering | Level 2 control, Level 3 site operations, Level 3.5 DMZ, Level 4 enterprise |
| Owner security requirements (OSR-class checklists) | Per-category control requirements, executed row by row and signed at FAT/SAT |
| Plant operating procedures | Patch windows, restart authority, access approval workflow |
Six Coordinated Defence Domains
Every layer an attacker must cross is engineered, verified and evidenced. Each domain is a separate work-breakdown family, so scope and price move together.
| # | Domain | What is engineered |
|---|---|---|
| 1 | Identity & Access | Domain governance: redundant domain controllers, DNS zones, OU/GPO policy set, certificate authority, RADIUS authentication, local-account cleanup |
| 2 | Endpoint Protection | Centralised antivirus, application whitelisting, OS hardening baseline, WSUS patch management with plant-safe scheduling |
| 3 | Network Segregation | Zone and conduit design, perimeter (L3.5) and control (L2) firewalls, managed switch hardening, controller and HMI protocol protection |
| 4 | Secure Remote Access (option) | Remote access gateway, multi-factor authentication, time-limited least-privilege sessions, full session audit |
| 5 | Monitoring & Detection | NEO SENTINEL platform, NIDS on SPAN mirrors, centralised log collection, configuration compliance baseline |
| 6 | Backup & Recovery | Backup infrastructure and schedules, retention cycles, and a verified restore — timed and documented |
Governance and assurance — functional design specification, risk assessment, FAT and SAT execution, documentation — span all six domains.

NEO SENTINEL: One Platform for Visibility, Configuration and Maintenance
NEO SENTINEL is neoDrive proprietary software, engineered for the same L2/L3 control networks it protects. It is what turns the monitoring domain from a shopping list of third-party tools into a single system with one accountable vendor.
| Capability | What it does |
|---|---|
| Asset monitoring | Live availability and performance of every server, workstation and network device; complete asset inventory fed by NIDS discovery |
| Secure configuration | Configuration baselines, drift detection and scheduled compliance reports mapped to the approved setting values |
| Intelligent maintenance | Maintenance planning from real device health data — alarms, trends and lifecycle records in one place |

How It Collects
| Source | Method | What it yields |
|---|---|---|
| Servers & workstations | Agent / WMI / SNMP | Health, performance, configuration state |
| Switches & firewalls | SNMP / syslog | Status, interfaces, rule and configuration changes |
| NIDS sensors | Passive SPAN mirror | Asset discovery and threat alerts feeding the asset base |
| Security logs | Central syslog | Retained per specification for the evidence record |
The SENTINEL server sits on the control network (Level 3). Collection is passive first, so there is no added load on plant traffic. Reports export to CSV and PDF, which is what makes them usable directly as FAT and SAT evidence.

Evidence-First Acceptance
The failure mode of most industrial security scopes is that they are accepted on a document rather than on a demonstration. Every control we deliver has a defined verification method fixed before configuration starts:
| Domain | Deliverables | Acceptance evidence |
|---|---|---|
| Identity & Access | Domain controllers, GPO policy set, CA, RADIUS, account inventory | Replication and DNS test logs, gpresult exports per endpoint, signed checklist rows |
| Endpoint | AV server and agents, enforced whitelist, hardened endpoints, WSUS | Agent and scan reports, blocked-execution test on the enforced whitelist, per-endpoint hardening checklists |
| Network | Firewall rule matrix, configured firewalls, hardened switches | Rule exports, blocked-traffic and port-security tests, design review record |
| Monitoring | NEO SENTINEL in operation, NIDS, central logging, compliance reports | Alarm and alert tests, asset-list export, sample compliance report |
| Backup & Recovery | Backup infrastructure, clients, schedules, restore procedure | Backup job success logs and a timed restore test report |
| Governance | FDS, risk assessment, FAT/SAT reports, evidence pack, as-built documents | Approval records, signed FAT and SAT reports, transmittals |
The principle: you sign against a record — test logs, exports, screenshots and reports — collected item by item. A backup that has never been restored is a hope, not a control.

Requirement Coverage and Traceability
Owner cybersecurity checklists for subsystem-class equipment typically define around thirteen control categories and well over a hundred individual check rows. Each category is mapped to a solution module, a work-breakdown family and a named piece of acceptance evidence before work starts — nothing implicit:
| Control category | Solution module | WBS family |
|---|---|---|
| Access control | Identity & Access | ACC |
| Vulnerability management — hardening | Endpoint Protection | END |
| Vulnerability management — patching | Endpoint Protection | END |
| Malware protection | Endpoint Protection | END |
| Controller / HMI protection | Network Segregation | NET |
| Switch and firewall hardening | Network Segregation | NET |
| Security log collection | Monitoring & Detection | MON |
| Asset management / NIDS | Monitoring & Detection | MON |
| Network monitoring system | Monitoring & Detection | MON |
| Configuration compliance management | Monitoring & Detection | MON |
| System backup | Backup & Recovery | REC |
| Documentation and drawings | Deliverables | GOV |
| Cybersecurity risk assessment | Implementation | GOV |

A Gated Delivery Method
The scope is frozen at a gate, designed at a gate, and accepted against a procedure. No date is promised before kickoff, because the schedule depends on inputs only the client holds.
| Stage | Content | Gate |
|---|---|---|
| 1. Requirement confirmation | Asset inventory, drawings, checklist applicability | Scope freeze (G1) |
| 2. Detailed design | FDS, architecture, firewall rule matrix, policy values | Design approval (G2) |
| 3. Configuration | Build and configure all six domains per approved design | — |
| 4. Internal verification | Checklist dry run — findings fixed before the client sees the system | — |
| 5. Factory acceptance test | Client-witnessed tests per approved procedure | Signed FAT report |
| 6. Site acceptance test | Site validation and punch-list closure | Signed SAT report |
| 7. Handover | Documentation package, as-built, training and transfer | — |
Transparent Pricing Mechanics
Cybersecurity scopes are notorious for quotations that cannot be interrogated. Ours is built from a unit man-day model with an explicit quantity factor, so repeat work is charged at its true marginal cost:
| Work type | Behaviour | Repeat ratio |
|---|---|---|
| Type A — design and documents | First unit carries the design effort; later units reuse heavily | r ≈ 0.2 |
| Type B — repeat configuration | First device validates the design; same-type devices reuse it | r ≈ 0.5 |
| Type C — per-device and site work | Effort repeats per unit; site days are never compressed | r ≈ 0.9 |
Kq = 1 + (Quantity − 1) × r, and Total = Base × Kq × Kc. A worked example: base 10 man-days at quantity 4 with r = 0.5 gives Kq = 2.5, so 25 man-days — not 40. Every quantity change re-prices mechanically, which removes renegotiation ambiguity in both directions.
Scope Boundaries
A clearly bounded scope is what prevents surprises at acceptance. Quantities are frozen against the client asset inventory at kickoff; anything outside the inventory is outside the scope until it is priced in.
| Typically included | Typically excluded unless separately quoted |
|---|---|
| Design, configuration and verification of the six domains | Hardware and software licences |
| FDS, procedures, risk assessment, test documentation | Corporate IT network changes |
| FAT execution and SAT support with evidence packs | Legacy or third-party systems outside the asset inventory |
| Checklist execution and signed results | 24/7 managed SOC operations and post-warranty updates |
| Single technical and commercial point of contact | Travel, visas and accommodation (quoted separately) |
Where This Fits
- Vendor packages entering a secured plant — CEMS, DAS, analyser shelters, compressor and boiler skids that must satisfy an owner’s third-party cybersecurity requirements before they are accepted.
- Existing subsystems being brought into compliance — where a security audit has produced findings and someone has to close them with evidence.
- DCS and SIS revamps — where segmentation, account governance and monitoring should be engineered in during the project rather than retrofitted afterwards.
- Multi-site programmes — where a repeatable baseline and a quantity-based price model matter more than a single bespoke design.
Request a NEO SENTINEL Assessment
Tell us the subsystem, the approximate device count (servers, workstations, firewalls, switches) and the owner requirement set you have to satisfy. We will come back with a scope outline, the applicable control categories and a quantity-based estimate — and the conversation will be with an engineer, not a sales call.
Related pages: NEO AEGIS — Alarm Management · NEO SynBlend — Blending Optimisation · DCS Engineering and Configuration
