OASIS Cyber Threat Intelligence (CTI) TC

 View Only

  • 1.  Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO

    Posted 06-13-2017 15:57
    So we have now have two primary use cases for location as an SDO.   1) Enable third parties to also assert that say a Threat Actor is at location foo 2) Be able to tie multiple locations to an object with different "relationship_types" and I would guess with different confidence levels. The pivoting and tracking I personally do not see as a point of value either way.  It just depends on software tracking the normalized value of the property or GUID.  Both are doable.  Reuse of location SDOs is probably not a valid argument either, based on discussions we have had. So we would need to be okay with the idea that we may have many version of Location:US.  Open questions: Where is the line between properties that get made into an SDO and those that do not?  For example, we decided that Cyber Observables should not be made an SDO. Bret From: Jason Keirstead <Jason.Keirstead@ca.ibm.com> Sent: Tuesday, June 13, 2017 7:01:19 AM To: Mark Davidson Cc: Bret Jordan; CTI OASIS GROUP; Back, Greg; John-Mark Gurney; John A Wunder; Nathan S. Reller; Nicholas Hayden; Patrick Maroney Subject: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO   This is a good point as well. While deconstructing an event, an analyst might have to use many location relationships for an indicator. "registered_from" and "originated_from" are very different things when looking at attacks utilizing DNS fast flux. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security Without data, all you are is just another person with an opinion - Unknown From:         Mark Davidson <Mark.Davidson@nc4.com> To:         Nicholas Hayden <nhayden@anomali.com>, John A Wunder <jwunder@mitre.org> Cc:         Patrick Maroney <pmaroney@wapacklabs.com>, Bret Jordan <Bret_Jordan@symantec.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, John-Mark Gurney <jmg@newcontext.com>, CTI OASIS GROUP <cti@lists.oasis-open.org>, "Back, Greg" <gback@mitre.org>, "Nathan S. Reller" <Nathan.Reller@jhuapl.edu> Date:         06/13/2017 09:50 AM Subject:         Re: [cti] [EXT] [cti] Location as a Top-Level SDO Sent by:         <cti@lists.oasis-open.org> In the interest of achieving principled negotiation, I’ll articulate my needs for this solution: Changing the location structure later on does not require significant modification to all STIX objects. For instance, if we made location a common property with a simple location=STRING, and then transitioned to location=JSON_OBJECT, that would require a lot of engineering re-work and I’d like to avoid it. I need to use location on any SDO, not just the ones that have been pre-ordained at design time (aka “now”). We saw this problem in spades in STIX 1.x, let’s not repeat it.   So far I’ve seen examples of what location-as-a-property (LAAP, for short) would look like. Is there a more concrete proposal?   As something of a side note (but directly to Nicholas’ point), I think they key factor here is that a substantial subset of this community perceives there to be one and only one valid relationship from any SDO to a location, that of “located at” (e.g., Threat Actor located at “Joe’s Pizza”). My sense is that the count of relationships is a distinguishing factor between whether an SDO is needed, or whether the information can be represented as a property.                 If there is one and only one valid relationship type, that information can be effectively encoded in the property reference. If there is more than one valid relationship type, then the Relationship Object is needed to indicate the relationship type.   Thank you. -Mark     From: <cti@lists.oasis-open.org> on behalf of Nicholas Hayden <nhayden@anomali.com> Date: Tuesday, June 13, 2017 at 8:47 AM To: John A Wunder <jwunder@mitre.org> Cc: Patrick Maroney <pmaroney@wapacklabs.com>, Bret Jordan <Bret_Jordan@symantec.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, John-Mark Gurney <jmg@newcontext.com>, CTI OASIS GROUP <cti@lists.oasis-open.org>, "Back, Greg" <gback@mitre.org>, "Nathan S. Reller" <Nathan.Reller@jhuapl.edu> Subject: Re: [cti] [EXT] [cti] Location as a Top-Level SDO   Can we derive a "Go No GO” checklist for SDO’s?  This might help us in resolving this and to John’s point future scenarios.  My proposal is we clearly define what the characteristics are which “Qualifies” something that needs to be an SDO.  So for example does it requiring versioning “Yes” ok thats a +1 toward making it an SDO.     Best Regards, Nicholas Hayden, CISSP, GICSP, CNDA, CEH, Sec+ Director of Engineering Anomali anomali.com 808 Winslow St Redwood City, CA 94063 Phone: (650) 257-0867 Twitter: @anomali PastedGraphic-2.tiff   On Jun 12, 2017, at 4:12 PM, Wunder, John A. < jwunder@mitre.org > wrote:   Yeah +1 to Pat…we’re a CTI org, let’s not maintain a database of geolocations.   More generally I also agree w/ Allan that this doesn’t really impact the SDO question. Either you:   -           Have the library and duplicate it in the embedded types -           Have the library and reference it by UUID (if we generate STIX UUIDs for it) -           Have the library and copy it into the referenced types (if we don’t generate UUIDs for it)   It would be nice to enumerate these types of scenarios and see how we can deal with each of them in each approach. I talked to Allan and I think he has the beginnings of that document started, I’ll get with him to push it to Google docs so we can all look over it.   John   From: < cti@lists.oasis-open.org > on behalf of Patrick Maroney < pmaroney@wapacklabs.com > Date: Monday, June 12, 2017 at 3:16 PM To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com > Cc: "Jason Mr. Keirstead" < Jason.Keirstead@ca.ibm.com >, "John-Mark Mr. Gurney" < jmg@newcontext.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Greg Back < gback@mitre.org >, " Nathan.Reller@jhuapl.edu " < Nathan.Reller@jhuapl.edu > Subject: Re: [cti] [EXT] [cti] Location as a Top-Level SDO   My .02:  If we're building, publishing, maintaining our own Geo-Location Data, we're doing something wrong.  This is one wheel we do not need to re-invent...again just my .02.   Patrick Maroney Principal Engineer - Data Science & Analytics Wapack Labs LLC (609)841-5104 pmaroney@wapacklabs.com   Public Key: http://pgp.mit.edu/pks/lookup?op=get&search=0x7C810C9769BD29AF   On Jun 11, 2017, at 11:58 PM, Bret Jordan < Bret_Jordan@symantec.com > wrote:   So if we were going to do this, we would probably need to build a library of locations by country and regions and publish them as a Committee Note and hope people just use the them for locations at the granularity of a country or group of countries.   Bret From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Jason Keirstead < Jason.Keirstead@ca.ibm.com > Sent: Sunday, June 11, 2017 7:35:18 PM To: jmg@newcontext.com Cc: Bret Jordan; cti@lists.oasis-open.org ; gback@mitre.org ; Nathan.Reller@jhuapl.edu Subject: Re: [cti] Re: [EXT] [cti] Location as a Top-Level SDO   You are assuming that we don't create a repository of "standard" location SDOs for things like continent and country names - IE the things that people would want to share in the first place. Which, I don't see why we would not do this, seeing how we're doing it for things like CAPEC.   - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security Without data, all you are is just another person with an opinion - Unknown    


  • 2.  Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO

    Posted 06-13-2017 16:45
    So after having a long discussion with Mark about his use case, that of having multiple locations attached to a single object, I have switched my view.  I now fully support this being an SDO, with some caveats.   1) I think we need to realize that people will want to attach multiple SDOs to an object and assert some level of confidence with various "relationship types".  Doing this via an embedded property is ugly ( I just did in JSON to see what it would be like ) and would require a lot of duplication with confidence and thus make it look like a STIX 1.x model.  2) I think people will want to timebox the location assertion. Thus we need to add something like valid_from and vaild_to to the relationship object 3) We need to be okay with the idea that there may be many versions of "location=Europe" 4) We need to figure out where is the line in the sand between objects being an SDO and not. Bret From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com> Sent: Tuesday, June 13, 2017 9:57:15 AM To: Jason Keirstead; Mark Davidson Cc: CTI OASIS GROUP; Back, Greg; John-Mark Gurney; John A Wunder; Nathan S. Reller; Nicholas Hayden; Patrick Maroney Subject: [cti] Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO   So we have now have two primary use cases for location as an SDO.   1) Enable third parties to also assert that say a Threat Actor is at location foo 2) Be able to tie multiple locations to an object with different "relationship_types" and I would guess with different confidence levels. The pivoting and tracking I personally do not see as a point of value either way.  It just depends on software tracking the normalized value of the property or GUID.  Both are doable.  Reuse of location SDOs is probably not a valid argument either, based on discussions we have had. So we would need to be okay with the idea that we may have many version of Location:US.  Open questions: Where is the line between properties that get made into an SDO and those that do not?  For example, we decided that Cyber Observables should not be made an SDO. Bret From: Jason Keirstead <Jason.Keirstead@ca.ibm.com> Sent: Tuesday, June 13, 2017 7:01:19 AM To: Mark Davidson Cc: Bret Jordan; CTI OASIS GROUP; Back, Greg; John-Mark Gurney; John A Wunder; Nathan S. Reller; Nicholas Hayden; Patrick Maroney Subject: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO   This is a good point as well. While deconstructing an event, an analyst might have to use many location relationships for an indicator. "registered_from" and "originated_from" are very different things when looking at attacks utilizing DNS fast flux. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security Without data, all you are is just another person with an opinion - Unknown From:         Mark Davidson <Mark.Davidson@nc4.com> To:         Nicholas Hayden <nhayden@anomali.com>, John A Wunder <jwunder@mitre.org> Cc:         Patrick Maroney <pmaroney@wapacklabs.com>, Bret Jordan <Bret_Jordan@symantec.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, John-Mark Gurney <jmg@newcontext.com>, CTI OASIS GROUP <cti@lists.oasis-open.org>, "Back, Greg" <gback@mitre.org>, "Nathan S. Reller" <Nathan.Reller@jhuapl.edu> Date:         06/13/2017 09:50 AM Subject:         Re: [cti] [EXT] [cti] Location as a Top-Level SDO Sent by:         <cti@lists.oasis-open.org> In the interest of achieving principled negotiation, I’ll articulate my needs for this solution: Changing the location structure later on does not require significant modification to all STIX objects. For instance, if we made location a common property with a simple location=STRING, and then transitioned to location=JSON_OBJECT, that would require a lot of engineering re-work and I’d like to avoid it. I need to use location on any SDO, not just the ones that have been pre-ordained at design time (aka “now”). We saw this problem in spades in STIX 1.x, let’s not repeat it.   So far I’ve seen examples of what location-as-a-property (LAAP, for short) would look like. Is there a more concrete proposal?   As something of a side note (but directly to Nicholas’ point), I think they key factor here is that a substantial subset of this community perceives there to be one and only one valid relationship from any SDO to a location, that of “located at” (e.g., Threat Actor located at “Joe’s Pizza”). My sense is that the count of relationships is a distinguishing factor between whether an SDO is needed, or whether the information can be represented as a property.                 If there is one and only one valid relationship type, that information can be effectively encoded in the property reference. If there is more than one valid relationship type, then the Relationship Object is needed to indicate the relationship type.   Thank you. -Mark     From: <cti@lists.oasis-open.org> on behalf of Nicholas Hayden <nhayden@anomali.com> Date: Tuesday, June 13, 2017 at 8:47 AM To: John A Wunder <jwunder@mitre.org> Cc: Patrick Maroney <pmaroney@wapacklabs.com>, Bret Jordan <Bret_Jordan@symantec.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, John-Mark Gurney <jmg@newcontext.com>, CTI OASIS GROUP <cti@lists.oasis-open.org>, "Back, Greg" <gback@mitre.org>, "Nathan S. Reller" <Nathan.Reller@jhuapl.edu> Subject: Re: [cti] [EXT] [cti] Location as a Top-Level SDO   Can we derive a "Go No GO” checklist for SDO’s?  This might help us in resolving this and to John’s point future scenarios.  My proposal is we clearly define what the characteristics are which “Qualifies” something that needs to be an SDO.  So for example does it requiring versioning “Yes” ok thats a +1 toward making it an SDO.     Best Regards, Nicholas Hayden, CISSP, GICSP, CNDA, CEH, Sec+ Director of Engineering Anomali anomali.com 808 Winslow St Redwood City, CA 94063 Phone: (650) 257-0867 Twitter: @anomali PastedGraphic-2.tiff   On Jun 12, 2017, at 4:12 PM, Wunder, John A. < jwunder@mitre.org > wrote:   Yeah +1 to Pat…we’re a CTI org, let’s not maintain a database of geolocations.   More generally I also agree w/ Allan that this doesn’t really impact the SDO question. Either you:   -           Have the library and duplicate it in the embedded types -           Have the library and reference it by UUID (if we generate STIX UUIDs for it) -           Have the library and copy it into the referenced types (if we don’t generate UUIDs for it)   It would be nice to enumerate these types of scenarios and see how we can deal with each of them in each approach. I talked to Allan and I think he has the beginnings of that document started, I’ll get with him to push it to Google docs so we can all look over it.   John   From: < cti@lists.oasis-open.org > on behalf of Patrick Maroney < pmaroney@wapacklabs.com > Date: Monday, June 12, 2017 at 3:16 PM To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com > Cc: "Jason Mr. Keirstead" < Jason.Keirstead@ca.ibm.com >, "John-Mark Mr. Gurney" < jmg@newcontext.com >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, Greg Back < gback@mitre.org >, " Nathan.Reller@jhuapl.edu " < Nathan.Reller@jhuapl.edu > Subject: Re: [cti] [EXT] [cti] Location as a Top-Level SDO   My .02:  If we're building, publishing, maintaining our own Geo-Location Data, we're doing something wrong.  This is one wheel we do not need to re-invent...again just my .02.   Patrick Maroney Principal Engineer - Data Science & Analytics Wapack Labs LLC (609)841-5104 pmaroney@wapacklabs.com   Public Key: http://pgp.mit.edu/pks/lookup?op=get&search=0x7C810C9769BD29AF   On Jun 11, 2017, at 11:58 PM, Bret Jordan < Bret_Jordan@symantec.com > wrote:   So if we were going to do this, we would probably need to build a library of locations by country and regions and publish them as a Committee Note and hope people just use the them for locations at the granularity of a country or group of countries.   Bret From: cti@lists.oasis-open.org < cti@lists.oasis-open.org > on behalf of Jason Keirstead < Jason.Keirstead@ca.ibm.com > Sent: Sunday, June 11, 2017 7:35:18 PM To: jmg@newcontext.com Cc: Bret Jordan; cti@lists.oasis-open.org ; gback@mitre.org ; Nathan.Reller@jhuapl.edu Subject: Re: [cti] Re: [EXT] [cti] Location as a Top-Level SDO   You are assuming that we don't create a repository of "standard" location SDOs for things like continent and country names - IE the things that people would want to share in the first place. Which, I don't see why we would not do this, seeing how we're doing it for things like CAPEC.   - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security Without data, all you are is just another person with an opinion - Unknown    
    Original Message


Related Content