Threat intelligence sharing: tying one hand behind our backs


Chad Loeven

Editor: Helen Martin


‘We will need to collaborate and implement standardized threat data sharing.' Chad Loeven

Table of contents

The lifeblood of a security vendor is threat data. We consume it, transform it (into threat intelligence), publish it and act on it. Regardless of whether our products are in the consumer space, enterprise, cloud or all of the above, the capacity of our technologies to act effectively in protecting our customers is either driven or validated (or both) by threat intelligence.

Anti-virus vendors have collaborated since the early days of the industry, using VirusTotal and other forums for sharing malware samples and URLs. But as AV vendors evolve and merge with other security vendors and technologies into some variation of ‘advanced threat protection and/or detection’, the shortcomings of current threat-data-sharing arrangements are becoming apparent.

Despite an alphabet soup of technical standards and initiatives, the sharing of threat data remains essentially an ad-hoc and bespoke process. This is especially true of sharing amongst security vendors and CERTs, if we view the key stakeholders in threat sharing as divided into four groups: national and government CERTs; security vendors; enterprise end-users; and consumer end-users.

With few exceptions, consumer and enterprise end users consume threat intelligence indirectly via vendors’ products. The real challenge lies where CERTs, agencies and vendors generate and consume the raw data.

According to a recent report by ENISA [1], the key problems for effective information sharing are legal and technical barriers, as well as lack of interest from cybersecurity stakeholders. In my own experience, setting up sharing arrangements with corporate and government entities involves a bespoke tangle of legal agreements. Once you’re over the legal hurdles, you’re faced with a technical thicket of formats and data exchange methods, with no single default standard.

Even within enterprises, data silos are the norm – as we found out recently in trying to set up a sharing arrangement with another security vendor. Different product groups each had their own sets of threat data in their own formats, covered by their own partner and sharing agreements, and those were entirely separate from threat data available from the vendor’s own CERT, which was separate from its customer-facing threat centre – all this within one enterprise.

This is hardly exceptional – the ENISA report noted that email was the primary method for exchange of threat data.

There’s no shortage of technical standards for exchanging threat data – IODEF, STIX, OpenIOCs, and more – and certainly secure web services offer better ways of intelligently sharing and updating threat data. So why do so many organizations default to email, or perhaps only slightly better, dumping files to each other via FTP?

My view is that, while well intentioned, initiatives like Mitre’s TAXII (Trusted Automated eXchange of Indicator Information) protocol [2] and FS-ISAC [3] for the financial services industry are too complex, too fragmented amongst different groups, or both, to achieve the widespread adoption they need to be truly effective.

Microsoft recently issued a virtual call to arms [4] for better industry collaboration with the goal of not just minimizing, but eliminating whole classes of malware. That’s a goal we as an industry can all support. However, in order to be successful, we will need to collaborate and implement standardized threat data sharing that is:

  • Simple enough to accommodate and incorporate existing sample- and URL-sharing arrangements.

  • Flexible enough to layer on optional sharing of threat metadata.

  • Able to support sharing of threat metadata through widely adopted and straightforward standards such as OpenIOC and Yara rules.

  • Able to provide for secure, granular access only by trusted parties.

I’m up for it. Let’s talk and make it happen.



Latest articles:

Nexus Android banking botnet – compromising C&C panels and dissecting mobile AppInjects

Aditya Sood & Rohit Bansal provide details of a security vulnerability in the Nexus Android botnet C&C panel that was exploited to compromise the C&C panel in order to gather threat intelligence, and present a model of mobile AppInjects.

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…

Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.