STIX Profiles are a mechanism to describe a particular usage of STIX as practiced by a community, organization, or tool. Profiles are represented using a specially-formatted Excel spreadsheet. The use of this spreadsheet ensures that all community members consistently create and understand profiles as well as allows for automated profile validation.
Excel was chosen as the initial format because it’s machine-processable (through libraries for various programming languages) yet still human-readable. The goals of the format were to ensure that analysts and business owners could understand the subset of STIX that was being discussed, that developers could understand what supporting products needed to support, and that instance documents could be automatically validated against as many of the profile rules as possible.
The Excel format is based on a set of tabs in the spreadsheet:
The overview sheet is used to give people reading the profile a high-level understanding of what the profile supports without having to delve into the details. It contains metadata such as the name of the profile, who created it, version, releasability as well as a summary of which STIX components, CybOX objects, vocabularies, and features are supported. The overview tab must be manually configured by the author and is not used for automated validation.
The Namespaces and Instance Mapping tabs are used only to support automated validation and can be ignored by those reading a profile. Respectively they map namespace prefixes to full namespaces and row headings to the XPaths to find the construct.
The data tabs contain the actual profile content. Each tab contains all types for a particular STIX or CybOX namespace and indicates how those types may be used. Not all namespaces will be visible in most profiles: profile authors typically hide tabs that are entirely excluded from the profile in order to cut down on noise. For example, an indicator sharing profile likely will not have tabs for Exploit Target or Threat Actor because they’re disallowed.
Profile rules are specified in the Occurrence, Implementation, Value(s), and Notes columns.
| Column | Description | Format |
|---|---|---|
| Occurrence | Indicates whether a particular field are allowed. The value of this field also determines the color of the entire row. | Single Term: MUST, SHOULD, MAY, SHOULD NOT, MUST NOT. |
| Implementation | Indicates a required implementation for an extension point via the xsi:type. For example, the Type field in indicator might set this to stixVocabs:IndicatorTypeVocab-1.1. |
Comma-separated list of possible implementations |
| Value(s) | Indicates a set of values, one of which is required to be set in the field if the field is present. Note that if the field is marked MAY, it's also permissible for this field to be absent. If it is present however, it must be set to one of the listed values. This field is only applicable to simple value types, not structured content (i.e. you can't define a set value for a structured field). | Comma-separated list of possible values |
| Notes | Indicates miscellaneous notes or conformance requirements that don't fall into any other category. This field is meant for human consumption, not automated validation. Even though this field is not automatically validated, conformance rules specified here are considered normative for the profile and documents that do not conform are not considered compliant even if they pass automated validation. | Free text |
STIX profiles are based defining rules for how STIX types may be used. For example, the top-level of any STIX document is STIX_Package, which is an instance of STIXType in the STIX Core schema. Therefore, the rules that define how STIX_Package must be used can be found in the STIXType section of the STIX Core profile tab. That tab lists each field and the rules for that field.
For each field that is permitted in the profile, the type that defines that field will also be present, with two exceptions: simple types (strings, numbers, text, etc.) without structure don’t need to be defined and are not present, and types in external schemas may not be present. Other types, however, will be present in their corresponding tab and will also be fully defined.
Types that are not referenced from anywhere else (i.e. types whose only instantiations are marked MUST NOT) are generally hidden by profile authors because they’re inaccessible in instance documents. They’re considered disallowed by proxy because all the places they may be used are as well.
Profiles are a complicated topic. Please get in touch with the team if you have any questions or think this documentation could be improved.