The open letter on collective cyber defense puts information sharing at the center of its proposal, for cybersecurity companies, governments, and frontier AI companies alike:
“Share threat intelligence and tested playbooks… share tools, playbooks, and credible threat assessments with governments, security partners, and open-source maintainers.”
The most common objection we hear from security teams when asked to join an ISAC (Information Sharing and Analysis Center) or similar mechanism is: “we can’t share our telemetry, it has sensitive data in it.” It’s a legitimate concern — but it’s not a valid reason to skip participation. It’s a reason to properly design the anonymization process before sharing. This guide is about that process.
What gets shared and what never does
Before the “how,” define the “what.” These categories should almost never leave your organization, even anonymized:
- Personal data belonging to customers or employees.
- Proprietary business information (contracts, pricing, roadmap).
- Details that would allow specific systems to be identified by their exact configuration (very specific internal software versions, real hostnames).
What is genuinely valuable to share, and what this guide focuses on:
- Indicators of compromise (IOCs): malware hashes, malicious IPs and domains, C2 patterns.
- Tactics, techniques, and procedures (TTPs) observed, mapped to MITRE ATT&CK.
- AI-assisted attack patterns (e.g., LLM-generated phishing with detectable characteristics, use of malicious agents).
- Response playbooks that worked, with no identifiable data from the original incident.
Step 1 — Anonymization pipeline before sharing
Never share raw telemetry. Define a pipeline with at least these stages:
- Selective extraction: pull only the fields relevant to the IOC/TTP (not the entire system log).
- Identifier generalization: replace internal IPs, hostnames, and usernames with consistent placeholders (
internal-host-A, not the real name), preserving relational structure only if it’s needed for the analysis. - Temporal aggregation: instead of “this attack occurred at 14:32:07 on 8/30,” use broader windows (“afternoon of 8/30”) unless temporal precision is critical to the TTP.
- Legal/compliance review: a mandatory step, not optional, before anything leaves the organization — especially in regulated sectors (finance, healthcare).
Step 2 — Standard format so it’s useful to others
Sharing information in an ad-hoc format reduces its usefulness. Use recognized standards:
- STIX/TAXII for structured IOCs and TTPs — this is the format most ISACs and platforms (including MISP) natively consume.
- Mapping to MITRE ATT&CK so the TTP is comparable across organizations with different contexts.
- Sightings, not just indicators: if you can, indicate how many times you observed the pattern and in what general context (sector, system type), not just the isolated indicator.
Step 3 — Choose the right sharing mechanism
Not all sharing mechanisms are equal in terms of the trust level and sensitivity they can handle:
| Mechanism | Trust level | What to share there |
|---|---|---|
| Sector-specific ISAC | High (verified membership) | Detailed TTPs, full playbooks |
| Open platforms (public MISP communities) | Medium-low | Generic IOCs, no sensitive context |
| Bilateral channels with trusted partners | Very high | Specific incident details shared under NDA |
| Report to government/national CERT | High (regulatory obligation in some sectors) | Everything required by applicable regulation |
Step 4 — Receive, not just give
The value of joining an ISAC is bidirectional. Define an internal process for consuming intelligence shared by others:
- Automated ingestion of STIX/TAXII feeds into your SIEM or threat-intel platform.
- A triage process to determine which received IOCs/TTPs apply to your specific tech stack (not everything applies to everyone).
- Feedback to the ISAC when an indicator shared by another member actually helped you detect something — this reinforces trust in the collective mechanism.
Step 5 — Measure the value of participating
To justify the effort internally (legal, engineering, security team time):
- Number of your own detections that originated from IOCs received via the ISAC.
- Investigation time saved thanks to TTPs already documented by other members.
- Feedback received on the usefulness of what your organization shared.
Checklist
- ☐ Define categories of data that never get shared, no exceptions
- ☐ Design an anonymization pipeline (extraction → generalization → aggregation → legal review)
- ☐ Adopt STIX/TAXII format and MITRE ATT&CK mapping
- ☐ Choose sharing mechanism(s) based on trust level and information sensitivity
- ☐ Automate ingestion of external threat intel into your SIEM
- ☐ Measure bidirectional value (what you gave, what you received, what actually helped)
Part of a series on how to put into practice the principles from OpenAI’s open letter on collective cyber defense (August 2026). Back to the full guide.
