OASIS Cyber Threat Intelligence (CTI) TC

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

Why not just add CybOX patterning to the list of enumerations? Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org On Fri, Jul 15, 2016 at 12:59 PM -0400, "Wunder, John A." < jwunder@mitre.org > wrote: 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

Right now it’s in the pattern type list and is also the default value of the pattern_type field. So, yes.
 
The questions are kind of higher-level, asking how much we should force tools to do things our way:
1.       
Should implementing CybOX Patterning be required for tools that want to claim they processes STIX indicators?
2.       
Should we allow for pattern types to be used that are not explicitly listed in the specification?
 

From: Patrick Maroney <Pmaroney@Specere.org>
Date: Friday, July 15, 2016 at 1:08 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>
Subject: Re: [cti] Question on indicator patterns


 




Why not just add CybOX patterning to the list of enumerations?

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org

 





On Fri, Jul 15, 2016 at 12:59 PM -0400, "Wunder, John A." < jwunder@mitre.org > wrote:



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

Thanks John. .02: 1. Should implementing CybOX Patterning be required for tools that want to claim they processes STIX indicators?:  No.   Suggest this "claims" aspect be part of "Profiles" (this term is intended in the sense of other standards: e.g. KMIP Profiles vs. the legacy STIX Profiles context). 2. Should we allow for pattern types to be used that are not explicitly listed in the specification?: Yes. I think we should allow for extensibility.  I don't want to go down the "rabbit-hole", but for example one might want to express analytic/statistical patterns.  Allowing this would enable us to experiment and bring forth and demonstrate practical applications for consideration in future versions of the standards. Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org _____________________________ From: Wunder, John A. < jwunder@mitre.org > Sent: Friday, July 15, 2016 1:14 PM Subject: Re: [cti] Question on indicator patterns To: Patrick Maroney < pmaroney@specere.org >, < cti@lists.oasis-open.org > Right now it’s in the pattern type list and is also the default value of the pattern_type field. So, yes.   The questions are kind of higher-level, asking how much we should force tools to do things our way: 1.        From: Patrick Maroney < Pmaroney@Specere.org > Date: Friday, July 15, 2016 at 1:08 PM To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, "Wunder, John A." < jwunder@mitre.org > Subject: Re: [cti] Question on indicator patterns   Why not just add CybOX patterning to the list of enumerations? Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org   On Fri, Jul 15, 2016 at 12:59 PM -0400, "Wunder, John A." < jwunder@mitre.org > wrote: 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

I think vote Yes to #1 but I prefer Open Vocabulary to #2. I don't like the idea of us having a closed pattern vocabulary and then us also arbitrarily electing to include Snort and YARA in it, as it feels like we are making an endorsement of those two patterning grammars - at the end of the day, although are widely used, are both proprietary (not based on an any actual standard, open or closed). - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Patrick Maroney ---07/15/2016 02:08:42 PM---Why not just add CybOX patterning to the list of enumerations? Patrick Maroney From: Patrick Maroney <Pmaroney@Specere.org> To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org> Date: 07/15/2016 02:08 PM Subject: Re: [cti] Question on indicator patterns Sent by: <cti@lists.oasis-open.org> Why not just add CybOX patterning to the list of enumerations? Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org On Fri, Jul 15, 2016 at 12:59 PM -0400, "Wunder, John A." < jwunder@mitre.org > wrote: 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