[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Re: Observable Patterning
Great post, Terry (I really like the JSON examples :)). A few thoughts from my perspective:
These are all valid scenarios for Indicator-based patterns, for detecting some particular flavor of badness. This is an important distinction, as in my view patterns should be used only for Indicators – in other places, their
semantics are less clear (what do they mean? how should they be used?). It’s also worth noting that in such cases when we’re referring to events, we’re really referring to the corresponding detectable artifacts of the events, such as emails, DNS queries, and
the like.
Option 1: Patterns only in CybOX, removed from STIX
Pros:
Cons:
Option 3: Patterns only in STIX, no CybOX
Personally, this is my preferred option :-) I like to think about it this way:
A binding to CybOX would essentially be a flattened list of CybOX Object fields, for use in patterning. This would be defined against a specific version of CybOX, and would likely exclude fields
(and even possibly Objects) that don’t make sense for detection, such as entities like Process IDs that are temporal and/or non-deterministic in nature. It would also allow us to state exactly what a particular field means in a pattern and how it should be
detected.
Other bindings could then be developed against other, non-CybOX data models. For instance, I know there’s been some discussion in the past on detecting money mule activity – if we had a domain
independent patterning implementation, we could develop a binding against an ACH bank transaction data model (for instance), and use it to express patterns against it.
So as a strawman, in JSON this could look something like (where the type field indicates the CybOX binding):
indicator: { Pros:
Cons:
Regards,
Ivan
From: Terry MacDonald
Date: Tuesday, September 29, 2015 at 2:30 AM To: Mark Davidson Cc: Joep Gommers, Ivan Kirillov, Jerome Athias, Patrick Maroney, Terry MacDonald, "cti@lists.oasis-open.org" Subject: Re: [cti] Re: Observable Patterning I would agree Mark, I do think the topics are intertwined. Even after looking at this for some time, I still couldn't decide whether patterning should sit within CybOX, STIX or both. So I decided to try and take a step back to look at what the
bigger picture.
I decided to look at the type of scenarios that one would want to describe, and see which patterning option would best cover those scenarios. As I see it there are a few major types of scenarios one would want to capture using patterns:
I used the above scenarios along with the following guidance found within the STIX and CybOX sites:
I then tried to pull these together to describe the 3 different options we have for where patterns sit.
At this point, I prefer Option 1, but I would like to see what others think.
-----
Option 1: Patterns only in CybOX, removed from STIX
This option changes the Indicator object to only have a single Cybox Pattern description in it. That single pattern contains as little or as much information in it to describe the scenarios listed above. Using the great posts within the Github issue (https://github.com/CybOXProject/schemas/issues/381)
I've attempted to describe the 4 scenarios I listed earlier using a JSON style notation, as if the patterns and sequencing was done within CybOX. THe resulting psuedo code is below. Please note: The cybox patterns would all sit within a STIX Indicator object.
I haven't put the STIX Indicator in the psuedo code.
Single item:
id: id1,
objects: [{ id: obj1
type: DomainObject
properties: [{
path: /type
condition: EQUALS
value: FQDN
},{
path: /value
condition {
obj1
}
}
Single regex:
pattern: {
id: id2,
objects: [{ id: obj1
type: DomainObject
properties: [{
path: /type
condition: EQUALS
value: FQDN
},{
path: /value
condition: MATCHES
value: xx3\[a-b]{3}.*\.com
}]
}],
condition {
obj1
}
}
Group of Patterns:
pattern: {
id: id3,
objects: [{ id: obj1
type: FileObject
properties: [{
path: /hashes/hash/simple_hash_value
condition: EQUALS
value: c38862b4835729d979e7940d72a48172
},{
id: obj2
type: FileObject
properties: [{
path: /filename
condition: CONTAINS
value: malicious.dll
}]
}],
condition {
obj1 OR obj2
}
}
Sequence of Group of Patterns:
pattern: {
id: id4,
objects: [{ id: obj1
type: DomainObject
properties: [{
path: /type
condition: EQUALS
value: FQDN
},{
path: /value
condition {
obj1
}
},
pattern: {
id: id5,
objects: [{ id: obj1
type: FileObject
properties: [{
path: /hashes/hash/simple_hash_value
condition: EQUALS
value: c38862b4835729d979e7940d72a48172
},{
id: obj2
type: FileObject
properties: [{
path: /filename
condition: CONTAINS
value: malicious.dll
}]
}],
condition {
obj1 OR obj2
}
},
pattern_sequence: {
id: seqid1,
sequence: [{
idref: id4,
order: 1
},{
idref: id5,
order: 2,
after: PT5S #ISO8601 duration standard format (after 5 secs)
within: PT1M #ISO8601 duration standard format (within
}]
}
Pros:
Cons:
-----
Option 2: Patterns only in STIX, uses CybOX as it is used now
This option reuses the Indicator object's Observable Composition as the thing that offers the patterning. This is trying to use the existing way of doing things but in a pattern style. Using a JSON style notation, the resulting psuedo code is below. Please
note, there isn't any way of sequencing indicators easily at present within STIX, so I took the liberty of adding the indicator_sequence section (although there is bound to be a better way of doing it). There are Observable Events/Actions that could be used
instead to potentially describe the temporal nature of the indicator sequence but I couldnt work out how to make that easily discernable.
Single item:
indicator: {
id: id1,
observable: {
object: [{
id: obj1
type: DomainObject
properties: [{
path: /type
condition: EQUALS
value: FQDN
},{
path: /value
}
}
Single regex:
indicator: {
id: id2,
observable: {
object: [{
id: obj1
type: DomainObject
properties: [{
path: /type
condition: EQUALS
value: FQDN
},{
path: /value
condition: EQUALS
value: xx3\[a-b]{3}.*\.com
}]
}],
}
}
Group of Patterns:
indicator: {
id: id3,
observable: {
observable_composition: {
operator: OR
observable: {
object: {
id: obj1
type: FileObject
properties: [{
path: /hashes/hash/simple_hash_value
condition: EQUALS
value: c38862b4835729d979e7940d72a48172
}]
}
},
observable: {
object: {
id: obj1
type: FileObject
properties: [{
path: /hashes/hash/simple_hash_value
condition: EQUALS
value: c38862b4835729d979e7940d72a48172
}]
}
}
}
}
}
Sequence of Group of Patterns:
indicator: {
id: id4,
observable: {
object: [{
id: obj1
type: DomainObject
properties: [{
path: /type
condition: EQUALS
value: FQDN
},{
path: /value
condition: EQUALS
value: xx3\[a-b]{3}.*\.com
}]
}],
}
},
indicator: {
id: id3,
observable: {
observable_composition: {
operator: OR
observable: {
object: {
id: obj1
type: FileObject
properties: [{
path: /hashes/hash/simple_hash_value
condition: EQUALS
value: c38862b4835729d979e7940d72a48172
}]
}
},
observable: {
object: {
id: obj1
type: FileObject
properties: [{
path: /hashes/hash/simple_hash_value
condition: EQUALS
value: c38862b4835729d979e7940d72a48172
}]
}
}
}
}
},
indicator_sequence: {
id: seqid1,
sequence: [{
idref: id4,
order: 1
},{
idref: id5,
order: 2,
after: PT5S #ISO8601 duration standard format (after 5 secs)
within: PT1M #ISO8601 duration standard format (within
}]
}
Pros:
Cons:
-----
Option 3: Patterns only in STIX, no CybOX
This option would make patterns only in the STIX Indicator object and not use CybOX objects at all, which in my opinion is wrong. So I didn't even bother fleshing out that scenario :).
Cheers
Terry MacDonald | STIX, TAXII, CybOX Consultant Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those
of my employers.
On 29 September 2015 at 02:34, Davidson II, Mark S
<mdavidson@mitre.org> wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]