Hey all,
We did raise this issue before on the lists, and had roughly the same set of people advocating for it (Pat, Allan, now Jason). We can certainly re-open it if there’s a large number of new people who want to see it, but in the absence of
that I think we should focus on this particular question. Those that want to use GeoJSON could maybe form a small group, agree on a custom property name, and if that goes well bring it up in 2.2?
Also just to re-iterate: GeoJSON **doesn’t support precision/uncertainty**…the way you would do this in GeoJSON is draw a circle centered at the lat/lng with the given radius, in which case it’s hard to differentiate if you’re saying that’s
the uncertainty or if you’re literally describing a circle (i.e. it likely resolved to a city, in which case the “correct” approach is to draw a bounding box around the city, not just a circle). If you just want to represent a lat/lng as a point there’s no
ability to specify uncertainty.
Of the other options, I’ve seen most people express that “optional, no default” is either their first or second option…to me that suggests we’re approaching consensus for that approach, though of course we should continue this discussion.
John
From: Allan Thomson <
athomson@lookingglasscyber.com>
Date: Thursday, July 20, 2017 at 10:49 AM
To: Patrick Maroney <
pmaroney@wapacklabs.com>, Sarah Kelley <
Sarah.Kelley@cisecurity.org>, Nicholas Hayden <
nhayden@anomali.com>, "kyle.r.maxwell@accenture.com" <
kyle.r.maxwell@accenture.com>, "Bret Jordan (CS)" <
Bret_Jordan@symantec.com>, John Wunder
<
jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <
cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] [External] [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision
When the topic of GeoJSON has been raised within the TC previously no one really spoke up. It seems like multiple people are now suggesting that we reconsider.
As an advocate for having GeoJSON as an option within the Location Object I would suggest that it * should * at least be an option to have a GeoJSON property included in the Location object so that the folks that wanted that capability
can use it.
Given that the TC seemed against that then our plans were to use a custom property included with the location object the GeoJSON property.
If enough orgs agree that this is of value then maybe we should not make it custom but a regular property.
Allan Thomson
CTO
+1-408-331-6646
LookingGlass Cyber Solutions
From: "cti-stix@lists.oasis-open.org" <
cti-stix@lists.oasis-open.org> on behalf of Patrick Maroney <
pmaroney@wapacklabs.com>
Date: Thursday, July 20, 2017 at 7:42 AM
To: Sarah Kelley <
Sarah.Kelley@cisecurity.org>, Nicholas Hayden <
nhayden@anomali.com>, "kyle.r.maxwell@accenture.com" <
kyle.r.maxwell@accenture.com>, Bret Jordan <
Bret_Jordan@symantec.com>, "Wunder, John" <
jwunder@mitre.org>, "cti-stix@lists.oasis-open.org"
<
cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] [External] [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision
Along with previous Use Case example of tracking/modeling the activities of a terrorist cell through their cyber footprints, there are other similar markers to what Sarah highlights: Actor X met Actor Y at location Z. Wifi and Cell data
can be used for fairly accurate human and asset location tracking (and correlation to sensor data like Video Cameras, ATM Machines, POS transactions).
We can all wholeheartedly agree that your garden variety IOC Exchange is indeed one of the major use cases for STIX/TAXII. However, it should NOT be the only use case we consider.
I'll also repeat my advocacy for adopting existing well vetted and adopted standards (like GeoJSON in this case).
The argument for adopting JSON was made and won years ago -- So let's use it here. As pointed out in this most recent incarnation: there are a wide variety of tools and frameworks that support GeoJSON. We don't need to re-litigate precision,
and any of a number of other Geo Location attributes -- It's already been done.
Question to the Chairs: Is this topic "ballot worthy"?
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 Jul 20, 2017, at 10:24 AM, Sarah Kelley <
Sarah.Kelley@cisecurity.org > wrote:
Don’t forget that location isn’t just for IP location data. It could be “This threat actor works in this building or lives at this address.”
Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-ISAC)
31 Tech Valley Drive
East Greenbush, NY 12061
sarah.kelley@cisecurity.org 518-266-3493
24x7 Security Operations Center
SOC@cisecurity.org - 1-866-787-4722
<image001.png>
<image002.png> <image003.png> <image004.png> <image005.png>
From: <
cti-stix@lists.oasis-open.org >
on behalf of Nicholas Hayden <
nhayden@anomali.com >
Date: Thursday, July 20, 2017 at 10:20 AM
To: "
kyle.r.maxwell@accenture.com " <
kyle.r.maxwell@accenture.com >
Cc: Bret Jordan <
Bret_Jordan@symantec.com >, John A Wunder <
jwunder@mitre.org >,
"
cti-stix@lists.oasis-open.org " <
cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] [External] [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision
Do we really need granularity on this item or just relative? Honestly how many ip’s are directly linked to a very specific address. From what I’ve seen majority of them are linked to a city.
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 Jul 19, 2017, at 12:22 PM,
kyle.r.maxwell@accenture.com wrote:
So what is the problem this would actually solve? I understand the use case of specifying a human-readable location (“Dallas, Texas, USA”, “1600 Pennsylvania Ave, Washington, DC”, etc.) but I don’t quite understand
what lat/long is used for in this context.
From: <
cti-stix@lists.oasis-open.org >
on behalf of Bret Jordan <
Bret_Jordan@symantec.com >
Date: Tuesday, July 18, 2017 at 9:51 PM
To: "Wunder, John A." <
jwunder@mitre.org >
Cc: "
cti-stix@lists.oasis-open.org " <
cti-stix@lists.oasis-open.org >
Subject: [External] [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision
Since we do not yet really know what we need here, I would propose that we add this field at a later time. I fully understand the problem we think we are trying to solve, but I am
not sure we have identified the best solution. It would be nice if we had a bunch of real-world problems in products that were driving this.
Further, if you are uncertain about a location you should NOT be using lat/long to represent the location. You should be using one of the other properties like region, country, city,
administrative_area, etc. Those are the named non-precise ways of doing location.
Bret
Sent from my iPhone
On Jul 18, 2017, at 11:33 PM, Wunder, John A. <
jwunder@mitre.org > wrote:
Hey everyone,
We’ve been having a conversation about the best way to represent the precision of a given latitude and longitude pair. What I mean by that is, if I give you 45.234234 latitude by 45.2342 longitude (literally just
typed random numbers there) is that describing an exact point, just pointing to a city center, or even just pointing to a country?
We have a couple options here:
Just define in normative text that, for STIX, latitude and longitude is approximate. This would mean that you couldn’t really rely on it to be accurate to an address, even in cases where it was.
Have an optional property to represent the precision. If the property is present, it describes the precision in terms of meters. If absent, we have two options:
Precision is unspecified, and consumers can take that however they want
Default precision to perhaps 10km (roughly a zip code), so consumers can pretend the value was that
Have a required precision property
We also talked about significant digits but due to the ways JSON parsers read data it would mean using a string and likely that data would also be lost in those cases too (and even if there it’s harder to get to).
It didn’t seem like a great option compared to any of the above, but maybe we’re missing something.
So, what do people think? Any other arguments for one or the other?
I don’t have any strong opinions really other than that #3 is probably not workable (producers would just make up a value in a lot of cases).
John
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by
you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of
internal compliance with Accenture policy.
______________________________________________________________________________________
www.accenture.com .....
This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination,
distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.
. . . . .