Several publications have already nominated 2015 as “The Year of Threat Intelligence Sharing,” and threat intelligence sharing has certainly been in the news. Though the first half of the year has seen little in the way of new specifications, entire ecosystems of standards that few people previously knew have finally gained some recognition due to their use in threat intelligence sharing efforts.
Much current attention goes to what I will call the DHS specifications. The U.S. Department of Homeland Security (DHS) leads these community-driven efforts, and the MITRE Corporation provides them with an electronic home. These specifications include the well-known Common Vulnerabilities and Exposures (CVE) and Common Vulnerability Scoring System (CVSS) efforts, among a wealth of others. CybOX, STIX and TAXII, specifically, have drawn recent attention.
CybOX
The Cyber Observable eXpression (CybOX) specification defines a representation for observable attributes of computer and network activities and entities. Observables include things like files, HTTP sessions, X509 certificates and others, including system configuration items. The CybOX specification essentially provides a standardized but extensible vocabulary for describing the things we may observe about a computing system and its operations. Indicators, on the other hand, are observables set in a particular context. For example, the name of a Windows registry key could be an observable. That observable having a specific value, however, could be an indicator of the presence of a threat. IP addresses represent another sort of observable, and particular ones can be indicators of malicious intent.
STIX
The Structured Threat Information eXpression (STIX) provides a standardized XML-based language to express the details of threat intelligence items and threat context. It uses CybOX as the expression language for many of the elements that STIX syntax can represent, but it can also contain information expressed in other formats. The standardization allows security researchers and practitioners to exchange threat intelligence with much lower risk of miscommunication, and it enables certain forms of automated processing of threat intelligence items. The STIX specification includes structures to represent many aspects of security intelligence in practice, including threat actors, threat campaigns, security incidents and others. It makes heavy use of other DHS specifications to specify formats for the data items each STIX entity contains.
TAXII
The Trusted Automated eXchange of Indicator Information (TAXII) offers secure transportation and interchange of threat intelligence information. Many articles make it seem that TAXII only supports STIX-formatted content, but it can transport information in a wide variety of formats. However, current practice typically teams TAXII transport with STIX expression and CybOX vocabulary. TAXII defines the exchange protocol in terms of standardized services and message exchanges that support multiple sharing models, including hub-and-spoke, peer-to-peer and subscription. While TAXII provides secure transport, it avoids policy considerations such as topology, trust issues and governance. Higher-level protocols and agreements must address the policy concerns.
The Rest
Most recent articles focus intensely on STIX, TAXII and CybOX. Some don’t even mention that CVE and CVSS also play a role in the ecosystem. Many don’t mention the other, complementary specifications in the DHS suite. The Common Platform Enumeration (CPE) and Common Configuration Enumeration (CCE) specifications standardize the description of platforms and configurations in the same way that CVE standardizes descriptions of vulnerabilities. The Common Configuration Scoring System (CCSS) provides a set of metrics based on CVSS. Less well-known are:
And the stable contains others, as well. Taken together, they aim to cover the entire scope of the security communication space in a sort of normalized fashion.
Recent Moves
Part of the stir surrounding the sharing of threat intelligence includes announcements by various commercial and open source projects that they are adding support for the STIX, TAXII and CybOX specifications and their relatives. In many cases, these notices serve simply to remind everyone that the project already has support and tracks the specifications as they evolve. These specifications have all been around for at least a couple of years, and a wide variety of the available tools already support them. At least for now, support will be a requirement for new entrants into the market simply due to the buzz surrounding them.
History
Remember that the current efforts in the private sector are not the first attempts to encourage threat intelligence sharing, and they are not the only game in town, either. In particular, reality forced the military and intelligence organizations to manage and share threat intelligence within their own operations and those of their partners, such as weapons system development companies.
The first efforts toward greater threat intelligence sharing date at least to 1998 in the form of Presidential Decision Directive/NSC-63, “Protecting America’s Critical Infrastructures,” issued by former President Bill Clinton. This directive resulted in the establishment of the National Infrastructure Protection Center (NIPC) and a variety of Information Sharing and Analysis Centers (ISACs). In 2004, the Intelligence Reform and Terrorism Prevention Act established the U.S. Computer Emergency Readiness Team’s (US-CERT) National Cybersecurity and Communications Integration Center (NCCIC), the FBI’s National Cyber Investigative Joint Task Force (NCIJTF) and U.S. Cyber Command. In addition, a variety of players created the Industry Consortium for the Advancement of Security on the Internet (ICASI) in 2007, and specific industries also created focused threat intelligence exchange efforts, particularly in health care, with the HITRUST Alliance. And those are just the efforts on the civilian side.
U.S. Government, Defense and Threat Intelligence
You might imagine that military and intelligence forces and governments have specialized risks, requirements and threats. The cold hand of reality compelled these forces to take the issues more seriously than the rest of us. Their standardization efforts in the U.S. revolve around the Defense Information Systems Agency (DISA) and the U.S. National Institute of Standards and Technology (NIST). NIST produces specifications regarding system security, as well, specifically the Cybersecurity Framework, and hosts the Computer Security Resource Center. DISA produces Secure Technical Implementation Guides (STIGs) to standardize secure installation and maintenance of information systems. This high-level term refers to a wide variety of standards that contain technical guidance, allowing installers and maintenance personnel to lock down systems that might otherwise be vulnerable to attack.
More recently, these organizations have been moving toward fully embracing the NIST’s Security Content Automation Protocol (SCAP). The National Vulnerability Database (NVD) provides official SCAP mappings. This suite of open standards aims to enable automated management and measurement of security configurations as well as threat intelligence sharing. Though not often mentioned, the STIX protocol can encapsulate SCAP payloads just as easily as any other expression. In fact, many of the standards covered by the SCAP umbrella come from the DHS suite, a welcome convergence of practice. SCAP actually comprises the following standards:
All of those except XCCDF, OCIL and CCSS come from the DHS suite, and NIST defines the rest. XCCDF provides a standard representation for structured collections of system configuration rules. The standard supports automated information interchange along with compliance testing and scoring, while organizations can still tailor its use to their needs. Compared to the DHS suite, XCCDF overlaps most with CCE. Luckily, that is the only significant difference between the SCAP umbrella and the DHS suite of specifications.
OCIL provides a standardized framework to express checklist questions and procedures to interpret the responses to the questions, while CCSS has a set of metrics to measure the severity of software configuration issues. It is derived from the well-known CVSS specification to provide a similar capability.
Walk a MILE
The Managed Incident Lightweight Exchange (MILE) package of standards covers roughly the same territory as the DHS suite of specifications, particularly CybOX, STIX and TAXII. The MILE standard itself defines a data format for indicators and incidents. The package also includes the Incident Object Description and Exchange Format (IODEF). This incorporates many of the DHS suite specifications for its data field formats, provides a format for exchange of operational and statistical incident information and supports automated processing. The package also includes IODEF for Structured Cybersecurity Information (IODEF-SCI) extensions and Realtime Internetwork Defense (RID), supporting automated intelligence and incident sharing.
More
A number of other efforts also exist, either to fill perceived gaps in the coverage of the existing standards and specifications or to correct perceived flaws in them. The Mandiant-developed Open Indicators of Compromise (OpenIOC) specification provides a vocabulary for technical details of indicators of compromise. It has some overlap with CybOX but also expands the available vocabulary. Verizon produced the Vocabulary for Event Recording and Incident Sharing (VERIS) standard to define a vocabulary of metrics for describing security incidents. As with OpenIOC, it has some overlap with CybOX, but it also expands the available vocabulary.
Finally, US-CERT developed the Traffic Light Protocol (TLP). This specification provides a set of designations rather than a data format but could easily be included in any relevant standard or specification. TLP classifies intelligence that might be shared to control the scope of sharing. It defines four levels of sharing and identifies each one with a color:
- Red: The item cannot be shared at all.
- Amber: The item may only be shared within the organization that originated it.
- Green: The item can be shared outside the organization, but only within a limited sector or community.
- White: The item can be freely shared.
It’s a Wrap
Neither the concept nor the practice of threat intelligence sharing is revolutionary. Renewed interest can be laid at the door of the successes that attackers have enjoyed over the last few years. The news has been full of the publicly disclosed incidents, and you can bet that quite a few undisclosed ones occurred, as well. The combination of widespread interest and need drive the current activity. Attackers have been painfully successful lately, and we defenders must up our game. Threat intelligence sharing can help us do that. With the need so obvious, activity swirls around threat intelligence sharing at the moment and is unlikely to wane until the situation improves. Luckily, the history of these efforts provides us with experienced practitioners, and the standards and specifications appear to be driving to a convergence. Until that moment arrives, the tools will have to support competing standards in at least some cases. But current work appears to be driving toward a (mostly) converged environment with a variety of products and projects integrating the standards and capabilities to acquire, package, exchange and consume standards-based threat intelligence data.
Research Technologist, IBM Security X-Force