Critical Infrastructure: Mission Domain Intelligence Guide

In an office network the worst outcome is data loss. On a substation or a water treatment line the worst outcome is a physical process operating outside its safe envelope, and the safety case was written assuming no one was lying to the controller.

What Critical Infrastructure covers as a mission domain

Critical infrastructure intelligence covers the systems whose failure causes cascading harm: electricity, water and wastewater, oil and gas, health, transport, telecommunications, finance and food supply. The analytic focus differs from enterprise security because the assets are operational technology, the priority order is safety then availability then integrity then confidentiality, and consequence is physical. Work involves asset and dependency mapping, exposure assessment across engineering and remote access paths, adversary capability matching, and consequence modelling that engineers rather than IT teams can validate.

Sub-areas include industrial control protocols and their absent authentication, engineering workstations and project file integrity, safety instrumented systems, vendor and integrator remote access, positioning and timing dependencies, and the physical security of unmanned sites. Threat actors range from state pre-positioning teams and ransomware affiliates hitting corporate networks that force operational shutdown, to hacktivists exploiting internet-exposed devices, to insiders and metal thieves.

Why it matters

Interruption propagates. A water utility losing chemical dosing control creates a public health emergency. Electricity failure removes water pumping, telecommunications and hospital function within hours. These sectors typically run equipment on twenty to thirty year lifecycles with narrow maintenance windows and heavy change control, so exposures persist far longer than in enterprise environments, and compensating controls such as segmentation and monitoring carry more weight than patching ever will.

What analysts actually look for

These are the concrete, observable signals that carry weight in this area of work:

Human machine interfaces and engineering panels reachable from the public internet, indexed by scan services, often with default or vendor credentials
Control logic downloads or configuration writes to programmable controllers outside an approved maintenance window or change record
Industrial protocol traffic containing write and command function codes from a host that has only ever polled read registers
New or reactivated vendor remote access sessions preceding unexplained process alarms, particularly outside contracted support hours
Positioning and timing anomalies affecting synchrophasor, telecoms or transport systems, consistent with satellite navigation jamming or spoofing
Physical intrusion indicators at unmanned sites: cut fencing, disabled cameras, tampered enclosures or copper theft near control cabinets
Hacktivist channels posting screen captures of control interfaces, sometimes genuine, frequently honeypots or long-dead demonstration systems
Corporate network ransomware activity spreading toward historians, jump hosts or the demilitarised zone that separates business from plant

Where the data comes from

Authoritative and openly available collection points. Always confirm licensing and terms before operational or commercial use:

CISA ICS advisories — Vendor-specific vulnerability detail, affected firmware versions and mitigations for control equipment
MITRE ATT&CK for ICS — Adversary technique taxonomy specific to operational technology, including impairment of process and safety functions
Sector ISACs (E-ISAC, WaterISAC, Health-ISAC) — Peer incident reporting and sector-specific advisories with operational context you cannot get elsewhere
Shodan and Censys — Evidence of internet-exposed control devices and protocol banners, used strictly for passive exposure assessment
ENISA and national NIS competent authority guidance — Regulatory expectations, incident reporting duties and sector risk assessments across the European Union
NERC CIP standards and regulator enforcement notices — Baseline control requirements for bulk electric systems plus documented real-world compliance failures
Dragos, Claroty and Nozomi public reporting — Threat group profiling and protocol-level detection research specific to industrial environments
National regulators and safety bodies — Incident statistics, licence conditions and enforcement history establishing the operator's obligations

A working method

A repeatable sequence beats ad-hoc searching. This is a practical starting workflow:

Map assets and dependencies — Build an inventory covering control devices, engineering workstations, remote access paths and the upstream utilities the site itself depends on.
Assess exposure passively — Identify internet-reachable devices, vendor tunnels and flat network segments using passive data. Active scanning of live control networks can itself cause outages.
Model consequence, not just likelihood — Work with process engineers to establish what an attacker with control could physically cause, and which safety layers are independent of the compromised system.
Match adversary capability — Compare observed threat activity against the specific equipment, protocols and access paths present, discarding threats that cannot reach this plant.
Prioritise mitigations with operations — Rank by consequence reduction achievable within real maintenance windows, favouring segmentation, monitoring and out-of-band recovery over patching.
Exercise the response — Rehearse a scenario with engineering, safety and communications present, including manual operation, and record where the plan failed.

How this connects across the intelligence taxonomy

Intelligence work does not respect neat boundaries. The mission domain you are working, the disciplines you practise, and the data points you pivot on are one connected system. These are the direct relationships for this entry — every link is also a tag, so you can follow any thread across the whole library.

Practised with these disciplines

Cyber Intelligence — Adversary Activity in Networks and Systems
Technical Intelligence — Technology Capability, Design, and Exploitation
Geospatial Intelligence — Intelligence Derived from Place
Energy Intelligence — Energy Production, Transport, and Markets
Risk Intelligence — Structured Assessment of Threat and Consequence
Vulnerability Intelligence — Weaknesses, Exploitation, and Prioritization
Measurement & Signature Intel — Signatures, Measurements, and Physical Phenomena

Worked in these data points

IP Address — Internet Protocol address identifying a device or server on a network.
Facility / Site — A physical installation — plant, base, port, data centre — with a fixed footprint and function.
CVE / Vulnerability — Common Vulnerabilities and Exposures identifier for a known flaw.
ASN — Autonomous System Number identifying a network operator on the internet.
Location / Coordinates — A geographic point, place, or region — the basis of GEOINT analysis.
Event / Incident — A discrete real-world occurrence — protest, strike, breach, seizure — with time, place, and actors.
GPS Coordinates — Precise latitude/longitude coordinates identifying an exact point on Earth — the atomic unit of GEOINT analysi

Adjacent mission domains

Inside the platform: where Critical Infrastructure lives

The Quantus platform is 204 pages behind a 147-item sidebar organised into six working groups: Command (24 items), Dashboards (15), Threat Theaters (14), Intelligence Domains (15), Investigate (34), and Administration (45). This entry is not a page in isolation — it is a thread running through several of them.

The modules that matter most here:

domain.php?d=critinfra — Critical Infrastructure dashboard
theater.php?d=critinfra — Threat theater view
ip-profile.php — IP Address profile
detection-rules.php — CVE / Vulnerability profile
asn-profile.php — ASN profile
search.php — Advanced search, filter and pivot
correlate.php — Correlation graph
cases.php — Case management

Each dashboard is local-first: it renders from the platform’s own database rather than depending on a live third-party call, so it still works when an upstream API is unreachable or rate-limited. Heavy aggregates are cached with a hard query time cap and degrade to the last good value instead of hanging the page.

Automation, playbooks and AI skills

Analysis that only happens when someone remembers to run it is not a capability. The platform ships a 30-step automation pipeline (cron.php) that collects, ingests, resolves, enriches, correlates and scores on a schedule — 25 seeders, 11 resolvers and 7 enrichment runners, all idempotent and cursor-based so a run can be interrupted and resumed without duplicating or losing work.

Relevant playbooks

Of the 14 incident playbooks in playbooks.php, these apply directly to Critical Infrastructure:

APT Intrusion Analysis — a step-checked workflow with the pivots, sources and handling rules already wired in.
NetFlow / Traffic Anomaly — a step-checked workflow with the pivots, sources and handling rules already wired in.
Ransomware Incident Intelligence — a step-checked workflow with the pivots, sources and handling rules already wired in.

AI skills that apply

The 16 one-click operations in ai-skills.php are deterministic jobs, not free-text generation. The ones that matter here:

Threat Hunt
Correlate Infrastructure
Run Alert Rules
Detection Rules
Summarise (Copilot)
Generate Report

Alerting closes the loop: rules in alerts.php fire on new indicators matching a saved query, so a first sighting in this area raises a notification rather than waiting to be noticed at the next review.

Feeds, data sources and the API

The collection layer runs a feed registry of free, machine-readable sources — bulk blocklists and trackers (Maltrail, IPsum, FireHOL, the full abuse.ch corpora, phishing databases, Emerging Threats, Spamhaus, DigitalSide, ThreatView), authoritative government feeds (CISA KEV, OFAC, UN and EU sanctions lists), and reference datasets (RIR allocations, ip-to-ASN and geolocation tables, MITRE ATT&CK, EPSS). collect.php pulls them server-side on a schedule; feeds.php and source-catalog.php show what is registered, what it covers and when it last ran.

Anything the platform holds is reachable programmatically. The REST API in api.php exposes 11 endpoints — status, stats, search, lookup, recent, export, bulk_check, top_threats, by_category, categories, check — and export.php streams 18 formats in bounded chunks, so a million-row export neither exhausts memory nor times out:

STIX 2.1, MISP, OpenIOC 1.1, CEF (ArcSight), LEEF 2.0 (QRadar), Zeek/Bro intel, Snort/Suricata rules, Palo Alto EDL, BIND RPZ, hosts blackhole, iptables, CSV, JSON, NDJSON/JSONL, XML.

That covers the CTI standards (STIX 2.1, MISP, OpenIOC), SIEM ingestion (CEF, LEEF, Zeek), detection engines (Snort/Suricata), and direct enforcement (Palo Alto EDL, BIND RPZ, hosts, iptables) — so intelligence developed here can be actioned in the tools you already run, without a manual reformatting step. A TAXII 2.1 server and a MISP/RSS feed are also served for pull-based sharing.

Use cases

Three ways this entry earns its keep in day-to-day work:

Triage under time pressure. An artifact or report lands and you need a defensible read in minutes, not days. Map assets and dependencies is the first move; the platform pre-computes the enrichment so the analyst spends the time on judgement rather than lookups.
Building the picture. A single indicator is rarely the story. Model consequence, not just likelihood turns one artifact into a network — shared infrastructure, repeated selectors, the same operator behind different names — via the correlation graph and the cross-entity link engine.
Producing something actionable. Analysis that ends in a document nobody can use is wasted. Exercise the response feeds the case file, the detection rule, the block list or the referral — with sourcing attached so the recipient can verify it.

Case management (cases.php), watchlists, saved searches and scheduled reports mean the work persists between sessions and survives an analyst leaving the team.

How each sector uses Critical Infrastructure

The same entry is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The underlying artifacts are shared — the constraints, outputs and thresholds are not.

🎖 Military and defence

Defence planners treat critical infrastructure as both a dependency and a protected object. Analysis supports force protection at bases that draw power, water and telecommunications from civilian networks, host nation infrastructure assessment for deployments, and resilience planning where mobilisation depends on rail, ports and fuel. It feeds intelligence preparation of the operational environment with dependency mapping and single points of failure. Constraints are strict in the domestic setting: military assistance to civil authorities operates under defined legal arrangements, and analysis identifying vulnerabilities in civilian systems is itself sensitive material requiring careful handling and controlled distribution.

🕵 National intelligence

National agencies track pre-positioning in infrastructure networks, which is a strategic indicator rather than a security incident. The requirement is to distinguish criminal intrusion, opportunistic scanning and deliberate access held for later use, and to understand what an adversary would need to cause an effect. Fusion is essential because technical telemetry alone rarely reveals intent; procurement, personnel and diplomatic reporting supply the rest. Classification is difficult because the operators who need the warning are private companies with limited clearances, so tearline production and cleared industry channels are central. Success is measured by warning that led to remediation before an effect occurred.

👮 Law enforcement

Law enforcement handles intrusions into utilities as serious criminal offences with public safety consequences, and the evidential requirements are unchanged by the sector: preserved logs, imaged systems, documented custody and lawful process for third party records. Operational technology environments complicate this, since taking a controller offline for imaging can affect service delivery and engineering staff may prioritise restoration over preservation. Investigators need agreed protocols with operators before an incident. Charging decisions may involve aggravated offences where safety was endangered, and prosecutors will need expert evidence explaining what the intrusion could have caused, not only what it did.

🔍 Private investigation and corporate security

Consultants and corporate security teams working for operators focus on asset inventory, exposure assessment, vendor access governance and consequence modelling. The practical products are a map of what is reachable from the internet, which remote access paths vendors hold, and which failures cascade. A private actor must not scan or test systems without written authorisation, and unauthorised probing of a utility can constitute a serious offence with safety implications. Testing in operational technology environments requires engineering sign off and often a physical safety case. Reports should assume regulatory review, because sector regulators increasingly require evidence of assessment and remediation.

📰 Journalism and OSINT media

Reporting on infrastructure vulnerability carries a genuine harm calculus that most beats do not. Publishing specific exposed systems, addresses or control protocol detail can enable an attack on services people depend on. Verification should rely on documented evidence and operator confirmation rather than on scan results alone, since internet exposed devices are frequently honeypots or misidentified. Responsible practice is to notify the operator and the national authority before publication and allow reasonable remediation time. Where a story concerns regulatory failure, the public interest is usually served by describing the class of weakness and the accountability gap rather than a reproducible target list.

🌍 NGO, humanitarian and human rights

Humanitarian organisations engage with infrastructure through service continuity for populations: water, health facilities, electricity for cold chains and telecommunications for coordination. In conflict, attacks on infrastructure raise international humanitarian law questions and documentation supports accountability, so records of damage, timing and effect on civilians should be collected to an evidential standard. Do no harm applies to publication, since detailing which facilities are still functioning can make them targets. Duty of care covers staff operating in degraded environments, and assessments should be shared with local operators who can act, not only with donors.

🎓 University and research

Research spans dependency modelling, cascading failure simulation, operational technology security and sector governance. Methodological care is needed because real operational data is rarely available, so results often rest on synthetic models whose assumptions drive the conclusions; those assumptions must be published. Ethics approval applies where research involves operator staff or could produce exploitable findings, and responsible disclosure norms apply to vulnerabilities discovered in industrial products. Share models and code, document validation against any real events available, and avoid publishing detail that provides a practical attack path, which is a recognised constraint rather than a limitation on academic freedom.

Playbook: working Critical Infrastructure end to end

A repeatable sequence, from the moment the requirement lands to the moment a product is delivered and the case is closed out. Each phase states what you are trying to establish, not merely what to click — the point is a defensible chain of reasoning, not a checklist.

Phase 1 — Define consequence before threat

Start with what must not happen: loss of supply to a population, contamination, safety system failure, or a cascade into dependent sectors. Rank scenarios by consequence and recovery time, not by likelihood of a particular attacker. This reframes the whole assessment, because the systems that matter are rarely the ones with the most vulnerabilities. A good output is a short list of unacceptable outcomes agreed with engineering and executive leadership.

Phase 2 — Build the asset and dependency inventory

Enumerate operational technology assets, their function, their safety role and their communication paths, then map dependencies on power, telecommunications, water, fuel and third party services. Include the dependencies of your dependencies where they concentrate on a single provider. The output is an inventory engineers recognise as accurate, which is a harder test than completeness and the point where most programmes fail.

Phase 3 — Map the access paths

Identify every route into the control environment: engineering workstations, jump hosts, vendor remote access, cellular modems, historians bridging to corporate networks, and forgotten dial up or wireless links. Verify physically where records are unreliable, because field devices are routinely installed outside asset management. A good output lists each path with its owner, its authentication method and whether it can be monitored, and flags the ones nobody could account for.

Phase 4 — Assess exposure without touching production

Use passive techniques, configuration review, network captures and vendor documentation rather than active scanning, which can crash legacy controllers. Where active testing is justified, do it on a test bench or during a planned outage with engineering sign off and a safety case. The output is an exposure picture with a documented method that would satisfy a regulator and would not itself have caused an incident.

Phase 5 — Model the adversary realistically

Distinguish opportunistic criminal actors, ideologically motivated intruders and state actors pre-positioning for later use, because their behaviour and the appropriate response differ. Assess what each would need to achieve the consequences on your list: access, engineering knowledge, process understanding and time. Most damaging scenarios require process knowledge that generic intrusion does not provide, which is a defensible reason to prioritise differently from an enterprise environment.

Phase 6 — Establish monitoring that fits the environment

Deploy passive network monitoring and protocol aware detection rather than agents on controllers, and baseline normal engineering activity so deviations are visible. Include physical and process signals, since an anomaly in a process variable can be the first indication of a manipulation. A good output is detection tuned by engineers who know what normal looks like, with alerts that route to people able to interpret them at any hour.

Phase 7 — Govern vendor and remote access

Inventory every vendor with access, define time bounded and monitored sessions, and remove standing credentials. Include contractual requirements for notification and evidence sharing. Test the process by attempting to establish access through the official route and seeing what actually happens. The output is a governed access register where each entry has a named owner, an expiry and a monitoring record.

Phase 8 — Plan response with engineering

Write incident procedures that acknowledge operational reality: what may be isolated, what must never be disconnected, who can authorise a shutdown, and how manual operation works if control systems are untrusted. Rehearse with control room staff, not only with IT. A good output is a plan that the shift engineer at three in the morning can follow, which is a completely different document from a corporate incident response policy.

Phase 9 — Preserve evidence without endangering service

Agree in advance with law enforcement how evidence will be preserved when the priority is restoring supply. Identify what can be captured safely, such as network traffic, logs and configuration exports, and what requires an outage. Record engineering decisions contemporaneously. The output is a preservation protocol signed off by legal, engineering and the relevant authority before an incident, not negotiated during one.

Phase 10 — Coordinate across the sector

Share indicators and consequence relevant findings through sector information sharing bodies and the national authority, with handling markings that let recipients act. Infrastructure sectors are interdependent, so a finding at one operator is usually relevant to several. A good output is a report a peer operator can use to check their own environment within a day, which means it must include what to look for and where.

Phase 11 — Test recovery against the consequence list

Exercise restoration for the scenarios you said were unacceptable, including operation without corporate IT, without vendor support and with degraded telecommunications. Measure time to restore supply, not time to restore systems. The output is a measured recovery time per scenario with the specific dependencies that extended it, which is the evidence that drives investment far more effectively than a risk register entry.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

Source register: what to collect from, and how

Sources are listed with their access model so you can plan around cost and licensing before you build a dependency on them. Open means no account required; registration means a free account or API key; licensed means paid or institutional access. Always confirm current terms — licensing changes, and a source that was free for research may not be free for commercial or evidential use.

Source	Access	What it gives you	How it is used here
CISA advisories and ICS advisories	Open	United States government advisories covering industrial control system vulnerabilities, affected products and mitigations.	Primary feed for vulnerabilities in the specific controllers and software an operator runs.
MITRE ATT&CK for ICS	Open	Technique taxonomy specific to industrial control environments including impact and process manipulation techniques.	Structuring detection coverage and threat modelling in operational technology rather than enterprise terms.
National Vulnerability Database	Open	Vulnerability records with severity scoring, affected version ranges and vendor references. Cross referenced to vendor advisories and exploitation reporting.	Assessing which disclosed vulnerabilities apply to the installed base and their exploitation status.
Shodan and Censys	Registration	Internet wide scan data identifying exposed services including industrial protocols and remote access.	Checking whether your own or a supplier's control systems are reachable from the internet.
NERC CIP standards and enforcement records	Open	North American reliability standards for bulk electric system cyber security, with published violation and lessons learned material.	Benchmarking control expectations and learning from documented compliance failures. Enforcement records show which controls fail most often in practice.
ENISA threat landscape reporting	Open	European assessments of sector threats, including transport, energy and health infrastructure. Includes sector specific analysis and annual threat landscape reporting.	Regional threat context and policy framing for European operators and regulators. Useful for framing obligations under European network security law.
IEC 62443 standards series	Licensed	International standards for security of industrial automation and control systems, covering zones, conduits and lifecycle.	Reference architecture and control framework for segmentation and supplier requirements. Also the basis for security requirements written into supplier contracts.
NIST SP 800-82 guide to OT security	Open	Detailed United States guidance on securing operational technology including risk management and architecture.	Practical control guidance adapted to environments where availability and safety dominate. Particularly useful where patching is constrained by safety certification.
Sector ISACs	Registration	Sector specific information sharing centres distributing incident intelligence and defensive content among operators.	Peer warning about campaigns targeting the same equipment and processes you operate.
Dragos and specialist OT threat research	Open	Published research on threat groups targeting industrial environments and on incident case studies.	Threat group profiles specific to control systems rather than generic enterprise intrusion sets.
Vendor product security advisories	Open	Manufacturer notices on vulnerabilities, firmware updates and workarounds for controllers and engineering software.	Authoritative patching and mitigation information for the specific installed equipment. Subscription to vendor notification is essential for legacy installed base.
National regulator guidance	Open	Sector regulator requirements and guidance on resilience, incident reporting and security duties for operators.	Establishing the legal obligations that shape assessment scope and reporting timelines. Reporting timelines differ by sector and must be confirmed locally.
Incident reporting datasets and outage records	Open	Public records of service interruptions, their causes and duration maintained by regulators and system operators.	Grounding consequence models in observed failure and recovery behaviour rather than assumption.
IAEA nuclear security guidance	Open	International guidance on computer security at nuclear facilities and protection of safety related systems.	Reference framework where safety instrumented systems and regulatory oversight are involved. Applies wherever safety instrumented systems are within scope.

Prefer sources that publish a methodology and a revision history. A dataset that changes silently is a liability in any product that has to survive challenge.

Tooling

Tools commonly used against Critical Infrastructure. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

Passive OT network monitoring platforms — Protocol aware traffic analysis and asset discovery without touching devices. Limitation: requires suitable network taps and blind to activity on serial or isolated segments.
Configuration review and offline analysis — Examines controller and engineering workstation configuration for exposure and drift. Limitation: depends on accurate exports and cooperation from engineering teams.
Asset inventory systems for OT — Maintains a register of devices, firmware and network position. Limitation: field devices installed by contractors are routinely missing until physically verified.
Consequence and dependency modelling — Maps cascading failure paths between systems and sectors. Limitation: models are only as good as the dependency data, which is usually incomplete outside the operator.
Protocol aware intrusion detection signatures — Detects anomalous control commands and engineering operations. Limitation: needs baselining by people who understand normal process behaviour, or it produces unusable noise.
Test benches and digital twins — Allow security testing without risking production processes. Limitation: expensive to build and rarely mirror the legacy equipment that carries the real risk.
Vendor remote access brokers — Provide time bounded, recorded and approved vendor sessions. Limitation: only effective if all legacy access paths are actually removed rather than left as backups.
Exposure monitoring against scan data — Alerts when operator systems appear in internet wide scan datasets. Limitation: attribution of a scanned device to an owner is often wrong, so findings need physical verification.

AI skills and automation in detail

These are deterministic jobs with defined inputs and outputs, not open-ended prompting. Each is idempotent and cursor-based: interrupt one and it resumes where it stopped rather than duplicating work or losing progress.

Threat Hunt — Runs saved hypotheses against the corpus and surfaces what matches, with the query preserved as a versioned artifact.
Correlate Infrastructure — Builds the cross-entity link graph: shared hosting, reused certificates, overlapping registrants, repeated selectors.
Run Alert Rules — Evaluates saved rules against new data so a first sighting raises a notification rather than waiting for review.
Detection Rules — Generates YARA, Sigma and Snort/Suricata logic from the selected indicators, ready to deploy.
Summarise (Copilot) — Produces a narrative summary beside the underlying records. It explains; it never creates indicators or assigns attribution.
Generate Report — Assembles a sourced product from the current case or query, with provenance attached to each element.

A note on the boundary: the only skill that involves a language model is Summarise (Copilot), and it writes prose about records that already exist. Nothing else on this list involves generation of any kind. No indicator, relationship or attribution in the platform originates from a model. See the full skill list.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

Start from consequence, not vulnerability. A high severity vulnerability on a device that cannot affect the process matters less than a weak credential on a system that can, and vulnerability counts systematically mislead in this sector.
The dangerous access path is usually the one nobody owns. Cellular modems installed for a commissioning project, contractor laptops and forgotten dial up links appear in incident after incident precisely because no register lists them.
Damaging manipulation requires process knowledge, not just access. Assessing whether an intruder could actually cause harm means asking what they would need to understand about the plant, which usually narrows the credible threat set considerably.
Never active scan production control systems casually. Legacy controllers fail on unexpected traffic, and a security assessment that trips a plant has caused exactly the outcome it was meant to prevent.
Engineers detect anomalies security tools miss. A control room operator noticing a valve behaving oddly has caught manipulations that no signature would flag, so build reporting routes from the plant floor into security.
Measure recovery in supply restored, not systems restored. Boards understand outage duration to customers, and that metric also exposes the dependencies, such as vendor support and telecommunications, that system level metrics hide.
Publication restraint is part of the tradecraft. Specific exposed assets and reproducible control detail create risk to services people depend on, so notify the operator and national authority first and describe the class of weakness publicly.

Measuring whether it is working

Capability claims should be falsifiable. These are the measures that show whether work on Critical Infrastructure is producing anything, and they are worth baselining before you change process or tooling.

Measured time to restore supply for each unacceptable consequence scenario, taken from exercises rather than estimated.
Percentage of control environment access paths with a named owner, an expiry and monitoring in place.
Number of previously unknown assets or connections discovered per physical verification cycle, trending toward zero.
Detection coverage against MITRE ATT&CK for ICS techniques, reported alongside the telemetry that supports each.
Vendor session compliance rate: proportion of remote access events that went through the governed, recorded route.
Mean time from vendor advisory publication to assessed applicability and mitigation decision for installed equipment.
Proportion of incidents where evidence was preserved according to the agreed protocol without extending the outage.

Beware of measuring volume alone. Indicator counts and report counts rise easily and say little; time-to-attribution, proportion of findings that survive review, and how often a product changed a decision say a great deal.

Common pitfalls

Applying enterprise patch cadence logic to systems where an unplanned restart is a bigger risk than the vulnerability
Believing an air gap that has not been tested; almost every claimed isolated network has a vendor modem or a data historian bridge
Amplifying hacktivist claims that turn out to be honeypots, demonstration rigs or screenshots of systems that were never in service
Confusing internet exposure with exploitability, and equally confusing lack of exposure with safety when vendor access exists
Ignoring supply chain and integrator risk, where one engineering firm holds remote access to dozens of unrelated operators
Producing threat reporting engineers cannot use because it never mentions the specific device, protocol or process involved

Legal and ethical considerations

Operators sit under sector-specific regulation with mandatory incident reporting on short clocks, and reporting duties may attach before the technical picture is clear. Detailed asset and vulnerability information about national infrastructure is itself sensitive and usually protectively marked; share it under agreement, not in public reporting. Never conduct active scanning or testing without written authorisation from the asset owner and their safety authority. Where safety systems are implicated, health and safety law and accident investigation powers take precedence over security process.

Data integrity: no fabrication, no drift, no hallucination

Intelligence that cannot be traced back to a source is not intelligence, it is assertion. Everything in this entry — and everything in the platform behind it — is built on a small number of non-negotiable rules.

Provenance on every record

Every indicator carries the source that supplied it, a first-seen and last-seen timestamp, and a sighting count. Where several feeds report the same artifact, each contribution is recorded separately rather than collapsed, so you can see whether a finding rests on one source or twelve. Source attribution travels with the data into every export, so a recipient can audit a claim without asking you for the working.

Nothing is invented to fill a gap

If the platform has no data for Critical Infrastructure, it says so. Empty is displayed as empty — never padded with plausible-looking placeholder values, sample records or illustrative examples that a reader might mistake for observations. A dashboard with no rows is a true statement about collection coverage, and it is treated as a gap to close, not a blemish to hide.

Scoring is deterministic and reproducible

Threat scores, reputation grades and risk tiers are computed from stated inputs with fixed weights, not estimated. The same inputs always produce the same output, and the formula is visible rather than a black box. Aggregates are cached with an explicit time-to-live so a figure on screen is never silently stale — and when a heavy query exceeds its time budget the platform serves the last known-good value and labels it, rather than inventing a fresh number or hanging.

Where AI is used, and where it is not

Language models summarise and explain. They do not create indicators, assign attribution or manufacture relationships. No IP address, wallet, hash or identity in the platform originates from a model — every one is ingested from a named feed, resolved from a reference dataset, or entered by an analyst with a source recorded. Copilot output is presented as narrative alongside the underlying records, never in place of them, so a reader can always check the summary against the evidence.

Guarding against drift

Enrichment is additive and timestamped rather than overwriting. Reference data — sanctions lists, allocations, taxonomies — is re-synchronised from the authority on a schedule instead of being edited in place, so local copies cannot quietly diverge from the source of truth. Attribution is recorded with a confidence level and the reporting it rests on, and inferred relationships are labelled as inferred. When a source retracts or corrects, the correction propagates rather than leaving a stale assertion behind.

What this means for you

You can put a finding from this platform in front of a regulator, a court, a board or a partner agency and show where each element came from. That is the standard the tooling is built to — because in this work, being confidently wrong is more damaging than being usefully uncertain.

By the numbers

The taxonomy this entry belongs to is not a marketing list — it is the actual structure of the platform: 52 mission domains, 52 intelligence disciplines and 65 data points, each with a live dashboard behind it. Supporting that: 18 indicator types, 14 playbooks, 16 AI skills, 18 export formats and a 30-step automated pipeline.

This particular entry connects directly to 7 intelligence disciplines, 7 data points, 6 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

Why not just patch everything like an enterprise environment?

Because availability and safety constraints make patching a change management problem with an outage cost, and vendor certification often prohibits unapproved updates on safety related systems. Many controllers cannot be patched at all and are supported for decades. The practical approach is compensating controls: segmentation into zones and conduits, strict control of engineering workstations, monitored and time bounded vendor access, and detection tuned to the process. Prioritise the small set of vulnerabilities that are reachable and consequence relevant, and be explicit with regulators about why the remainder are managed rather than remediated.

How do we tell pre-positioning from ordinary criminal intrusion?

Look at behaviour after access. Criminal actors monetise quickly through extortion or data theft, generally within days, and rarely invest in understanding the process. Pre-positioning looks like persistent, quiet access with attention to engineering documentation, network topology and control system knowledge, and no monetisation despite obvious opportunity. Living off the land techniques and use of legitimate remote access are common because they avoid detection. Where the picture is ambiguous, report it as ambiguous and escalate to the national authority, since the response and the notification obligations differ substantially.

Is internet exposed control equipment as common as scan data suggests?

Exposure is real but scan derived counts overstate it. Many results are honeypots, misidentified devices, vendor demonstration systems or simulators, and ownership attribution from IP address is frequently wrong. Treat scan findings as leads requiring verification with the supposed owner. That said, the recurring pattern of a modem installed for maintenance convenience, a historian bridged to a corporate network or a remote terminal unit reachable over cellular is genuine and has featured in real incidents, so the correct response is verification rather than dismissal.

What should an operator agree with law enforcement in advance?

How evidence will be preserved when restoring supply is the overriding priority. That means agreeing what can be captured without an outage, such as network traffic, logs and configuration exports; who can authorise taking a device out of service; how engineering decisions during response will be recorded; and the point of contact on both sides at any hour. It should also cover information sharing constraints, since operators may face regulatory reporting duties on different timelines. Agreeing this during an incident wastes the hours when preservation is still possible.

How do we justify investment without a recent incident?

Use measured recovery time against defined unacceptable consequences. A rehearsed scenario showing that supply to a given population cannot be restored within a stated period without vendor support that may be unavailable is far more persuasive than a risk matrix. Pair it with regulatory obligations and with peer incidents in the same sector, which boards find credible. Avoid framing built on vulnerability counts or generic threat statistics, because they invite debate about likelihood, whereas a demonstrated recovery gap invites a decision about tolerance.

Can red teaming be done safely in operational technology?

Only with engineering leadership, a safety case and clear boundaries, and usually not against live production. Legitimate approaches include assessment against a test bench or digital twin, tabletop exercises with control room staff, purple team work on the enterprise to operational technology boundary, and physical assessment of access controls. Where live testing is genuinely necessary, it runs during a planned outage with a rollback plan and an engineer authorised to stop it instantly. Testing that risks the process defeats the purpose of the exercise and can constitute an offence if unauthorised.

Standards, frameworks and further reading

Work that references a recognised framework is easier to defend, easier to hand over, and easier for a partner to consume:

IEC 62443, the international standard series for industrial automation and control system security including zone and conduit architecture.
NIST SP 800-82, guidance on operational technology security addressing availability and safety constrained environments.
NERC CIP, mandatory reliability standards governing cyber security for the North American bulk electric system.
NIS2 Directive and equivalent national regimes, imposing security and incident reporting duties on essential service operators.
MITRE ATT&CK for ICS, the technique taxonomy used to structure detection and threat modelling in control environments.
ISO 22301 business continuity management, framing recovery objectives and continuity testing for essential services.
IAEA nuclear security series guidance on computer security at nuclear facilities and protection of safety systems.
Coordinated vulnerability disclosure norms for industrial products, governing how weaknesses reach vendors and operators.

References

Primary sources and authoritative references for this entry. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

Industrial control systems advisories — Cybersecurity and Infrastructure Security Agency. Government advisories on control system vulnerabilities and mitigations.
Guide to Operational Technology Security, SP 800-82 — National Institute of Standards and Technology. Reference guidance for securing industrial control environments.
MITRE ATT&CK for ICS — MITRE. Technique taxonomy specific to industrial control system attacks.
Critical Infrastructure Protection standards — North American Electric Reliability Corporation. Mandatory cyber security standards for the bulk electric system.
Threat Landscape reports — European Union Agency for Cybersecurity. Annual assessment of threats to European critical sectors.
IEC 62443 industrial security standards — International Electrotechnical Commission. Standards series for security of industrial automation and control systems.
Nuclear Security Series computer security guidance — International Atomic Energy Agency. Guidance on protecting computer systems at nuclear facilities.
OT threat group research — Dragos. Published profiles of threat activity groups targeting industrial environments.

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this entry: correlates control system exposure, vendor access paths and sector advisories against real consequence models. Explore the platform, or browse the rest of the library by following any tag above.