CTI STIX Subcommittee

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

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

Pat,


I have no doubt that there are organizations with use-cases that require tracking such geolocation data. However, it isn't clear to me that this is the sort of information that would be frequently shared across sub-community boundaries. Each non-trivial
capability we add to STIX (even if it is optional) increases both the real and perceived workload for producers of STIX-compliant tools. Therefore, we need to be very careful about such additions.



I would suggest that if there is a sub-commmunity that wishes to share GeoJSON-specified bounding boxes and other such data that that community can and should agree on custom-properties to convey this information. Then, down the road if there is widespread
demand for this data to be standardized, we can add it to STIX.


This work is always a balancing act and there isn't one "right" answer. However, in this case my preference, FWIW, is that we adopt a wait-and-see attitude towards adding GeoJSON.



Rich

Sent with BlackBerry Work
(www.blackberry.com)




From: Patrick Maroney < pmaroney@wapacklabs.com >
Date: Tuesday, Jun 27, 2017, 6:18 PM



To: Wunder, John A. < jwunder@mitre.org >
Cc: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] GeoJSON


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

I agree with you Rich.  We can easily add this later if there proves to be a ground swell of need. Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Struse, Richard J. <rjs@mitre.org> Sent: Wednesday, June 28, 2017 5:51:47 AM To: Patrick Maroney; Wunder, John A. Cc: cti-stix@lists.oasis-open.org Subject: [EXT] RE: [cti-stix] GeoJSON   Pat, I have no doubt that there are organizations with use-cases that require tracking such geolocation data. However, it isn't clear to me that this is the sort of information that would be frequently shared across sub-community boundaries. Each non-trivial capability we add to STIX (even if it is optional) increases both the real and perceived workload for producers of STIX-compliant tools. Therefore, we need to be very careful about such additions. I would suggest that if there is a sub-commmunity that wishes to share GeoJSON-specified bounding boxes and other such data that that community can and should agree on custom-properties to convey this information. Then, down the road if there is widespread demand for this data to be standardized, we can add it to STIX. This work is always a balancing act and there isn't one "right" answer. However, in this case my preference, FWIW, is that we adopt a wait-and-see attitude towards adding GeoJSON. Rich Sent with BlackBerry Work (www.blackberry.com) From: Patrick Maroney < pmaroney@wapacklabs.com > Date: Tuesday, Jun 27, 2017, 6:18 PM To: Wunder, John A. < jwunder@mitre.org > Cc: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] GeoJSON 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

Hey all,
 
Unless there are any other last-minute thoughts on this it seems like we probably don’t have enough support to include GeoJSON. We can move forward without it for 2.1 and re-evaluate in future releases.

John
 

From: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
Date: Wednesday, June 28, 2017 at 2:21 PM
To: "Struse, Richard J." <rjs@mitre.org>, Patrick Maroney <pmaroney@wapacklabs.com>, John Wunder <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [EXT] RE: [cti-stix] GeoJSON


 


I agree with you Rich.  We can easily add this later if there proves to be a ground swell of need.
 
Bret





From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Struse, Richard J. <rjs@mitre.org>
Sent: Wednesday, June 28, 2017 5:51:47 AM
To: Patrick Maroney; Wunder, John A.
Cc: cti-stix@lists.oasis-open.org
Subject: [EXT] RE: [cti-stix] GeoJSON

 




Pat,


 


I have no doubt that there are organizations with use-cases that require tracking such geolocation data. However, it isn't clear to me that this is the sort of information that would be frequently shared across sub-community boundaries.
Each non-trivial capability we add to STIX (even if it is optional) increases both the real and perceived workload for producers of STIX-compliant tools. Therefore, we need to be very careful about such additions.



 


I would suggest that if there is a sub-commmunity that wishes to share GeoJSON-specified bounding boxes and other such data that that community can and should agree on custom-properties to convey this information. Then, down the road if
there is widespread demand for this data to be standardized, we can add it to STIX.



 


This work is always a balancing act and there isn't one "right" answer. However, in this case my preference, FWIW, is that we adopt a wait-and-see attitude towards adding GeoJSON.



 


Rich


Sent with BlackBerry Work
(www.blackberry.com)






From: Patrick Maroney < pmaroney@wapacklabs.com >


Date: Tuesday, Jun 27, 2017, 6:18 PM


 



To: Wunder, John A. < jwunder@mitre.org >


Cc: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org >


Subject: Re: [cti-stix] GeoJSON


 

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

On 27.06.2017 20:45:48, Wunder, John A. wrote: > > 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. > Slight clarification: on the call we discussed the possibility of representing lat/long as GeoJSON Points, which *would* eliminate the "two ways of doing things" problem. That said, tools which only aimed for MaxMind functionality might not be capable of processing GeoJSON Polygons. (This might be addressed by some thoughtful additions to the Interoperability specs.) John's right about the consensus on the working call: unless some compelling arguments are brought to the table, most likely we will defer GeoJSON support to STIX 2.2+. -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "When old dreams die, new ones come to take their place. God pity a one-dream man." --Robert Goddard Attachment: signature.asc Description: Digital signature

To clarify, I think what would be deferred to a later date is re-evaluating whether or not GeoJSON support belongs in STIX at all.  As written it sounded as if that was a foregone conclusion that was simply pushed to a later release. 
I don’t believe that to be the case.
 
On 6/28/17, 8:05 AM, "Trey Darley" <cti-stix@lists.oasis-open.org on behalf of trey@newcontext.com> wrote:
 
    On 27.06.2017 20:45:48, Wunder, John A. wrote:
    >
    > 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.
    >
    
    Slight clarification: on the call we discussed the possibility of
    representing lat/long as GeoJSON Points, which *would* eliminate the
    "two ways of doing things" problem.
   
    That said, tools which only aimed for MaxMind functionality might not
    be capable of processing GeoJSON Polygons. (This might be addressed by
    some thoughtful additions to the Interoperability specs.)
   
    John's right about the consensus on the working call: unless some
    compelling arguments are brought to the table, most likely we will
   
defer GeoJSON support to STIX 2.2+.
   
    --
    Cheers,
    Trey
    ++--------------------------------------------------------------------------++
    Director of Standards Development, New Context
    gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338
    ++--------------------------------------------------------------------------++
    --
    "When old dreams die, new ones come to take their place. God pity a
    one-dream man." --Robert Goddard
   

On 28.06.2017 12:20:09, Struse, Richard J. wrote: > To clarify, I think what would be deferred to a later date is > re-evaluating whether or not GeoJSON support belongs in STIX at all. > As written it sounded as if that was a foregone conclusion that was > simply pushed to a later release. I don’t believe that to be the > case. > Thanks for the clarification, Richard. It was not my intent to suggest that GeoJSON would *definitely* be added in a future release. Poor phraseology on my part, apologies for the confusion. -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "It Has To Work." --RFC 1925 Attachment: signature.asc Description: Digital signature

Lets do what we have now in the doc, and push the debate about GeoJSON to a future date.   Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Trey Darley <trey@newcontext.com> Sent: Wednesday, June 28, 2017 6:25:00 AM To: Struse, Richard J. Cc: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: [EXT] Re: [cti-stix] GeoJSON   On 28.06.2017 12:20:09, Struse, Richard J. wrote: > To clarify, I think what would be deferred to a later date is > re-evaluating whether or not GeoJSON support belongs in STIX at all. > As written it sounded as if that was a foregone conclusion that was > simply pushed to a later release. I don’t believe that to be the > case. > Thanks for the clarification, Richard. It was not my intent to suggest that GeoJSON would *definitely* be added in a future release. Poor phraseology on my part, apologies for the confusion. -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "It Has To Work." --RFC 1925