RE: [cti-stix] RE: Indicators and patterning

I would think that the STIX pattern should always be required, as it's native to the protocol. We could then change the name of the field that lists other pattern types to something like additional_patterns and make it optional.

On 26 Oct. 2016 11:29 am, "Wunder, John A." <jwunder@mitre.org> wrote:

Sorry not sure I'm following exactly what you're proposing...

Will a STIX pattern still be required for all indicators? Will we define the YARA and Snort fields for 2.0?

If you use only a STIX pattern, can we make the pattern types property optional?

We would lose the ability to specify pattern versions with this approach...do we need to specify additional structure to do so?

Since an indicator can now have more than one pattern we need some text to call out how they're related (are they alternatives? do they need to test for the same exact things? Is one preferred?)

John

From: Bret Jordan (CS) <Bret_Jordan@symantec.com>

Date: Tuesday, Oct 25, 2016, 6:16 PM

To: Allan Thomson <athomson@lookingglasscyber.com>, Wunder, John A. <jwunder@mitre.org>, Back, Greg <gback@mitre.org>, cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org>

Subject: Re: [cti-stix] RE: Indicators and patterning

I can go for that... A much cleaner solution than what we have now.

Bret

From: Allan Thomson <athomson@lookingglasscyber.com>
Sent: Tuesday, October 25, 2016 3:39:42 PM
To: Bret Jordan (CS); Wunder, John A.; Back, Greg; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] RE: Indicators and patterning

So we’re agreeing J

Keep the included patterns identifier and have a specific content attribute for each pattern included.

allan

From: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
Date: Tuesday, October 25, 2016 at 2:29 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, "Wunder, John" <jwunder@mitre.org>, "Back, Greg" <gback@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] RE: Indicators and patterning

This is very similar to what I was proposing...

{

"type": "indicator",

...,

"pattern" : "<some STIX cyber observable pattern>",

...

}

Then in the future if we decide we really do want to support Yara or SNORT or OpenIOC then we can add something like:

{

"type": "indicator",

...,

"included_patterns": [ "stix", "yara"],

"pattern" : "<some STIX cyber observable pattern>",

"yara": "<some yara pattern>",

...

}

Or if you just wanted to send SNORT in the future you could do:

{

"type": "indicator",

...,

"included_patterns": [ "snort"],

"snort": "<some yara pattern>",

...

}

The nice thing about this design, IMHO, is it follows our custom properties model. This allows vendors to easily expand what they support and do, without having to worry about the "pattern-lang-ov" open vocabulary and should make it easier for us to "add" properties in the future. It also allows us to build a model in the future where a single Indicator may include multiple patterns in different languages at the same time.

As I start coding APIs and tools to work with STIX 2.0, I am finding things that I want to shine a big light on.

Bret

From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Sent: Tuesday, October 25, 2016 3:18:51 PM
To: Wunder, John A.; Back, Greg; Bret Jordan (CS); cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] RE: Indicators and patterning

I suggest that if you remove the identifier field that states what field is used then in future if others want to convey alternate fields such as yara, snort….etc then how does a recipient know which field should be used? It also has the problem that it forces cybox field to be always be included when this might not be relevant.

It comes back down to the fact that you would still need something to say ‘use the yara field instead of the cybox pattern field’. Similarly if someone is using yara by forcing producers to generate cybox pattern content when its not used or necessary for a use case is wasteful and inefficient.

Upon reflection, I suggest we keep a field pattern_lang is a list that identifies what content is provided where the values has { cybox-pattern } for now and in future if yara or snort content is produced then those additional fields can be added.

So

Object 1 {

Pattern_provided: [ “cybox” ]

Cybox_pattern: <cybox pattern string>

}

Object 2 {

Pattern_provided: [ “snort” ]

Snort_pattern: <snort pattern string>

}

Object 3 {

Pattern_provided: [ “cybox”, “snort” ]

Cybox_pattern: <cybox pattern string>

Snort_pattern: <snort pattern string>

}

allan

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org>
Date: Tuesday, October 25, 2016 at 1:49 PM
To: "Back, Greg" <gback@mitre.org>, "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] RE: Indicators and patterning

I think this would be a re-evaluation of whether we think it’s valuable to be able to use Snort and YARA patterns instead of STIX Patterns in Indicators. At the time, we opened this up as an extension because we felt that people would want to, for example, write a Yara pattern and use that in an indicator that they link to some malware. Yara, Snort, and OpenIOC are very popular languages for sharing IOCs, after all -- more so than STIX. IMO the merge of STIX and CybOX into a single Work Product doesn’t really change that reasoning.

That said I was always relatively ambivalent on this point, so if consensus is to remove them I wouldn’t object too much.

John

From: <cti-stix@lists.oasis-open.org> on behalf of Greg Back <gback@mitre.org>
Date: Tuesday, October 25, 2016 at 4:21 PM
To: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] RE: Indicators and patterning

I think getting rid of pattern_lang and pattern_lang_version makes sense (and assume pattern-lang-ov would go away as well). My only concern with using custom properties is that if “pattern” field is required, I’m not sure what would go in that field for other types of indicators.

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Bret Jordan (CS)
Sent: Tuesday, October 25, 2016 1:36 PM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Indicators and patterning

All,

When we started really working on STIX 2.0 we had this idea that CybOX was going to be separate and we should treat it as a separate thing entirely.. This unfortunately caused us to make some design decisions in STIX to reflect this artificial line in the sand we had drawn. Fast forward 10 months and we have now merged STIX and CybOX and during this merge we have been able to clean up some of the weirdness that existed with the artificial line in the sand.

There is however, one thing that is still in the specification, that we did because of this separation that I would personally like to us get rid of.

In Indicators we created the following 3 fields to address the artificial separation:

pattern

pattern_lang

pattern_lang_version

The idea was if we are going to support CybOX as a separate "thing" we might also want to support "other" things. I would suggest at this stage we drop support for "other" things and just have a single "pattern" property.

If people want to do YARA or SNORT, they can do it via a custom property. And if we find in a later release that lots of people want to support YARA or SNORT we can then create properties for them.

Bret

cti-stix message