Re: [cti] Agenda for Tuesdayâs call

["Emily Ratliff" <Emily.Ratliff@ibm.com>]

Here are notes from
todays working group meeting. As always, corrections are welcomed.




Emily Ratliff
STSM, Security Architect
Office of the CTO
1 512 653 1052 Mobile
1 512 286 9947 Office
emily.ratliff@ibm.com
IBM Security



From:
       Bret
Jordan <Bret_Jordan@symantec.com>
To:
       Jason
Keirstead <Jason.Keirstead@ca.ibm.com>, "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org>
Date:
       09/28/2019
10:02 AM
Subject:
       [EXTERNAL]
[cti] Agenda for Tuesdayâs call
Sent
by:        <cti@lists.oasis-open.org>

---

All, 

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

Bret 

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

But then I miss network-traffic:src_ref.resolves_to_refs[*].valueand 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/24AND 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

Attachment: CTI-WorkingCall-MeetingNotes-2019-10-01.pdf
Description: Adobe PDF document