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:

VB2019 paper: APT cases exploiting vulnerabilities in region‑specific software

Some APT attacks are carried out by exploiting vulnerabilities in region-specific software. Government agencies frequently use such localized software, and this tends to be the target of attackers. In Japan, there have been many cases where attacks…

Detection of vulnerabilities in web applications by validating parameter integrity and data flow graphs

Web application vulnerabilities are an important entry vector for threat actors. In this paper researchers Abhishek Singh and Ramesh Mani detail algorithms that can be used to detect SQL injection in stored procedures, persistent cross-site scripting…

VB2019 paper: Cyber espionage in the Middle East: Unravelling OSX.WindTail

It’s no secret that many nation states possess offensive macOS cyber capabilities, though such capabilities are rarely publicly uncovered. However, when such tools are detected, they provide unparalleled insight into the operations and techniques…

VB2019 paper: 2,000 reactions to a malware attack – accidental study

This paper presents an analysis of 1,976 unsolicited answers received from the targets of a malicious email campaign, who were mostly unaware that they were not contacting the real sender of the malicious messages. Many of the victims were unaware…

VB2019 paper: Why companies need to focus on a problem they don't know they have

There is a type of crime, breach of company policy, misuse of company assets and security threat that is often overlooked: as one in 500 employees use their work computer to handle child sexual abuse material. This crime and misuse of company assets…

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.