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: Re: [cti] Observable Patterning


Um, nobody is suggesting that the CybOX 2.x / STIX 1.x standards are going to be deleted from the internet, guys.


DFAX, MAEC, et al are *not* OASIS standards. If we're going to constrain what with do inside OASIS based on the perceived needs of non-OASIS standards, then we're doomed.


I could just as easily make up a standard (call it FooBAR), define it in such a way that it relies on some totally whacky STIX construct that everybody else wants to eliminate in STIX 2.0, and suddenly, what, OASIS-CTI is going to be magically constrained because my random standard uses something weird nobody else cares about?


No thanks! The DFAX, MAEC, et al communities are more than welcome to a) join OASIS and voice their own arguments or b) continue using the CybOX 2.x / STIX 1.x standards as the exist today.


Cheers,
Trey
--
Trey Darley
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company
www.soltra.com



From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Sent: Monday, September 21, 2015 20:04
To: Kirillov, Ivan A.
Cc: cti@lists.oasis-open.org
Subject: Re: [cti] Observable Patterning
 

"Regarding 2), it seems to me that patterning is inherent to Indicators, and thus should be part of STIX. I just can’t see the use case for a CybOX Observable with a pattern that stands on its own, or is used in a non-Indicator context. This would also serve to greatly simplify CybOX, as it would mean that CybOX can ONLY capture instances of cyber data.
"

While I tend to agree, I am curious if moving patterning to the Indicator level (which implies removing existing patterning from CybOX) would affect other non-STIX uses of CybOX (such as the DFAX standard I recently found out about). If the non-STIX users of CybOX also need patterning, then it seems to push for patterning to be part of CybOX, not STIX.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Inactive hide details for "Kirillov, Ivan A." ---09/21/2015 02:47:51 PM---Relaunching this as a separate thread based on Jerome"Kirillov, Ivan A." ---09/21/2015 02:47:51 PM---Relaunching this as a separate thread based on Jerome’s suggestion, so as to not further hijack the

From: "Kirillov, Ivan A." <ikirillov@mitre.org>
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 09/21/2015 02:47 PM
Subject: [cti] Observable Patterning
Sent by: <cti@lists.oasis-open.org>





Relaunching this as a separate thread based on Jerome’s suggestion, so as to not further hijack the discussion around Bernd’s suggested refactoring.

I think there are a few broad questions around this topic that we can touch upon here:

1. What capabilities should STIX/CybOX patterning have?
2. Where should STIX/CybOX patterning live?
3. Should patterns have their own implementation/structure, or continue to be embedded in Observables/Objects?

As far as 1) I would say the following, as a straw man:

* Conditional operators
* AND
* OR
* NOT
* Basic temporal operators
* FOLLOWED_BY
* WITHIN
* String matching
* EQUALS
* DOES_NOT_EQUAL
* CONTAINS
* DOES_NOT_CONTAIN
* Basic arithmetic operators
* >
* <
* >=
* <=
* Regular Expressions
* PCRE compatible
* Variable substitution

Regarding 2), it seems to me that patterning is inherent to Indicators, and thus should be part of STIX. I just can’t see the use case for a CybOX Observable with a pattern that stands on its own, or is used in a non-Indicator context. This would also serve to greatly simplify CybOX, as it would mean that CybOX can ONLY capture instances of cyber data.

With regards to 3), I see lots of advantages to having a separate structure for patterns, which I’ve documented in the corresponding CybOX issue [1]. The short of it is that it will get rid of the instance/pattern duality, allow for the creation of a domain-specific patterning language (necessary for more complex pattern expressions), and also give us the flexibility to move patterning out to wherever makes the most sense (whether it’s STIX or somewhere else).

[1] https://github.com/CybOXProject/schemas/issues/381
Separate Patterns and Instances in CybOX Observables and Objects · Issue #381 · CybOXProject/schemas
Currently, a CybOX Observable, in combination with an Object, can define either an observed instance of some data (e.g., a file), or a pattern for detecting some data. While this duality has its us...



Regards,
Ivan



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