Threat intelligence sharing: tying one hand behind our backs

2014-04-02

Chad Loeven

RSA, USA
Editor: Helen Martin

Abstract

‘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.

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest articles:

VB2018 paper: Fake News, Inc.

As the world grapples with massive disinformation campaigns waged by the intelligence agencies of hostile nations, we should not forget that such activities are not limited to the purview of the Bears or Pandas of the world, and that even relatively…

Alternative communication channel over NTP

Nikolaos Tsapakis explores Network Time Protocol (NTP) as an alternative communication channel, providing practical examples, code, and the basic theory behind the idea.

VB2018 paper: Under the hood: the automotive challenge

In an average five-year-old car, there are about 30 different computers on board. In an average new car, there are double that number, and in some cases up to 100. That’s the size of network an average SMB would have, only there’s no CIO/CISO, and…

VB2018 paper: Android app deobfuscation using static-dynamic cooperation

Malicious Android applications are quite common, and can even be found from time to time in the Google Play Store. Thus, a lot of work has been done in both industry and academia on Android app analysis, and in particular, static code analysis. One…

VB2018 paper: Anatomy of an attack: detecting and defeating CRASHOVERRIDE

CRASHOVERRIDE is the first publicly known malware designed to impact electric grid operations. Reviewing previously unavailable data covering logs, forensics, and various incident information, in this paper Joe Slowik outlines the CRASHOVERRIDE…


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.