Re: [cti-stix] GeoJSON

[Patrick Maroney <pmaroney@wapacklabs.com>]

We have an existing well defined/adopted JSON representation for GeoLocation data.  There are a variety of Open Source libraries, frameworks, et al that can consume, understand, and produce a rich representation of GeoLocation attributes.  For example Elastic Stack.  

Use Case --  We had a recent use case to map the real-time spread of WannaCry from both a temporal and GeoLocation perspective.  The ability to visualize multiple overlays of geographic regions as a time-series map of ISP Endpoints, ASNs, et al, was extremely powerful and provided valuable unique insights.  We leveraged the inherent OOTB Elastic Search GeoJSON capabilities to quickly develop this time-series Kibana geo dashboard. 

While not specifically in the scope of the CTI TC, the fusion of physical to cyber domains is a critical requirement to meet the underlying objectives of our endeavors.  For example, the time-series mapping of the movement and interactions of terrorist cells in the physical domain via cyber based observables (cell phones, Wifi Hotspots, Digital Video surveillance, Train/Airline Tickets) is a case in point for real-world use cases. Ever increasing Triangulation accuracy within polygonal geoloc data is the scenario.

 Throw in IoT as well.   

To the extent we can exercise our due diligence (without undue impacts to our core mission statements), we should ensure we can integrate and fuse with these other Domains.  

Therefore I advocate for adoption of the full representational capabilities of GeoJSON in CTI TC STIX.

Patrick Maroney

Principal Engineer - Data Science & Analytics

Wapack Labs LLC

pmaroney@wapacklabs.com

(609)841-5104

On Jun 27, 2017, at 4:45 PM, Wunder, John A. <jwunder@mitre.org> wrote:

Hey all,

 

One of the topics we’ve been talking about for location is the inclusion of a field to capture GeoJSON (http://geojson.org/) content. If you’re not familiar, GeoJSON is an RFC to capture geographic data structures (points, lines, multipoints, multilines, polygons, collections) in JSON.

 

Allan Thomson has suggested that we include GeoJSON on the location object. We discussed it a bit on the working call today, though, and it seemed like nobody had a real need for it…people pretty much just wanted the attributes from maxmind (region, country, administrative_area, city, street_address, latitude, longitude) and felt that GeoJSON was too much at this point. But obviously the TC is bigger than the working call.

 

To outline the options:

 

Option 1: Include GeoJSON as an optional property alongside the other MaxMind-style attributes, including latitude and longitude. This creates a bit of “two ways of doing things”, because then you can either use GeoJSON to represent a point or you can just use the lat/long fields in the core location object.

 

Option 2: Defer GeoJSON for now, mark it as a reserved word. This means that we have one very straightforward way of representing both addresses and lat/lng, but do not have a way to draw other geometries (multiple points, lines, bounding boxes, etc).

 

Which do people prefer? Do you have a use case for the more feature-rich capabilities that GeoJSON provides, or is it sufficient to just stick with the MaxMind attributes? If you think we should go with Option 1, do you have use cases for the more complicated data structures that you can share?

 

Consensus from the working call (about 12 people on the call) is that we should go with Option 2 and not include GeoJSON at this time.

 

Thanks,

John