OT CTI: Cyber Threat Intelligence for Industrial Systems

OT CTI is cyber threat intelligence designed for decisions about operational technology and industrial control systems. It does not become OT intelligence because a report mentions a PLC, SCADA server, or critical-infrastructure sector. It becomes useful when external and internal evidence is matched to real equipment, firmware, network paths, engineering workflows, process functions, operating state, safety constraints, and accountable action.

The same threat can have very different meaning across sites. A vulnerable remote-access component may control a production line, support a building system, sit unused in inventory, or be isolated behind a maintenance process. A technique described in public reporting may be technically possible but unable to reach the physical function that matters. Conversely, an ordinary identity or IT compromise can become an OT risk through an engineering workstation, historian, domain trust, vendor tunnel, backup server, or shared administration path.

This guide explains intelligence requirements, asset and process context, sources, vulnerability analysis, behavior mapping, attribution, handling, analytic method, products, detection, response, governance, and measurement for industrial environments.

Define OT Scope From the Physical Function

NIST SP 800-82 Rev. 3 defines OT broadly as programmable systems and devices that interact with the physical environment or manage devices that do. The scope includes industrial control systems, building automation, transportation, physical access control, environmental monitoring, and other cyber-physical systems. NIST emphasizes performance, reliability, and safety requirements alongside security.

Start from the service or process: generating electricity, treating water, moving material, maintaining temperature, operating rail signaling, controlling building access, or protecting personnel. Map the control, view, safety, quality, and recovery functions that sustain it. Then identify controllers, HMIs, engineering workstations, safety systems, historians, gateways, remote access, identity dependencies, update paths, backups, vendors, and connected IT.

This function-first scope prevents a flat list of industrial-looking devices from defining the mission. It also identifies IT systems whose compromise can affect OT even when they never issue an industrial protocol command.

Write Intelligence Requirements for Named Decisions

Every requirement needs a consumer, decision, time horizon, scope, evidence threshold, and review trigger. Examples include:

• Which current threats could interrupt this site’s critical process in the next 90 days?
• Does a new vendor advisory affect as-operated equipment, and what action is safe before the next maintenance window?
• Which remote-access paths are being targeted in our sector, and which local controls need verification?
• Which adversary behaviors should engineering and monitoring teams test for on a named architecture?
• What warning indicators would justify moving a process to manual or isolated operation?

Avoid requirements such as “monitor threats to OT.” They do not define what would change. Record what the consumer can authorize: an inventory check, vendor escalation, detection update, access restriction, maintenance change, spare-part decision, exercise, or continuity action.

Review requirements with operations, engineering, safety, maintenance, incident response, architecture, and business leadership. A security team cannot infer acceptable process interruption or safe containment from cyber evidence alone.

Build the Local Context That Makes Threat Reporting Relevant

External intelligence cannot determine local exposure without a maintained site view. For each important asset, preserve vendor, product family, exact model, hardware revision, firmware and software, enabled functions, network zone, addresses, protocol roles, owner, lifecycle status, support contract, safety or criticality role, approved communication, remote paths, and upstream dependencies.

Connect assets to process functions and operating modes. A logic download during a controlled outage differs from the same action during production. A vendor account approved for one cell does not become expected across the plant. A historian, identity provider, virtual platform, or time source may be an IT-managed dependency whose loss changes OT behavior.

CISA and international partners’ OT asset inventory guidance emphasizes ownership, classification, performance monitoring, change management, and continuous improvement. Record provenance and last verification. “In inventory” is not the same as “present, connected, configured this way, and supporting this process now.”

Use Sources With Different OT Visibility

A useful source portfolio combines:

• site telemetry, engineering logs, historian data, work orders, configuration history, maintenance findings, and incident cases;
• equipment vendors, integrators, service providers, and sector specialists with product or deployment knowledge;
• CISA ICS advisories, vendor security notices, national CERTs, vulnerability databases, and exploitation reporting;
• sector ISACs, ISAOs, trusted peer groups, regulators, and government partners;
• malware analysis, vulnerability research, passive DNS, infrastructure reporting, and relevant criminal-ecosystem observations;
• safety, reliability, physical security, geopolitical, and supply-chain reporting that changes the threat model.

Evaluate access and limits. A vendor knows its product but may not see exploitation outside customers who report it. A sector group sees participating members. A network sensor sees only its observation point. An operator can explain process meaning but may not know the attacker’s infrastructure.

Preserve the original source, publication and observation time, affected scope, handling terms, corrections, and confidence. Ten articles repeating one vendor advisory are one evidentiary stream.

Match Vulnerabilities to the As-Operated System

Begin with exact product identity. Match vendor, product, model, component, hardware revision, firmware or software, configuration, licensed feature, and deployment role. Confirm whether the vulnerable function is enabled and reachable from a plausible path. Gateways, embedded components, OEM branding, and integrator packages can obscure the affected technology.

Then assess exploitation evidence, required access, privilege, process consequence, existing segmentation, engineering controls, monitoring, vendor mitigation, maintenance constraints, rollback, spares, support status, and validation. A critical score does not establish local risk. An apparently modest weakness on a reachable engineering path can matter more than a high score on an isolated unused function.

Separate treatments: patch, vendor update, configuration change, disablement, access restriction, isolation, monitoring, operational workaround, or replacement. Test changes against representative equipment and process conditions. If immediate patching creates safety or availability risk, document a time-bounded alternative with an owner, monitoring, review trigger, and planned permanent treatment.

Use ATT&CK for ICS as a Behavior Vocabulary

The MITRE ATT&CK for ICS matrix organizes behaviors across initial access, execution, persistence, evasion, discovery, lateral movement, collection, command and control, inhibition of response, impairment of process control, and impact. Use it to normalize reports, identify evidence needs, build hypotheses, compare cases, and communicate testing goals.

Do not convert technique counts into risk or coverage percentages. A listed technique may require a platform, access path, protocol, privilege, or process condition absent from the site. One detection may observe only part of one procedure. An adversary can achieve the same objective through a behavior not represented in the current model.

For each relevant procedure, record the source, observed platform, access, preconditions, target role, process effect, data sources, local feasibility, confidence, and defensive action. Preserve the distinction between behavior reported elsewhere and behavior confirmed in your environment.

Assess Campaigns and Actors Without Letting Attribution Drive Everything

Actor and campaign reporting can explain targeting, access methods, preferred sectors, regional context, operational tempo, capability, and likely objectives. It can guide collection and exercises. It should not become a list of famous names detached from local exposure.

Separate evidence for activity clustering from evidence for sponsorship or direction. Malware overlap, infrastructure, victimology, language, time zone, operational security, and public government attribution have different weight and independence. State alternative explanations and confidence. A vendor’s cluster name may not map cleanly to another source’s name.

Defenders often can act before attribution is resolved. A confirmed exposed remote service, stolen engineering identity, unauthorized logic change, or loss of process view justifies action based on behavior and consequence. Use actor context when it changes priority, scope, collection, communication, or response—not as a prerequisite for defense.

Protect Sensitive Site and Engineering Information

OT intelligence can expose network diagrams, equipment models, firmware, logic, setpoints, safety functions, remote-access paths, maintenance windows, supplier relationships, recovery weaknesses, and physical consequences. That information can help defenders and attackers.

Define collection authority, purpose, handling labels, access roles, retention, secure storage, sharing approval, supplier restrictions, sanitization, and correction. Separate broadly shareable behaviors from site-identifying details. Use need-to-know access for engineering artifacts while ensuring responders can obtain required evidence during an incident.

Validate sharing agreements before an event. Specify what can move to vendors, sector communities, authorities, insurers, laboratories, and peer organizations. A handling label does not replace contractual, legal, safety, privacy, export, or national-security obligations.

Produce a Traceable OT Intelligence Assessment

Use a repeatable sequence:

1. Restate the decision and deadline. Define what the consumer can change.

2. Preserve the claims and sources. Separate observed facts, reported facts, assumptions, and assessments.

3. Validate local applicability. Match assets, versions, architecture, process function, operating mode, dependencies, and controls.

4. Test competing explanations. Consider maintenance, failure, configuration error, legitimate remote support, opportunistic crime, espionage, and deliberate process targeting where evidence permits.

5. Assess likelihood and consequence separately. A low-frequency path can still justify resilience work when physical consequence is severe.

6. State confidence and gaps. Explain which missing evidence could change the judgment.

7. Recommend an owner, action, safe timing, validation, and review trigger. Do not stop at “increase monitoring.”

Deliver Products That Fit Engineering and Operations Work

Different consumers need different products. A site engineer needs affected equipment, configuration, safe checks, vendor action, maintenance implications, and rollback. A monitoring team needs behavior, data requirements, expected process context, query logic, triage fields, and limitations. An incident commander needs affected functions, safe containment choices, decision authority, external coordination, and continuity status. Leadership needs consequence, uncertainty, options, deadlines, and residual risk.

Useful formats include a rapid advisory assessment, affected-asset list, threat-to-process map, collection request, behavior package, detection hypothesis, remote-access warning, supplier question set, exercise scenario, strategic trend assessment, and incident intelligence note.

Version every product. Include requirement, scope, observation window, sources, confidence, handling, owner, expiry, and what changed. Withdraw or correct intelligence when affected versions, exploitation evidence, asset state, or vendor guidance changes.

Convert Intelligence Into Bounded Monitoring and Testing

Translate a relevant behavior into a hypothesis tied to the site. Define the asset roles, zones, protocol operations, identities, process modes, engineering approvals, time window, data sources, and safe response. Network evidence may show a logic-write request, while controller records, project history, historian values, alarms, and operator context establish outcome and authorization.

Prefer passive collection where active interaction could create risk, but state its limits. A sensor sees only traffic crossing its position. Encrypted, serial, local, or alternate paths may be absent. Validate parsers against the actual protocol, model, and firmware. Test failover, gateways, maintenance, redundant paths, and data loss.

Use controlled exercises and known-good events. Never deploy uncontrolled malware or issue hazardous commands to prove a detection. An intelligence-led test should have written authorization, engineering ownership, bounded equipment, safe payloads, stop conditions, cleanup, and evidence review.

Integrate OT CTI With Response, Governance, and Metrics

Route intelligence into vulnerability management, remote-access governance, engineering change, detection, incident response, continuity, procurement, supplier management, spares, and exercises. CISA’s Principles of OT Cybersecurity emphasizes decisions that sustain safe, secure operations. CISA’s voluntary Cross-Sector Cybersecurity Performance Goals also call for collaboration between IT and OT security rather than isolated teams.

During response, preserve process and safety authority. Security can recommend isolation, identity revocation, or access restriction, but the responsible operator and engineer must assess physical effects unless immediate life safety requires an established emergency action. Maintain manual-operation, loss-of-view, rebuild, vendor, regulatory, and public-safety plans before an incident.

Measure decision outcomes: affected exposure validated before the deadline; warnings that changed access or maintenance; critical functions with mapped intelligence requirements; high-priority behaviors with tested evidence; corrections issued; unknown assets found; supplier responses improved; and exercise lessons closed. Do not count feeds, indicators, reports, or ATT&CK techniques as value by themselves.

Start small. Select one critical function, two recurring decisions, a few complementary sources, and named IT, OT, engineering, safety, and response owners. Demonstrate that evidence reaches a safe action and feedback improves the next assessment. Expand only when that loop works.