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.
allan
From:
"Jordan, Bret" <>
Date: Friday, July 15, 2016 at 10:43 AM
To: Allan Thomson <>
Cc: "Wunder, John" <>, "" <>
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.)
Thanks,
Bret
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 <> 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.
allan
From: ""
<> on behalf of "Wunder, John" <>
Date: Friday, July 15, 2016 at 9:59 AM
To: "" <>
Subject: [cti] Question on indicator patterns
All,
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.
Link to indicator: https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.muftrcpnf89v
John
