This page contains suggested practices (sometimes called best practices) for producing and consuming STIX content. Following these practices will ensure the best conformance with the design goals of STIX and the best compatibility with other STIX tools. These are not requirements, however: in some cases, technical or business requirements will mean you can’t comply with them and that’s fine. Think of them as “do it this way unless you have a good reason not to”.
General practices apply across STIX (and sometimes CybOX).
STIX IDs should be unique for all instances of content and are implemented as XML QNames. Each ID includes both a namespace portion (optional) and an ID portion (required) separated by a colon (:). The recommend approach to creating STIX IDs is to define a producer namespace and namespace prefix, then use the form:
[ns prefix]:[construct type]-[GUID]
The “ns prefix” should be a namespace prefix bound to a namespace owned/controlled by the producer of the content. It is the responsibility of the producer to ensure that the namespace is unique from namespaces used by any other producers and that the ID portion (after the colon) is unique within the specified namespace (before the colon).
Some examples:
acme:package-ce431003-ad07-4c96-bd7a-a50a3196e2a0
acme:indicator-bf8bc5d5-c7e6-46b0-8d22-7500fea77196
acme:campaign-79090715-8d6a-46b7-943b-c0bb9e063788
In order to use this approach, you will need to define that namespace prefix in the head of your XML document:
<stix:STIX_Package xmlns:acme="http://acme.example.com" ...
This format provides high assurance that IDs will be both unique and meaningful, because the producer namespace denotes who’s producing it, the construct name denotes what it is, and the overall ID including the GUID lends a high degree of confidence in its uniqueness.
STIX has several constructs with the potential to assign IDs to them such that they can be unambiguously referenced from elsewhere.
Technically the decision to specify an ID on a given construct is optional based on the specifics of the usage context.
As a simple general rule specifying IDs on particular instances of constructs enables clear referencing, relating and pivoting.
This supports several very common STIX use cases such as:
For these reasons, it is suggested that IDs be specified for the following commonly referenced and/or reused constructs unless there is clear reason not to:
As a simple general rule specifying IDs is not suggested for constructs embedded within other constructs (e.g. a CybOX Object containing the embedded specification of another CybOX Related_Object) where the embedded constructs are really only relevant/valid/important within the context of the enclosing construct. In other words they provide contextual characterization for the enclosing construct but would not be of interest on their own. The upside of this is slightly less complexity of IDs on everything. The downside is that it would not be possible to reference or pivot on the embedded constructs.
The top-level STIX components as well as other important constructs (VulnerabilityType, for example) each have fields for Title, Description, and Short_Description:
Title field is recommended for all constructs and should be short enough that a consumer can use it as or in a heading.Description field is the primary descriptive field. Any length of text is fine and this field supports optional formatting via the @structuring_format field.Short_Description field is the secondary description and should only be used if the Description field is already populated and another, shorter, description is available.The intent of the Short_Description field is to contain an abbreviated version of the content in the Description field when such abbreviated content is available. Consumers should not have to guess whether the primary description is contained in Description or Short_Description and so producers should always populate Description first before populating Short_Description.
Also note that some types have additional name fields beyond Title. For example, MalwareInstanceType has a Name field and CampaignType has a list of Names. Though similar, these fields have slightly different purposes: the Title field is used to give a title to the STIX construct while the Name field is used to give the name of the thing that the STIX construct describes. The easiest way to see the differences is via an example:
| Scenario | Title | Name |
|---|---|---|
| Representing the general concept of SpyEye | TTP Title = “SpyEye” | Malware Name = “SpyEye” |
| Representing a specific analysis of the SpyEye Malware | TTP Title = “Analysis of SpyEye Performed with Cuckoo” | Malware Name = “SpyEye” |
In the first example the STIX TTP is representing the general concept of SpyEye and therefore the TTP Title and Malware Name are the same. There’s no more specific context that the STIX TTP conveys beyond the malware and therefore duplicating the name is perfectly fine. This probably covers the majority of cases.
In the second example a specific analysis of SpyEye and therefore the TTP Title is more specific than just SpyEye. In cases like this where the STIX construct conveys a more particular analysis, viewpoint, or characterization of the general concept then it’s appropriate to give it a more specific title indicating that.
With the release of STIX 1.2, the Description field now supports multiple entries. The primary use case for this is the ability to mark each description with a different set of markings: for example, on could be TLP:RED while another could be TLP:GREEN.
Use of multiple descriptions is recommended only to support this use case: separating descriptions by paragraph or into sections is more appropriately accomplished via structuring the description in something like markdown or HTML and setting the structuring_format correctly.
To support this capability, several fields were added to the Description element:
id field is strongly recommended in order to appropriately target the description elements that you wish to mark. idref is not available and descriptions cannot be referenced in the same way that other idable fields can.ordinality field is used to order the description elements so they can be re-assembled in a way that makes sense. XML order is not determinitive in some XML processors and therefore it’s not enough to simply order the XML elements: setting ordinality manually is required.python-stix will handle both of these items for you.
InformationSourceType is used to describe the who, what, and when of the production of the information in the containing construct. Among other things it’s used to describe who produced the information, when it was produced, what tools were used to produce it and what it was derived from.
Information source is applied at several layers of the data model and at each of these layers it applies to that content and all content nested inside of it except when overriden (see below) by a more localized source. For example:
STIX_Header, it applies to the package/report itself as well as individually to all constructs.Indicator, it applies to the construct itself (always overriding any Information_Source set at the package level) and individually to any contained relationships or statements.For the purposes of Information Source override means “completely replaces”.
Note that on Indicator the information source field is called Producer. On Observable, it’s called Observable_Source and uses the semantics and structure of the CybOX MeasureSourceType.
In many cases, you’ll have an option to define a component relationship by one of two approaches: either including the related component within the parent component (embedding) or by referencing the related component by ID to a representation in a global location (referencing).
What is it?
Relationships via embedded definition are achieved when a relationship from one component (source) to another (sink) is asserted by defining/specifying the sink from within the source. If an id is specified for the sink it can be referenced from other components as well.
NOTE: Embedding the definition of a component within another component does not imply a hard parent-child relationship limiting its relevancy to only the embedding component. As noted in the suggested practices for Assigning IDs, for situations where the embedded component is really only relevant/valid/important within the context of the embedding component it is suggested practice to not specify an ID for it. This explicitly denotes its local-only relevance and prevents it from participating in relationships to components other than the embedding one. For situations where the simplicity, brevity and readability of relationship via embedded definition is desirable but the embedded content may be relevant/valid/important outside the context of only the embedding component, an ID can be specified for it and it can participate in relationships to components other than the embedding one.
Example with IDs on embedded content (related TTP and COA content is general enough to be relevant outside the context of the Indicator):
<stix:STIX_Header>
<stix:Title>Example watchlist that contains domain information.</stix:Title>
<stix:Package_Intent xsi:type="stixVocabs:PackageIntentVocab-1.0">Indicators - Watchlist</stix:Package_Intent>
</stix:STIX_Header>
<stix:Indicators>
<stix:Indicator xsi:type="indicator:IndicatorType" id="example:Indicator-2e20c5b2-56fa-46cd-9662-8f199c69d2c9" timestamp="2014-05-08T09:00:00.000000Z">
<indicator:Type xsi:type="stixVocabs:IndicatorTypeVocab-1.1">Domain Watchlist</indicator:Type>
<indicator:Description>Sample domain Indicator for this watchlist</indicator:Description>
<indicator:Observable id="example:Observable-87c9a5bb-d005-4b3e-8081-99f720fad62b">
<cybox:Object id="example:Object-12c760ba-cd2c-4f5d-a37d-18212eac7928">
<cybox:Properties xsi:type="DomainNameObj:DomainNameObjectType" type="FQDN">
<DomainNameObj:Value condition="Equals" apply_condition="ANY">malicious1.example.com##comma##malicious2.example.com##comma##malicious3.example.com</DomainNameObj:Value>
</cybox:Properties>
</cybox:Object>
</indicator:Observable>
<indicator:Indicated_TTP>
<stixCommon:TTP xsi:type="ttp:TTPType" id="example:TTP-4f5db5e2-7ed2-4bfd-9df8-fa8253fcb2fe">
<ttp:Title>Drive-by Download</ttp:Title>
</stixCommon:TTP>
</indicator:Indicated_TTP>
<indicator:Suggested_COAs>
<indicator:Suggested_COA>
<stixCommon:Course_Of_Action xsi:type="coa:CourseOfActionType" id="example:COA-2493dce9-1b2b-4396-9660-cfc19b8a6b38">
<coa:Title>Block Downloads from Malicious Domain</coa:Title>
</stixCommon:Course_Of_Action>
</indicator:Suggested_COA>
</indicator:Suggested_COAs>
</stix:Indicator>
</stix:Indicators>Example without IDs on embedded content (related TTP content is general enough to be relevant outside the context of the Indicator but related COA content is not):
<stix:STIX_Header>
<stix:Title>Indicators for Teufelhund malware dropsite.</stix:Title>
<stix:Package_Intent xsi:type="stixVocabs:PackageIntentVocab-1.0">Indicators - Watchlist</stix:Package_Intent>
</stix:STIX_Header>
<stix:Indicators>
<stix:Indicator xsi:type="indicator:IndicatorType" id="example:Indicator-aedba5fa-1a30-4c59-9264-a930b99536f9" timestamp="2014-05-08T09:00:00.000000Z">
<indicator:Title>Indicator for Teufelhund malware dropsite domain.</indicator:Title>
<indicator:Type xsi:type="stixVocabs:IndicatorTypeVocab-1.1">Domain Watchlist</indicator:Type>
<indicator:Observable id="example:Observable-82de1cdf-7cf0-4f9a-9b98-5c40235a70a5">
<cybox:Object id="example:Object-f8fb1238-ec28-4ddd-9f37-35b31d718db7">
<cybox:Properties xsi:type="DomainNameObj:DomainNameObjectType" type="FQDN">
<DomainNameObj:Value condition="Equals">yolohipster.com</DomainNameObj:Value>
</cybox:Properties>
</cybox:Object>
</indicator:Observable>
<indicator:Indicated_TTP>
<stixCommon:TTP xsi:type="ttp:TTPType" id="example:TTP-2b6bf957-bc5b-4aa1-a604-691baeb63e3d">
<ttp:Title>Teufelhund malware</ttp:Title>
</stixCommon:TTP>
</indicator:Indicated_TTP>
<indicator:Suggested_COAs>
<indicator:Suggested_COA>
<stixCommon:Course_Of_Action xsi:type="coa:CourseOfActionType"> <!-- NOTE: no @id specified for this Course_Of_Action as it is VERY specific to this Indicator-->
<coa:Title>Redirect requests for yolohipster.com to quarantine.acme.com</coa:Title>
</stixCommon:Course_Of_Action>
</indicator:Suggested_COA>
</indicator:Suggested_COAs>
</stix:Indicator>
</stix:Indicators>Relationship via embedded definition is desirable when simplicity, brevity and readability of the content is of concern or the content is very localized in context and less likely that portions will be interrelated with other content.
What is it?
Relationships via reference are achieved when a relationship from one component (source) to another (sink) is asserted by including a reference within the source in the form of an idref referencing the defined id for the sink.
Example:
<stix:STIX_Header>
<stix:Title>Example watchlist that contains domain information.</stix:Title>
<stix:Package_Intent xsi:type="stixVocabs:PackageIntentVocab-1.0">Indicators - Watchlist</stix:Package_Intent>
</stix:STIX_Header>
<stix:Observables cybox_major_version="2" cybox_minor_version="1">
<cybox:Observable id="example:Observable-87c9a5bb-d005-4b3e-8081-99f720fad62b">
<cybox:Object id="example:Object-12c760ba-cd2c-4f5d-a37d-18212eac7928">
<cybox:Properties xsi:type="DomainNameObj:DomainNameObjectType" type="FQDN">
<DomainNameObj:Value condition="Equals" apply_condition="ANY">malicious1.example.com##comma##malicious2.example.com##comma##malicious3.example.com</DomainNameObj:Value>
</cybox:Properties>
</cybox:Object>
</cybox:Observable>
</stix:Observables>
<stix:Indicators>
<stix:Indicator xsi:type="indicator:IndicatorType" id="example:Indicator-2e20c5b2-56fa-46cd-9662-8f199c69d2c9" timestamp="2014-05-08T09:00:00.000000Z">
<indicator:Type xsi:type="stixVocabs:IndicatorTypeVocab-1.1">Domain Watchlist</indicator:Type>
<indicator:Description>Sample domain Indicator for this watchlist</indicator:Description>
<indicator:Observable idref="example:Observable-87c9a5bb-d005-4b3e-8081-99f720fad62b" />
<indicator:Indicated_TTP>
<stixCommon:TTP xsi:type="ttp:TTPType" idref="example:TTP-4f5db5e2-7ed2-4bfd-9df8-fa8253fcb2fe"/>
</indicator:Indicated_TTP>
<indicator:Suggested_COAs>
<indicator:Suggested_COA>
<stixCommon:Course_Of_Action xsi:type="coa:CourseOfActionType" idref="example:COA-2493dce9-1b2b-4396-9660-cfc19b8a6b38"/>
</indicator:Suggested_COA>
</indicator:Suggested_COAs>
</stix:Indicator>
</stix:Indicators>
<stix:TTPs>
<stix:TTP xsi:type="ttp:TTPType" id="example:TTP-4f5db5e2-7ed2-4bfd-9df8-fa8253fcb2fe">
<ttp:Title>Drive-by Download</ttp:Title>
</stix:TTP>
</stix:TTPs>
<stix:Courses_Of_Action>
<stix:Course_Of_Action xsi:type="coa:CourseOfActionType" id="example:COA-2493dce9-1b2b-4396-9660-cfc19b8a6b38">
<coa:Title>Block Downloads from Malicious Domain</coa:Title>
</stix:Course_Of_Action>
</stix:Courses_Of_Action>Relationship via reference is desirable when flexibility, potential reuse and correlation of the content is a key concern or when part of a larger body of highly interrelated content.
Embedded content with no id:
Embedded content with id:
Referenced content:
These situations are a judgment call, but when making that judgment you should consider whether the related construct has value individually or only within the context of the parent? If it only has value in the parent, embedding it may be appropriate. Otherwise it’s probably better to reference it. If you’re unsure, it’s generally safer to reference it.
8 major STIX constructs are versioned:
It is always suggested that you version these constructs by including a relevant @id and @timestamp per the STIX versioning guide.
Note that many constructs that have a @timestamp attribute also have an Information_Source field with a Time field inside it. The Time field has a field called Produced_Time, which can easily be confused with @timestamp. Though similar, these fields are not used for the same purposes. @timestamp is used only for versioning and represents the time that version of the versioned structure was created. Information_Source/Time/Produced_Time is not related to versioning and represents the time the record (not that version of the record) was created. In some ways, they can be thought of as created time and modified time but in other ways they are used for completely different purposes.
See the Versioning concept discussion for more information.
There are two primary ways to create references in STIX 1.2: you can either create a reference to a specific version of a construct or you can create a reference to the latest version of a construct.
To create a reference to a specific version, set the idref attribute to the ID of the construct you want to reference and set the timestamp attribute to the exact timestamp of the version that you want to reference:
<stixCommon:TTP idref="example:ttp-cc250866-cde4-4029-bf37-4b65bf712cb9" timestamp="2014-02-20T09:00:00.000000" />
The alternative is to omit the timestamp attribute, which indicates that the reference is to the latest version of that construct:
<stixCommon:TTP idref="example:ttp-cc250866-cde4-4029-bf37-4b65bf712cb9" />
In general you should use the version-specific reference if you’re concerned that the meaning of the referenced construct could change and make the reference invalid, while you should use the version-agnostic reference if you just want to reference the latest version of the construct despite any changes that might occur.
References to non-versioned constructs (anything with an id/idref but not a timestamp) implicitly use the latter form.
Many places in STIX use controlled vocabularies to represent data. When possible, you should use the vocabularies included in the STIX defaults. If necessary you can use your own vocabulary or even use strings outside of any vocabularies.
If you do this to add values that you think might be useful for other STIX users, you should let us know so we can consider adding it to the default vocabulary.
The values of timestamp fields MUST follow the ISO 8601 format and SHOULD include a time zone whenever possible in order to eliminate ambiguity. This matches the format used by the XML Schema dateTime date type: YYYY-MM-DDThh:mm:ss+-hh:mm. Note that T is the delimiter between the date and time portions, and the time zone offset is delimited by either a + or a - to indicate the relative offset from UTC.
As of STIX 1.2, the contextual fields in STIX_Header have been deprecated. If you want to give context to set of STIX content you should use a Report. The Information_Source field is still available and should be used to indicate the source of content that’s included in the report (in other words, it’s equivalent to setting the Information_Source in each individual construct).
As of STIX 1.2, the Report construct should be used to give context to a set of STIX content. You’ll often see this in cases where a producer wants wrap up some threat intelligence with a common story such as a report about a particular campaign, actor, or piece of malware. The available fields are Title, Intent, Description, Short_Description, and Information_Source. At least Title, Intent, and Information_Source are recommended.
Note that unlike STIXType, the Information_Source field does not apply to the content included in the report but simply to the report itself.
Reports allow you to both reference content and embed content in order to denote that it’s included in the report. It’s generally suggested that you reference content from reports unless you have a good reason to embed it (document size, for example).
If possible, an indicator should include the following fields:
When creating observables for use as patterns within indicators, you should always set the condition attribute on all possible fields to an appropriate value, even if that value is equals. Leaving off the condition attribute implies that the observable is an instance rather than a pattern.
As described in Concept: Observable Instances vs Observable Patterns, there are two different forms of “Observables” possible in STIX: observable instances and observable patterns. Each form has its own purposes to represent various relevant information in STIX.
Some basic guidance is provided below on which forms of observables are appropriate for which purposes in STIX.
Outgoing network connection to a particular IP that occurred at a specific time
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<stix:STIX_Package id="example:STIXPackage-f61cd874-494d-4194-a3e6-6b487dbb6d6e" version="1.2">
<stix:Observables cybox_major_version="2" cybox_minor_version="1">
<cybox:Observable id="example:Observable-1d44cf4b-2cf9-4749-b93f-c8608cf21928">
<cybox:Observable_Source>
<cyboxCommon:Time>
<cyboxCommon:Start_Time>2014-05-08T09:00:00.000000Z</cyboxCommon:Start_Time>
</cyboxCommon:Time>
</cybox:Observable_Source>
<cybox:Object id="example:Object-3f21459c-6b15-4d7d-afc4-5c1912623e7d">
<cybox:Properties xsi:type="NetworkConnectionObj:NetworkConnectionObjectType">
<NetworkConnectionObj:Destination_Socket_Address>
<SocketAddressObj:IP_Address category="ipv4-addr">
<AddressObj:Address_Value>116.010.191.223</AddressObj:Address_Value>
</SocketAddressObj:IP_Address>
</NetworkConnectionObj:Destination_Socket_Address>
</cybox:Properties>
</cybox:Object>
</cybox:Observable>
</stix:Observables>
</stix:STIX_Package>
Related_Observable on a Sighting. Example »An Indicator specifies a set of three domains used for malware C2 and you wish to report a sighting specifying which of the three you observed
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
<stix:Indicator xsi:type="indicator:IndicatorType" id="example:Indicator-2e20c5b2-56fa-46cd-9662-8f199c69d2c9" timestamp="2014-05-08T09:00:00.000000Z">
<indicator:Type xsi:type="stixVocabs:IndicatorTypeVocab-1.1">Domain Watchlist</indicator:Type>
<indicator:Observable id="example:Observable-87c9a5bb-d005-4b3e-8081-99f720fad62b">
<cybox:Object id="example:Object-12c760ba-cd2c-4f5d-a37d-18212eac7928">
<cybox:Properties xsi:type="DomainNameObj:DomainNameObjectType" type="FQDN">
<DomainNameObj:Value condition="Equals" apply_condition="ANY">malicious1.example.com##comma##malicious2.example.com##comma##malicious3.example.com</DomainNameObj:Value>
</cybox:Properties>
</cybox:Object>
</indicator:Observable>
<indicator:Sightings>
<indicator:Sighting>
<indicator:Source>
<stixCommon:Identity>
<stixCommon:Name>FooBar Inc.</stixCommon:Name>
</stixCommon:Identity>
</indicator:Source>
<indicator:Related_Observables>
<indicator:Related_Observable>
<stixCommon:Observable id="example:Observable-45b3acdf-1888-4bcc-89a9-6d9f8116fede">
<cybox:Object id="example:Object-a3d36250-42fa-4653-9172-87b87598390c">
<cybox:Properties xsi:type="DomainNameObj:DomainNameObjectType" type="FQDN">
<DomainNameObj:Value>malicious2.example.com</DomainNameObj:Value>
</cybox:Properties>
</cybox:Object>
</stixCommon:Observable>
</indicator:Related_Observable>
</indicator:Related_Observables>
</indicator:Sighting>
</indicator:Sightings>
</stix:Indicator>
The basic details of a phishing email received as part of an attack
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
<stix:Incident xsi:type="incident:IncidentType" id="example:Incident-91d2d63c-ac96-4660-ae4a-20119c43b318" timestamp="2014-05-11T12:00:00Z">
<incident:Related_Observables>
<incident:Related_Observable>
<indicator:Observable id="example:Observable-Pattern-5f1dedd3-ece3-4007-94cd-7d52784c1474">
<cybox:Object id="example:Object-3a7aa9db-d082-447c-a422-293b78e24238">
<cybox:Properties xsi:type="EmailMessageObj:EmailMessageObjectType">
<EmailMessageObj:Header>
<EmailMessageObj:From category="e-mail">
<AddressObj:Address_Value>Rerun@state.gov</AddressObj:Address_Value>
</EmailMessageObj:From>
<EmailMessageObj:Subject>SkyNet Architecture Review</EmailMessageObj:Subject>
</EmailMessageObj:Header>
</cybox:Properties>
<cybox:Related_Objects>
<cybox:Related_Object>
<cybox:Properties xsi:type="FileObj:FileObjectType">
<FileObj:File_Extension>pdf</FileObj:File_Extension>
<FileObj:Size_In_Bytes>87022</FileObj:Size_In_Bytes>
<FileObj:Hashes>
<cyboxCommon:Hash>
<cyboxCommon:Type xsi:type="cyboxVocabs:HashNameVocab-1.0">MD5</cyboxCommon:Type>
<cyboxCommon:Simple_Hash_Value>cf2b3ad32a8a4cfb05e9dfc45875bd70</cyboxCommon:Simple_Hash_Value>
</cyboxCommon:Hash>
</FileObj:Hashes>
</cybox:Properties>
<cybox:Relationship xsi:type="cyboxVocabs:ObjectRelationshipVocab-1.0">Contains</cybox:Relationship>
</cybox:Related_Object>
</cybox:Related_Objects>
</cybox:Object>
</indicator:Observable>
</incident:Related_Observable>
</incident:Related_Observables>
</stix:Incident>
Details of a particular laptop infected with malware
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
<incident:Affected_Assets>
<incident:Affected_Asset>
<incident:Type xsi:type="incident:AssetTypeType">Laptop</incident:Type>
<incident:Ownership_Class xsi:type="stixVocabs:OwnershipClassVocab-1.0">Internally-Owned</incident:Ownership_Class>
<incident:Management_Class xsi:type="stixVocabs:ManagementClassVocab-1.0">Internally-Managed</incident:Management_Class>
<incident:Location_Class xsi:type="stixVocabs:LocationClassVocab-1.0">Internally-Located</incident:Location_Class>
<incident:Nature_Of_Security_Effect>
<incident:Property_Affected>
<incident:Property xsi:type="stixVocabs:LossPropertyVocab-1.0">Confidentiality</incident:Property>
</incident:Property_Affected>
<incident:Property_Affected>
<incident:Property xsi:type="stixVocabs:LossPropertyVocab-1.0">Integrity</incident:Property>
</incident:Property_Affected>
</incident:Nature_Of_Security_Effect>
<incident:Structured_Description cybox_major_version="2" cybox_minor_version="1">
<cybox:Observable>
<cybox:Object>
<cybox:Properties xsi:type="ProductObj:ProductObjectType">
<ProductObj:Vendor>Dell</ProductObj:Vendor>
<ProductObj:Device_Details xsi:type="DeviceObj:DeviceObjectType">
<cyboxCommon:Custom_Properties>
<cyboxCommon:Property name="Inventory Tracking Number">MM343287</cyboxCommon:Property>
</cyboxCommon:Custom_Properties>
<DeviceObj:Manufacturer>Dell</DeviceObj:Manufacturer>
<DeviceObj:Model>E6500</DeviceObj:Model>
<DeviceObj:Serial_Number>JZNZ12S</DeviceObj:Serial_Number>
<DeviceObj:Firmware_Version>A27</DeviceObj:Firmware_Version>
<DeviceObj:System_Details xsi:type="SystemObj:SystemObjectType">
<SystemObj:OS><cyboxCommon:Description>Windows 7</cyboxCommon:Description></SystemObj:OS>
<SystemObj:Processor>Intel Core 2 Duo P9500 2.53 GHz / nVIDIA Quadro NVS 160M</SystemObj:Processor>
<SystemObj:Total_Physical_Memory></SystemObj:Total_Physical_Memory>
</DeviceObj:System_Details>
</ProductObj:Device_Details>
</cybox:Properties>
</cybox:Object>
</cybox:Observable>
</incident:Structured_Description>
</incident:Affected_Asset>
</incident:Affected_Assets>
A specific registry key with a specific value
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<stix:Indicator xsi:type="indicator:IndicatorType" id="example:Indicator-b5325352-a178-4bd9-b203-278c01083f9b">
<indicator:Observable id="example:observable-503abed0-b00b-4f4e-94fe-9ebc6abaffdd">
<cybox:Object id="example:object-acee05cf-9a37-4c6b-9c90-83caf01604d2">
<cybox:Properties xsi:type="WinRegistryKeyObj:WindowsRegistryKeyObjectType">
<WinRegistryKeyObj:Key condition="Contains">Microsoft\Windows\CurrentVersion\Run\load</WinRegistryKeyObj:Key>
<WinRegistryKeyObj:Hive condition="Equals">Software</WinRegistryKeyObj:Hive>
<WinRegistryKeyObj:Values>
<WinRegistryKeyObj:Value>
<WinRegistryKeyObj:Data condition="Contains">acrord32.exe</WinRegistryKeyObj:Data>
</WinRegistryKeyObj:Value>
</WinRegistryKeyObj:Values>
</cybox:Properties>
</cybox:Object>
</indicator:Observable>
<indicator:Indicated_TTP>
<stixCommon:TTP xsi:type="ttp:TTPType">
<ttp:Title>Zaphod Malware</ttp:Title>
</stixCommon:TTP>
</indicator:Indicated_TTP>
</stix:Indicator>
Block traffic to a particular IP address
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
<stix:Course_Of_Action id="example:coa-55f57cc7-ddd5-467b-a3a2-6fd602549d9e" xsi:type="coa:CourseOfActionType" version="1.1">
<coa:Title>Block traffic to PIVY C2 Server (10.10.10.10)</coa:Title>
<coa:Stage xsi:type="stixVocabs:COAStageVocab-1.0">Response</coa:Stage>
<coa:Type xsi:type="stixVocabs:CourseOfActionTypeVocab-1.0">Perimeter Blocking</coa:Type>
<coa:Objective>
<coa:Description>Block communication between the PIVY agents and the C2 Server</coa:Description>
<coa:Applicability_Confidence>
<stixCommon:Value xsi:type="stixVocabs:HighMediumLowVocab-1.0">High</stixCommon:Value>
</coa:Applicability_Confidence>
</coa:Objective>
<coa:Parameter_Observables cybox_major_version="2" cybox_minor_version="1" cybox_update_version="0">
<cybox:Observable id="example:Observable-e04425e4-60a2-4d91-a9f9-0ca956f19edb">
<cybox:Object id="example:Address-d5bc7186-319d-44e0-85f4-0b65f59034a3">
<cybox:Properties xsi:type="AddressObj:AddressObjectType" category="ipv4-addr">
<AddressObj:Address_Value condition="Equals">10.10.10.10</AddressObj:Address_Value>
</cybox:Properties>
</cybox:Object>
</cybox:Observable>
</coa:Parameter_Observables>
<coa:Impact>
<stixCommon:Value xsi:type="stixVocabs:HighMediumLowVocab-1.0">Low</stixCommon:Value>
<stixCommon:Description>This IP address is not used for legitimate hosting so there should be no operational impact.</stixCommon:Description>
</coa:Impact>
<coa:Cost>
<stixCommon:Value xsi:type="stixVocabs:HighMediumLowVocab-1.0">Low</stixCommon:Value>
</coa:Cost>
<coa:Efficacy>
<stixCommon:Value xsi:type="stixVocabs:HighMediumLowVocab-1.0">High</stixCommon:Value>
</coa:Efficacy>
</stix:Course_Of_Action>
The Heartbleed vulnerability (CVE-2014-0160) affects a specific set of versions of openssl
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<stixCommon:Exploit_Target xsi:type="et:ExploitTargetType">
<et:Vulnerability>
<et:Title>Heartbleed</et:Title>
<et:Description>The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug.</et:Description>
<et:CVE_ID>CVE-2014-0160</et:CVE_ID>
<et:CVSS_Score>
<et:Base_Score>5.0</et:Base_Score>
<et:Base_Vector>AV:N/AC:L/Au:N/C:P/I:N/A:N</et:Base_Vector>
</et:CVSS_Score>
<et:Affected_Software>
<et:Affected_Software>
<stixCommon:Observable>
<cybox:Object>
<cybox:Properties xsi:type="ProductObj:ProductObjectType">
<ProductObj:Product condition="Equals">openssl</ProductObj:Product>
<ProductObj:Version condition="Equals" apply_condition="ANY">1.0.2:beta1##comma##1.0.1f##comma##1.0.1##comma##1.0.1:beta1##comma##1.0.1:beta2##comma##1.0.1:beta3##comma##1.0.1a##comma##1.0.1b##comma##1.0.1c##comma##1.0.1d##comma##1.0.1e</ProductObj:Version>
</cybox:Properties>
</cybox:Object>
</stixCommon:Observable>
</et:Affected_Software>
</et:Affected_Software>
</et:Vulnerability>
</stixCommon:Exploit_Target>
A particular set of IPs used for Zeus malware command and control
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
<stix:Observables cybox_major_version="1" cybox_minor_version="1">
<cybox:Observable id="example:observable-c8c32b6e-2ea8-51c4-6446-7f5218072f27">
<cybox:Object id="example:object-d7fcce87-0e98-4537-81bf-1e7ca9ad3734">
<cybox:Properties xsi:type="AddressObject:AddressObjectType" category="ipv4-addr">
<AddressObject:Address_Value condition="Equals">198.51.100.2</AddressObject:Address_Value>
</cybox:Properties>
</cybox:Object>
</cybox:Observable>
<cybox:Observable id="example:observable-b57aa65f-9598-04fb-a9d1-5094c36d5dc4">
<cybox:Object id="example:object-f4fac80a-1239-47cc-b0e6-771b1a73f817">
<cybox:Properties xsi:type="AddressObject:AddressObjectType" category="ipv4-addr">
<AddressObject:Address_Value condition="Equals">198.51.100.17</AddressObject:Address_Value>
</cybox:Properties>
</cybox:Object>
</cybox:Observable>
<cybox:Observable id="example:observable-19c16346-0eb4-99e2-00bb-4ec3ed174cac">
<cybox:Object id="example:object-174bf9a3-f163-4919-9119-b52598f97ce3">
<cybox:Properties xsi:type="AddressObject:AddressObjectType" category="ipv4-addr">
<AddressObject:Address_Value condition="Equals">203.0.113.19</AddressObject:Address_Value>
</cybox:Properties>
</cybox:Object>
</cybox:Observable>
</stix:Observables>
<stix:TTPs>
<stix:TTP xsi:type="ttp:TTPType" id="example:ttp-dd955e08-16d0-6f08-5064-50d9e7a3104d" timestamp="2014-02-20T09:00:00.000000Z">
<ttp:Title>Zeus Malware C2 Channel</ttp:Title>
<ttp:Resources>
<ttp:Infrastructure>
<ttp:Type>Malware C2</ttp:Type>
<ttp:Observable_Characterization cybox_major_version="2" cybox_minor_version="1">
<cybox:Observable idref="example:observable-c8c32b6e-2ea8-51c4-6446-7f5218072f27"/>
<cybox:Observable idref="example:observable-b57aa65f-9598-04fb-a9d1-5094c36d5dc4"/>
<cybox:Observable idref="example:observable-19c16346-0eb4-99e2-00bb-4ec3ed174cac"/>
</ttp:Observable_Characterization>
</ttp:Infrastructure>
</ttp:Resources>
</stix:TTP>
</stix:TTPs>
Attackers are targeting victims with 15-inch MacBook Pro Retina laptops with a particular CPU and memory configuration and running OSX Mavericks 10.9.2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<stix:TTP xsi:type="ttp:TTPType" id="example:ttp-1173cf17-709a-4427-bf60-7f5828c7bbcf">
<ttp:Victim_Targeting>
<ttp:Targeted_Technical_Details cybox_major_version="1" cybox_minor_version="1">
<cybox:Observable id="example:observable-674d2736-cd3a-45c8-85a2-93cbacc9ed17">
<cybox:Object id="example:object-c77147b7-4d4c-4880-81cb-19ae016eec1d">
<cybox:Properties xsi:type="DeviceObj:DeviceObjectType">
<DeviceObj:Manufacturer condition="Equals">Apple</DeviceObj:Manufacturer>
<DeviceObj:Model condition="Equals">15-inch MacBook Pro with Retina Display</DeviceObj:Model>
<DeviceObj:System_Details xsi:type="SystemObj:SystemObjectType">
<SystemObj:OS>
<cyboxCommon:Description condition="Equals">OSX Mavericks 10.9.2</cyboxCommon:Description>
<cyboxCommon:Identifier condition="Equals">cpe:/o:apple:mac_os_x:10.9.2</cyboxCommon:Identifier>
</SystemObj:OS>
<SystemObj:Processor condition="Equals">2.2GHz Quad-core Intel Core i7</SystemObj:Processor>
<SystemObj:Total_Physical_Memory condition="Equals">16GB</SystemObj:Total_Physical_Memory>
</DeviceObj:System_Details>
</cybox:Properties>
</cybox:Object>
</cybox:Observable>
</ttp:Targeted_Technical_Details>
</ttp:Victim_Targeting>
</stix:TTP>
Whether you are characterizing instances or patterns, the types of observables you may wish to characterize in STIX/CybOX can vary widely from the very simple to the complex depending on what you are trying to Concepts: Composition of Observables and Indicators provides more information characterizing the potential levels of detail for observable composition in STIX/CybOX.
The table below gives guidance on the suggested level of detail to use for a range of common use cases.
| Use case | Example | Suggested level of detail |
|---|---|---|
| If you need to talk about a single property. | A file with name=”foo.exe” | Single Object with single Property |
| If you need to talk about multiple properties of a single object. | A file with name=”foo.exe” and size=”1896Kb” | Single Object with multiple Properties |
| If you need to talk about specific properties of multiple related objects. | An email with a subject=“Syria strategic plans leaked” and an attached file with name=“bombISIS.pdf” | Multiple related Objects |
| If you need to talk about logical (AND/OR) combinations of other observable patterns. | A file with name=”barfoobar” exists AND an outgoing network connection occurs to “46.123.99.25” | Composition of observable patterns |
| If you need to talk about a logical (AND/OR) combination of observable patterns on a single property of a single object (e.g. an IP watch list) and you want to specify this in the most compact and concise form available. | An IP watchlist for “10.0.0.0, 10.0.0.1, 10.0.0.3” | Composition of observable patterns - shorthand list form |
| If you need to define an Indicator (including context info) logically composed of other potentially preexisting Indicators for which you wish to detect their contexts separately. | A file with a specific hash indicating a particular malware variant AND an outgoing network connection to a specific IP address indicating known C2, together indicating a particular campaign combining the two. | Composition of Indicators |
Suggested practices for choosing which CybOX object to use are on the CybOX suggested practices page.
The XPath specified in a data marking controlled structure field must select all fields (elements and attributes) that the marking will be applied to. It is not sufficient to select only the root element using the / character. Instead, you should use the node() function to select relevant nodes. For example, to select the entire document you should use //node() while to select a parent construct (Indicator, for example), you could use ancestor-or-self::stix:Indicator//node().
As noted in the annotations, prefixes are valid if they are declared in scope of the Controlled_Structure element.