The Intelligence Gap Nobody Talks About in Incident Reviews
Compromise assessment teams see a recurring pattern in their post-incident findings. Organizations that experienced breaches often had access to threat intelligence that described the exact technique, infrastructure, or malware family used against them. The intelligence existed somewhere in the ecosystem. It simply never reached the right analyst at the right moment in a usable format. The July 2026 threat intelligence reports circulating across security communities have highlighted this dynamic again, with persistent threats maintaining footholds in environments where detection data was available but siloed.
This is the core pain point for security operations teams: the problem is rarely a total absence of intelligence. It is the gap between intelligence that exists and intelligence that gets operationalized inside a specific organization's defenses. Threat sharing programs, when designed poorly, close neither of these gaps. They produce more feeds, more noise, and more analyst fatigue. When designed well, they compress the window between a threat becoming known somewhere and becoming detectable everywhere.
This article focuses on building sharing programs that close that window in practice, not in theory.
What Community Intelligence Actually Means in Operational Terms
Community threat intelligence is any information about adversary tactics, techniques, infrastructure, or indicators that originates outside your organization and reaches you through a structured sharing relationship. That definition is broad by design. It covers Information Sharing and Analysis Centers (ISACs), government-backed platforms like CISA's Automated Indicator Sharing, vendor threat intelligence communities, sector-specific working groups, and informal peer networks among security practitioners.
The Iran-linked Cavern Manticore C2 framework is a useful reference point. Detailed technical analysis of that modular command-and-control infrastructure became available through community research before many potential targets had incorporated defensive signatures into their environments. Organizations participating in active sharing programs received actionable indicators earlier than those relying solely on commercial feeds. The distinction matters because modular C2 frameworks are specifically engineered to evade signature-based detection by rotating components. Early behavioral indicators, shared through community channels, gave defenders a chance to detect staging activity before full compromise.
The 0ktapus campaign against more than 130 organizations demonstrated a similar dynamic. The campaign used relatively straightforward phishing infrastructure, but the scale and targeting pattern only became visible when defenders across multiple victimized organizations compared notes. No single organization's telemetry revealed the full scope. Shared intelligence reconstructed the campaign's breadth and allowed later-targeted organizations to harden before attackers reached them.
Types of Sharing Relationships and What Each Delivers
Formal ISACs provide sector-specific context that general threat feeds lack. Financial sector ISACs understand fraud-related attack patterns in ways that a broad commercial feed does not. Healthcare ISACs track ransomware groups specifically targeting medical records systems. Energy sector ISACs focus on operational technology threats that have entirely different risk profiles than enterprise IT attacks. If your organization operates in a regulated sector, ISAC membership is foundational, not optional.
Government sharing programs offer early warning on nation-state activity. CISA's sharing mechanisms, the UK's NCSC early warning service, and equivalent bodies in other jurisdictions distribute indicators related to state-sponsored campaigns that commercial vendors often cannot publicly attribute. The Cavern Manticore research benefited from this type of government-backed disclosure pipeline.
Peer networks among practitioners, whether through conferences, Signal groups, regional security communities, or vendor user groups, provide something the structured programs often lack: context and speed. An analyst at a peer organization who encountered a suspicious IP or an unusual email header pattern two days ago can share that observation directly, before it propagates through formal channels. This informal layer is where the fastest indicator sharing actually happens.
Why Most Sharing Programs Stall at the Feed Subscription Stage
Organizations that implement threat sharing programs often begin and end with feed subscriptions. They add STIX/TAXII feeds to their SIEM, configure automated ingestion, and consider the program operational. The feeds produce indicators. The SIEM generates alerts. Analysts work those alerts without understanding the campaign context behind any given indicator.
This approach has predictable failure modes. Feeds produce high volumes of indicators with varying quality and relevance. Analysts cannot distinguish between an indicator that is critically relevant to their environment and one that pertains to a sector or geography entirely unlike their own. Alert fatigue develops. Rules get tuned down. Eventually, relevant indicators produce alerts that go uninvestigated.
The missed incidents described in recent compromise assessment findings stem from exactly this pattern. Detection tooling flagged activity. Analysts deprioritized the alerts. Threats persisted for weeks or months. The problem was not the absence of intelligence. It was the absence of context that would have elevated those alerts to urgent status.
Effective sharing programs address this by separating indicator consumption from intelligence consumption. Indicators (IPs, domains, hashes) are tactical artifacts. Intelligence is the context that explains what those indicators mean, what campaign they belong to, what the adversary is trying to accomplish, and what your environment looks like to that adversary. Sharing programs that deliver intelligence, not just indicators, produce analysts who can make decisions rather than simply work a queue.
Building the Sharing Program: Phase One (Today)
The immediate priority is establishing baseline participation in at least two sharing communities: one formal and one peer-based. For most organizations, the formal community should be the relevant sector ISAC or a government early warning program. The peer community should be whatever practitioner network your security team already has informal relationships with, formalized into a lightweight agreement about what can be shared and how.
Set up a dedicated channel or process for receiving shared intelligence that goes directly to an analyst rather than into an automated pipeline. The goal at this stage is to build the human habit of consuming external intelligence before automating the consumption. Automation applied before your analysts understand what they are receiving produces the feed subscription problem described above.
Conduct an inventory of what your organization can share outward. Many security teams assume they have nothing valuable to contribute. Invariably, they have observations about scanning patterns, phishing lures targeting their industry, or unusual traffic that has not appeared in any public reporting. These observations have significant value to peers in similar environments. Organizations that contribute to sharing communities receive higher-quality intelligence in return, both because of reciprocity norms and because their specific context helps peers refine what they share back.
Designate one analyst as the sharing program owner. This person is responsible for consuming incoming intelligence, triaging it for relevance, converting relevant items into defensive actions, and preparing outbound contributions. Without ownership, sharing programs diffuse into everyone's responsibility and therefore no one's.
Building the Sharing Program: Phase Two (This Week)
Once baseline participation is established, focus on integration between sharing channels and your existing detection infrastructure. The goal is to reduce the time between receiving an indicator or behavioral description and having a corresponding detection rule or block in place.
Establish a tiered indicator handling process. Tier one indicators come with high-confidence context from a trusted sharing partner and affect your likely threat profile directly. These should be implemented within hours of receipt. Tier two indicators come from feeds or less-contextualized sources and require analyst review before implementation. Tier three indicators are low-confidence or low-relevance and should be logged for trend analysis without immediate action. Many teams apply the same handling to all indicators, which means tier one indicators sit in the same queue as tier three noise.
Build a simple tracking document that records every external intelligence item received, the action taken, and the outcome. This sounds administrative, but it serves two functions. First, it surfaces which sharing sources produce actionable intelligence and which produce noise, allowing you to prioritize your analyst's consumption time. Second, it builds the institutional record that allows you to demonstrate the program's value when leadership asks why it requires ongoing resource allocation.
Begin structuring your outbound contributions. When your team identifies a phishing campaign targeting your industry, documents the lure technique, the sender infrastructure, and any payload behavior, that information packaged into a brief report becomes a high-value contribution to your sharing community. The packaging matters. Raw indicators shared without context are less valuable than indicators with campaign context, target profile, and suggested detection logic.
Handling Sensitive Information Appropriately
A common obstacle to sharing is concern about disclosing sensitive information about your environment, your vulnerabilities, or your incidents. The Traffic Light Protocol (TLP) framework exists specifically to address this. TLP:RED restricts information to specific recipients. TLP:AMBER limits sharing to the recipient organization. TLP:GREEN allows sharing within a community. TLP:CLEAR permits unrestricted sharing. Using TLP designations when both sending and receiving intelligence allows your team to contribute without exposing information your organization cannot afford to make broadly available.
Legal review of sharing agreements is appropriate for formal programs. Most sector ISACs have established legal frameworks that address liability concerns for members who share incident information. For peer networks, a brief written agreement about TLP adherence and information handling expectations is usually sufficient.
Building the Sharing Program: Phase Three (This Quarter)
The quarterly horizon is where sharing programs either become durable capabilities or atrophy back to passive feed subscriptions. The focus at this stage is measurement, automation of well-understood processes, and expansion of the sharing network.
Measure the program against response speed. Calculate the average time between an indicator becoming available in your sharing community and that indicator generating a detection or block in your environment. Track this metric quarterly. A well-functioning program should show consistent reduction in this lag time as your processes mature.
Automate indicator ingestion for tier one sources after your analysts have validated the quality of those sources over several months. Automation applied to trusted, contextualized intelligence from known partners is appropriate. Automation applied to unknown sources without quality validation produces the alert fatigue problem you started with.
Expand your peer network deliberately. Identify organizations of similar size, sector, and threat profile with security teams whose judgment you respect. Formal peer intelligence sharing agreements with five to ten peer organizations provide more operationally relevant intelligence than dozens of feed subscriptions. The 0ktapus investigation demonstrated what small numbers of organizations comparing notes can accomplish when they have direct communication channels rather than relying on formal reporting pipelines.
Develop your team's contribution quality. Assign one analyst per quarter to produce a structured threat brief based on your organization's internal observations. Even if the incident was minor, documenting the technique, the timeline, the indicators, and your response provides genuine value to peers. Teams that contribute consistently receive more direct, contextualized intelligence from their network than teams that only consume.
Integrating Community Intelligence Into Incident Response
The highest-value application of community intelligence is during active incident response. When your team is investigating a potential compromise, querying your sharing network for related observations can dramatically accelerate scoping. If a peer organization encountered the same infrastructure two weeks earlier, their documentation of attacker behavior, persistence mechanisms, and lateral movement patterns can tell your responders where to look rather than requiring them to reconstruct the picture from scratch.
Build the habit of querying sharing communities at the start of every significant investigation. Send a TLP:AMBER query describing the indicators you have observed and asking whether any peer has seen related activity. Even negative responses are valuable because they help scope the incident to your environment specifically.
When your incident response concludes, publish a sanitized post-incident report to your sharing community. Timing matters here. A report published thirty days after an incident is less valuable than one published within a week, while the campaign may still be active against other potential victims. The WSzero DDoS botnet's rapid iteration through versions is an example of why timely sharing matters: by the time a version is documented through formal channels, a new variant may already be propagating. Peer networks that share observations in near-real-time compress the adversary's advantage window.
What Good Looks Like After Twelve Months
A mature sharing program after one year of consistent operation shows several observable characteristics. Analysts consume external intelligence as a standard part of their daily workflow rather than treating it as an occasional supplement. Your organization contributes to the sharing community on a regular cadence and receives direct, contextualized requests from peers who value your perspective. Your indicator handling process differentiates between sources by quality and relevance rather than treating all feeds equally. You can measure the program's contribution to response speed with actual data.
The Cavern Manticore research, the 0ktapus campaign documentation, and the persistent threat patterns surfaced in recent compromise assessments all point to the same conclusion: adversaries operate across organizational boundaries while defenders historically have operated within them. Threat sharing programs restructure the defensive landscape so that intelligence about adversary behavior propagates across the same boundaries that attackers exploit. Building that capability is not a sophisticated technical problem. It is an operational discipline problem, and the organizations that solve it reduce their breach risk in ways that no single defensive tool can replicate.
Practical Takeaways for Security Operations Teams
- Join at least one sector ISAC and one peer practitioner network before adding another commercial feed subscription.
- Designate a named owner for the sharing program with dedicated time allocated to consumption, triage, and contribution.
- Implement TLP designations on all outbound sharing and require them on significant inbound items to manage sensitive information appropriately.
- Track the lag between external indicator availability and internal detection implementation, and review this metric quarterly.
- Build outbound contribution as a structured obligation, not an occasional activity, because contribution quality determines the quality of intelligence you receive in return.
- Query your sharing network at the start of significant incident investigations to leverage peer experience before reconstructing attacker behavior from scratch.
- Apply automation only to indicator sources your analysts have validated over time, not to all inbound feeds simultaneously.
