RE: [Non-DoD Source] RE: [cti-stix] Re: Location in 2.0

["Katz, Gary CTR DC3\\DCCI" <Gary.Katz.ctr@dc3.mil>]

Jason,
     Yes, geolocations for IPs change all the time and it is possible to use a number of different methods to hide your original location but it is still a very useful data point for performing cyber analytics that our analysts like to have.  

-Gary

-----Original Message-----
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jason Keirstead
Sent: Friday, October 14, 2016 1:27 PM
To: Katz, Gary CTR DC3\DCCI
Cc: 'Patrick Maroney'; cti-stix@lists.oasis-open.org; 'Wunder, John A.'; Bret Jordan (CS)
Subject: [Non-DoD Source] RE: [cti-stix] Re: Location in 2.0

I still question the utility of encoding the point-in-time results of an IP location lookup into any STIX document.

Lets not delude ourselves into thinking that the resolution of Geo IP location changes on a minute to minute basis so that it is critical that you record where it is "now" in case it changes by tomorrow, because it's just not true. The most accurate providers that exist only update their databases weekly, most only do it monthly - and the data they are using for that update, is already even further out of date, and even if it wasn't, it is still of highly questionable accuracy, especially in the ever-growing world of mobile, where it is just completely wrong 100% of the time.

And I am not even getting into VPNs, Proxies, Tor, etc.

So... what are we trying to accomplish here..

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown 


Inactive hide details for "Katz, Gary CTR DC3\\DCCI" ---10/14/2016 10:24:36 AM---If we kick it out of 2.0, all that means is th"Katz, Gary CTR DC3\\DCCI" ---10/14/2016 10:24:36 AM---If we kick it out of 2.0, all that means is that everyone that cares about where attacks are coming

From: "Katz, Gary CTR DC3\\DCCI" <Gary.Katz.ctr@dc3.mil>
To: "'Patrick Maroney'" <Pmaroney@Specere.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "'Wunder, John A.'" <jwunder@mitre.org>, "Bret Jordan (CS)" <bret_jordan@symantec.com>
Date: 10/14/2016 10:24 AM
Subject: RE: [cti-stix] Re: Location in 2.0
Sent by: <cti-stix@lists.oasis-open.org>

________________________________




If we kick it out of 2.0, all that means is that everyone that cares about where attacks are coming from (which hopefully is most of us) are going to have to custom implement a location property, with everyone implementing something different.  

-----Original Message-----
From: Patrick Maroney [mailto:Pmaroney@Specere.org] 
Sent: Friday, October 14, 2016 9:11 AM
To: cti-stix@lists.oasis-open.org; 'Wunder, John A.'; Bret Jordan (CS); Katz, Gary CTR DC3\DCCI
Subject: [Non-DoD Source] Re: [cti-stix] Re: Location in 2.0

[+1] on (1) kicking it back to 2.1 so we can get consensus & (2) removing current location artifacts so we are free to implement presumed consensus solution.


Patrick Maroney
Email: pmaroney@specere.org
Cell: (609)841-5104

________________________________

From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan (CS) <Bret_Jordan@symantec.com>
Sent: Thursday, October 13, 2016 5:47:48 PM
To: Katz, Gary CTR DC3\DCCI; 'Wunder, John A.'; cti-stix@lists.oasis-open.org
Subject: [cti-stix] Re: Location in 2.0 


Personally I feel like we constantly flirt with this line in the sand of making every field in the data model its own object with relationships linking it back.  I also worry about, how do we actually build a location object and what goes in it?  It will not be a simple straight forward debate.  I am guessing that it is about a 3 month debate to get right.  




As the email archives can attest, I am generally in favor of a flatter, simpler design.  




Bret

________________________________

From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Katz, Gary CTR DC3\DCCI <Gary.Katz.ctr@dc3.mil>
Sent: Thursday, October 13, 2016 3:19:06 PM
To: 'Wunder, John A.'; cti-stix@lists.oasis-open.org
Subject: [cti-stix] RE: Location in 2.0 

I'm not sure I completely agree with moving location to a separate SDO.  We just got done a meeting where analysts were requesting that location information, such as Geo IP data was attached to the IP and not a separate object.  Now this may be just how we display it rather than how it is held in STIX, but it's something to consider.  (Note: when we are attaching a geolocation to an IP we are including the date at which it resolved)

Either way, the below location information is pretty useful stuff.  Knowing that an intrusion set is associated with nation state A vs. nation state B is fairly important.  Same thing for an identity.  

-----Original Message-----
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Wunder, John A.
Sent: Thursday, October 13, 2016 5:00 PM
To: cti-stix@lists.oasis-open.org
Subject: [Non-DoD Source] [cti-stix] Location in 2.0

All,



One of the issues that Allan brought up at the last face-to-face is that location information might be better encoded as a separate SDO rather than as fields on the existing SDOs. Given that, how should we address location attributes in 2.0?



IMO, given that we want to discuss this in 2.1, for 2.0 we should remove location attributes from STIX (for now). That would keep us from breaking things in a future version and would mean removing the following fields:



Identity:

-          Regions

-          Nationalities



Intrusion Set:

-          Region

-          Country



Any objections to this? It would let us get 2.0 out and then work on location for 2.1.



Thanks,

John



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