STIX 2.0 documentation is available here. This site contains archived STIX 1.x documentation. STIX is now maintained by the OASIS CTI TC.
File Hash Reputation
Although there are variations, reputation services generally present information about a single data point (IP address, file by hash, e-mail, URLs, and domains) and how likely it is that that data point is “malicious”. As you might expect, that’s the perfect use case for a STIX Indicator and so that will be the focus of this idiom. If you’re not already familiar with basic STIX indicators, read the Indicator for C2 IP Address for some background on creating indicators in general.
This idiom will cover some specific cases that many reputation services have to deal with:
Where the reputation score itself goes
How custom scoring systems or vocabularies are represented
Keep in mind that many reputation services are request/response: the consumer asks for information about a single hash and the producer creates a response specific to that hash. This idiom only describes the “response” part of that cycle. To see a more transport-oriented view of this idiom that incorporates TAXII, take a look at their TAXII Service Profile for IP Reputation. This STIX idiom is a subset of that that goes into more detail on the STIX side.
Shortcut: Already very comfortable creating or parsing indicators? Reputation services are just an indicator with a “Confidence” field that indicates the score itself (use a custom vocabulary if you need to).
The basic data model is the same as for most indicators:
A top-level indicator to bring together:
A CybOX object to represent the data point
An indicated TTP on the indicator to describe how the object is malicious
A confidence to indicate the reputation score (the likelihood that the object is malicious)
The Indicator forms the framework for the reputation result. All of the other data will be added under that.
In particular, because this is an indicator keep in mind that all of the fields on the CybOX object MUST have a @condition explicitly set. In most cases (such as for single IP addresses, file hashes, and URLs) the condition can just be “Equals”.
In this example, the SHA256 hash for the file is given along with the notation that the match should (of course, because it’s a hash) be an equality match:
To make indicators more useful it’s strongly suggested that an Indicated_TTP be included on the indicator. This is a relationship that points to the TTP construct to describe what about the object is bad: maybe it’s a piece of malware, maybe it’s an IP used for C2, maybe it’s an e-mail address used for spear phishing. In rare cases it might be impossible for a producer to create this information and, in those cases, it may be omitted.
For almost all reputation services, the reputation score isn’t how bad the indicated object is but how likely it is that the object is bad. In the indicator context, this data is represented on the Confidence field (which can in some ways be thought of as a synonym for Indicated_TTP/Confidence). This field can either use the default vocabulary (HighMediumLow) or a custom vocabulary to represent a different scoring system.
When using a custom vocabulary, the @vocab_name field represents the name of the scoring system and the @vocab_reference field represents a URL to something that defines the scoring system. In this example, we just use a placeholder link to Wikipedia but in a real service it should be set to the documentation for the scoring system so that consumers can understand the score that they get.