Opening Framing
A single organization defending against sophisticated threat actors is like one soldier facing an army. But thousands of organizations sharing intelligence—each contributing what they see, each benefiting from what others learn—creates a collective defense that no adversary can fully evade. When one organization detects a new attack, shared intelligence can protect thousands of others before they're targeted.
Intelligence sharing transforms individual defense into collective security. ISACs (Information Sharing and Analysis Centers) connect organizations within sectors. Government agencies distribute advisories. Commercial vendors aggregate threat data. And informal communities of trust share insights that never appear in public reports. Effective participation in these ecosystems multiplies your defensive capabilities.
This week covers sharing frameworks and communities, legal and trust considerations, sharing standards and protocols, building sharing relationships, and measuring sharing value. You'll learn to both contribute to and benefit from the collective intelligence ecosystem.
Key insight: Sharing isn't charity—it's strategy. What you give comes back multiplied.
1) The Intelligence Sharing Ecosystem
Multiple overlapping communities and channels enable threat intelligence sharing:
Sharing Ecosystem Overview:
┌─────────────────────────────────────────────────────────────┐
│ SHARING LANDSCAPE │
├─────────────────────────────────────────────────────────────┤
│ │
│ GOVERNMENT ◄──────────────────────────────► PRIVATE SECTOR │
│ │ │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ ISACs/ISAOs │ │ │
│ │ │ (Sector-Specific Sharing) │ │ │
│ │ └─────────────────────────────┘ │ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────────┐ ┌──────────────────┐ │
│ │ CISA │ │ Commercial │ │ Informal Trust │ │
│ │ FBI/NSA │ │ Feeds │ │ Groups │ │
│ │ Alerts │ │ Vendors │ │ Peer Networks │ │
│ └──────────┘ └──────────────┘ └──────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘Key Sharing Organizations:
Information Sharing Organizations:
ISACs (Information Sharing and Analysis Centers):
┌─────────────────────────────────────────────────────────────┐
│ Sector-specific sharing communities │
│ │
│ Major ISACs: │
│ - FS-ISAC (Financial Services) │
│ - H-ISAC (Healthcare) │
│ - MS-ISAC (State/Local Government) │
│ - IT-ISAC (Information Technology) │
│ - E-ISAC (Electricity) │
│ - A-ISAC (Aviation) │
│ - RH-ISAC (Retail & Hospitality) │
│ - ONG-ISAC (Oil & Natural Gas) │
│ │
│ Value: │
│ - Sector-specific threat intelligence │
│ - Peer connections within industry │
│ - Coordinated response during sector-wide incidents │
│ - Trusted sharing environment │
│ │
│ Membership: Usually requires membership fee │
└─────────────────────────────────────────────────────────────┘
ISAOs (Information Sharing and Analysis Organizations):
┌─────────────────────────────────────────────────────────────┐
│ More flexible than ISACs, not sector-limited │
│ │
│ Examples: │
│ - Regional sharing groups │
│ - Topic-specific communities (ransomware, etc.) │
│ - Cross-sector initiatives │
│ │
│ Value: Flexibility, specific focus areas │
└─────────────────────────────────────────────────────────────┘
Government Programs:
┌─────────────────────────────────────────────────────────────┐
│ CISA (Cybersecurity and Infrastructure Security Agency): │
│ - Alerts and advisories │
│ - AIS (Automated Indicator Sharing) │
│ - Joint Cyber Defense Collaborative (JCDC) │
│ │
│ FBI: │
│ - InfraGard (FBI-private sector partnership) │
│ - IC3 (Internet Crime Complaint Center) │
│ - Flash reports and Private Industry Notifications │
│ │
│ NSA/CYBERCOM: │
│ - Cybersecurity advisories │
│ - Threat actor disclosures │
│ │
│ Value: Classified-derived intelligence, legal authority │
└─────────────────────────────────────────────────────────────┘
Commercial Sharing:
┌─────────────────────────────────────────────────────────────┐
│ Threat Intelligence Platforms: │
│ - Aggregate data from customers │
│ - Share anonymized insights │
│ - Provide enriched intelligence │
│ │
│ Vendor Communities: │
│ - Microsoft Security Intelligence │
│ - CrowdStrike Falcon Intelligence │
│ - Recorded Future Insikt Group │
│ │
│ Value: Scale, automation, enrichment │
└─────────────────────────────────────────────────────────────┘Informal Sharing:
Informal Sharing Networks:
PEER NETWORKS:
┌─────────────────────────────────────────────────────────────┐
│ Description: │
│ - Personal relationships between security professionals │
│ - Often built at conferences, previous employers │
│ - High trust, fast sharing │
│ │
│ Channels: │
│ - Direct messaging (Signal, etc.) │
│ - Private Slack/Discord servers │
│ - Mailing lists │
│ - Conference hallway conversations │
│ │
│ Value: │
│ - Fastest sharing channel │
│ - Highest trust │
│ - Context-rich intelligence │
│ - "What are you seeing?" real-time exchange │
│ │
│ Challenge: Doesn't scale, relationship-dependent │
└─────────────────────────────────────────────────────────────┘
COMMUNITY PLATFORMS:
┌─────────────────────────────────────────────────────────────┐
│ Twitter/X Security Community: │
│ - Real-time threat discussion │
│ - Malware sample sharing │
│ - Vulnerability disclosure │
│ │
│ MalwareBazaar / VirusTotal: │
│ - Sample sharing │
│ - Community tagging │
│ - Analysis sharing │
│ │
│ GitHub: │
│ - Detection rules (Sigma, YARA) │
│ - Tool development │
│ - Threat research │
│ │
│ Value: Open access, large community │
│ Challenge: Quality varies, attribution uncertain │
└─────────────────────────────────────────────────────────────┘
TRUST GROUPS:
┌─────────────────────────────────────────────────────────────┐
│ Description: │
│ - Invite-only groups of vetted professionals │
│ - Often regional or role-specific (CISOs, IR, etc.) │
│ - Operate under sharing agreements │
│ │
│ Examples: │
│ - Regional CISO roundtables │
│ - Incident response community groups │
│ - Threat intel analyst networks │
│ │
│ Value: High trust + specific relevance │
└─────────────────────────────────────────────────────────────┘Key insight: Different sharing channels serve different needs. Participate in multiple channels for comprehensive coverage.
2) Legal and Trust Frameworks
Effective sharing requires navigating legal requirements and establishing trust:
Legal Considerations:
CYBERSECURITY INFORMATION SHARING ACT (CISA 2015):
┌─────────────────────────────────────────────────────────────┐
│ US law enabling threat information sharing │
│ │
│ Key Provisions: │
│ - Authorizes sharing cyber threat indicators │
│ - Provides liability protection for sharing │
│ - Requires removal of personal information │
│ - Enables sharing with federal government │
│ │
│ Protections: │
│ - Antitrust exemption for sharing │
│ - FOIA exemption for shared information │
│ - Liability protection when done properly │
│ │
│ Requirements: │
│ - Remove PII not related to threat │
│ - Share for cybersecurity purposes │
│ - Follow specified procedures │
└─────────────────────────────────────────────────────────────┘
PRIVACY CONSIDERATIONS:
┌─────────────────────────────────────────────────────────────┐
│ What CAN be shared: │
│ - Technical indicators (IPs, domains, hashes) │
│ - Attack patterns and TTPs │
│ - Vulnerability information │
│ - Anonymized incident data │
│ │
│ What requires CAUTION: │
│ - Victim identifying information │
│ - Employee data │
│ - Customer information │
│ - Attribution claims │
│ │
│ GDPR/Privacy Law Considerations: │
│ - IP addresses may be personal data in EU │
│ - Legitimate interest basis for security sharing │
│ - Minimize personal data in shared intelligence │
└─────────────────────────────────────────────────────────────┘
REGULATORY REQUIREMENTS:
┌─────────────────────────────────────────────────────────────┐
│ Some sectors REQUIRE sharing: │
│ │
│ - Financial Services: Various reporting requirements │
│ - Healthcare: HHS breach reporting │
│ - Critical Infrastructure: CIRCIA (coming) │
│ - Defense Industrial Base: DFARS 7012 │
│ │
│ Know your sector's requirements │
└─────────────────────────────────────────────────────────────┘Traffic Light Protocol (TLP):
Traffic Light Protocol (TLP) 2.0:
PURPOSE:
Standard for indicating sharing restrictions on
sensitive information
TLP:CLEAR
┌─────────────────────────────────────────────────────────────┐
│ Color: White/No restriction │
│ Sharing: Unlimited - public disclosure permitted │
│ │
│ Use when: │
│ - Information is already public │
│ - No harm from public disclosure │
│ - Widest dissemination desired │
│ │
│ Example: Published CVE details, public advisories │
└─────────────────────────────────────────────────────────────┘
TLP:GREEN
┌─────────────────────────────────────────────────────────────┐
│ Color: Green │
│ Sharing: Community-wide, but not public │
│ │
│ Use when: │
│ - Useful to broader community │
│ - Should not be published publicly │
│ - Can share within peer organizations │
│ │
│ Example: IOCs from incident, general threat warnings │
└─────────────────────────────────────────────────────────────┘
TLP:AMBER
┌─────────────────────────────────────────────────────────────┐
│ Color: Amber │
│ Sharing: Limited to organization + need-to-know │
│ │
│ TLP:AMBER: Share with members of own organization │
│ who need to know │
│ │
│ TLP:AMBER+STRICT: Share only within own organization, │
│ not with clients or partners │
│ │
│ Use when: │
│ - Effective response requires limited sharing │
│ - Broader sharing could cause harm │
│ │
│ Example: Detailed incident information, victim names │
└─────────────────────────────────────────────────────────────┘
TLP:RED
┌─────────────────────────────────────────────────────────────┐
│ Color: Red │
│ Sharing: Only specific recipients, no further sharing │
│ │
│ Use when: │
│ - Information is extremely sensitive │
│ - Sharing beyond recipients would cause harm │
│ - Typically verbal or in-person only │
│ │
│ Example: Active investigation details, source protection │
└─────────────────────────────────────────────────────────────┘
TLP IN PRACTICE:
- Always label shared intelligence with TLP
- Respect TLP designations from others
- When in doubt, use more restrictive level
- TLP can be downgraded over time
- Never upgrade without source permissionBuilding Trust:
Trust Framework:
TRUST ELEMENTS:
┌─────────────────────────────────────────────────────────────┐
│ 1. IDENTITY VERIFICATION │
│ - Know who you're sharing with │
│ - Verify organizational affiliation │
│ - Vet individuals before sensitive sharing │
│ │
│ 2. RECIPROCITY │
│ - Two-way sharing relationship │
│ - Contributors, not just consumers │
│ - Share even when it's uncomfortable │
│ │
│ 3. CONFIDENTIALITY │
│ - Protect shared information appropriately │
│ - Honor TLP designations │
│ - Don't attribute without permission │
│ │
│ 4. RELIABILITY │
│ - Share accurate information │
│ - Correct errors quickly │
│ - Maintain quality standards │
│ │
│ 5. TIMELINESS │
│ - Share when information is actionable │
│ - Don't sit on useful intelligence │
│ - Respond to requests promptly │
└─────────────────────────────────────────────────────────────┘
EARNING TRUST:
┌─────────────────────────────────────────────────────────────┐
│ Start Small: │
│ - Share lower-sensitivity intelligence first │
│ - Build track record of reliability │
│ - Demonstrate handling of received intelligence │
│ │
│ Add Value: │
│ - Share unique insights, not just re-shared content │
│ - Provide context and analysis │
│ - Respond helpfully to questions │
│ │
│ Be Consistent: │
│ - Regular participation, not just during crises │
│ - Follow through on commitments │
│ - Maintain relationships over time │
└─────────────────────────────────────────────────────────────┘Key insight: Trust is the currency of intelligence sharing. Build it slowly, protect it carefully, never abuse it.
3) Sharing Standards and Automation
Technical standards enable automated, scalable intelligence sharing:
Intelligence Sharing Standards:
STIX (Structured Threat Information Expression):
┌─────────────────────────────────────────────────────────────┐
│ Purpose: Standard language for threat intelligence │
│ Version: STIX 2.1 (current) │
│ │
│ Core Objects: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Attack Pattern │ TTP description (maps to ATT&CK) │ │
│ │ Campaign │ Named attack campaign │ │
│ │ Course of Action│ Recommended response │ │
│ │ Identity │ Person or organization │ │
│ │ Indicator │ Detection pattern (IOCs) │ │
│ │ Infrastructure │ Systems used by adversary │ │
│ │ Intrusion Set │ Adversary behaviors │ │
│ │ Malware │ Malware description │ │
│ │ Observed Data │ Raw observations │ │
│ │ Report │ Intelligence report │ │
│ │ Threat Actor │ Adversary profile │ │
│ │ Tool │ Software used │ │
│ │ Vulnerability │ Weakness (CVE) │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Relationship Objects: │
│ - Link any objects together │
│ - Types: uses, targets, indicates, mitigates, etc. │
└─────────────────────────────────────────────────────────────┘
STIX Example:
{
"type": "bundle",
"id": "bundle--example",
"objects": [
{
"type": "indicator",
"id": "indicator--abc123",
"created": "2024-03-15T12:00:00Z",
"name": "Malicious IP",
"pattern": "[ipv4-addr:value = '192.168.1.100']",
"pattern_type": "stix",
"valid_from": "2024-03-15T00:00:00Z",
"labels": ["malicious-activity"]
},
{
"type": "malware",
"id": "malware--def456",
"name": "Evil RAT",
"malware_types": ["remote-access-trojan"],
"is_family": true
},
{
"type": "relationship",
"id": "relationship--ghi789",
"relationship_type": "indicates",
"source_ref": "indicator--abc123",
"target_ref": "malware--def456"
}
]
}TAXII (Transport Protocol):
TAXII (Trusted Automated eXchange of Intelligence Info):
PURPOSE:
Transport mechanism for sharing STIX content
TAXII 2.1 CONCEPTS:
┌─────────────────────────────────────────────────────────────┐
│ Server: Hosts threat intelligence │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ API Root │ │
│ │ └── Collection 1 (e.g., "Ransomware IOCs") │ │
│ │ │ └── STIX Objects │ │
│ │ └── Collection 2 (e.g., "APT Activity") │ │
│ │ └── STIX Objects │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Client: Consumes or contributes intelligence │
│ - Poll: Request objects from collection │
│ - Push: Add objects to collection │
└─────────────────────────────────────────────────────────────┘
TAXII OPERATIONS:
GET /collections/
- List available collections
GET /collections/{id}/objects/
- Retrieve objects from collection
- Filter by type, date, etc.
POST /collections/{id}/objects/
- Add new objects to collection
Example Request:
GET /taxii2/collections/abc123/objects/
?added_after=2024-03-14T00:00:00Z
&type=indicator
Response: STIX bundle with matching indicatorsAutomated Sharing Implementation:
Automated Sharing Architecture:
┌─────────────────────────────────────────────────────────────┐
│ YOUR ORGANIZATION │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ THREAT INTEL PLATFORM │ │
│ │ ┌──────────┐ ┌───────────┐ ┌────────────────┐ │ │
│ │ │ Internal │ │ Analysis │ │ Dissemination │ │ │
│ │ │ Data │ │ Engine │ │ Module │ │ │
│ │ └────┬─────┘ └─────┬─────┘ └───────┬────────┘ │ │
│ │ │ │ │ │ │
│ │ └──────────────┴────────────────┘ │ │
│ └──────────────────────┬───────────────────────────────┘ │
│ │ │
│ ┌───────────┴───────────┐ │
│ │ TAXII Client │ │
│ └───────────┬───────────┘ │
└─────────────────────────┼───────────────────────────────────┘
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ ISAC │ │ CISA │ │ Commercial │
│ TAXII │ │ AIS │ │ Feed │
│ Server │ │ Server │ │ Server │
└─────────────┘ └─────────────┘ └─────────────┘
Automation Benefits:
- Real-time sharing (no manual steps)
- Consistent formatting
- Scalable to many sources
- Reduced analyst burden
- Faster time-to-protection
Implementation Considerations:
- Quality filtering (don't ingest everything)
- Deduplication
- Confidence scoring
- Aging/expiration
- False positive managementMISP (Malware Information Sharing Platform):
MISP Overview:
PURPOSE:
Open source threat intelligence sharing platform
FEATURES:
┌─────────────────────────────────────────────────────────────┐
│ - Event-based intelligence storage │
│ - Attribute types for all IOC types │
│ - Correlation engine │
│ - Taxonomies and tagging │
│ - Sharing groups │
│ - Feed ingestion │
│ - STIX/TAXII support │
│ - API for automation │
│ - Synchronization between instances │
└─────────────────────────────────────────────────────────────┘
MISP STRUCTURE:
Event
├── Attributes (IOCs)
│ ├── IP address
│ ├── Domain
│ ├── File hash
│ └── ...
├── Objects (structured groups)
│ ├── File object
│ ├── Network object
│ └── ...
├── Tags (taxonomies)
│ ├── tlp:amber
│ ├── malware_classification:ransomware
│ └── ...
└── Sharing group
USE CASES:
- Internal TIP (Threat Intelligence Platform)
- ISAC infrastructure
- Cross-organization sharing
- Feed aggregation
- Incident trackingKey insight: Standards enable scale. Manual sharing works for occasional collaboration; automation works for continuous intelligence exchange.
4) Effective Sharing Practices
Being an effective sharing partner means contributing quality intelligence and using received intelligence well:
What to Share:
HIGH-VALUE SHARING:
┌─────────────────────────────────────────────────────────────┐
│ Incident-Derived Intelligence: │
│ - IOCs from confirmed incidents │
│ - TTPs observed in attacks │
│ - Attack timelines and progression │
│ - Lessons learned │
│ │
│ Why valuable: First-hand, verified, contextual │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ Novel Discoveries: │
│ - New malware samples │
│ - Unreported infrastructure │
│ - New TTPs or variations │
│ - Zero-day exploitation │
│ │
│ Why valuable: Not available elsewhere │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ Sector-Specific Insights: │
│ - Industry targeting patterns │
│ - Sector-specific attack methods │
│ - Regulatory-relevant threats │
│ │
│ Why valuable: Relevant to peer organizations │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ Analysis and Context: │
│ - Attribution assessments │
│ - Trend analysis │
│ - Threat actor updates │
│ - Campaign tracking │
│ │
│ Why valuable: Transforms data into intelligence │
└─────────────────────────────────────────────────────────────┘
LOW-VALUE SHARING (Avoid):
┌─────────────────────────────────────────────────────────────┐
│ - Re-sharing public reports without adding value │
│ - Unvalidated IOCs from unknown sources │
│ - Aged intelligence without current relevance │
│ - Information without context │
│ - Noise (commodity malware, scanning activity) │
└─────────────────────────────────────────────────────────────┘Quality Standards:
Intelligence Quality Checklist:
BEFORE SHARING, VERIFY:
□ ACCURACY
- Is this information verified?
- What is the confidence level?
- Have you validated indicators?
□ CONTEXT
- Is sufficient context provided?
- Can recipient understand relevance?
- Is the threat explained?
□ ACTIONABILITY
- Can recipient act on this?
- Are defensive recommendations included?
- Is timing still relevant?
□ PRIVACY
- Is PII removed/minimized?
- Are victim identities protected?
- Is source protection maintained?
□ FORMATTING
- Is TLP correctly applied?
- Is format standard (STIX preferred)?
- Are attributes properly typed?
QUALITY INDICATOR EXAMPLE:
Poor Quality:
"Bad IP: 192.168.1.100"
Good Quality:
┌─────────────────────────────────────────────────────────────┐
│ Indicator: 192.168.1.100 │
│ Type: IPv4 Address │
│ Context: Cobalt Strike C2 server │
│ First Seen: 2024-03-10 │
│ Last Seen: 2024-03-15 │
│ Confidence: High (observed in confirmed incident) │
│ Source: Internal incident investigation │
│ Related: SHA256 hash of beacon, domain aliases │
│ ATT&CK: T1071.001 (Web Protocols) │
│ TLP: AMBER │
│ Recommendation: Block at firewall, alert on connection │
│ Validity: Likely active 30 days based on actor pattern │
└─────────────────────────────────────────────────────────────┘Receiving and Using Intelligence:
Using Received Intelligence:
INTAKE PROCESS:
┌─────────────────────────────────────────────────────────────┐
│ 1. RECEIVE │
│ - Automated ingestion where possible │
│ - Manual review for high-value/sensitive │
│ - Document source and TLP │
│ │
│ 2. VALIDATE │
│ - Check source reliability │
│ - Verify technical accuracy │
│ - Assess relevance to organization │
│ │
│ 3. ENRICH │
│ - Add internal context │
│ - Correlate with existing intelligence │
│ - Check against local data │
│ │
│ 4. OPERATIONALIZE │
│ - Create detections where appropriate │
│ - Update block lists │
│ - Brief relevant teams │
│ - Track in TIP │
│ │
│ 5. FEEDBACK │
│ - Report hits/matches to source │
│ - Share false positive findings │
│ - Confirm usefulness │
└─────────────────────────────────────────────────────────────┘
OPERATIONALIZATION MATRIX:
Intelligence Type → Action
┌─────────────────────┬─────────────────────────────────────┐
│ Critical threat │ Immediate blocking, alert creation, │
│ to sector │ leadership notification │
├─────────────────────┼─────────────────────────────────────┤
│ Active campaign │ Detection rules, hunting queries, │
│ IOCs │ block lists │
├─────────────────────┼─────────────────────────────────────┤
│ Threat actor │ Update threat model, adjust │
│ profile update │ priorities, brief teams │
├─────────────────────┼─────────────────────────────────────┤
│ TTP information │ Detection development, purple │
│ │ team exercise planning │
├─────────────────────┼─────────────────────────────────────┤
│ Strategic trends │ Risk assessment update, │
│ │ executive briefing │
└─────────────────────┴─────────────────────────────────────┘Key insight: Good sharing partners both give and receive well. Use intelligence you receive, and share back what you learn.
5) Building Sharing Programs
Effective intelligence sharing requires organizational commitment and structure:
Sharing Program Components:
GOVERNANCE:
┌─────────────────────────────────────────────────────────────┐
│ Sharing Policy: │
│ - What can be shared (and what cannot) │
│ - Approval requirements by sensitivity │
│ - TLP handling procedures │
│ - Legal and compliance requirements │
│ │
│ Roles: │
│ - Sharing coordinator (primary contact) │
│ - Approval authority │
│ - Legal review (when needed) │
│ - Technical implementation │
│ │
│ Relationships: │
│ - ISAC membership and participation │
│ - Government partnerships │
│ - Peer relationships │
│ - Vendor coordination │
└─────────────────────────────────────────────────────────────┘
OPERATIONS:
┌─────────────────────────────────────────────────────────────┐
│ Inbound Intelligence: │
│ - Feed management │
│ - Manual intelligence review │
│ - Quality assessment │
│ - Operationalization workflow │
│ │
│ Outbound Intelligence: │
│ - Incident-derived sharing │
│ - Research and analysis sharing │
│ - Contribution tracking │
│ - Partner notification │
│ │
│ Technical Infrastructure: │
│ - TIP (Threat Intelligence Platform) │
│ - TAXII server/client │
│ - Secure communication channels │
│ - Integration with security tools │
└─────────────────────────────────────────────────────────────┘Measuring Sharing Value:
Sharing Program Metrics:
CONTRIBUTION METRICS:
┌─────────────────────────────────────────────────────────────┐
│ - Intelligence items shared (count) │
│ - Unique vs. derivative contributions │
│ - Feedback received on shared intelligence │
│ - Community recognition/reputation │
│ │
│ Goal: Track that you're contributing, not just consuming │
└─────────────────────────────────────────────────────────────┘
CONSUMPTION VALUE:
┌─────────────────────────────────────────────────────────────┐
│ - Shared intelligence hits in environment │
│ - Threats detected via shared indicators │
│ - Incidents prevented through early warning │
│ - Time saved through shared analysis │
│ │
│ Goal: Quantify value received from sharing communities │
└─────────────────────────────────────────────────────────────┘
RELATIONSHIP HEALTH:
┌─────────────────────────────────────────────────────────────┐
│ - Active sharing relationships (count) │
│ - Response time to requests │
│ - Reciprocity ratio (give vs. receive) │
│ - Community participation level │
│ │
│ Goal: Ensure sustainable, healthy relationships │
└─────────────────────────────────────────────────────────────┘
Example Dashboard:
Intelligence Sharing - Q1 2024
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Contributions:
- Indicators shared: 450
- Reports shared: 12
- Unique (first-hand): 85%
- Partner feedback: 15 positive responses
Consumption:
- Indicators received: 12,500
- Operationalized: 2,100 (17%)
- Detection hits: 45
- Incidents informed: 3
Relationships:
- Active ISAC membership: 2
- Government partnerships: 3
- Peer relationships: 15
- Reciprocity ratio: 1:28 (giving more)Overcoming Sharing Barriers:
Common Barriers and Solutions:
BARRIER: "We can't share—it's too sensitive"
┌─────────────────────────────────────────────────────────────┐
│ Solutions: │
│ - Use TLP to control distribution │
│ - Anonymize victim-specific details │
│ - Share TTPs without revealing incident │
│ - Start with lower-sensitivity items │
│ - Get legal approval for sharing policy │
└─────────────────────────────────────────────────────────────┘
BARRIER: "We don't have anything worth sharing"
┌─────────────────────────────────────────────────────────────┐
│ Solutions: │
│ - Every incident has shareable intelligence │
│ - Analysis of public information adds value │
│ - Even "negative" findings are useful │
│ - Questions to community are contributions │
│ - Detection rules are valuable sharing │
└─────────────────────────────────────────────────────────────┘
BARRIER: "We don't have time for sharing"
┌─────────────────────────────────────────────────────────────┐
│ Solutions: │
│ - Build sharing into incident response process │
│ - Automate where possible (STIX/TAXII) │
│ - Assign dedicated sharing coordinator │
│ - Make sharing part of analyst workflow │
│ - Use templates to reduce effort │
└─────────────────────────────────────────────────────────────┘
BARRIER: "We're just going to help competitors"
┌─────────────────────────────────────────────────────────────┐
│ Solutions: │
│ - Adversaries are the real competitor │
│ - Rising tide lifts all boats │
│ - Sector incidents hurt entire industry │
│ - What you receive far exceeds what you give │
│ - Reputation benefits of being good partner │
└─────────────────────────────────────────────────────────────┘
BARRIER: "Legal won't approve"
┌─────────────────────────────────────────────────────────────┐
│ Solutions: │
│ - Educate legal on CISA 2015 protections │
│ - Develop pre-approved sharing procedures │
│ - Use ISACs (built-in legal frameworks) │
│ - Create sharing agreement templates │
│ - Start with government sharing (clear legal basis) │
└─────────────────────────────────────────────────────────────┘Key insight: The organizations that share most effectively also receive the most value. Invest in sharing relationships as you would any strategic partnership.
Real-World Context
Case Study: ISAC Early Warning Success
During a coordinated ransomware campaign targeting healthcare, H-ISAC played a critical role in collective defense. The first victim shared IOCs within hours of detection—before their incident was even contained. H-ISAC distributed the intelligence immediately with TLP:AMBER designation. Within 24 hours, five member organizations reported blocking the same attack at perimeter based on shared IOCs. Two organizations discovered they had already been targeted but hadn't detected it—the shared intelligence enabled them to contain active compromises. Post-incident analysis estimated the sharing prevented $50M+ in collective damages. The first victim's willingness to share during active incident—despite the discomfort—protected the entire sector.
Case Study: Trust Network in Action
A CISO discovered unusual activity suggesting possible nation-state compromise. Before engaging formal channels, they reached out to trusted peers via Signal: "Anyone else seeing [specific pattern]?" Within an hour, three peers confirmed similar activity in their environments. This informal sharing achieved two things: confirmed the activity wasn't unique (reducing likelihood of false positive) and enabled coordinated response. The group collectively engaged CISA, providing correlated intelligence that led to a joint advisory within a week. The informal trust network enabled faster response than any formal channel could have achieved.
Sharing Community Quick Reference:
Getting Started with Sharing:
IMMEDIATE ACTIONS:
□ Join your sector ISAC
□ Register for CISA AIS
□ Join InfraGard (if in US)
□ Follow security researchers on Twitter/X
□ Subscribe to government alerts
BUILD RELATIONSHIPS:
□ Attend sector conferences
□ Participate in ISAC calls/meetings
□ Join regional security groups
□ Connect with peers at similar organizations
□ Engage with vendor communities
ESTABLISH PROCESSES:
□ Create sharing policy
□ Define approval workflow
□ Implement TIP for intelligence management
□ Build sharing into incident response
□ Track contributions and consumption
RESOURCE LINKS:
- National Council of ISACs: nationalisacs.org
- CISA AIS: cisa.gov/ais
- InfraGard: infragard.org
- MISP Project: misp-project.org
- OASIS STIX/TAXII: oasis-open.github.io/cti-documentationIntelligence sharing transforms individual defense into collective security. The investment in relationships and processes pays dividends when threats emerge.
Guided Lab: Intelligence Sharing Exercise
In this lab, you'll practice creating shareable intelligence products and participate in simulated sharing.
Lab Environment:
- MISP instance (local or cloud)
- Sample incident data
- STIX templates
- Sharing templates
Exercise Steps:
- Review sample incident data
- Identify shareable intelligence
- Remove/anonymize sensitive information
- Create STIX-formatted indicators
- Apply appropriate TLP designation
- Add context and recommendations
- Enter into MISP as event
- Simulate sharing to partner
- Receive and process partner's shared intelligence
Reflection Questions:
- What was hardest to anonymize while keeping value?
- How did you decide on TLP designation?
- What context was most important to include?
Week Outcome Check
By the end of this week, you should be able to:
- Describe the threat intelligence sharing ecosystem
- Explain ISAC/ISAO roles and value
- Apply Traffic Light Protocol correctly
- Navigate legal considerations for sharing
- Use STIX/TAXII for automated sharing
- Create quality, shareable intelligence products
- Build and maintain sharing relationships
- Measure sharing program effectiveness
🎯 Hands-On Labs (Free & Essential)
Practice building shareable intelligence before moving to reading resources.
🧭 OpenCTI Demo: Create a Shareable Report
What you'll do: Build a short report with TTPs, IOCs, and relationships.
Why it matters: Structured intel is easier to share and operationalize.
Time estimate: 90-120 minutes
🧩 MISP: Create a TLP-Labeled Event
What you'll do: Build an event with indicators, context, and TLP tags.
Why it matters: MISP is a common sharing platform in the field.
Time estimate: 2-3 hours
📝 Lab Exercise: TLP + Sanitization Drill
Task: Redact sensitive details from a mock incident and assign TLP.
Why it matters: Safe sharing protects partners and your organization.
Time estimate: 60-90 minutes
🧩 Lab: Supply Chain STIX Bundle
What you'll do: Build a STIX bundle for a vendor compromise scenario.
Why it matters: Supply chain intel must be shareable and actionable.
Time estimate: 60-90 minutes
💡 Lab Tip: Add enough context to act, but never expose victim-identifying data.
🧩 Supply Chain Intelligence Sharing
Vendor compromises affect entire ecosystems. Sharing needs to balance transparency, legal concerns, and actionability.
Sharing focus:
- Include affected versions and hashes
- Provide mitigation guidance
- Use TLP for safe distribution
- Coordinate with ISACs and vendors📚 Building on CSY101 Week-14: Align disclosure with governance and compliance expectations.
Resources
Lab
Complete the following lab exercises to practice intelligence sharing skills.