OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti-comment] STIX 2.1 comment - Comparison expression on SCO


There is an important nuance we have to be extremely cognizant of here.

STIX Patterns *do not* match against SCO objects, *at all*. They match against Observations, in the general sense.

SCO is the language we use inside a pattern, to represent those observations. But the actual matching *is not* being made against SCO.

This is a small but very important nuance because it has numerous implementation ramifications and if you say it the wrong way, it limits the usefulness of STIX patterning as a whole.

Given this...

- I do not agree with the suggested change in isolation;

- *However* I think we need to take a closer look at what has happened in the patterning spec in 2.1, because the term "SCO" is now everywhere in it, where it was not in 2.1. Without giving it a complete and thorough review yet, this fact gives me great pause as I suspect there are a lot of places we may need to correct here. I am going to try to take a swath through this this weekend.


-
Jason Keirstead
Chief Architect - IBM Security Threat Management
www.ibm.com/security

"Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure."

- Thomas J. Watson




From:        David Bizeul <david.bizeul@sekoia.fr>
To:        cti-comment@lists.oasis-open.org
Date:        09/12/2019 02:33 PM
Subject:        [EXTERNAL] [cti-comment] STIX 2.1 comment - Comparison _expression_ on SCO
Sent by:        <cti-comment@lists.oasis-open.org>




Hello,

The table of section "9.6 Comparison Expressions" might have a mistake. The last sentence of the description of the boolean operator "AND" should read:
"a and b MUST both evaluate to true on the same SCO"
instead of "a and b MUST both evaluate to true on the same Observation"
Indeed as mentioned in "9.5 Observation Expressions": "When matching an Observation against an Observation _expression_, all Comparison Expressions contained within the Observation _expression_ MUST match against the same SCO", and "Observation" is defined as an Observed Data SDO in "9.1 Definitions".

Which leads me to a second remark: it is possible to put constraints on single SCOs (via Observation Expressions) and multiple observations (via Observation Operators) but not on multiple SCOs corresponding to the same observation if they can not be linked by existing properties.

As a consequence how can one match observations that associate a "user-account" to a "file" or a "user-account" to a "network-traffic" independantly of the relationship path?

Another example is two subnets that should never be seen together. One could write:
[(network-traffic:src_ref.value ISSUBSET 10.10.10.0/24 AND network-traffic:dst_ref.value ISSUBSET 10.10.20.0/24) OR (network-traffic:src_ref.value ISSUBSET10.10.20.0/24 AND network-traffic:dst_ref.value ISSUBSET 10.10.10.0/24)]

But then I miss network-traffic:src_ref.resolves_to_refs[*].value and all its variants. Enumerating all the possible relationships seems cumbersome and error-prone. 
An idea for a later version: wouldn't it be more simple to write something like:
{ipv4-addr:value ISSUBSET 10.10.10.0/24 AND ipv4-addr:value ISSUBSET 10.10.20.0/24}
Since they are in the same observation, one already know they are linked.

Best regards

--
David Bizeul
CTO @ SEKOIA







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]