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.
The most common way to share threat intelligence in 2016 is to place the threat intelligence in a CSV file and make it available via http or https with or without basic auth. A harder way to share threat intelligence in 2016 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 digest and share threat intelligence, once familiar with CIF (which is no small feat), CIF can give you a lot of advanced capabilities essentially for free.
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.
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.
| 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 |
#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"
#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"
#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"
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 and an example description found in mature threat intelligence feeds.
| 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 |
| 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) |
Mature threat intelligence feeds will give a description about the data that can be found in the feed. Sometimes that description will be found in a separate document or webpage and in other cases it will be found as a header in the feed itself. Here's an example high quality description from the Dragon Research Group (DRG) that can be found as a header in their CSV sshpwauth report.
# Dragon Research Group (DRG)
# sshpwauth report
# 2016-04-19 16:55:02 - 2016-04-26 16:55:02
#
# To read more about SSH password authentication issues and how to
# mitigate SSH password authentication brute force attacks based on
# report data such as this, see:
#
# <http://www.dragonresearchgroup.org/insight/sshpwauth-tac.html>
#
# README: The sshpwauth report is for free for non-commercial use
# ONLY. If you wish to discuss commercial use of this
# service, please contact the Dragon Research Group (DRG)
# for more information. Redistribution of the sshpwauth
# report is prohibited without the express permission of
# the Dragon Research Group (DRG).
#
# This report is informational. It is not a blacklist, but some
# operators may choose to use it to help protect their networks
# and hosts in the forms of automated reporting and mitigation
# services. The data is provided on an as-is basis with no
# expressed warranty or guarantee of accuracy. Use of this data
# is at your own risk. If you have questions about this report
# do not hesitate to contact us by any of the means below.
#
# The Dragon Research Group (DRG) is a volunteer research
# organization dedicated to further the understanding of
# online criminality and to provide actionable intelligence
# for the benefit of the entire Internet community.
#
# URL: <http://www.dragonresearchgroup.org>
# email: dragon@dragonresearchgroup.org
# PGP key: 0x47196BBF
# IRC: irc://irc.freenode.net/drg
# Twitter: http://twitter.com/dragonresearch
#
# Entries consist of fields with identifying characteristics of a
# a source IP address that has been seen attempting to remotely
# login to a host using SSH password authentication. This report
# lists hosts that are highly suspicious and are likely conducting
# malicious SSH password authentication attacks. Each entry is
# sorted according to a route origination ASN. An entry for the
# IP address may be listed more than once if there are multiple
# origin AS (MOAS) announcements for the covering prefix. We use
# the Team Cymru IP address to ASN mapping service to construct a
# origin AS number and name. For details about this Team Cymru
# service, see <http://www.team-cymru.org/Services/ip-to-asn.html>.
#
# Formatting is as follows:
#
# ASN | ASname | saddr | utc | category
#
# Each field is described below. Please note any special formatting
# rules to aid in processing this file with automated tools and scripts.
# Blank lines may be present to improve the visual display of this file.
# Lines beginning with a hash ('#') character are comment lines. All
# other lines are report entries. Each field is separated by a pipe
# symbol ('|') and at least two whitespace characters on either side.
#
# ASN Autonomous system number originating a route for the entry
# IP address. Note, 4-byte ASNs are supported and will be
# displayed as a 32-bit integer.
#
# ASname A descriptive network name for the associated ASN. The
# name is truncated to 30 characters.
#
# saddr The source IPv4 or IPv6 address that is being reported.
#
# utc A last seen timestamp formatted as YYYY-MM-DD HH:MM:SS
# and in UTC time.
#
# category Descriptive tag name for this entry. For this report,
# the text sshpwauth will appear.
#
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
- Create groups to share threat intelligence selectively
- Generate feeds of threat intelligence
- Support many Output_Plugins output types, not only CSV
- Give your partners an API to program against
- Whitelisting capabilities
