Most Data Centre Cyber Assessments Audit the Wrong Network.
The corporate IT side gets a real audit. The facilities side gets an asset list, an SNMP walk and a CVE rollup on PDUs that the operator cannot reboot. The deliverable looks rigorous and answers the wrong question.
- BACnet and SNMP discovery scans booked as the OT audit
- IT vulnerability scanners pointed at BMS controllers — JACEs and PDUs are not built to be probed
- CVE rollups on devices the operator cannot patch and cannot reboot — change windows for a CRAH controller do not exist
- Generic ATT&CK technique mentions, with no mapping to BACnet, Modbus, IPMI or the controllers actually running the hall
- No consequence model tied to PUE, SLA credit or tenant notification — the report stops at severity, never reaches outcome
The colo operator recognises this report. The hyperscale operator has filed five of them. None of them changed what the facilities team is afraid of at 03:00.
Data Centre OT Risk Is an SLA Equation. Not a Patch Backlog.
Data centre OT risk has three terms and CVE count is not one of them. A BMS controller can carry a CVSS 9.8 vulnerability and present negligible risk — and a fully patched chiller plant controller can sit one BACnet write away from a hall trip. The rubric matters.
| Term | What it measures | What it ignores |
|---|---|---|
| Consequence | Thermal excursion, hall trip, redundant-path loss, suppression mis-trigger, SLA credit exposure, tenant notification, hardware damage — measured in facility outcomes, not data records | CVE severity in isolation |
| Adversary capability | Plausible threat actor tier for this site, this tenant mix, this geography — opportunist, insider, criminal, nation-state — and the techniques each can actually deploy against facilities OT | Theoretical exploits no realistic adversary will weaponise against a BMS |
| Exposure | Reachable attack surface accounting for BMS-network segregation, IT/OT boundary, supervisor-vs-controller separation, vendor remote access and contractor identity hygiene | Open-port counts on a flat-BMS-VLAN assumption |
Risk = Consequence × Capability × Exposure. Every finding in our report scores on this rubric. Every recommendation moves one of these three terms — and is sized against an SLA clock, not a patch calendar.
Our Method — ATT&CK for ICS, Mapped to the Protocols and Devices on Your Floor.
MITRE ATT&CK for ICS is the public scaffold. On its own it is a vocabulary, not an assessment. We add three layers of mapping that turn a vocabulary into a finding the facilities team can act on.
| Layer | What we map | Example |
|---|---|---|
| Protocol layer | Each ATT&CK technique against the protocols actually on the BMS network — BACnet/IP, Modbus TCP, SNMP v1/v2c/v3, IPMI / Redfish, OPC UA, Niagara Fox, KNX where present | T0855 Unauthorized Command Message → BACnet write-property on chiller setpoint objects |
| Device layer | Each technique against the controllers and gateways in the hall — BMS controllers (Niagara JACE, Tridium, Distech, Honeywell, Siemens Desigo), CRAC / CRAH, chiller plant managers, PDUs (Vertiv, Schneider, Eaton), UPS, ATS, leak detection, EPMS gateways, suppression panels | T0836 Modify Parameter → CRAH supervisory setpoint via Niagara JACE |
| Consequence layer | Each technique against the facility outcome it produces — thermal excursion, hot-aisle breach, false alarm flood, suppression mis-trigger, redundant-path loss, tenant SLA clock-start | Hall-wide hot-aisle excursion during peak load window |
The library is curated for the controller stacks and protocol mixes we see in colo and hyperscale halls — and it grows with every engagement.
Worked Example — BACnet Setpoint Injection on a Chilled-Water Loop.
One real chain, end to end, against the rubric. This is what twinos Assess · Data Centre emits against a BACnet BMS — not a hand-written finding, not a CVE row, not a CVSS number. One row out of a generated register.
| Step | Finding |
|---|---|
| Technique | T0855 Unauthorized Command Message / T0836 Modify Parameter — BACnet/IP write-property against chilled-water supply setpoint objects on the plant controller |
| Protocol exposure | BACnet/IP is unauthenticated by default; the BMS supervisory VLAN is flat; write-property is accepted from any source on the segment; BACnet/SC not deployed |
| Device exposure | Chiller plant controller and CRAH supervisor on the same VLAN as the BMS engineering workstation; vendor remote-access jump-host writes against the same objects; no allow-list of legitimate writers |
| Adversary capability | Tier-2 criminal or opportunistic actor reaching the BMS VLAN via a stale contractor VPN credential — observed during scoping |
| Consequence | Chilled-water supply shifted 6 °C; hot-aisle excursion across Hall-2 and Hall-3 within 18 minutes; tenant notification triggered; SLA credit window opened; risk of cascaded shutdown if redundant chiller had been in maintenance |
| Risk score (our rubric) | Consequence: High · Capability: Medium · Exposure: High → Aggregate: High. CVE-only view of this chain: zero CVEs, no scanner output, would not appear on a quarterly VA report |
| Recommendation | Deploy BACnet/SC where supported; segregate supervisory VLAN behind an L3 boundary with whitelisted writers only; alert on write-property from non-supervisor sources at the BMS gateway; revoke stale contractor identities; enforce named-identity remote access for vendor jump-host |
Zero CVEs. SLA-credit-grade OT risk. Generated, not authored. The next three slides are how.
twinos Assess · Data Centre — ATT&CK at the Object · Property Level.
Public ATT&CK for ICS publishes technique names. twinos Assess holds a database of realisation conditions per technique — mapped to BACnet object types and properties, Modbus register semantics, IPMI / Redfish endpoints, Niagara station internals; equivalent surface for SNMP and OPC UA; and extended to OS hardening gaps and hardware exposure. For any controller whose configuration we hold, we can compute which techniques are realisable today — before we walk on site.
| Technique | Protocol primitive | Mapped point | Realisation conditions | Realisable? |
|---|---|---|---|---|
| T0855 Unauthorized Command Message | BACnet WriteProperty | chiller-CWS · present-value | WriteProperty accepted without authentication · BACnet/SC not enforced · supervisory VLAN flat | Yes — High consequence (hot-aisle excursion) |
| T0836 Modify Parameter | IPMI / Redfish | server thermal-limit registers | Default credentials in use · OOB management on production VLAN · firmware updates unsigned | Yes — Medium consequence (thermal-trip surface) |
| T0843 Modify Programming | Niagara station import | BMS schedule object | Station file writable from supervisor · no integrity check on import · no audit on schedule change | Yes — Medium consequence (schedule-driven excursion) |
Every row in our risk register starts as a realisation-condition query. The report is a join, not a narrative.
Two Scanners. Same Realisable Surface. Zero Impact on Your Floor.
Most assessments collect what an engineer can write down in a notebook. twinos Assess collects what the controller, its station files and its hardware actually say — and feeds it into the realisation-condition library.
| Mode | What it reads | Bus impact | What we see |
|---|---|---|---|
| Active — protocol | BACnet ReadProperty, Modbus reads, SNMPv3 walks, IPMI inventory under signed read-only ground rules | Negligible — read-only, rate-limited | Live controller state, subscribed objects, schedule and calendar bindings |
| Passive — protocol | Niagara station exports, BACnet EDE / PICS files, Modbus register maps, IPMI inventories | Zero packets on the BMS network | Full BACnet object model, supervisor-to-controller bindings, write paths |
| Passive — OS | Configuration exports from BMS supervisors, EWS and jump hosts — services, accounts, patch state, hardening posture | Zero | OS-level realisation conditions per technique |
| Passive — HW | Controller datasheets, FAT documents, PDU port surveys | Zero | Debug ports, console exposure, firmware extraction reachability, default-credential exposure |
On a typical colo or hyperscale hall, around 80 percent of the answer comes from Niagara station exports and BACnet EDE files alone. We bring the bus in only when the exports do not tell us.
The Risk Register Is Computed. Same Rubric, Every Site, Every Time.
There is one path from controller to register — and the customer can re-run it next year and get the same verdict.
- Scanner output — controller, protocol surface, OS posture, HW exposure
- × Realisation-condition database — per-technique realisability per asset
- × Consequence × Capability × Exposure rubric — per-asset, per-technique risk
- → Prioritised risk register, device-level roadmap, tenant-ready evidence pack, executive readout
- Same depth on every controller — the engineer does not get tired on Hall-3
- Reproducible — the auditor and the tenant can re-run the scan next year and replicate the verdict
- Recommendations move scanner-observable preconditions — close the precondition, the technique falls off the register on the next scan
- Comparable across halls — multi-site SLA risk roll-ups stop being apples-to-oranges
We compute the risk register the way a facilities engineer computes a thermal balance.
Risk-Based Scoring. Not CVE-Based.
The industry default
- Count CVEs per BMS asset from a vulnerability database
- Sum or average CVSS — produce a per-controller 'severity'
- Rank assets by patch backlog the operator cannot apply
- Heatmap by colour, file the report, present at the SteerCo
- Hall manager cannot reboot a CRAH controller in production
- Same finding next quarter, same colour, same shelf
The twinos rubric
- Score consequence per technique per controller — what breaks in the hall
- Tier the plausible adversary for this site, this tenant mix, this geography
- Score exposure with BMS segmentation and remote-access hygiene credited
- Risk = Consequence × Capability × Exposure — defensible line by line
- Recommendations sized against the SLA clock, not a patch calendar
- The same controller can be 'CVSS 9.8' and negligible risk — and vice versa
What You Get — Artefacts, Not Adjectives.
| Deliverable | What it contains | Who reads it |
|---|---|---|
| Prioritised Facilities-OT Risk Register | Per-controller, per-technique findings — protocol, device class, consequence, capability tier, exposure, aggregate risk, recommendation | Facilities security lead, hall manager |
| Device-Level Remediation Roadmap | Sequenced 0–3 month, 3–9 month, 9–24 month actions — segmentation, BACnet/SC adoption, remote-access hardening, compensating controls; replacement only where it pays back | CISO, head of critical environments |
| Compliance & Tenant Evidence Pack | Findings mapped to IEC 62443-3-3, ISO 27001 Annex A, Uptime Tier compliance evidence, SOC 2 control narratives, tenant-facing security attestation appendix | Auditor, compliance officer, tenant security counterpart |
| Executive Readout | Boardroom and tenant-review narrative — what the floor is exposed to, what we are doing about it, what we are accepting and why | C-suite, key tenant security review |
Every artefact is defensible — line by line, against a documented rubric. The auditor, the tenant and the board read it the same way.
How an Engagement Runs — Without Touching the Hall.
Operations-conscious by design. We do not actively scan BMS controllers. We do not reboot a CRAC. We do not require a maintenance window to deliver the assessment.
- 1. Scoping — sites, halls, scope of BMS / EPMS / access systems, ground-rules signed off in writing (1 week)
- 2. Passive collection — span-port capture on the BMS supervisory VLAN, configuration export from JACEs and PDUs, drawing review, vendor remote-access review, interviews; no active probes on the OT network (1–2 weeks)
- 3. Protocol & device analysis — BACnet / Modbus / SNMP traffic decomposition, controller inventory, supervisor-vs-controller hygiene, vendor jump-host audit (1–2 weeks)
- 4. Risk modelling — apply the rubric, score consequence / capability / exposure, draft the risk register (1–2 weeks)
- 5. Validation workshop — walk the findings with facilities and corporate security teams; calibrate consequence and SLA exposure with the people who run the hall (2 days)
- 6. Report & readout — register, roadmap, evidence pack, executive readout (1 week)
Indicative duration — 4 weeks for a single hall, 6–10 weeks for a multi-hall or multi-site portfolio. No tripped CRACs. No tenant-notification incidents during the assessment itself.
Why twinos.
- Generated, not authored — every finding is computed from scanner output and a realisation-condition database; the engineer does not get tired and the auditor can re-run the scan next year
- Facilities-OT native methodology — built from BMS controllers, chiller plants and PDUs; not an IT framework retrofitted with BMS vocabulary
- Protocol- and device-specific to BACnet object / property — every finding cites the BACnet object, instance and property (or the equivalent Modbus register / IPMI endpoint), not a generic technique number
- Risk-based, not CVE-based — consequence × capability × exposure; the only rubric a board and a tenant security review can defend the same way
- Audit- and tenant-ready by construction — every artefact maps line-for-line to IEC 62443, ISO 27001 and Uptime evidence expectations; the SOC 2 narrative writes itself
- Operations-conscious — 80 percent of the answer comes from Niagara station exports and BACnet EDE files; we bring the bus in only when the exports do not tell us
We are the facilities-OT cyber assessment your critical-environments engineer would write if they had three months and a methodology.
Where This Sits in Your Programme.
The assessment is the entry point — and complete in itself. The risk register, roadmap and evidence pack stand on their own; many operators stop here and use the output to drive their facilities-OT security programme for a year.
When the next question is asked, the same methodology extends:
- Continuous facilities-OT monitoring — convert the risk register into live BACnet / Modbus / IPMI detections tuned to your controllers
- Architecture review — segment the BMS / EPMS / access estate, harden vendor remote access, instrument the supervisory boundary
- Incident response retainer — the team that wrote the rubric is the team that picks up the phone when the hall is hot
No upsell pressure. The assessment is sold standalone, priced standalone, and delivered standalone.