Incident Exchange and Threat Intelligence — pieces of the same puzzle
This is the first post in a 3-part series
The relationship between threat intelligence and incident exchange is often a point of confusion, largely due to the emerging nature of both disciplines and lack of clarity about the value of engaging in cyber threat information sharing. Enterprise security programs do not question the value of cyber threat information in assessing, monitoring, analyzing and responding to security incidents. Those with mature security programs have been using details and artifacts about attacks observed in the wild to make tactical decisions based on them. But most of the focus on cyber threat intelligence has been on collecting it from vendors or open source lists — not much has been discussed about exchanging these early warning signals between organizations and disseminating them among peers. Obviously there are barriers to exchanging incident information, including market/legal risk and trust in those who are participating in the exchange, but these are getting addressed both from a regulatory and technology perspective. And furthermore, ransomware attacks in the last 6 months, which essentially have gone after multiple targets with the same attack vectors, have proven the value of collective knowledge in making informed decisions.
Mature security organizations are starting to redefine their security programs to incorporate incident exchange alongside their traditional threat intelligence process. In this multi-part blog we will review how this is evolving and what you need to consider as you plan to build out an incident exchange and sharing program. To understand how this is evolving, let’s first briefly review how threat intelligence is used in current enterprise security.
The process typically starts with collecting threat data. The goal of intelligence collection is to identify threat indicators that might warn analysts of likely attacks or attacks underway. Many organizations start with open source intelligence, such as freely available security researcher reports, public “block lists,” and vendor blogs and publications. An increased understanding of the potential value of threat intelligence, and the emergence of common formats for sharing it such as STIX, has led a growing number of organizations to subscribe to commercial threat intelligence feeds.
The next step is to analyze this data for relevance and context. Security analysts must curate the collected threat data, determine what is relevant, timely and accurate, and then place it in context with what they are seeing on their networks. There are a variety of tools and techniques they use to do this, including some automation through emerging threat intelligence analysis products, but much of it boils down to an analyst’s own creativity and skill.
Once threat data is collected, determined to be relevant, and a potential or in-progress attack identified, analysts then must move to develop a remediation plan. Speed is often the goal here. The effectiveness of remediation is not only dependent on speed of action, but also on having enough context to see and understand the full scope of an attack so that all infiltration and exfiltration pathways are blocked.
Finally reports are created to store for future analytical support and shared with other internal operations. In some organizations, data might also be shared externally via email listservs or other formal exchange programs as part of a larger external collaboration initiative. When appropriate, reports are sometimes also shared with legal, law enforcement or government organizations.
Information sharing, or external incident exchange, is often seen as a reactive, reporting function rather than proactive defense support because it is often not fully considered until the end of the threat intelligence process. If collaboration happens at all, it is done ad hoc or done even later — perhaps as a large organization sharing its analysis after a breach has occurred, been investigated, remediated and legal ramifications reviewed and understood.
This is a missed opportunity. Incorporating incident exchange and collaboration throughout the process can provide value and addresses many of the challenges faced by analysts at each stage. Threat information collection, as done today, an often feel like drinking from a fire hose. For most organizations, they are dealing with too much data, not too little. And the challenge is sorting through the data collected to find what they need quickly enough to get ahead of an attack, or at least stop an in-progress attack before it becomes too damaging. By utilizing data from incidents observed by peers organizations security analysts can make informed decisions about how to prioritize their own incident investigation. Furthermore, this data can provide value by using it to correlate, and enrich internal security events.
There is value in using observations of others in your community throughout your cybersecurity operations — be it for reducing your attack surface or quicker remediation of adversarial events. Fig.1. is an illustration of correlated reports that were submitted by members of TruSTAR and can be used to quickly identify enrichment around reports of interest.
In my next post in this series, I will outline how a mature deployment of the threat intelligence lifecycle utilizes incident exchange and collaboration across the full process. My final post will walk a sample event through the lifecycle to illustrate how this all works together to speed detection and mitigation in a real-world environment.
