OASIS Cyber Threat Intelligence (CTI) TC

 View Only
Expand all | Collapse all

Re: [cti] Question on indicator patterns

  • 1.  Re: [cti] Question on indicator patterns

    Posted 07-15-2016 17:28




    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" <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


     



    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








  • 2.  Re: [cti] Question on indicator patterns

    Posted 07-15-2016 17:44
    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 > 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 < 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   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 Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail


  • 3.  Re: [cti] Question on indicator patterns

    Posted 07-15-2016 17:46




    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" <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 > 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 "
    < 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




     





    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






     









  • 4.  Re: [cti] Question on indicator patterns

    Posted 07-15-2016 20:25
    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


  • 5.  Re: [cti] Question on indicator patterns

    Posted 07-15-2016 23:25
    Hi All, My opinion is 1. Yes 2. Yes Both for the reasons stated by others in the affirmative in earlier responses. Cheers Terry MacDonald Cosive 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


  • 6.  Re: [cti] Question on indicator patterns

    Posted 07-16-2016 06:10




    Since this thread got bifurcated, I’m inserting my earlier comments below.  This is followed by a question and Use Case Example.
     
    “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.”
     
     
    Question :
     

    Since a STIX indicator can use multiple
    pattern_lang(s) in addition to
    CybOX, why should an implementation be required to implement CybOX Patterns to be compliant? 


     

     
    Use Case Example:
     

    Analysts from the ACME ISAC member organizations crowd-source the development and inter-exchange of Yara and ClamAV signatures via the ACME ISAC collaboration portal. Over time these signatures
    provide increasingly high fidelity detections of new variants of 0Day exploits in attachments, MIME multipart-message subtypes, embedded links, etc.  Based on the proven success of these signatures, some ACME ISAC members collectively developed custom hardened
    external mail gateways to process all incoming email messages and attachments.  They used a combination of open source projects including Yara and ClamAV).  An increasing percentage of ISAC member organizations are implementing similar in-house capabilities. 


     

    Although analysts and security operations staff receive immediate email notifications of new/modified Yara and ClamAV signatures, each organization has to login, review, manually download these
    signatures from the central ACME ISAC portal, and then transfer them to their custom external mail gateways.   Any delay in the download and operationalization of these new APT 0Day Yara and ClamAV signatures can result in completely missing the initial wave(s)
    of 0Day attacks.  This scenario often results in 100s to 1,000s of compromised systems, adversary entrenchment, etc., vs. stopping the attack at the perimeter early in the kill-chain.  In the ACME sector, minutes can make the difference between a non-event
    and a multi-million-dollar incident.

     

    ACME members want to use the CTI STIX andTAXII Standards via the
    ACME ISAC TAXII Central Gateways
    to automatically publish new high value, high priority, ClamAV and Yara signatures to their ISAC Membership via TAXII Feeds.  They only want to add the STIX and TAXII python code to their
    custom external mail gateways required to (1) subscribe to the ClamAV and Yara Feeds and (2) automatically deploy new/updated signatures.

     

     
    [
     {
       "type": "indicator",
       "id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",
       "created": "2016-04-06T20:03:48Z",
       "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",
       "title": " Poison Ivy ClamAV Sig Example ",
       "description": " Backdoor.PoisonIvy.DX ",
       "pattern":" Find.ClamAV.StartAt.300;Engine:81255,Target:0;3;616c696e;62773238;636564;300:0&1&2/clamav/r ",
       "pattern_lang": " ClamAV ",
       "valid_from": "2016-01-01T00:00:00Z"
     },
     {
       "type": "relationship",
       "id": "relationship--44298a74-ba52-4f0c-87a3-1824e67d7fad",
       "created": "2016-04-06T20:06:37Z",
       "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",
       "source_ref": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",
       "target_ref": "malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b",
       "kind_of_relationship": "indicates"
     },
     {
       "type": "malware",
       "id": "malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b",
       "created": "2016-04-06T20:07:09Z",
       "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",
       "title": "Poison Ivy"
     }
    ]

     

    By establishing Development TAXII Feeds, ACME ISAC can now also automatically publish and crowd-source testing of new signatures across a diverse set of ACME ISAC member environments.  This greatly
    accelerates iterations through the development lifecycle and the delivery of high quality, fully vetted signatures.

     

    Since they’re using CTI STIX and TAXII Standards, those ACME ISAC members requiring an intermediary process before operationalizing the signatures can implement their own custom workflows/code to
    process the ACME ISAC TAXII Feeds.  They can then publish via TAXII to their external mail gateways when approved.

     

     

    ACME ISAC manually shares select signatures with other external trusted entities. In some cases, they use trusted entities to strip attribution and re-publish signatures to other sectors or publicly. 
    This manual sharing of signatures consumes resources, delays dissemination, and complicates tracking, version control, etc.  Most of these trusted entities have operational TAXII Gateways or can process STIX Packages sent via secure Email.  ACME ISAC wants
    to use CTI STIX and TAXII Standards to automatically publish these high value ClamAV and Yara signatures via TAXII Feeds to these trusted entities.  By using the CTI STIX and TAXII Standards, all they need to do on their end is establish the Feeds.

     

     

    The authors of current tools that analyze and convert artifacts into
    non-CybOX pattern_lang signatures (e.g., Yara, ClamAV) can provide CTI Standards compliant frameworks that enable everyone to automatically consume artifacts and publish signatures via STIX and TAXII.


     

     
    Summary:
     

    In this real-world Use Case, the
    ACME ISAC Central TAXII Gateway s need to be “Full Service” implementations (including CybOX support). However,
    the end points (1) custom external mail gateways and (2) tools to create ClamAV and YARA  Signatures, do not. 


     

    Why should the stakeholders at the edges of this Artifact è Analsysis è Signature è Operationalization
    Chain have to implement the extra code required to process CybOX objects and patterns? 


     

    From both a Reliability and
    Security perspective, we should allow, in fact encourage , agents to implement
    only those functions required to fulfill their specific role(s) in the CTI TC Standards Ecosystem. 

     
     



    Patrick Maroney



     





     











  • 7.  Re: [cti] Question on indicator patterns

    Posted 07-17-2016 20:50
    Maybe this is where we need to separate the STIX certification into different categories to enable that differentiation to be recorded? Full STIX compliance: full STIX including full CybOX objects and patterning. Partial STIX compliance:  STIX implementation of more than the specialized STIX compliance but not a full implementation of all parts of STIX. Specialized STIX compliance: STIX and CybOX only focused on a specific subset of the language, and designed for a single purpose. For a full STIX implementation I would expect the platform to implement the CybOX patterning. For a specialized STIX implementation I would expect it to only be implemented if it was required in that instance. And as for allowing extensions to the list of signatures/patterns, I agree that's a good idea. Cheers Terry MacDonald Cosive On 16/07/2016 6:10 PM, "Patrick Maroney" < Pmaroney@specere.org > wrote: Since this thread got bifurcated, I’m inserting my earlier comments below.  This is followed by a question and Use Case Example.   “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.”     Question :   Since a STIX indicator can use multiple pattern_lang(s) in addition to CybOX, why should an implementation be required to implement CybOX Patterns to be compliant?      Use Case Example:   Analysts from the ACME ISAC member organizations crowd-source the development and inter-exchange of Yara and ClamAV signatures via the ACME ISAC collaboration portal. Over time these signatures provide increasingly high fidelity detections of new variants of 0Day exploits in attachments, MIME multipart-message subtypes, embedded links, etc.  Based on the proven success of these signatures, some ACME ISAC members collectively developed custom hardened external mail gateways to process all incoming email messages and attachments.  They used a combination of open source projects including Yara and ClamAV).  An increasing percentage of ISAC member organizations are implementing similar in-house capabilities.    Although analysts and security operations staff receive immediate email notifications of new/modified Yara and ClamAV signatures, each organization has to login, review, manually download these signatures from the central ACME ISAC portal, and then transfer them to their custom external mail gateways.   Any delay in the download and operationalization of these new APT 0Day Yara and ClamAV signatures can result in completely missing the initial wave(s) of 0Day attacks.  This scenario often results in 100s to 1,000s of compromised systems, adversary entrenchment, etc., vs. stopping the attack at the perimeter early in the kill-chain.  In the ACME sector, minutes can make the difference between a non-event and a multi-million-dollar incident.   ACME members want to use the CTI STIX andTAXII Standards via the ACME ISAC TAXII Central Gateways to automatically publish new high value, high priority, ClamAV and Yara signatures to their ISAC Membership via TAXII Feeds.  They only want to add the STIX and TAXII python code to their custom external mail gateways required to (1) subscribe to the ClamAV and Yara Feeds and (2) automatically deploy new/updated signatures.     [  {    "type": "indicator",    "id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",    "created": "2016-04-06T20:03:48Z",    "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",    "title": " Poison Ivy ClamAV Sig Example ",    "description": " Backdoor.PoisonIvy.DX ",    "pattern":" Find.ClamAV.StartAt.300;Engine:81255,Target:0;3;616c696e;62773238;636564;300:0&1&2/clamav/r ",    "pattern_lang": " ClamAV ",    "valid_from": "2016-01-01T00:00:00Z"  },  {    "type": "relationship",    "id": "relationship--44298a74-ba52-4f0c-87a3-1824e67d7fad",    "created": "2016-04-06T20:06:37Z",    "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",    "source_ref": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",    "target_ref": "malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b",    "kind_of_relationship": "indicates"  },  {    "type": "malware",    "id": "malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b",    "created": "2016-04-06T20:07:09Z",    "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",    "title": "Poison Ivy"  } ]   By establishing Development TAXII Feeds, ACME ISAC can now also automatically publish and crowd-source testing of new signatures across a diverse set of ACME ISAC member environments.  This greatly accelerates iterations through the development lifecycle and the delivery of high quality, fully vetted signatures.   Since they’re using CTI STIX and TAXII Standards, those ACME ISAC members requiring an intermediary process before operationalizing the signatures can implement their own custom workflows/code to process the ACME ISAC TAXII Feeds.  They can then publish via TAXII to their external mail gateways when approved.     ACME ISAC manually shares select signatures with other external trusted entities. In some cases, they use trusted entities to strip attribution and re-publish signatures to other sectors or publicly.  This manual sharing of signatures consumes resources, delays dissemination, and complicates tracking, version control, etc.  Most of these trusted entities have operational TAXII Gateways or can process STIX Packages sent via secure Email.  ACME ISAC wants to use CTI STIX and TAXII Standards to automatically publish these high value ClamAV and Yara signatures via TAXII Feeds to these trusted entities.  By using the CTI STIX and TAXII Standards, all they need to do on their end is establish the Feeds.     The authors of current tools that analyze and convert artifacts into non-CybOX pattern_lang signatures (e.g., Yara, ClamAV) can provide CTI Standards compliant frameworks that enable everyone to automatically consume artifacts and publish signatures via STIX and TAXII.     Summary:   In this real-world Use Case, the ACME ISAC Central TAXII Gateway s need to be “Full Service” implementations (including CybOX support). However, the end points (1) custom external mail gateways and (2) tools to create ClamAV and YARA  Signatures, do not.    Why should the stakeholders at the edges of this Artifact è Analsysis è Signature è Operationalization Chain have to implement the extra code required to process CybOX objects and patterns?    From both a Reliability and Security perspective, we should allow, in fact encourage , agents to implement only those functions required to fulfill their specific role(s) in the CTI TC Standards Ecosystem.      Patrick Maroney    


  • 8.  Re: [cti] Question on indicator patterns

    Posted 07-17-2016 22:29
    Perhaps we can achieve consensus on the following and move forward from there: (1) The nature of systems producing, transporting, consuming, and operationalizing CTI represent a special class in terms of risks and impacts of compromise.   (2) Our Adversaries will agressively target these systems as the effectiveness of same impede their ability and/or increase efforts/costs to execute "Actions on ObjectIves". (3) Attack Surface Reduction (ASR) should be a core tenet of the CTI TC Standards.  A majority of the diverse sets of systems operationally participating in a global CTI Ecosystem require system hardening. Therefore,  CTI TC Standards should only require implementation of the specific functional elements (e.g., Ports, Protocols, Services, Application interfaces) required to deliver a conformant instantiation of that feature/function. If we concur on these core tenets, then we need a mechanism to manage the resultant variability in conformant systems.  One way is to establish "Profiles".   The OASIS KMIP TC provides a reference implementation of the practical application of "Profiles" to Confomance Clauses and Interoperability Testing .  KMIP Profiles in turn link to associated KMIP Test Cases. Any Interested parties seeking representative examples of the principles advocated here can start with the Key Management Interoperability Protocol [1] Profiles and [2] Test-Cases.   [1] [ KMIP-Profiles] Key Management Interoperability Protocol Profiles Version 1.2. Edited by Tim Hudson and Robert Lockhart. 19 May 2015. OASIS Standard. http://docs.oasis-open.org/kmip/profiles/v1.2/os/kmip-profiles-v1.2-os.html . Latest version: http://docs.oasis-open.org/kmip/profiles/v1.2/kmip-profiles-v1.2.html [2] [KMIP-testcases-v1.2] Key Management Interoperability Protocol Test Cases Version 1.2. Edited by Tim Hudson and Faisal Faruqui. 11 November 2014. OASIS Committee Note 01. http://docs.oasis-open.org/kmip/testcases/v1.2/cn01/kmip-testcases-v1.2-cn01.html . Latest version: http://docs.oasis-open.org/kmip/testcases/v1.2/kmip-testcases-v1.2.html . Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org On Sun, Jul 17, 2016 at 4:50 PM -0400, "Terry MacDonald" < terry.macdonald@cosive.com > wrote: Maybe this is where we need to separate the STIX certification into different categories to enable that differentiation to be recorded? Full STIX compliance: full STIX including full CybOX objects and patterning. Partial STIX compliance:  STIX implementation of more than the specialized STIX compliance but not a full implementation of all parts of STIX. Specialized STIX compliance: STIX and CybOX only focused on a specific subset of the language, and designed for a single purpose. For a full STIX implementation I would expect the platform to implement the CybOX patterning. For a specialized STIX implementation I would expect it to only be implemented if it was required in that instance. And as for allowing extensions to the list of signatures/patterns, I agree that's a good idea. Cheers Terry MacDonald Cosive On 16/07/2016 6:10 PM, "Patrick Maroney" < Pmaroney@specere.org > wrote: Since this thread got bifurcated, I’m inserting my earlier comments below.  This is followed by a question and Use Case Example.   “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.”     Question :   Since a STIX indicator can use multiple pattern_lang(s) in addition to CybOX, why should an implementation be required to implement CybOX Patterns to be compliant?      Use Case Example:   Analysts from the ACME ISAC member organizations crowd-source the development and inter-exchange of Yara and ClamAV signatures via the ACME ISAC collaboration portal. Over time these signatures provide increasingly high fidelity detections of new variants of 0Day exploits in attachments, MIME multipart-message subtypes, embedded links, etc.  Based on the proven success of these signatures, some ACME ISAC members collectively developed custom hardened external mail gateways to process all incoming email messages and attachments.  They used a combination of open source projects including Yara and ClamAV).  An increasing percentage of ISAC member organizations are implementing similar in-house capabilities.    Although analysts and security operations staff receive immediate email notifications of new/modified Yara and ClamAV signatures, each organization has to login, review, manually download these signatures from the central ACME ISAC portal, and then transfer them to their custom external mail gateways.   Any delay in the download and operationalization of these new APT 0Day Yara and ClamAV signatures can result in completely missing the initial wave(s) of 0Day attacks.  This scenario often results in 100s to 1,000s of compromised systems, adversary entrenchment, etc., vs. stopping the attack at the perimeter early in the kill-chain.  In the ACME sector, minutes can make the difference between a non-event and a multi-million-dollar incident.   ACME members want to use the CTI STIX andTAXII Standards via the ACME ISAC TAXII Central Gateways to automatically publish new high value, high priority, ClamAV and Yara signatures to their ISAC Membership via TAXII Feeds.  They only want to add the STIX and TAXII python code to their custom external mail gateways required to (1) subscribe to the ClamAV and Yara Feeds and (2) automatically deploy new/updated signatures.     [  {    "type": "indicator",    "id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",    "created": "2016-04-06T20:03:48Z",    "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",    "title": " Poison Ivy ClamAV Sig Example ",    "description": " Backdoor.PoisonIvy.DX ",    "pattern":" Find.ClamAV.StartAt.300;Engine:81255,Target:0;3;616c696e;62773238;636564;300:0&1&2/clamav/r ",    "pattern_lang": " ClamAV ",    "valid_from": "2016-01-01T00:00:00Z"  },  {    "type": "relationship",    "id": "relationship--44298a74-ba52-4f0c-87a3-1824e67d7fad",    "created": "2016-04-06T20:06:37Z",    "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",    "source_ref": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",    "target_ref": "malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b",    "kind_of_relationship": "indicates"  },  {    "type": "malware",    "id": "malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b",    "created": "2016-04-06T20:07:09Z",    "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",    "title": "Poison Ivy"  } ]   By establishing Development TAXII Feeds, ACME ISAC can now also automatically publish and crowd-source testing of new signatures across a diverse set of ACME ISAC member environments.  This greatly accelerates iterations through the development lifecycle and the delivery of high quality, fully vetted signatures.   Since they’re using CTI STIX and TAXII Standards, those ACME ISAC members requiring an intermediary process before operationalizing the signatures can implement their own custom workflows/code to process the ACME ISAC TAXII Feeds.  They can then publish via TAXII to their external mail gateways when approved.     ACME ISAC manually shares select signatures with other external trusted entities. In some cases, they use trusted entities to strip attribution and re-publish signatures to other sectors or publicly.  This manual sharing of signatures consumes resources, delays dissemination, and complicates tracking, version control, etc.  Most of these trusted entities have operational TAXII Gateways or can process STIX Packages sent via secure Email.  ACME ISAC wants to use CTI STIX and TAXII Standards to automatically publish these high value ClamAV and Yara signatures via TAXII Feeds to these trusted entities.  By using the CTI STIX and TAXII Standards, all they need to do on their end is establish the Feeds.     The authors of current tools that analyze and convert artifacts into non-CybOX pattern_lang signatures (e.g., Yara, ClamAV) can provide CTI Standards compliant frameworks that enable everyone to automatically consume artifacts and publish signatures via STIX and TAXII.     Summary:   In this real-world Use Case, the ACME ISAC Central TAXII Gateway s need to be “Full Service” implementations (including CybOX support). However, the end points (1) custom external mail gateways and (2) tools to create ClamAV and YARA  Signatures, do not.    Why should the stakeholders at the edges of this Artifact è Analsysis è Signature è Operationalization Chain have to implement the extra code required to process CybOX objects and patterns?    From both a Reliability and Security perspective, we should allow, in fact encourage , agents to implement only those functions required to fulfill their specific role(s) in the CTI TC Standards Ecosystem.      Patrick Maroney    


  • 9.  Re: [cti] Question on indicator patterns

    Posted 07-18-2016 23:30
    STIX and CybOX are language specifications, not products.  As such they can not do or require any type of implementation details.  About the only place we can do some of that is in TAXII....  And even then, it will be limited.  It is really up to vendor to produce good products and users to implement and deploy those products in a sound way.  So no, I do not agree with those core tenets.  They are unachievable.   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 17, 2016, at 16:28, Patrick Maroney < Pmaroney@Specere.org > wrote: Perhaps we can achieve consensus on the following and move forward from there: (1) The nature of systems producing, transporting, consuming, and operationalizing CTI represent a special class in terms of risks and impacts of compromise.   (2) Our Adversaries will agressively target these systems as the effectiveness of same impede their ability and/or increase efforts/costs to execute Actions on ObjectIves . (3) Attack Surface Reduction (ASR) should be a core tenet of the CTI TC Standards.  A majority of the diverse sets of systems operationally participating in a global CTI Ecosystem require system hardening. Therefore,  CTI TC Standards should only require implementation of the specific functional elements (e.g., Ports, Protocols, Services, Application interfaces) required to deliver a conformant instantiation of that feature/function. If we concur on these core tenets, then we need a mechanism to manage the resultant variability in conformant systems.  One way is to establish Profiles .   The OASIS KMIP TC provides a reference implementation of the practical application of Profiles to Confomance Clauses and Interoperability Testing .  KMIP Profiles in turn link to associated KMIP Test Cases. Any Interested parties seeking representative examples of the principles advocated here can start with the Key Management Interoperability Protocol [1] Profiles and [2] Test-Cases.   [1] [ KMIP-Profiles] Key Management Interoperability Protocol Profiles Version 1.2. Edited by Tim Hudson and Robert Lockhart. 19 May 2015. OASIS Standard. http://docs.oasis-open.org/kmip/profiles/v1.2/os/kmip-profiles-v1.2-os.html . Latest version: http://docs.oasis-open.org/kmip/profiles/v1.2/kmip-profiles-v1.2.html [2] [KMIP-testcases-v1.2] Key Management Interoperability Protocol Test Cases Version 1.2. Edited by Tim Hudson and Faisal Faruqui. 11 November 2014. OASIS Committee Note 01. http://docs.oasis-open.org/kmip/testcases/v1.2/cn01/kmip-testcases-v1.2-cn01.html . Latest version: http://docs.oasis-open.org/kmip/testcases/v1.2/kmip-testcases-v1.2.html . Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org On Sun, Jul 17, 2016 at 4:50 PM -0400, Terry MacDonald < terry.macdonald@cosive.com > wrote: Maybe this is where we need to separate the STIX certification into different categories to enable that differentiation to be recorded? Full STIX compliance: full STIX including full CybOX objects and patterning. Partial STIX compliance:  STIX implementation of more than the specialized STIX compliance but not a full implementation of all parts of STIX. Specialized STIX compliance: STIX and CybOX only focused on a specific subset of the language, and designed for a single purpose. For a full STIX implementation I would expect the platform to implement the CybOX patterning. For a specialized STIX implementation I would expect it to only be implemented if it was required in that instance. And as for allowing extensions to the list of signatures/patterns, I agree that's a good idea. Cheers Terry MacDonald Cosive On 16/07/2016 6:10 PM, Patrick Maroney < Pmaroney@specere.org > wrote: Since this thread got bifurcated, I’m inserting my earlier comments below.  This is followed by a question and Use Case Example.   “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.”     Question :   Since a STIX indicator can use multiple pattern_lang(s) in addition to CybOX, why should an implementation be required to implement CybOX Patterns to be compliant?      Use Case Example:   Analysts from the ACME ISAC member organizations crowd-source the development and inter-exchange of Yara and ClamAV signatures via the ACME ISAC collaboration portal. Over time these signatures provide increasingly high fidelity detections of new variants of 0Day exploits in attachments, MIME multipart-message subtypes, embedded links, etc.  Based on the proven success of these signatures, some ACME ISAC members collectively developed custom hardened external mail gateways to process all incoming email messages and attachments.  They used a combination of open source projects including Yara and ClamAV).  An increasing percentage of ISAC member organizations are implementing similar in-house capabilities.    Although analysts and security operations staff receive immediate email notifications of new/modified Yara and ClamAV signatures, each organization has to login, review, manually download these signatures from the central ACME ISAC portal, and then transfer them to their custom external mail gateways.   Any delay in the download and operationalization of these new APT 0Day Yara and ClamAV signatures can result in completely missing the initial wave(s) of 0Day attacks.  This scenario often results in 100s to 1,000s of compromised systems, adversary entrenchment, etc., vs. stopping the attack at the perimeter early in the kill-chain.  In the ACME sector, minutes can make the difference between a non-event and a multi-million-dollar incident.   ACME members want to use the CTI STIX andTAXII Standards via the ACME ISAC TAXII Central Gateways to automatically publish new high value, high priority, ClamAV and Yara signatures to their ISAC Membership via TAXII Feeds.  They only want to add the STIX and TAXII python code to their custom external mail gateways required to (1) subscribe to the ClamAV and Yara Feeds and (2) automatically deploy new/updated signatures.     [  {     type : indicator ,     id : indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f ,     created : 2016-04-06T20:03:48Z ,     created_by_ref : source--f431f809-377b-45e0-aa1c-6a4751cae5ff ,     title : Poison Ivy ClamAV Sig Example ,     description : Backdoor.PoisonIvy.DX ,     pattern : Find.ClamAV.StartAt.300;Engine:81255,Target:0;3;616c696e;62773238;636564;300:0&1&2/clamav/r ,     pattern_lang : ClamAV ,     valid_from : 2016-01-01T00:00:00Z  },  {     type : relationship ,     id : relationship--44298a74-ba52-4f0c-87a3-1824e67d7fad ,     created : 2016-04-06T20:06:37Z ,     created_by_ref : source--f431f809-377b-45e0-aa1c-6a4751cae5ff ,     source_ref : indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f ,     target_ref : malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b ,     kind_of_relationship : indicates  },  {     type : malware ,     id : malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b ,     created : 2016-04-06T20:07:09Z ,     created_by_ref : source--f431f809-377b-45e0-aa1c-6a4751cae5ff ,     title : Poison Ivy  } ]   By establishing Development TAXII Feeds, ACME ISAC can now also automatically publish and crowd-source testing of new signatures across a diverse set of ACME ISAC member environments.  This greatly accelerates iterations through the development lifecycle and the delivery of high quality, fully vetted signatures.   Since they’re using CTI STIX and TAXII Standards, those ACME ISAC members requiring an intermediary process before operationalizing the signatures can implement their own custom workflows/code to process the ACME ISAC TAXII Feeds.  They can then publish via TAXII to their external mail gateways when approved.     ACME ISAC manually shares select signatures with other external trusted entities. In some cases, they use trusted entities to strip attribution and re-publish signatures to other sectors or publicly.  This manual sharing of signatures consumes resources, delays dissemination, and complicates tracking, version control, etc.  Most of these trusted entities have operational TAXII Gateways or can process STIX Packages sent via secure Email.  ACME ISAC wants to use CTI STIX and TAXII Standards to automatically publish these high value ClamAV and Yara signatures via TAXII Feeds to these trusted entities.  By using the CTI STIX and TAXII Standards, all they need to do on their end is establish the Feeds.     The authors of current tools that analyze and convert artifacts into non-CybOX pattern_lang signatures (e.g., Yara, ClamAV) can provide CTI Standards compliant frameworks that enable everyone to automatically consume artifacts and publish signatures via STIX and TAXII.     Summary:   In this real-world Use Case, the ACME ISAC Central TAXII Gateway s need to be “Full Service” implementations (including CybOX support). However, the end points (1) custom external mail gateways and (2) tools to create ClamAV and YARA  Signatures, do not.    Why should the stakeholders at the edges of this Artifact è Analsysis è Signature è Operationalization Chain have to implement the extra code required to process CybOX objects and patterns?    From both a Reliability and Security perspective, we should allow, in fact encourage , agents to implement only those functions required to fulfill their specific role(s) in the CTI TC Standards Ecosystem.      Patrick Maroney     Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail


  • 10.  Re: [cti] Question on indicator patterns

    Posted 07-19-2016 02:30
    As a CISSP, I would have to point you to the (ISC)2 Code of Ethics. While I can understand that Pat points could be more appropriate in the context of guidelines around CTI, or in another Top Level Standard for CTI implementation (a la PCI DSS i.e.), neglecting the 'CTI Threat Model', imho, would not help preserving and so for promoting public trust and confidence in the CTI infrastructure. Examples  of such, at this point, are  encryption or non-repudiation. On Tuesday, 19 July 2016, Jordan, Bret < bret.jordan@bluecoat.com > wrote: STIX and CybOX are language specifications, not products.  As such they can not do or require any type of implementation details.  About the only place we can do some of that is in TAXII....  And even then, it will be limited.  It is really up to vendor to produce good products and users to implement and deploy those products in a sound way.  So no, I do not agree with those core tenets.  They are unachievable.   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 17, 2016, at 16:28, Patrick Maroney < Pmaroney@Specere.org > wrote: Perhaps we can achieve consensus on the following and move forward from there: (1) The nature of systems producing, transporting, consuming, and operationalizing CTI represent a special class in terms of risks and impacts of compromise.   (2) Our Adversaries will agressively target these systems as the effectiveness of same impede their ability and/or increase efforts/costs to execute "Actions on ObjectIves". (3) Attack Surface Reduction (ASR) should be a core tenet of the CTI TC Standards.  A majority of the diverse sets of systems operationally participating in a global CTI Ecosystem require system hardening. Therefore,  CTI TC Standards should only require implementation of the specific functional elements (e.g., Ports, Protocols, Services, Application interfaces) required to deliver a conformant instantiation of that feature/function. If we concur on these core tenets, then we need a mechanism to manage the resultant variability in conformant systems.  One way is to establish "Profiles".   The OASIS KMIP TC provides a reference implementation of the practical application of "Profiles" to Confomance Clauses and Interoperability Testing .  KMIP Profiles in turn link to associated KMIP Test Cases. Any Interested parties seeking representative examples of the principles advocated here can start with the Key Management Interoperability Protocol [1] Profiles and [2] Test-Cases.   [1] [ KMIP-Profiles] Key Management Interoperability Protocol Profiles Version 1.2. Edited by Tim Hudson and Robert Lockhart. 19 May 2015. OASIS Standard. http://docs.oasis-open.org/kmip/profiles/v1.2/os/kmip-profiles-v1.2-os.html . Latest version: http://docs.oasis-open.org/kmip/profiles/v1.2/kmip-profiles-v1.2.html [2] [KMIP-testcases-v1.2] Key Management Interoperability Protocol Test Cases Version 1.2. Edited by Tim Hudson and Faisal Faruqui. 11 November 2014. OASIS Committee Note 01. http://docs.oasis-open.org/kmip/testcases/v1.2/cn01/kmip-testcases-v1.2-cn01.html . Latest version: http://docs.oasis-open.org/kmip/testcases/v1.2/kmip-testcases-v1.2.html . Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org On Sun, Jul 17, 2016 at 4:50 PM -0400, "Terry MacDonald" < terry.macdonald@cosive.com > wrote: Maybe this is where we need to separate the STIX certification into different categories to enable that differentiation to be recorded? Full STIX compliance: full STIX including full CybOX objects and patterning. Partial STIX compliance:  STIX implementation of more than the specialized STIX compliance but not a full implementation of all parts of STIX. Specialized STIX compliance: STIX and CybOX only focused on a specific subset of the language, and designed for a single purpose. For a full STIX implementation I would expect the platform to implement the CybOX patterning. For a specialized STIX implementation I would expect it to only be implemented if it was required in that instance. And as for allowing extensions to the list of signatures/patterns, I agree that's a good idea. Cheers Terry MacDonald Cosive On 16/07/2016 6:10 PM, "Patrick Maroney" < Pmaroney@specere.org > wrote: Since this thread got bifurcated, I’m inserting my earlier comments below.  This is followed by a question and Use Case Example.   “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.”     Question :   Since a STIX indicator can use multiple pattern_lang(s) in addition to CybOX, why should an implementation be required to implement CybOX Patterns to be compliant?      Use Case Example:   Analysts from the ACME ISAC member organizations crowd-source the development and inter-exchange of Yara and ClamAV signatures via the ACME ISAC collaboration portal. Over time these signatures provide increasingly high fidelity detections of new variants of 0Day exploits in attachments, MIME multipart-message subtypes, embedded links, etc.  Based on the proven success of these signatures, some ACME ISAC members collectively developed custom hardened external mail gateways to process all incoming email messages and attachments.  They used a combination of open source projects including Yara and ClamAV).  An increasing percentage of ISAC member organizations are implementing similar in-house capabilities.    Although analysts and security operations staff receive immediate email notifications of new/modified Yara and ClamAV signatures, each organization has to login, review, manually download these signatures from the central ACME ISAC portal, and then transfer them to their custom external mail gateways.   Any delay in the download and operationalization of these new APT 0Day Yara and ClamAV signatures can result in completely missing the initial wave(s) of 0Day attacks.  This scenario often results in 100s to 1,000s of compromised systems, adversary entrenchment, etc., vs. stopping the attack at the perimeter early in the kill-chain.  In the ACME sector, minutes can make the difference between a non-event and a multi-million-dollar incident.   ACME members want to use the CTI STIX andTAXII Standards via the ACME ISAC TAXII Central Gateways to automatically publish new high value, high priority, ClamAV and Yara signatures to their ISAC Membership via TAXII Feeds.  They only want to add the STIX and TAXII python code to their custom external mail gateways required to (1) subscribe to the ClamAV and Yara Feeds and (2) automatically deploy new/updated signatures.     [  {    "type": "indicator",    "id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",    "created": "2016-04-06T20:03:48Z",    "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",    "title": " Poison Ivy ClamAV Sig Example ",    "description": " Backdoor.PoisonIvy.DX ",    "pattern":" Find.ClamAV.StartAt.300;Engine:81255,Target:0;3;616c696e;62773238;636564;300:0&1&2/clamav/r ",    "pattern_lang": " ClamAV ",    "valid_from": "2016-01-01T00:00:00Z"  },  {    "type": "relationship",    "id": "relationship--44298a74-ba52-4f0c-87a3-1824e67d7fad",    "created": "2016-04-06T20:06:37Z",    "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",    "source_ref": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",    "target_ref": "malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b",    "kind_of_relationship": "indicates"  },  {    "type": "malware",    "id": "malware--31b940d4-6f7f-459a-80ea-9c1f17b5891b",    "created": "2016-04-06T20:07:09Z",    "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",    "title": "Poison Ivy"  } ]   By establishing Development TAXII Feeds, ACME ISAC can now also automatically publish and crowd-source testing of new signatures across a diverse set of ACME ISAC member environments.  This greatly accelerates iterations through the development lifecycle and the delivery of high quality, fully vetted signatures.   Since they’re using CTI STIX and TAXII Standards, those ACME ISAC members requiring an intermediary process before operationalizing the signatures can implement their own custom workflows/code to process the ACME ISAC TAXII Feeds.  They can then publish via TAXII to their external mail gateways when approved.     ACME ISAC manually shares select signatures with other external trusted entities. In some cases, they use trusted entities to strip attribution and re-publish signatures to other sectors or publicly.  This manual sharing of signatures consumes resources, delays dissemination, and complicates tracking, version control, etc.  Most of these trusted entities have operational TAXII Gateways or can process STIX Packages sent via secure Email.  ACME ISAC wants to use CTI STIX and TAXII Standards to automatically publish these high value ClamAV and Yara signatures via TAXII Feeds to these trusted entities.  By using the CTI STIX and TAXII Standards, all they need to do on their end is establish the Feeds.     The authors of current tools that analyze and convert artifacts into non-CybOX pattern_lang signatures (e.g., Yara, ClamAV) can provide CTI Standards compliant frameworks that enable everyone to automatically consume artifacts and publish signatures via STIX and TAXII.     Summary:   In this real-world Use Case, the ACME ISAC Central TAXII Gateway s need to be “Full Service” implementations (including CybOX support). However, the end points (1) custom external mail gateways and (2) tools to create ClamAV and YARA  Signatures, do not.    Why should the stakeholders at the edges of this Artifact è Analsysis è Signature è Operationalization Chain have to implement the extra code required to process CybOX objects and patterns?    From both a Reliability and Security perspective, we should allow, in fact encourage , agents to implement only those functions required to fulfill their specific role(s) in the CTI TC Standards Ecosystem.      Patrick Maroney    


  • 11.  RE: [cti] Question on indicator patterns

    Posted 07-19-2016 14:13
    From the Information Assurance Implementation Considerations document currently being drafted for OpenC2: "One of the cornerstone ideals from the Information Systems Security Engineering process is to separate the problem space from the solution space. The problem space defines what the system will do, while the solution space defines how the system will solve the problems." 2 1/2 of the three tenets lie squarely within the problem domain, and I believe are entirely appropriate as aspirational statements motivating CTI efforts. The second half of tenet three (system hardening) encroaches on the solution domain and may not be appropriate as a tenet. I agree with Bret's other point that baby steps (verifying protocol interoperability) are most appropriate at this technology readiness level. Once STIX has the same market penetration and universal interoperability as, say, TLS :-), then ISSE, risk management, profiles, conformance levels, and certification efforts may come into play. Dave Kemp NSA, Secure Mission Architecture Engineering


  • 12.  Re: [cti] Question on indicator patterns

    Posted 07-19-2016 16:01
    I will simplify and close on my argument to the community:  Conformance to a standard IS an implementation detail.  The generalized question posed to the community was whether or not conformant  implementations MUST implement all features and functions.  The argument is that they should not for the reasons given.  The decision appears to be that they must.   On to the next windmill Rocinante! Patrick Maroney President Integrated Networking Technologies, Inc. Desk: (856)983-0001 Cell: (609)841-5104 Email: pmaroney@specere.org On Tue, Jul 19, 2016 at 10:12 AM -0400, "Kemp, David P" < dpkemp@nsa.gov > wrote: From the Information Assurance Implementation Considerations document currently being drafted for OpenC2: "One of the cornerstone ideals from the Information Systems Security Engineering process is to separate the problem space from the solution space.  The problem space defines what the system will do, while the solution space defines how the system will solve the problems." 2 1/2 of the three tenets lie squarely within the problem domain, and I believe are entirely appropriate as aspirational statements motivating CTI efforts.  The second half of tenet three (system hardening) encroaches on the solution domain and may not be appropriate as a tenet. I agree with Bret's other point that baby steps (verifying protocol interoperability) are most appropriate at this technology readiness level.  Once STIX has the same market penetration and universal interoperability as, say, TLS :-), then ISSE, risk management, profiles, conformance levels, and certification efforts may come into play. Dave Kemp NSA, Secure Mission Architecture Engineering


  • 13.  Re: [cti] Question on indicator patterns

    Posted 07-19-2016 18:19
    On 19.07.2016 16:00:30, Patrick Maroney wrote: > I will simplify and close on my argument to the community: > Conformance to a standard IS an implementation detail. The > generalized question posed to the community was whether or not > conformant implementations MUST implement all features and > functions. The argument is that they should not for the reasons > given. The decision appears to be that they must. > Hey, Pat - I think the argument is rather that at this stage in the game we're not prepared to have that conversation. We've got a number of folks in the TC working furiously - early mornings, late nights, weekends, and holidays - all striving to get the committee draft specs out by 29 July. I don't think there's anyone in the TC who would discount the need to eventually define specifics around conformance to the CTI standards. It's just that there are only so many hours in a day, and out of the almost 300 TC members, there are about 25-30 who are doing the lion's share of the work. We will get around to tackling conformance soon. We just don't have the bandwidth *now*. Moreover, as there are liable to be substantive changes to the various draft specs during the upcoming public comment periods it would be rather a dubious undertaking to tackle conformance *now*. -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "Conservative, n.: One who admires radicals centuries after they're dead." --Leo Rosten Attachment: signature.asc Description: Digital signature


  • 14.  Re: [cti] Question on indicator patterns

    Posted 07-20-2016 04:24
    Hi, I would like to clarify one point. While I think it has now been clarified, that, what I felt has an ambiguity behind the use of the term "unachievable" in the previous context of this thread, was referring to the "time paradigm", and not the "infeasibility" of ensuring a secure/resilient CTI infrastructure; I would like to apologize for the misunderstanding caused by my previous email, and especially the ambiguity behind the term "Ethics". Please kindly disregard my previous message. Best regards


  • 15.  Re: [cti] Question on indicator patterns

    Posted 07-18-2016 13:19
    On 18.07.2016 08:50:23, Terry MacDonald wrote: > Maybe this is where we need to separate the STIX certification into > different categories to enable that differentiation to be recorded? > > Full STIX compliance: full STIX including full CybOX objects and > patterning. > > Partial STIX compliance: STIX implementation of more than the > specialized STIX compliance but not a full implementation of all > parts of STIX. > > Specialized STIX compliance: STIX and CybOX only focused on a > specific subset of the language, and designed for a single purpose. > The CybOX Patterning language was created to encompass matching on both network and endpoint-related data. Yara does a fine job on the endpoint as does Snort on the network, but the CybOX SC as could find no open standard patterning language addressing both, the CybOX Patterning language was developed. Now clearly one would expect that a SIEM claiming to support STIX Indicators would have the capability to handle matching on both network and endpoint-related data. But one would *not* expect (for example) a web proxy to know what to do with Windows Registry Keys but a web proxy claiming to support STIX Indicators *should* be able to do something sensible (and well-defined) upon receiving a STIX Indicator, containing a CybOX Pattern enumerating URLs, IP addresses, etc. From the perspective of claiming conformance to the standards, there's obviously some variance to be accounted for depending on what type of tool or product you're talking about Currently we addressed this by inserting this text into the STIX Indicator spec: "...and MUST be supported, as described by the CybOX Patterning conformance specification." We worked furiously on the CybOX Patterning spec last week but ran out of time to address this. There is currently no text in the CybOX Patterning spec describing conformance in these distinctly different use cases but this is a known issue and one which we will be working to address this week. Hope that clears things up a bit! ^_^ -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "Every networking problem always takes longer to solve than it seems like it should." --RFC 1925 Attachment: signature.asc Description: Digital signature


  • 16.  Re: [cti] Question on indicator patterns

    Posted 07-18-2016 23:40
    baby steps....  Even the Wifi Alliance did not start out with everything. The first steps in this process should be very basic.  Namely, for patterning, can you support an equals/matching operator.  For network devices they should be able to support IP address and domain names..  For host based stuff they should be able to support file hashes, and file names.   Rinse and repeat over time. It would be an AMAZING problem to have, to have so many vendors out there doing STIX/CybOX and TAXII that we need to build a layered certification and assessment program.  But for the next 2 years or so, the reality is, we just need people to adopt these standards and start doing things with them.    The market will ultimately decide how much of the certification and assessment we need to end up doing.  If everyone's products work well with each other, and users do not complain to us that all of the solutions are broken, then things are good.   The biggest areas I can see us working on are: 1) If I send you a Object FOO, and then request that Object back, is it hash perfect? Do this for a whole library of objects. 2) For data markings over TAXII, if I tell you I can only support TLP AMBER, can I get a document that I know is TLP RED things like that..  I am sure we can easily come up with a list of 15-20 simple tests that vendors can do, to verify their solutions work.   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 18, 2016, at 07:18, Trey Darley < trey@kingfisherops.com > wrote: On 18.07.2016 08:50:23, Terry MacDonald wrote: Maybe this is where we need to separate the STIX certification into different categories to enable that differentiation to be recorded? Full STIX compliance: full STIX including full CybOX objects and patterning. Partial STIX compliance: STIX implementation of more than the specialized STIX compliance but not a full implementation of all parts of STIX. Specialized STIX compliance: STIX and CybOX only focused on a specific subset of the language, and designed for a single purpose. The CybOX Patterning language was created to encompass matching on both network and endpoint-related data. Yara does a fine job on the endpoint as does Snort on the network, but the CybOX SC as could find no open standard patterning language addressing both, the CybOX Patterning language was developed. Now clearly one would expect that a SIEM claiming to support STIX Indicators would have the capability to handle matching on both network and endpoint-related data. But one would *not* expect (for example) a web proxy to know what to do with Windows Registry Keys but a web proxy claiming to support STIX Indicators *should* be able to do something sensible (and well-defined) upon receiving a STIX Indicator, containing a CybOX Pattern enumerating URLs, IP addresses, etc. From the perspective of claiming conformance to the standards, there's obviously some variance to be accounted for depending on what type of tool or product you're talking about Currently we addressed this by inserting this text into the STIX Indicator spec: ...and MUST be supported, as described by the CybOX Patterning conformance specification. We worked furiously on the CybOX Patterning spec last week but ran out of time to address this. There is currently no text in the CybOX Patterning spec describing conformance in these distinctly different use cases but this is a known issue and one which we will be working to address this week. Hope that clears things up a bit! ^_^ -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4  5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- Every networking problem always takes longer to solve than it seems like it should. --RFC 1925 Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail


  • 17.  Re: [cti] Question on indicator patterns

    Posted 07-18-2016 13:04
    On 15.07.2016 13:24:27, John-Mark Gurney wrote: > > 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 > For the reasons enumerated by Allan, Jason, & John-Mark, my vote is yes on MVP and yes on open vocab. -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea." --RFC 1925 Attachment: signature.asc Description: Digital signature


  • 18.  Re: [cti] Question on indicator patterns

    Posted 07-18-2016 13:06
    Thanks everyone. For the drafts that will go out today, we’ve used the MUST language for CybOX with an open vocabulary for other languages. 1) Yes – MUST language 2) Yes – open vocab John On 7/18/16, 9:03 AM, "Trey Darley" <trey@kingfisherops.com> wrote: On 15.07.2016 13:24:27, John-Mark Gurney wrote: > > 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 > For the reasons enumerated by Allan, Jason, & John-Mark, my vote is yes on MVP and yes on open vocab. -- Cheers, Trey ++--------------------------------------------------------------------------++ Kingfisher Operations, sprl gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea." --RFC 1925