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] Question on indicator patterns

Hi Bret – I know that folks can create their own fields. My philosophy is to embrace the likelihood that other enumerations will happen therefore support the option of an ov choice rather than fight it.




From: "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Friday, July 15, 2016 at 10:43 AM
To: Allan Thomson <athomson@lookingglasscyber.com>
Cc: "Wunder, John" <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Question on indicator patterns


My opinion:


1 - Yes

2 - No (if someone wants to do something else, they can create their own field.)  









Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

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

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 


On Jul 15, 2016, at 11:27, Allan Thomson <athomson@lookingglasscyber.com> wrote:


My vote.


#1 – yes


rationale: CyBox is effectively required for STIX already and not requiring it for this specific aspects is missing the point on CyBox+STIX.


#2 – yes


rationale: ov’s can provide the enumeration but we should allow organizations flexibility to include patterns or grammars that advance the field beyond what is considered possible without having to rev the STIX or CyBox specs. We should not be so closed minded that improvements in this area are not possible. We should embrace innovation and support it without requiring revs of the spec.




From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org>
Date: Friday, July 15, 2016 at 9:59 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Question on indicator patterns




A couple questions about indicator patterns have come up and we could use some further thoughts on them.


For background, each STIX Indicator contains a single pattern, of a specified pattern type. Right now, the default pattern type is CybOX and CybOX patterns are considered “mandatory to implement” for STIX indicator consumers. The other set of pattern languages that are allowed are contained in a closed enumeration (i.e. they cannot be extended)…the only two other than CybOX are Snort and YARA. So, I have two questions for you:


1.      Should CybOX Patterning be “mandatory to implement” for STIX indicator consumers? The impact of this would be that tools that do STIX indicators but not CybOX patterning (i.e. they only accept Snort rules) would not be considered STIX compliant.

2.      Should the pattern lang list be an open vocabulary that tools can add to? In other words, if somebody wants to put some pattern type in that field that we haven’t explicitly listed, should they be able to?


My thoughts are:


1.      Yes, CybOX patterning should be MTI. We need to do more work on the CybOX patterning side to define what it means to conform to it but at a high-level I think it should be MTI.

2.      No, we should hardcode an enumeration…for such a key part of the indicator (useless without it), we need to have a well-defined and well-known list. If people want to do something other than what we pre-define they should either use a custom field or it shouldn’t be considered STIX.





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