OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Jason – I believe having the source convey what they believe the location to be is useful context even if you have the ability to determine location yourself.

 

Firstly, if a location does not match with your determined location for the same public IP/entity then that is reason to question either a) your own source b) their source’s trust level. In either case, ambiguity on location is an indication that is worth further scrutiny and not just disregarded.

 

Secondly, there are also cases where you will never be able to necessarily determine location.

 

For example, a threat source has a location of a device’s office location, floor #, x+y on the floor, building #, and campus address. This tool is being used inside a larger organization’s security infrastructure and is sharing the location using STIX/TAXII with other security tools (all within the perimeter). This information may have been determined by location capabilities that another tool as a recipient does not have access to. Typically, commonly shared location feeds are public internet only. They don’t have necessarily have the information to locate something non-public inside a perimeter.

 

Is this useful? Yes. Because an IT/SecOps incident response team can now walk to the exact location within the building where the device was located at the time of the particular issue reports on.

 

So should STIX allow location to be convey if the source has it. Yes.

 

Should the recipient always assume they know better than the source on location of the entity? It depends.

 

Allan

 

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Friday, October 14, 2016 at 11:31 AM
To: "Gary.Katz.ctr@dc3.mil" <Gary.Katz.ctr@dc3.mil>
Cc: Patrick Maroney <Pmaroney@Specere.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John" <jwunder@mitre.org>, "Bret Jordan (CS)" <bret_jordan@symantec.com>
Subject: Re: [cti-stix] RE: [Non-DoD Source] RE: [cti-stix] Re: Location in 2.0

 

To be clear - I perfectly understand why analysts desire this information.

My point (and perhaps it is being lost), is that every major security tool I have ever used in my life already has geo-location of IP addresses built into it. All of the vendors who are going to use STIX, already have geo-location.

So if you hand me a STIX document with "location" data in it, and I absorb it in my tool for analysis, should I trust that random data of which I have no idea what it's providence is or accuracy level, or look it up myself internally?

-
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


nactive hide details for "Katz, Gary CTR DC3\\DCCI" ---10/14/2016 03:05:0"Katz, Gary CTR DC3\\DCCI" ---10/14/2016 03:05:05 PM---Jason, Yes, geolocations for IPs change all the time and it is possible to use a number of diff

From: "Katz, Gary CTR DC3\\DCCI" <Gary.Katz.ctr@dc3.mil>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: "'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 03:05 PM
Subject: [cti-stix] RE: [Non-DoD Source] RE: [cti-stix] Re: Location in 2.0
Sent by: <cti-stix@lists.oasis-open.org>





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 






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







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]