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
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: David Bizeul <david.bizeul@sekoia.fr>
- Date: Fri, 27 Sep 2019 15:49:26 -0300
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]