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


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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

Subject: Agenda for Tuesdayâs call


This is just a reminder that we will be talking about this issue specifically, on Tuesdayâs working call.


Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

On Sep 27, 2019, at 12:50 PM, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

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

"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>


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 AND network-traffic:dst_ref.value ISSUBSET OR (network-traffic:src_ref.value ISSUBSET10.10.20.0/24 AND network-traffic:dst_ref.value ISSUBSET]

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 AND ipv4-addr:value ISSUBSET}
Since they are in the same observation, one already know they are linked.

Best regards

David Bizeul

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