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


I don't really see Test_Mechanisms as a candidate for reusing the patterning that we've been discussing. Each Test_Mechanism rule is a rule derived from the Indicators, and written in the tools native language. It doesn't make sense to me to have  patterning in the Test_Mechanism unless it is natively in the tool that uses the rules.

I do think that patterning makes more sense residing within the STIX Indicator object (and moving Observable Instances to a new top-level Sighting object), and then using a top-level relationship object to record the relationship between the patterned STIX Indicator object and the STIX Test_Mechanism.

Cheers

Terry MacDonald | STIX, TAXII, CybOX Consultant




Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

On 24 September 2015 at 23:30, Kirillov, Ivan A. <ikirillov@mitre.org> wrote:
In order for a pattern to be specified in a STIX Indicator (e.g., ‘IP Address in 1.2.3.4/24’), would the pattern would need to use fields from a CybOX object? If the answer is yes, does that create a hard dependency between STIX Indicator and a particular CybOX object and version?

Having a separate patterning structure would mean that we would somehow need to reference CybOX Object fields, and unless we completely decouple CybOX from STIX Indicators (this seems unlikely, though I believe there have been a few suggestions to this effect), there would indeed be a hard dependency between a STIX Indicator and a particular CybOX Object version. This is necessary to explicitly specify the semantics of “what” the Indicator is looking for. 

What about consistency with other uses of STIX Indicator? Consider a SNORT signature or YARA rule – patterning is contained in those signatures and wouldn’t be at the STIX Indicator level, which seems inconsistent to me.

This seems to be more of an issue with how different types of patterns are captured in STIX Indicators. CybOX-based patterns are currently represented as a separate entity, whereas other types of patterns (SNORT, YARA, etc.) are captured as Test_Mechanisms. Given their functional overlap, it may make more sense to have a single “Pattern” field that can be extended to capture CybOX-based patterns, SNORT rules, YARA sigs, etc.

Regards,
Ivan

From: Mark Davidson
Date: Thursday, September 24, 2015 at 9:06 AM
To: Trey Darley, Ivan Kirillov, "cti@lists.oasis-open.org"
Subject: RE: Observable Patterning

What implication would patterning in STIX Indicators have for the relationship between STIX Indicators and CybOX objects?

 

In order for a pattern to be specified in a STIX Indicator (e.g., ‘IP Address in 1.2.3.4/24’), would the pattern would need to use fields from a CybOX object? If the answer is yes, does that create a hard dependency between STIX Indicator and a particular CybOX object and version?

 

What about consistency with other uses of STIX Indicator? Consider a SNORT signature or YARA rule – patterning is contained in those signatures and wouldn’t be at the STIX Indicator level, which seems inconsistent to me.

 

> Patterning should live in _one_ place and have _one_ syntax.

I really like this idea, and I’m asking questions that I hope will lead us in this direction.

 

Thank you.

-Mark

 

From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Trey Darley
Sent: Thursday, September 24, 2015 4:30 AM
To: Kirillov, Ivan A. <ikirillov@mitre.org>; cti@lists.oasis-open.org
Subject: [cti] Re: Observable Patterning

 

+100, Ivan.

 

Patterning should live in _one_ place and have _one_ syntax.

 

I tend to think the STIX Indicator level is the right place for this to live.

 

Cheers,

Trey

--

Trey Darley

Senior Security Engineer

Soltra | An FS-ISAC & DTCC Company

 


From:cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Kirillov, Ivan A. <ikirillov@mitre.org>
Sent: Monday, September 21, 2015 19:47
To:
cti@lists.oasis-open.org
Subject: [cti] Observable Patterning

 

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).

 

 

Regards,

Ivan




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