Profiles are a mechanism to describe a particular usage of STIX as practiced by a community, organization, or tool. Continue reading to understand the concept behind profiles, or jump ahead to representation, creating a profile, or validating against profiles.
STIX 1.2 Profile Template
STIX 1.2 Sample Profile
The STIX language was designed to support the full scope of cyber threat intelligence use cases and therefore the data model is fairly broad in scope. It incorporates everything from low-level indicators and observables all the way up to threat actors and campaigns.
This broad scope allows STIX to support a large variety of use cases and correlation across those use cases, but it also means that the full data model is probably not required to support any single use case. For example, an organization using STIX for indicator sharing may not need the threat actor attribution portions of the data model.
STIX profiles are the formalization of this concept: a particular subset of STIX as practiced by a community, organization, or tool.
Indicator, observable, and TTP are in-scope but campaign, course of action, exploit target, incident, and threat actor are out-of-scope. The full example of that profile can be downloaded above.
Profiles can be thought of a second compatibility level for STIX content: STIX content can be valid STIX but if it doesn’t conform to the rules outlined in the profile it is not compliant with a profile or tools that only support that profile. In fact, the spreadsheet profile representation even allows for automated validation of STIX instance content against it.
Profiles outline several types of rules:
Terms compliant with RFC 2119 are used to indicate presence rules. Older versions of STIX profiles used custom terms as indicated below. These terms are still valid for older profiles but those creating new profiles should use the formal RFC2119 terms.
| RFC Term | Legacy Term |
|---|---|
| MUST | Required |
| SHOULD | Suggested |
| MAY | Optional |
| SHOULD NOT | (none) |
| MUST NOT | Prohibited |
Profiles are used for two primary purposes:
If all parties in an information exchange agree on a profile or an implementation specifies a governing profile it narrows the scope of STIX from the entire data model to just what is specified in the profile.
For users and those defining the sharing model, profiles are useful in reaching a common understanding about what will be shared. The community or set of users can prohibit certain constructs using a profile, for example, to denote that they do not plan to share that sort of information.
For developers, profiles are helpful because they narrow the scope of STIX that must be understood and developed against. Rather than having to understand the full set of STIX constructs and all of the fields of each of those constructs, developers implementing against a profile can limit themselves to just the fields allowed in that profile and users of that implementation can have clear expectations of what sorts of information the implementation can handle.
This diagram illustrates the use of a shared profile between two organizations to facilitate the sharing of a subset of STIX. In this example, the profile specifies that STIX Indicators and TTPs are in scope for the profile – the other top-level STIX objects are not. As such, profiles can assist organizations in establishing governance and policy about what will be shared and can also help guide the implementation of solutions targeted to the subset of STIX defined by a profile.
Although all types of profiles indicate similar rules, there are a few distinctions in how to think about profiles meant for different uses.
Community profiles describe how a particular sharing community (an industry collaboration group, a government sharing program, etc.) will use STIX. In these types of profiles, you have many parties involved in both producing and consuming information. Community profiles can also be created outside the context of any particular sharing program to help standardize practices across the entire industry.
These profiles should be developed with participation from most or all members of the community to ensure that they aren’t too focused on any one technical implementation or one organization’s biases.
Presence rules are created as follows:
Producer profiles describe how one particular producer will be creating STIX documents. This is useful for tool developers, commercial threat intelligence feeds, and sharing programs where a single producer is publishing to many consumers. The use of a profile in this case makes it easier for consumers to implement only the portion of STIX that is actually used. It can also help consumers understand the type of information that they producer will be publishing in order to decide whether the feed is worth consuming at all.
Producer profiles can be compared to community profiles to determine whether the producer is compliant with any given community profile. Using the profile layering concept outlined in the profile whitepaper, a producer profile is compatible with a community profile if it is a complete subset (child) of that profile.
For producer profiles, the producer itself should develop the profile in order to ensure that it is accurate. They should consider whether fields will always be present, might be present, or will never be present:
Note that producer profiles don’t typically have a “suggested” category. This is because the producer will populate optional fields as defined by the data their product produces and therefore the distinction is less relevant.
Consumer profiles are essentially compatibility statements: a consumer can create them to demonstrate which portions of STIX they support. They can then be compared to community or producer profiles to determine whether the consumer is compatible.
If a consumer profile is a parent (superset) of either a producer or community profile it can be considered fully compatible. In other cases, it may be a partial superset/subset but have support for ignoring fields it does not handle rather than throwing an error, in which case it can be considered partially compatible.
Consumers base compatibility with the ability to parse certain fields from an incoming STIX document.
Given the ecosystem of profiles that would likely exist, it’s also helpful to think of profiles as supporting layered compatibility.
Considering the sharing use case for example, a broad “threat sharing” profile might be defined to detail which constructs are allowed for sharing of threat information in a particular community, while a narrower “indicator sharing” profile might be created based on the threat sharing profile that specifies further constraints on the set of fields or values specifically to what is used for indicator sharing. This is referred to here as “layered” profiles, with the “parent” layer containing a less constrained superset of what is allowed in child profiles.
This means that a child profile may:
The key is that a child profile is always a further constraint of the parent profile and is never a loosening or expansion. Because of these rules, any STIX document that complies with a child profile also complies with the parent profile (and, by extension, any of that parent’s parents) because of the upward loosening nature of the layering. Consumers of STIX documents are assured that by fully supporting a parent profile they inherently support STIX content produced according to any of that profile’s child profiles and, vice versa, producers of STIX documents can be assured that all consumers that support the parent profile will be able to parse content they produce that is conformant with any of that parent’s child profiles.
The current representation for STIX profiles is a specifically-formatted Excel spreadsheet. The representation page goes into detail on how the format works and the profile templates available above are a good start.
Though profiles are most useful in the development period for users and developers in the community to agree upon their STIX formats, in some use cases it’s also helpful to validate the instance content does indeed conform to the profile. When using the standard Excel format, the STIX Validator tool can be used to validate a STIX document against a profile. Further information on this is available on the profile validation page.
STIX profiles are generally created through community agreement (for community profiles) or by a product manager or developer documenting what their product will support. An authoring guide is available for those who will be performing the technical work of creating the Excel-formatted spreadsheet.
Profiles are a complicated topic. Please get in touch with the team if you have any questions or think this documentation could be improved.