Skip to content
This repository has been archived by the owner on May 23, 2019. It is now read-only.

Sharing Threat Intelligence

Gabriel Iovino edited this page Jun 2, 2015 · 10 revisions

Sharing Threat Intelligence

At some point you may want to share your threat intelligence with others. This may be public like Zeustracker or with trusted private partners or private communities. This is a introductory guide to sharing threat intelligence.

Baseline


Method of Sharing

The most common way to share threat intelligence in 2015 is to place the intelligence in a CSV file and make it available via http or https with basic auth. A harder way to share threat intelligence in 2015 is to use SMTP and possibly GPG, which requires your partners to parse SMTP messages and possibly unencrypt if encrypted.

One of the goals of the CIF project is to make it easier to share threat intelligence, once familiar with CIF (which is no small feat), CIF can give you a lot of advanced capabilities essentially for free.

Most Specific Indicator

Whenever possible share the most specific indicator you have. If you have:

  • URL - share the malicious URL
  • IP address - share the ip address, port and protocol
  • FQDN - share the FQDN

All too often someone will start with a malicious URL then resolve the A record or strip out the domain and share the IP address or domain as the malicious indicator. Due to shared hosting, compromised servers or compromised web applications, often the most specific indicator is the best indicator (most confident) of potential compromise.

Minimum Sharing


There is a bare minimum that one should strive for when sharing threat intelligence. You can share less than what is described below but the entity on the other side will have to make a lot of assumptions and these assumptions will likely lead to a decreased level of confidence in the shared threat intelligence.

Common Parameters

Parameter Name Values Description
observable <string> IP address, URI, domain
description <string> describe the observation
lasttime <string> ISO 8601 (2013-06-18T10:10:00Z)
portlist <int> 22,25,80
protocol <int> <string> 6 or tcp, 17 or udp

Infrastructure

#address,portlist,protocol,lasttime,description
"192.168.1.1","22","tcp","2013-06-18T10:10:00Z","scanner"
"192.168.10/24","80,443","tcp","2013-06-17T08:01:56Z","botnet"

Domain

#address,lasttime,description
"example.com","2013-06-16T12:00:00Z","botnet"
"car.example.com","2013-06-16T12:00:00Z","malware"
"google.com","2013-06-01T12:00:00Z","whitelist"

URI

#address,lasttime,description
"http://www.example.com/bad.php","2013-06-16T12:00:00Z","malware"
"https://controller.example.com/bad.php","2013-06-16T12:00:00Z","botnet"

Advanced Sharing


As you mature in your threat intelligence sharing capabilities, you may find that your partners need more than the bare minimum as described above. Below are some common parameters found in mature threat intelligence feeds.

Common Parameters

Parameter Name Values Description
alternativeid <string> usually a url pointing to the original data point (as a reference id)
alternativeid_restriction <string> rfc5070 (public, need-to-know, private) or TLP
confidence <int> see Confidence (fixme)
description <string> short (1-2 space delimited word) description of the activity (eg: tdss spyeye)
restriction <string> rfc5070 (public, need-to-know, private) or TLP
source <string> source of the feed, usually the domain where the feed is from (eg: example.com)

Sharing with CIF


As mentioned above, one of CIF's goals is to make it easier to share threat intelligence. If you deploy a CIF instance and feed your threat intelligence to CIF, what capabilities does CIF give you in regard to sharing threat intelligence?

  • Create users with API keys (fixme)
  • Create groups (fixme) to share threat intelligence selectively
  • Generate [feeds] (fixme) of threat intelligence
  • Support many Output_Plugins output types (fixme), not only CSV
  • Give your partners an API (fixme) to program against
  • Whitelisting (fixme) capabilities
Clone this wiki locally