Protecting Industrial Environments Without Exposing Sensitive Operational Data

Cyber threat intelligence becomes more valuable when organisations can learn from each other.

If one industrial operator identifies malicious infrastructure, an unusual access pattern, a new attacker technique, or suspicious activity involving an industrial protocol, that information could help another organisation recognise the same threat before it causes disruption.

In principle, the model is straightforward:

In Operational Technology, however, the reality is considerably more complicated. Industrial threat intelligence can contain information about critical assets, network relationships, engineering systems, remote-access paths, industrial protocols, vulnerabilities, and operational behaviour. Sharing too little may make the intelligence useless. Sharing too much may disclose sensitive information about the environment being protected.

This creates one of the fundamental challenges for collaborative OT defence:

How can an organisation warn others about a cyber threat without revealing unnecessary details about its own industrial infrastructure?

The AICOT project identifies this directly as a challenge. Operators may hesitate to exchange threat intelligence because of privacy, regulatory, competitive, and trust concerns, while the project aims to enable secure, privacy-preserving Cyber Threat Intelligence (CTI) exchange while strengthening trust and auditability.

 

OT Threat Intelligence Is More Than an IP Address

Threat intelligence is sometimes reduced to Indicators of Compromise such as:

• Malicious IP addresses
• Domains
• File hashes
• URLs
• Malware signatures

These indicators remain useful, but OT attacks frequently require additional context.

Imagine that an organisation observes:

Engineering workstation → PLC → unexpected write operation

Simply sharing the source IP address or the system identifier tells another organisation very little.

More useful intelligence might describe:

• The type of industrial asset involved
• The protocol being used
• The operation or command observed
• How access to the environment was obtained
• Whether legitimate engineering software was involved
• The sequence of activity preceding the event
• The attacker behaviour or technique
• The confidence level of the observation
• Whether similar activity has been observed elsewhere

This context makes the intelligence considerably more useful for detection. It can also make it more sensitive.

Asset identifiers, internal addresses, network zones, product information, engineering relationships, remote-access infrastructure, vulnerabilities, or operational patterns may reveal details that an organisation does not want distributed outside a trusted group.

Sharing Everything Is Not the Answer

Consider an operator that detects suspicious activity against a production controller.

A raw incident record might contain:

• Internal hostnames
• Internal IP addresses
• PLC model and firmware information
• Network segmentation details
• Engineering workstation identities
• User information
• Vulnerability information
• Remote-access infrastructure
• Exact timestamps
• Process or production information

Another organisation probably does not need all of this information to protect itself.

What it may need is something closer to:

A compromised remote-access account was followed by access to an engineering workstation and an unusual industrial write operation against a controller during active production.

The second description preserves the behaviour of interest without necessarily exposing the complete architecture in which it occurred.

This principle can be thought of as threat-intelligence minimisation:

Share enough information to make the intelligence operationally useful, but avoid sharing information that does not need to leave the originating environment.

The correct balance is difficult. Remove too much context and the intelligence becomes a generic indicator with limited detection value. Include too much and the organisation may expose information that creates security, privacy, operational, or commercial concerns.

Trust Is as Important as the Intelligence

There is another problem. Receiving threat intelligence does not automatically mean it should be trusted.

A security team needs to understand questions such as:

• Where did this information originate?
• When was it observed?
• Has it been modified?
• How confident is the source?
• Is the source authorised to distribute it?
• Is the intelligence still valid?
• Has another trusted organisation confirmed the activity?

This becomes particularly important when intelligence contributes to automated or AI-assisted detection. Suppose an OT defence platform receives an external indicator identifying an IP address as malicious. If that information has unknown provenance, is several years old, or was incorrectly classified, automatically treating every connection to that address as a critical industrial incident could produce poor security decisions. The intelligence therefore needs context about the intelligence itself.

Provenance, integrity, confidence, timestamps, sharing permissions, and audit history all contribute to whether another organisation can safely use it.

Interoperability Solves Only Part of the Problem

Industry standards already provide mechanisms for representing and exchanging threat intelligence. STIX provides a structured language for expressing cyber threat and observable information, while TAXII provides an application-layer protocol for exchanging CTI between systems. OASIS describes STIX and TAXII as supporting capabilities such as collaborative threat analysis and automated threat exchange.

These standards are important because two security platforms need a common way to represent and transport intelligence. But a shared format does not automatically solve the wider OT problem.

Two organisations may both support STIX/TAXII and still disagree about:

• What information should be shared
• Who should receive it
• How sensitive fields should be handled
• How source authenticity should be verified
• How long information should remain available
• Whether intelligence can be redistributed
• How contributions should be audited

Interoperability allows systems to communicate. Trust determines whether organisations are willing to communicate.

 

From Information Sharing to Trusted Sharing

This is why successful CTI exchange requires more than a transport protocol.

A practical model needs several layers.

• Information Minimisation: Only information necessary for the security objective should leave the originating organisation. Sensitive identifiers or environmental details may need to be removed, generalised, pseudonymised, or otherwise protected where appropriate.
• Access Control: Not every participant should necessarily receive every piece of intelligence. Information may need to be distributed according to sector, trust group, sensitivity, organisational role, or other sharing policies.
• Provenance: Recipients need to know where intelligence came from and whether its origin can be trusted.
• Integrity: Participants need confidence that intelligence has not been silently altered between creation and consumption.
• Auditability: Where sensitive intelligence is exchanged, organisations may need to understand who contributed, accessed, updated, or redistributed information.
• Interoperability: Shared intelligence should remain usable across different cybersecurity platforms rather than becoming locked into one vendor or implementation. Trusted communities already play an important role in this area. ENISA describes Information Sharing and Analysis Centres (ISACs) as trusted hubs that enable organisations across critical sectors to collect, analyse, and securely exchange threat information.

The technical challenge is enabling this type of collaboration while preserving the controls required by individual operators.

Where Blockchain Can Contribute

AICOT explores blockchain-backed CTI sharing as part of its objective to provide privacy, trust, auditability, and European interoperability for threat-intelligence exchange. The important distinction is that blockchain should not be treated as a replacement for security controls. Putting sensitive industrial intelligence directly onto an immutable shared ledger would create its own risks.

Instead, blockchain-related mechanisms can potentially support specific trust functions around the exchange, such as:

• Recording verifiable evidence that intelligence was published
• Recording and preserving provenance information
• Supporting tamper-evident audit records
• Supporting verification alone may be enough to establish an attack.
• Tracking authorised CTI transactions
• Supporting distributed trust between participating organisations

Sensitive intelligence itself can remain subject to appropriate privacy, storage, encryption, and access-control mechanisms. In this model, blockchain is not the threat-intelligence database. It is part of the trust layer around the exchange. That distinction matters.

Why Shared CTI Matters for AI-Driven OT Defence

Threat intelligence becomes particularly interesting when combined with local OT monitoring. Consider two industrial operators.

 

The organisation creates a privacy-preserving CTI representation of the observed behaviour and shares it with an authorised community.

Neither individual event may be enough to establish an attack.

But intelligence from Operator A can provide additional context.

The detection pipeline can evolve from:

Local anomaly detected → Local anomaly + external CTI correlation + asset context + behavioural evidence

This can potentially increase detection confidence without requiring Operator A to disclose its complete industrial environment.

The broader model becomes:

The final decision still belongs within the receiving organisation. Shared CTI provides additional evidence rather than replacing local operational context.

AICOT: Toward Collaborative OT Defence

AICOT is developing an AI-powered cybersecurity platform specifically for Operational Technology and critical infrastructure. Led by Logstail, the project builds on its expertise in SIEM, data analytics, and security operations while extending these capabilities with OT-specific machine learning, anomaly detection, protocol analysis, monitoring, and response.

Secure CTI exchange is also one of AICOT’s core objectives. The project specifically targets blockchain-backed sharing designed to support privacy, trust, auditability, and interoperability.

This matters because no industrial operator has complete visibility into the threat landscape. One organisation may identify attacker infrastructure. Another may observe a new industrial technique. A third may detect a behavioural pattern that does not yet correspond to a known signature.

Individually, these may appear to be isolated observations. Shared responsibly, they can contribute to a stronger picture of the threat.

The objective is therefore not to create an environment in which every organisation exposes everything it knows. It is to create one in which organisations can contribute useful intelligence without surrendering control of sensitive operational information.

Conclusion

Cyber threat intelligence sharing is fundamentally a collaboration problem.

In Operational Technology, it is also a trust, privacy, and operational-security problem. Industrial organisations need enough context to recognise emerging threats, but that context can itself contain information about the systems they are trying to protect. Effective OT threat-intelligence exchange therefore requires more than collecting indicators and sending them between platforms.

It requires:

Useful intelligence + controlled disclosure + trusted provenance + integrity + interoperability + auditability

Standards such as STIX and TAXII provide important foundations for structured exchange, while trusted communities such as ISACs demonstrate the value of collaborative cyber defence.

AICOT extends this challenge into the OT domain by exploring privacy-preserving, blockchain-backed CTI exchange alongside AI-driven monitoring and detection. Because the strongest collaborative defence is not built by sharing everything. It is built by sharing the right intelligence, with the right level of trust, with the right participants.

Follow the AICOT project on LinkedIn and X for project updates and practical insights into AI-driven OT cybersecurity.

AICOT is funded by the European Union’s Digital Europe Programme under Grant Agreement No. 101249826. Views expressed are those of the authors and do not necessarily represent the European Union or the European Cybersecurity Competence Centre.

Contact Our Experts or Sign Up for Free