Observables in STIX represent stateful properties or measurable events pertinent to the operation of computers and networks.
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.
Whether you are characterizing instances or patterns, the types of observables (and indicators based on them) you may wish to characterize can vary widely from the very simple to the complex depending on what you are trying to convey.
The content below characterizes the different levels of observable/indicator complexity possible in STIX.
Lets begin with the simplest form of observable, a single property such as a filename.
Whether you want to convey an instance or a pattern on the property, the mechanism CybOX utilizes to convey this information is the Object. The CybOX Object construct enables the characterization of a given type of object (e.g. File, Email_Message, Network_Connection, Address, etc.). The structure allows the object characterizations to be associated with dynamic actions (which we will ignore for now for simplicity sake) or with other objects but at their core they are focused on characterizing the various properties of any given type of object (CybOX 2.1 provides property schemas for 90+ different cyber objects).
Given this, something simple like a filename can easily be expressed using the File_Name property field on a File Object. An instance can be described directly or a pattern can be conveyed using the CybOX property patterning capabilities on that property. More detail on mechanism and use »
Unlike some other approaches that treat all object properties as flat fields independent of each other or the particular object instance they apply to, STIX/CybOX associates the set of properties relevant to a given type of object together in that object’s property schema. This allows not only characterization of individual properties as flat fields but also allows characterization of multiple properties as relevant to a single instance of the given object. If you wish to characterize multiple properties that were observed (observable instance) for a single object you can simply specify multiple property fields on a single CybOX Object thus characterizing that that one single object had all of those properties. If you wish to specify a pattern for an object (observable pattern) that has a set of specific properties (and potentially specify patterning on each property) you can do this by simply specifying each property pattern using those property fields on a single object. Specifying patterns on multiple properties of an object (e.g. filename and filesize) using a flat field approach leads to ambiguity of whether all of the property patterns apply to the same single object instance or could potentially each map against different object instances. For example, a flat field approach might specify a pattern for filename=“foo.txt” and a pattern for filesize=“1896Kb” which could match against a FileA with both filename=“foo.txt” and filesize=“1896Kb” or it could match against a FileA with filename=“foo.txt” and a FileB with filesize=“1896Kb”. By enabling direct specification of multiple property patterns on a single object, STIX/CyboX allows this ambiguity to be avoided. Specifying a single object with multiple property patterns in STIX/CybOX is equivalent to a logical AND of those patterns but specifically as applied to a single instance of that object. In other words, for the pattern to be true all of the individual property patterns must be true on the same object instance. More detail on mechanism and use »
condition attribute and field value on each relevant a single object property
You may also wish to convey observable information that is not limited to the properties of a single instance object (e.g. an email message with a file attachment). STIX/CybOX enables this through the use of a Related_Objects structure available on any given Object that allows you to assert a relationship to another Object and to characterize the nature of the relationship with a label (e.g. “Contained_Within”). You can specify property patterns on any property fields of any of the related Objects. Similar to the semantics of multiple property patterns on a single Object (described above), property patterns on multiple Objects would evaluate as equivalent to a logical AND of those patterns but specifically as applied to a single instance of each Object and considering the specified inter-object relationships. In other words, for the pattern to be true all of the individual property patterns and specified relationships must be true. This approach to composing more complex observables through related objects is often referred to as “relational composition”. More detail on mechanism and use »
condition attribute and field value on each relevant a single object property.
There are also use cases requiring more complex matching logic that may call for the ability to specify patterns that are logical combinations of other observable patterns. STIX/CybOX support this capability through the Observable_Composition structure. Utilizing this structure, you can specify observable patterns that use a logical operator (AND | OR) to compose other observable patterns whether the the component patterns are simple single objects, multiple objects or even other Observable_Compositions themselves (supporting whatever level of composition needed). The evaluation of such patterns follows the explicit operator logic specified and the rules outlined above for object property and relationship patterns. This approach to composing more complex observables through logical combination is often referred to as “logical composition”. More detail on mechanism and use »
(often referred to as “logical composition”)
NOTE: Observables of this form are only valid as patterns and never as instances.
There is also a “shorthand” form of composition of observable patterns for the case where each component pattern consists of a single object property pattern all on the same object property (e.g. an IP watchlist of 100 IP addresses). Specifying this sort of composition is possible using the Observable_Composition form described above but is very space inefficient. To address this issue STIX/CybOX also provide the ability to utilize the approach described above for single properties of single objects but with the small twist of providing a list of possible values for the property pattern rather than just a single one. While semantically equivalent to a full logical composition using the Observable_Composition structure, this form is much more concise and is potentially useful for the specific case of composite patterns with a high degree of overlap on a single property field. More detail on mechanism and use »
NOTE: Observables of this form are only valid as patterns and never as instances.
condition and apply_condition attributes on the property field and the inclusion of a delimiter (by default the delimiter is “##comma##” but can be overridden) separated list of values within the property field body. Show Example
apply_condition attribute. This “list” form of composition can be thought of as a significantly more concise and compact shorthand representation for these semantics. It is especially useful for patterns involving a very large number of potential field values (e.g. an IP watch list).
While the above capabilities exist to specify observable patterns of varying complexity and detail, as “observables” they are all only specifying “factual” patterns without any context for interpretation. This additional context for the observable pattern that gives it meaning (what does it mean if the pattern evaluates “true”?) is provided by the STIX Indicator component. Similar to cases that require the more complex matching logic of composite observable patterns there are also cases that require logical composition of not only observable pattern matching logic but also of the contexts that go with individual observable patterns. To support the need for this sort of composition STIX provides the Composite_Indicator_Expression structure. It mirrors the same structural approach as the Observable_Composition structure with a logical (AND | OR) operator but enables the specification of composite Indicators such that:
Composition of observables directly using CybOX enables the “factual” specification of arbitrarily complex patterns (independent of usage context) for detection but in the end each observable only represents a single condition (as complex as it may be) to evaluate against. The evaluation is an all or nothing boolean (true/false) and offers no potential for partial evaluation matches on the pattern.
Indicators are about characterizing the context for a given potential pattern of observation and are intentionally abstracted from the technical details of specifying the “facts” of the pattern itself. Indicators do not duplicate the underlying capabilities of CybOX to characterize/specify observables but rather layer contexts on top of them. Indicator composition in STIX is a composition of detection contexts each of which at its root has its own (potentially complex) “factual” observable pattern.
A mechanism for Indicator composition is provided in STIX to support three primary use cases that cannot be effectively addressed through direct observable composition in CybOX:
NOTE: At the STIX language level, the complexity of Indicator composition is independent of the complexity of the underlying observable pattern. Each Indicator specifying an observable pattern treats that pattern as a simple boolean condition regardless of complexity.
Composition of Observables directly in CybOX is necessary to enable characterization of complex observations or specification of complex patterns for observation. This function cannot be accomplished at the Indicator composition level as Indicators not only lack the effective structures for complex observable pattern characterization but they are intentionally focused on providing context for the pattern.
Composition of Indicators is necessary to enable characterization of complex composite detection contexts (not just the pattern but also what the pattern means) where the individual sub-contexts of the composition are important and useful. This function cannot be accomplished at the Observable level as Observables are intentionally bound to “factual” characterizations/specifications of observables without contextual meaning to enable their flexible use in a range of differing contexts.
A range of differing levels of detail for composition (as described above) is available in STIX/CybOX and the appropriate level to use should be determined by the context of use.