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:

VB2019 paper: Domestic Kitten: an Iranian surveillance program

In a fundamental regime that is constantly wary of anything that might jeopardize its stability, and a region that is a hotbed of political conflicts and dissensions, it is not surprising to discover a large‑scale surveillance campaign that keeps an…

VB2019 paper: DNS on fire

Cisco Talos has identified malicious actors that have been targeting the DNS protocol successfully for the past several years. In this paper, researchers Warren Mercer & Paul Rascagnères present two of the threat actors they have been tracking.

Dexofuzzy: Android malware similarity clustering method using opcode sequence

This paper proposes the use of the ‘Dalvik EXecutable Opcode Fuzzy’ (‘Dexofuzzy’) hash to find similar malware variants without the need for an analyst to have systematic or mathematical knowledge.

VB2019 paper: We need to talk – opening a discussion about ethics in infosec

Several professionals defend the notion that technology and ethics have nothing to do with each other. This paper presents various schools of thought pertaining to the philosophy of justice, and explores how they could help us solve some of the…

VB2019 paper: Inside Magecart: the history behind the covert card-skimming assault on the e-Commerce industry

Magecart is an umbrella term given to at least 12 cybercrime groups that are placing digital credit card skimmers on compromised e-commerce sites at an unprecedented rate and with frightening success. This paper presents a timeline of the Magecart…


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.