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.


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.


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.


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.


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.


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.

More from X-Force

“Authorized” to break in: Adversaries use valid credentials to compromise cloud environments

4 min read - Overprivileged plaintext credentials left on display in 33% of X-Force adversary simulations Adversaries are constantly seeking to improve their productivity margins, but new data from IBM X-Force suggests they aren’t exclusively leaning on sophistication to do so. Simple yet reliable tactics that offer ease of use and often direct access to privileged environments are still heavily relied upon. Today X-Force released the 2023 Cloud Threat Landscape Report, detailing common trends and top threats observed against cloud environments over the past…

Email campaigns leverage updated DBatLoader to deliver RATs, stealers

11 min read - IBM X-Force has identified new capabilities in DBatLoader malware samples delivered in recent email campaigns, signaling a heightened risk of infection from commodity malware families associated with DBatLoader activity. X-Force has observed nearly two dozen email campaigns since late June leveraging the updated DBatLoader loader to deliver payloads such as Remcos, Warzone, Formbook, and AgentTesla. DBatLoader malware has been used since 2020 by cybercriminals to install commodity malware remote access Trojans (RATs) and infostealers, primarily via malicious spam (malspam). DBatLoader…

New Hive0117 phishing campaign imitates conscription summons to deliver DarkWatchman malware

8 min read - IBM X-Force uncovered a new phishing campaign likely conducted by Hive0117 delivering the fileless malware DarkWatchman, directed at individuals associated with major energy, finance, transport, and software security industries based in Russia, Kazakhstan, Latvia, and Estonia. DarkWatchman malware is capable of keylogging, collecting system information, and deploying secondary payloads. Imitating official correspondence from the Russian government in phishing emails aligns with previous Hive0117 campaigns delivering DarkWatchman malware, and shows a possible significant effort to induce a sense of urgency as…

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…