CTI STIX Subcommittee

 View Only

  • 1.  Re: [cti-stix] Indicator TLO

    Posted 05-17-2016 13:41




    Provided comments on the doc.
     
    Regarding the question on non-cybox patterns. Suggest that this be a post-MVP capability. If others feel strongly that it should be included then we should add an attribute that identifies
    the pattern type (i.e. the language used) in addition to the pattern itself. Then make the pattern type a controlled vocab with cybox as the default value (and if not included).
     
    allan
     

    From:
    "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
    Date: Sunday, May 15, 2016 at 2:24 PM
    To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
    Subject: [cti-stix] Indicator TLO


     



    All,

     


    John and I were reviewing the Indicator TLO today and there are just a few open tasks remaining before it can be moved to the Review phase.   Can we ask everyone to help us resolve these last few things?  It would be nice to move this from
    Development to Review by end of week.


     


    https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.8gcmzx50n1ri


     


    Open Tasks

                • What are the values for the Labels field?  Is it a controlled vocab or just an array of strings?


                • What is the Decay_Rate and is it MVP?


                • Do we allow non-cybox patterns (test mechanisms, like yara, openIOC, snort)? And is it MVP?


                • Clean up property descriptions 








     


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









     









  • 2.  RE: [cti-stix] Indicator TLO

    Posted 05-17-2016 21:36
    I would vote for the other pattern types be MVP, agree with how Allan suggests to do it. Having other pattern types as an option will be most valuable in initial deployment since everyone is currently using other pattern types. Not having it in initial deployment will leave a negative-first-impression among users that we would have to later overcome.
    Original Message


  • 3.  Re: [cti-stix] Indicator TLO

    Posted 05-17-2016 21:49
    After hearing what you all mentioned on the call this morning, I was thinking that something like this might be good?????  I think it was Allan that suggested encoding the version in the key.   {   type : indicator ,   id : indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f ,   created_time : 2016-04-06T20:03:48Z ,   created_by_ref : source--f431f809-377b-45e0-aa1c-6a4751cae5ff ,   title : Poison Ivy Malware ,   description : This file is part of Poison Ivy ,   pattern : {     cybox-3.0.0 : file-object.hashes.md5 = '3773a88f65a5e780c8dff9cdc3a056f3' ,     snort-1.2.3 : something in snort syntax ,     yara-4.6.7 : something in yara syntax   } } 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 May 17, 2016, at 15:36, Katz, Gary CTR DC3/DCCI < Gary.Katz.ctr@dc3.mil > wrote: I would vote for the other pattern types be MVP, agree with how Allan suggests to do it.  Having other pattern types as an option will be most valuable in initial deployment since everyone is currently using other pattern types.  Not having it in initial deployment will leave a negative-first-impression among users that we would have to later overcome.
    Original Message


  • 4.  Re: [cti-stix] Indicator TLO

    Posted 05-17-2016 22:17
    Jordan, Bret wrote this message on Tue, May 17, 2016 at 21:49 +0000: > After hearing what you all mentioned on the call this morning, I was thinking that something like this might be good????? I think it was Allan that suggested encoding the version in the key. > > { > "type": "indicator", > "id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f", > "created_time": "2016-04-06T20:03:48Z", > "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff", > "title": "Poison Ivy Malware", > "description": "This file is part of Poison Ivy", > "pattern": { > "cybox-3.0.0": "file-object.hashes.md5 = '3773a88f65a5e780c8dff9cdc3a056f3'", This should just be cybox... Unless we plan on supporting multiple version of CybOX in a single STIX Standard, which I don't think we plan on doing. > "snort-1.2.3": "something in snort syntax", > "yara-4.6.7": "something in yara syntax" I agree w/ encoding the version in the key.. This would make supporting multiple version of snort/yara, etc more straight forward. > > On May 17, 2016, at 15:36, Katz, Gary CTR DC3/DCCI <Gary.Katz.ctr@dc3.mil> wrote: > > > > I would vote for the other pattern types be MVP, agree with how Allan suggests to do it. Having other pattern types as an option will be most valuable in initial deployment since everyone is currently using other pattern types. Not having it in initial deployment will leave a negative-first-impression among users that we would have to later overcome. > > > >
    Original Message


  • 5.  Re: [cti-stix] Indicator TLO

    Posted 05-17-2016 22:40
    Encoding the cybox version might make things easier and allow CybOX to release more quickly.  But it may also mean problems for interoperability.  As saying you were STIX 2.0.0 compliant would not mean as much... You would have to stay STIX 2.0.0 and CybOX 3.0.0 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 May 17, 2016, at 16:16, John-Mark Gurney < jmg@newcontext.com > wrote: Jordan, Bret wrote this message on Tue, May 17, 2016 at 21:49 +0000: After hearing what you all mentioned on the call this morning, I was thinking that something like this might be good?????  I think it was Allan that suggested encoding the version in the key. {   type : indicator ,   id : indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f ,   created_time : 2016-04-06T20:03:48Z ,   created_by_ref : source--f431f809-377b-45e0-aa1c-6a4751cae5ff ,   title : Poison Ivy Malware ,   description : This file is part of Poison Ivy ,   pattern : {     cybox-3.0.0 : file-object.hashes.md5 = '3773a88f65a5e780c8dff9cdc3a056f3' , This should just be cybox...  Unless we plan on supporting multiple version of CybOX in a single STIX Standard, which I don't think we plan on doing.     snort-1.2.3 : something in snort syntax ,     yara-4.6.7 : something in yara syntax I agree w/ encoding the version in the key..  This would make supporting multiple version of snort/yara, etc more straight forward. On May 17, 2016, at 15:36, Katz, Gary CTR DC3/DCCI < Gary.Katz.ctr@dc3.mil > wrote: I would vote for the other pattern types be MVP, agree with how Allan suggests to do it.  Having other pattern types as an option will be most valuable in initial deployment since everyone is currently using other pattern types.  Not having it in initial deployment will leave a negative-first-impression among users that we would have to later overcome.
    Original Message


  • 6.  Re: [cti-stix] Indicator TLO

    Posted 05-18-2016 01:33




    Sorry if you discussed some of these topics on the call, had to miss it.
     
    As I think I said in a response to the message Ivan sent out, IMO a particular version of STIX should be locked to a particular version of CybOX. That would mean that the key should either
    be “cybox” or “cybox-3.0.0” and any other CybOX keys are considered custom properties.
     
    To be honest, I’m not a huge fan of just embedding the version in the key. It means that to pull out the snort sig you’d need to enumerate the keys, find the one with “snort” in it, parse
    out the version to see if you support it, and then pull the rule from that key. If we just have a nested object with the version key it’s just a matter of pulling the “snort” key, pulling the “version”, and pulling the “rule”. OTOH if people routinely send
    snort rules as multiple versions I guess it would be helpful, I don’t know how common that is. I don’t feel too strongly about this so don’t hold it up based on me, just seemed cleaner to me to have it nested.
     
    One other thing to consider is whether the value could/should be an object rather than a string. For our Snort test mechanism in STIX 1.2 we had a few different fields: rule, version, event
    filter, rate filter, and event suppression. They were added after a snort expert told us that sharing a snort rule without that extra data was not sufficient...not sure how often they’re used in practice though.
     
    Definitely agree that these non-CybOX pattern types are MVP.
     
    John
     

    From:
    <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
    Date: Tuesday, May 17, 2016 at 6:39 PM
    To: John-Mark Gurney <jmg@newcontext.com>
    Cc: "Katz, Gary CTR DC3/DCCI" <Gary.Katz.ctr@dc3.mil>, Allan Thomson <athomson@lookingglasscyber.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
    Subject: Re: [cti-stix] Indicator TLO


     



    Encoding the cybox version might make things easier and allow CybOX to release more quickly.  But it may also mean problems for interoperability.  As saying you were STIX 2.0.0 compliant would not mean as much... You would have to stay
    STIX 2.0.0 and CybOX 3.0.0







     


    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 May 17, 2016, at 16:16, John-Mark Gurney < jmg@newcontext.com > wrote:

     

    Jordan, Bret wrote this message on Tue, May 17, 2016 at 21:49 +0000:



    After hearing what you all mentioned on the call this morning, I was thinking that something like this might be good?????  I think it was Allan that suggested encoding the version in
    the key.

    {
     "type": "indicator",
     "id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",
     "created_time": "2016-04-06T20:03:48Z",
     "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",
     "title": "Poison Ivy Malware",
     "description": "This file is part of Poison Ivy",
     "pattern": {
       "cybox-3.0.0": "file-object.hashes.md5 = '3773a88f65a5e780c8dff9cdc3a056f3'",


    This should just be cybox...  Unless we plan on supporting multiple version
    of CybOX in a single STIX Standard, which I don't think we plan on doing.




       "snort-1.2.3": "something in snort syntax",
       "yara-4.6.7": "something in yara syntax"


    I agree w/ encoding the version in the key..  This would make supporting
    multiple version of snort/yara, etc more straight forward.





    On May 17, 2016, at 15:36, Katz, Gary CTR DC3/DCCI < Gary.Katz.ctr@dc3.mil > wrote:

    I would vote for the other pattern types be MVP, agree with how Allan suggests to do it.  Having other pattern types as an option will be most valuable in initial deployment since everyone is currently using other pattern types.  Not having it in initial deployment
    will leave a negative-first-impression among users that we would have to later overcome.


    Original Message


  • 7.  RE: [cti-stix] Indicator TLO

    Posted 05-18-2016 02:13




    I'm also currently on the fence about including a 3rd party pattern type in the key. I think I'd rather have a rule fail downstream than be unable to process a key because it's a new dot release that our product is unprepared for.




    Original Message


  • 8.  Re: [cti-stix] Indicator TLO

    Posted 05-18-2016 18:55
    Wunder, John A. wrote this message on Wed, May 18, 2016 at 01:32 +0000: > To be honest, I’m not a huge fan of just embedding the version in the key. It means that to pull out the snort sig you’d need to enumerate the keys, find the one with “snort” in it, parse out the version to see if you support it, and then pull the rule from that key. If we just have a nested object with the version key it’s just a matter of pulling the “snort” key, pulling the “version”, and pulling the “rule”. OTOH if people routinely send snort rules as multiple versions I guess it would be helpful, I don’t know how common that is. I don’t feel too strongly about this so don’t hold it up based on me, just seemed cleaner to me to have it nested. Remember that transport doesn't mean that's how an implementation will store it.. Doing that once on load doesn't sound like that big of an issue... If we don't put it there, then we make things lists to support different major versions.. Not everyone follows sane versioning of their language, etc. > One other thing to consider is whether the value could/should be an object rather than a string. For our Snort test mechanism in STIX 1.2 we had a few different fields: rule, version, event filter, rate filter, and event suppression. They were added after a snort expert told us that sharing a snort rule without that extra data was not sufficient...not sure how often they’re used in practice though. Now we are getting into the complexities of mandating how a third-party rule is defined... As soon as we go beyond a simple string (binary?), it'll be more of an endorsement that there isn't a need to use CybOX patterning.. > Definitely agree that these non-CybOX pattern types are MVP. If we restrict to simple string (or binary) yes. If we define more, then say that additional rules should not be MVP. > From: <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com> > Date: Tuesday, May 17, 2016 at 6:39 PM > To: John-Mark Gurney <jmg@newcontext.com> > Cc: "Katz, Gary CTR DC3/DCCI" <Gary.Katz.ctr@dc3.mil>, Allan Thomson <athomson@lookingglasscyber.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> > Subject: Re: [cti-stix] Indicator TLO > > Encoding the cybox version might make things easier and allow CybOX to release more quickly. But it may also mean problems for interoperability. As saying you were STIX 2.0.0 compliant would not mean as much... You would have to stay STIX 2.0.0 and CybOX 3.0.0 > > 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 May 17, 2016, at 16:16, John-Mark Gurney <jmg@newcontext.com< mailto:jmg@newcontext.com >> wrote: > > Jordan, Bret wrote this message on Tue, May 17, 2016 at 21:49 +0000: > > After hearing what you all mentioned on the call this morning, I was thinking that something like this might be good????? I think it was Allan that suggested encoding the version in the key. > > { > "type": "indicator", > "id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f", > "created_time": "2016-04-06T20:03:48Z", > "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff", > "title": "Poison Ivy Malware", > "description": "This file is part of Poison Ivy", > "pattern": { > "cybox-3.0.0": "file-object.hashes.md5 = '3773a88f65a5e780c8dff9cdc3a056f3'", > > This should just be cybox... Unless we plan on supporting multiple version > of CybOX in a single STIX Standard, which I don't think we plan on doing. > > > "snort-1.2.3": "something in snort syntax", > "yara-4.6.7": "something in yara syntax" > > I agree w/ encoding the version in the key.. This would make supporting > multiple version of snort/yara, etc more straight forward. > > > On May 17, 2016, at 15:36, Katz, Gary CTR DC3/DCCI <Gary.Katz.ctr@dc3.mil< mailto:Gary.Katz.ctr@dc3.mil >> wrote: > > I would vote for the other pattern types be MVP, agree with how Allan suggests to do it. Having other pattern types as an option will be most valuable in initial deployment since everyone is currently using other pattern types. Not having it in initial deployment will leave a negative-first-impression among users that we would have to later overcome. > >
    Original Message


  • 9.  Re: [cti-stix] Indicator TLO

    Posted 05-17-2016 23:19
    I agree with Gary on this. The other patterns types are already in use Sent from my iPhone > On May 17, 2016, at 5:36 PM, Katz, Gary CTR DC3/DCCI <Gary.Katz.ctr@dc3.mil> wrote: > > I would vote for the other pattern types be MVP, agree with how Allan suggests to do it. Having other pattern types as an option will be most valuable in initial deployment since everyone is currently using other pattern types. Not having it in initial deployment will leave a negative-first-impression among users that we would have to later overcome. > >
    Original Message


Related Content