There is a structural asymmetry in industrial security that rarely gets named directly. An adversary who builds tooling for a Schneider Triconex safety controller, or for the Siemens S7 protocol family, can point that tooling at every site running the same equipment. The engineering cost is paid once. Meanwhile the defenders at those sites almost never reuse each other's detection work. Each plant discovers the same behavior independently, months apart, and usually after something has already happened.
Collective threat intelligence is the attempt to close that gap. The idea is uncontroversial. The execution is where most programs quietly fail, because teams share the category of information that is easiest to export and least useful to receive.
The Indicators Most Programs Share Have a Short Half Life
Walk into a typical intelligence sharing arrangement and what moves across the boundary is a list: IP addresses, domain names, file hashes, maybe a YARA rule. This is the format the tooling supports, it fits neatly into STIX and TAXII feeds, and it is easy to sanitize before release.
It is also the layer an attacker can change in an afternoon.
David Bianco's Pyramid of Pain remains the clearest framing of why. Hash values sit at the bottom: recompile the binary and every hash in every feed is void. IP addresses and domains sit one level up: rotate infrastructure and the list is stale. Network artifacts, tools, and finally tactics, techniques, and procedures climb toward the top, where changing them costs the adversary real engineering time.
For enterprise IT, indicator sharing still earns its keep because the volume of commodity attacks is enormous and even a short-lived block list catches a lot of noise. For OT the calculus is different. The threats that actually matter to an industrial process are not commodity. They are small in number, patient, and built by people who expect to be hunted. Volt Typhoon, described in joint advisories from CISA and international partners as pre-positioning in critical infrastructure networks, was notable precisely for using valid credentials and native administrative tooling rather than malware that anyone could hash.
A shared list of bad IPs does very little against an adversary whose entire method is to look like your own administrators.
If your intelligence sharing program is measured by how many indicators you consume per month, you are measuring the wrong layer. The useful question is how many detections you now run that you did not have to design yourself.
What Is Genuinely Different About Industrial Networks
Here is the property that makes collective defense more promising in OT than in IT, and it has nothing to do with better feeds.
Industrial devices behave the same way across sites because they are the same devices doing the same physics. A PLC controlling a filling line and a PLC controlling a pump station run different logic, but at the wire they look remarkably similar. Both maintain a small, stable set of communication partners. Both use a narrow subset of protocol function codes, often three or four, unchanged for years. Both poll on a fixed interval with variance measured in milliseconds. Both move a nearly constant volume of bytes per hour.
That regularity is not a coincidence of configuration. It is a consequence of how deterministic control systems are engineered. A device that talks to a variable set of peers at irregular intervals is not a working controller.
This means a behavioral profile built at one site carries real information about the same device class at another site, in a way that an IP address never will. Statements like "this controller model never initiates outbound sessions," "this protocol implementation issues function code 90 only during engineering operations," or "this device family's session setup exposes a firmware identifier that most sensors discard" are portable facts about equipment, not facts about one network.
The shareable unit in OT is the behavior of a device class, not the address of an attacker.
Three Tiers of Shareable Knowledge
It helps to be explicit about what moves and what it is worth.
Tier one: indicators. Addresses, hashes, domains. Cheap to share, cheap to sanitize, decays fast. Keep consuming them, expect little.
Tier two: device and protocol behavior. Normal function code distributions per device family, expected peer cardinality, session setup fingerprints, timing envelopes, and the specific deviations that have historically preceded trouble. This is the tier that generalizes, and it is the tier almost nobody shares because it requires continuous full packet observation to produce in the first place.
Tier three: adversary technique patterns. MITRE ATT&CK for ICS gave the industry a common vocabulary here, covering behaviors such as manipulation of control, loss of view, and unauthorized program download. Technique level knowledge is the most durable of all, because an adversary changing technique is changing their approach, not their infrastructure.
The 2022 joint advisory on PIPEDREAM, the modular ICS toolkit also tracked as INCONTROLLER, is the clearest public example of tier three sharing done well. The capability was documented and published before it was observed causing damage in a live environment, describing how it interacted with specific controller families. Asset owners running that equipment could hunt for the described behavior rather than wait for an indicator to appear in a feed.
What Must Never Leave the Site
This is where collective intelligence programs earn or lose the trust of the plant, and the boundary needs to be drawn in engineering terms rather than legal ones.
Process values are not shareable. Setpoints, tag names, batch recipes, throughput figures, and control logic are competitive information and, in some sectors, safety information. A pump curve or a temperature profile can describe a proprietary process in enough detail to matter commercially.
Topology is not shareable either, at least not in identifiable form. The specific arrangement of zones and conduits at a site, mapped against IEC 62443 levels, is a roadmap for anyone who obtains it. The fact that a given device class typically sits at a zone boundary is useful and portable. The fact that your site's boundary sits at a particular address range is not.
The workable line is this: share what is true about the equipment, never what is true about your plant. A statement that generalizes to every owner of that device model is safe to contribute. A statement that only makes sense with your site diagram open next to it is not.
Programs that get this wrong in the cautious direction contribute nothing and receive nothing. Programs that get it wrong in the permissive direction get shut down by legal or by the operations director, usually permanently.
Regulation Is Starting to Assume This Exists
NIS2 does not merely tolerate intelligence sharing; it explicitly provides for voluntary cybersecurity information sharing arrangements among entities, alongside its incident notification obligations. The sector ISACs have been the practical vehicle for years, with the Electricity ISAC's role in disseminating the analysis of the 2015 and 2016 Ukraine grid attacks standing as the reference case for how quickly a well-run community can turn one victim's forensics into everyone else's detection logic.
The trend line is clear. Regulators increasingly assume that a mature operator both consumes and contributes. Being a pure consumer is becoming visible.
Membership Is Not Capability
The uncomfortable part is that joining a sharing community changes nothing on its own.
Tier two and tier three intelligence describes behavior. To act on a description of behavior you need a continuous record of behavior on your own network, at enough fidelity to compare against it. An advisory saying that a technique manifests as an unexpected program download to a controller is only actionable if something at your site is decoding that protocol continuously and can tell you whether it happened, and when, and from which host.
This is the practical argument for passive collection via SPAN or mirror ports with full packet inspection as the primary sensing layer, with flow telemetry as a complementary breadth signal. It transmits nothing into the process network, so it needs no maintenance window, and it produces exactly the artifact that collective intelligence assumes you have: a baseline of what your devices normally do, against which someone else's finding can be evaluated in minutes rather than weeks.
It also makes contribution possible. A site with continuous behavioral observation can answer the question every sharing community actually needs answered, which is not "have you seen this IP" but "does this pattern appear in your environment, and what did normal look like before it did." Vardar's approach starts from that same premise: the behavior of industrial equipment is regular enough to model, and a model built anywhere is worth something everywhere.
Where to Start
Three concrete moves, in order.
Join the ISAC for your sector and read the technique level reporting rather than the indicator feeds. Then audit whether you could actually answer a hunt request from that reporting today, using data you already collect. Most teams discover they cannot, and that gap is the real finding.
Second, decide your contribution boundary in writing before someone asks you for information during an incident. Equipment behavior yes, process and topology no. Having that settled in advance is what keeps the program alive after the first difficult request.
Third, treat behavioral baselines as the asset they are. The regularity of industrial devices is the one structural advantage defenders hold in this environment. An adversary can rotate every address and recompile every binary, but they cannot make a controller behave like something other than a controller while still using it to affect a physical process.
That constraint is the foundation collective defense in OT is actually built on.