Re: [cti] Question on indicator patterns

On 16/07/2016 8:24 AM, "John-Mark Gurney" <jmg@newcontext.com> wrote:

Allan Thomson wrote this message on Fri, Jul 15, 2016 at 17:46 +0000:
> 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.

There are issues if they use a third field.. Currently, pattern is a
required field (IMO, it doesn't make sense to make it optional to support
this case when an open vocab makes more sense), which means that either
pattern_lang will not be present, which means a conforming implementaiton
will take pattern to mean a cybox pattern, or we'll have to add other to
the vocab to ensure that a value in pattern_lang exists that conforming
implementations will know to ignore..

The simplist solution is an open vocab, as we expand it in future
revisions as people add support.. Similar to other parts of the
spec...

So, My votes:

1) yes
2) Yes - open vocab

> 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.)
>
>
> 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 <athomson@lookingglasscyber.com<mailto: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.
>
> allan
>
> From: "cti@lists.oasis-open.org<mailto:cti@lists.oasis-open.org>" <cti@lists.oasis-open.org<mailto:cti@lists.oasis-open.org>> on behalf of "Wunder, John" <jwunder@mitre.org<mailto:jwunder@mitre.org>>
> Date: Friday, July 15, 2016 at 9:59 AM
> To: "cti@lists.oasis-open.org<mailto:cti@lists.oasis-open.org>" <cti@lists.oasis-open.org<mailto:cti@lists.oasis-open.org>>
> 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
>

--
John-Mark

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

cti message