CTI STIX Subcommittee

Products are going to visually represent this information to users, so we need some concrete information around it.
 
Here are some examples, which are rental listings on HomeAway.com for a non-CTI example. (They are Portland, ME, not Portland, OR)
 
In a product, visually, an “imprecise” location is reasonable to represent as a circle (e.g., lat/long + precision):

 
Whereas a “precise” location could use a pin

 
 
As a potential consumer of this information, I would go for:
 
1.       
Lat/long (required)
2.       
Precision (optional, defaults to 0)

a.       
Alternatively we could just not have this field, and potentially add it in a later release
3.       
Some text describing that lat/long + precision define a geometric shape (e.g., a circle) that includes the location. This not only accounts for imprecision in the source data, it enables the use
case where somebody doesn’t want to be as specific as they could be. Maybe higher $$$ data sets are more precise.
 
When I think of Soltra’s use cases for location, it is displaying the information on screen for users, workflows (e.g., auto-route anything in APAC to team XYZ), and enrichment. The fields I list above support
all those. Anything that’s crazy big (e.g., lat/long, precision=1 AU) could get kicked out to a human for categorization or rejection.
 
Producers of CTI can weigh in on how useful the location property is or would be.
 
Thank you.
-Mark
 

From: <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Wednesday, July 19, 2017 at 12:51 AM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [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
 



Disclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify
the sender and destroy and delete any copies you may have received.

One quick note about our current Location SDO is that lat/lng are not required. You can say “US” or “Washington, DC, US” without giving a lat/lng, for example. Precision describes specifically precision of
lat/lng, though.
 
I’m also not sure how realistic a precision of 0 is. Even an address isn’t really precise to 0 meters, and this would mean that producers who can’t be bothered to populate precision are by default saying their
lat/lng is super precise, which is probably not accurate. If we do have optional with a default, I’d suggest we go with what New Context came up with (10km) in the absence of other compelling reasons.
 
John
 

From: Mark Davidson <Mark.Davidson@nc4.com>
Date: Wednesday, July 19, 2017 at 7:59 AM
To: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, John Wunder <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

Products are going to visually represent this information to users, so we need some concrete information around it.
 
Here are some examples, which are rental listings on HomeAway.com for a non-CTI example. (They are Portland, ME, not Portland, OR)
 
In a product, visually, an “imprecise” location is reasonable to represent as a circle (e.g., lat/long + precision):

 
Whereas a “precise” location could use a pin

 
 
As a potential consumer of this information, I would go for:
 

Lat/long (required) Precision (optional, defaults to 0)

Alternatively we could just not have this field, and potentially add it in a later release
Some text describing that lat/long + precision define a geometric shape (e.g., a circle) that includes the location. This not only accounts for imprecision
in the source data, it enables the use case where somebody doesn’t want to be as specific as they could be. Maybe higher $$$ data sets are more precise.
 
When I think of Soltra’s use cases for location, it is displaying the information on screen for users, workflows (e.g., auto-route anything in APAC to team XYZ), and enrichment. The fields I list above support
all those. Anything that’s crazy big (e.g., lat/long, precision=1 AU) could get kicked out to a human for categorization or rejection.
 
Producers of CTI can weigh in on how useful the location property is or would be.
 
Thank you.
-Mark
 

From: <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Wednesday, July 19, 2017 at 12:51 AM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [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
 


Disclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure
under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received
this communication in error, please notify the sender and destroy and delete any copies you may have received.

I’ve come to believe that precision should be optional.  The purist in me wants the text to say that if precision is omitted, the precision of the lat/long is unspecified.  But I’m willing to live with text
that says if precision is unspecified, it defaults to 10km as John-Mark originally proposed.
 

From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Wednesday, July 19, 2017 at 8:32 AM
To: Mark Davidson <Mark.Davidson@nc4.com>, Bret Jordan <Bret_Jordan@symantec.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

One quick note about our current Location SDO is that lat/lng are not required. You can say “US” or “Washington, DC, US” without giving a lat/lng, for example. Precision describes specifically precision of
lat/lng, though.
 
I’m also not sure how realistic a precision of 0 is. Even an address isn’t really precise to 0 meters, and this would mean that producers who can’t be bothered to populate precision are by default saying their
lat/lng is super precise, which is probably not accurate. If we do have optional with a default, I’d suggest we go with what New Context came up with (10km) in the absence of other compelling reasons.
 
John
 

From: Mark Davidson <Mark.Davidson@nc4.com>
Date: Wednesday, July 19, 2017 at 7:59 AM
To: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, John Wunder <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

Products are going to visually represent this information to users, so we need some concrete information around it.
 
Here are some examples, which are rental listings on HomeAway.com for a non-CTI example. (They are Portland, ME, not Portland, OR)
 
In a product, visually, an “imprecise” location is reasonable to represent as a circle (e.g., lat/long + precision):

 
Whereas a “precise” location could use a pin

 
 
As a potential consumer of this information, I would go for:
 

Lat/long (required) Precision (optional, defaults to 0)


Alternatively we could just not have this field, and potentially add it in a later release
Some text describing that lat/long + precision define a geometric shape (e.g., a circle) that includes the location. This not only accounts for imprecision
in the source data, it enables the use case where somebody doesn’t want to be as specific as they could be. Maybe higher $$$ data sets are more precise.
 
When I think of Soltra’s use cases for location, it is displaying the information on screen for users, workflows (e.g., auto-route anything in APAC to team XYZ), and enrichment. The fields I list above support
all those. Anything that’s crazy big (e.g., lat/long, precision=1 AU) could get kicked out to a human for categorization or rejection.
 
Producers of CTI can weigh in on how useful the location property is or would be.
 
Thank you.
-Mark
 

From: <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Wednesday, July 19, 2017 at 12:51 AM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [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
 


Disclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure
under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received
this communication in error, please notify the sender and destroy and delete any copies you may have received.

On 19.07.2017 12:47:55, Struse, Richard J. wrote: > I’ve come to believe that precision should be optional. The purist > in me wants the text to say that if precision is omitted, the > precision of the lat/long is unspecified. But I’m willing to live > with text that says if precision is unspecified, it defaults to 10km > as John-Mark originally proposed. > Thanks, Rich. I think this is the correct approach. -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "No matter how hard you try, you can't make a baby in much less than 9 months. Trying to speed this up *might* make it slower, but it won't make it happen any quicker." --RFC 1925 Attachment: signature.asc Description: Digital signature

I disagree Bret Sent from my iPhone > On Jul 19, 2017, at 3:39 PM, Trey Darley <trey@newcontext.com> wrote: > >> On 19.07.2017 12:47:55, Struse, Richard J. wrote: >> I’ve come to believe that precision should be optional. The purist >> in me wants the text to say that if precision is omitted, the >> precision of the lat/long is unspecified. But I’m willing to live >> with text that says if precision is unspecified, it defaults to 10km >> as John-Mark originally proposed. >> > > Thanks, Rich. > > I think this is the correct approach. > > -- > Cheers, > Trey > ++--------------------------------------------------------------------------++ > Director of Standards Development, New Context > gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 > ++--------------------------------------------------------------------------++ > -- > "No matter how hard you try, you can't make a baby in much less than 9 > months. Trying to speed this up *might* make it slower, but it won't > make it happen any quicker." --RFC 1925

Your opinion is noted. What do others on the list think? On 7/19/17, 9:59 AM, "Bret Jordan" <Bret_Jordan@symantec.com> wrote: I disagree Bret Sent from my iPhone > On Jul 19, 2017, at 3:39 PM, Trey Darley <trey@newcontext.com> wrote: > >> On 19.07.2017 12:47:55, Struse, Richard J. wrote: >> I’ve come to believe that precision should be optional. The purist >> in me wants the text to say that if precision is omitted, the >> precision of the lat/long is unspecified. But I’m willing to live >> with text that says if precision is unspecified, it defaults to 10km >> as John-Mark originally proposed. >> > > Thanks, Rich. > > I think this is the correct approach. > > -- > Cheers, > Trey > ++--------------------------------------------------------------------------++ > Director of Standards Development, New Context > gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 > ++--------------------------------------------------------------------------++ > -- > "No matter how hard you try, you can't make a baby in much less than 9 > months. Trying to speed this up *might* make it slower, but it won't > make it happen any quicker." --RFC 1925

I agree with Bret's point about unspecified data being unspecified.  Since we cannot know what the actual value is, we should not be adding that data.  Leave it to the provider to include it if they have it.  So my opinion is leave it as optional and only use with a value if it is actually specified by the provider. Rich Shok U.S. Bank - Information Security Services Threat Intelligence & Automation 612.973.7185 - Office richard.shok@usbank.com From:         "Struse, Richard J." <rjs@mitre.org> To:         Bret Jordan <Bret_Jordan@symantec.com>, Trey Darley <trey@newcontext.com> Cc:         "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date:         07/19/2017 09:04 AM Subject:         [EXTERNAL] Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision Sent by:         <cti-stix@lists.oasis-open.org> Your opinion is noted. What do others on the list think? On 7/19/17, 9:59 AM, "Bret Jordan" <Bret_Jordan@symantec.com> wrote:    I disagree    Bret            Sent from my iPhone        > On Jul 19, 2017, at 3:39 PM, Trey Darley <trey@newcontext.com> wrote:    >    >> On 19.07.2017 12:47:55, Struse, Richard J. wrote:    >> I’ve come to believe that precision should be optional. The purist    >> in me wants the text to say that if precision is omitted, the    >> precision of the lat/long is unspecified. But I’m willing to live    >> with text that says if precision is unspecified, it defaults to 10km    >> as John-Mark originally proposed.    >>    >    > Thanks, Rich.    >    > I think this is the correct approach.    >    > --    > Cheers,    > Trey    > ++--------------------------------------------------------------------------++    > Director of Standards Development, New Context    > gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338    > ++--------------------------------------------------------------------------++    > --    > "No matter how hard you try, you can't make a baby in much less than 9    > months. Trying to speed this up *might* make it slower, but it won't    > make it happen any quicker." --RFC 1925     U.S. BANCORP made the following annotations --------------------------------------------------------------------- Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. ---------------------------------------------------------------------

As I stated a few days ago - if we are
going to start including precision then I would rather we just go back
to GeoJSON which is an existing RFC supported out of the box by many products. Folks pressed to not use GeoJSON because
they would not use all the features, and now we're talking about re-inventing
things it already gives us. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security Without data, all you are is just another person with an opinion - Unknown
From:      
  "Struse, Richard
J." <rjs@mitre.org> To:      
  Bret Jordan <Bret_Jordan@symantec.com>,
Trey Darley <trey@newcontext.com> Cc:      
  "Wunder, John
A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>,
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date:      
  07/19/2017 11:02 AM Subject:    
    Re: [cti-stix]
Re: [EXT] [cti-stix] Location, latitude/longitude, and precision Sent by:    
    <cti-stix@lists.oasis-open.org> Your opinion is noted. What do others on the list
think? On 7/19/17, 9:59 AM, "Bret Jordan" <Bret_Jordan@symantec.com>
wrote:    I disagree    Bret            Sent from my iPhone        > On Jul 19, 2017, at 3:39 PM, Trey Darley <trey@newcontext.com>
wrote:    >    >> On 19.07.2017 12:47:55, Struse, Richard J. wrote:    >> I’ve come to believe that precision should be optional.
The purist    >> in me wants the text to say that if precision is
omitted, the    >> precision of the lat/long is unspecified. But I’m
willing to live    >> with text that says if precision is unspecified,
it defaults to 10km    >> as John-Mark originally proposed.    >>    >    > Thanks, Rich.    >    > I think this is the correct approach.    >    > --    > Cheers,    > Trey    > ++--------------------------------------------------------------------------++    > Director of Standards Development, New Context    > gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A
831A 270A 6C4F C338    > ++--------------------------------------------------------------------------++    > --    > "No matter how hard you try, you can't make a baby
in much less than 9    > months. Trying to speed this up *might* make it slower,
but it won't    > make it happen any quicker." --RFC 1925    

In all fairness, GeoJSON is a big lift in terms of implementation complexity and isn’t really comparable to one additional precision property.
 
Given that, how would you respond to John’s original question regarding precision?
 

From: <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, July 19, 2017 at 10:32 AM
To: Richard Struse <rjs@mitre.org>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

As I stated a few days ago - if we are going to start including precision then I would rather we just go back to GeoJSON which is an existing RFC supported out of the box by
many products.

Folks pressed to not use GeoJSON because they would not use all the features, and now we're talking about re-inventing things it already gives us.

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

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




From:         "Struse, Richard J." <rjs@mitre.org>
To:         Bret Jordan <Bret_Jordan@symantec.com>, Trey Darley <trey@newcontext.com>
Cc:         "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>
Date:         07/19/2017 11:02 AM
Subject:         Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision
Sent by:         <cti-stix@lists.oasis-open.org>






Your opinion is noted. What do others on the list think?

On 7/19/17, 9:59 AM, "Bret Jordan" <Bret_Jordan@symantec.com> wrote:

   I disagree
   Bret
   
   
   Sent from my iPhone
   
   > On Jul 19, 2017, at 3:39 PM, Trey Darley <trey@newcontext.com> wrote:
   >
   >> On 19.07.2017 12:47:55, Struse, Richard J. wrote:
   >> I’ve come to believe that precision should be optional. The purist
   >> in me wants the text to say that if precision is omitted, the
   >> precision of the lat/long is unspecified. But I’m willing to live
   >> with text that says if precision is unspecified, it defaults to 10km
   >> as John-Mark originally proposed.
   >>
   >
   > Thanks, Rich.
   >
   > I think this is the correct approach.
   >
   > --
   > Cheers,
   > Trey
   > ++--------------------------------------------------------------------------++
   > Director of Standards Development, New Context
   > gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338
   > ++--------------------------------------------------------------------------++
   > --
   > "No matter how hard you try, you can't make a baby in much less than 9
   > months. Trying to speed this up *might* make it slower, but it won't
   > make it happen any quicker." --RFC 1925
   

Yeah I agree with Rich here, GeoJSON is far beyond a lat/lng with precision. In fact, looking through the GeoJSON specification, they don’t even include anything to indicate precision or uncertainty.
 

From: "Struse, Richard J." <rjs@mitre.org>
Date: Wednesday, July 19, 2017 at 10:36 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, John Wunder <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

In all fairness, GeoJSON is a big lift in terms of implementation complexity and isn’t really comparable to one additional precision property.
 
Given that, how would you respond to John’s original question regarding precision?
 

From: <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, July 19, 2017 at 10:32 AM
To: Richard Struse <rjs@mitre.org>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

As I stated a few days ago - if we are going to start including precision then I would rather we just go back to GeoJSON which is an existing RFC supported out of the box
by many products.

Folks pressed to not use GeoJSON because they would not use all the features, and now we're talking about re-inventing things it already gives us.

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

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




From:         "Struse, Richard J." <rjs@mitre.org>
To:         Bret Jordan <Bret_Jordan@symantec.com>, Trey Darley <trey@newcontext.com>
Cc:         "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>
Date:         07/19/2017 11:02 AM
Subject:         Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision
Sent by:         <cti-stix@lists.oasis-open.org>






Your opinion is noted. What do others on the list think?

On 7/19/17, 9:59 AM, "Bret Jordan" <Bret_Jordan@symantec.com> wrote:

   I disagree
   Bret
   
   
   Sent from my iPhone
   
   > On Jul 19, 2017, at 3:39 PM, Trey Darley <trey@newcontext.com> wrote:
   >
   >> On 19.07.2017 12:47:55, Struse, Richard J. wrote:
   >> I’ve come to believe that precision should be optional. The purist
   >> in me wants the text to say that if precision is omitted, the
   >> precision of the lat/long is unspecified. But I’m willing to live
   >> with text that says if precision is unspecified, it defaults to 10km
   >> as John-Mark originally proposed.
   >>
   >
   > Thanks, Rich.
   >
   > I think this is the correct approach.
   >
   > --
   > Cheers,
   > Trey
   > ++--------------------------------------------------------------------------++
   > Director of Standards Development, New Context
   > gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338
   > ++--------------------------------------------------------------------------++
   > --
   > "No matter how hard you try, you can't make a baby in much less than 9
   > months. Trying to speed this up *might* make it slower, but it won't
   > make it happen any quicker." --RFC 1925
   

Sorry for the spam, but Section 3.4.3 of GeoURI is also instructive:

3.4.3 . 
Location Uncertainty
   The 'u' ("uncertainty") parameter indicates the amount of uncertainty
   in the location as a value in meters.  Where a 'geo' URI is used to
   identify the location of a particular object, <uval> indicates the
   uncertainty with which the identified location of the subject is
   known.
 
   The 'u' parameter is optional and it can appear only once.  If it is
   not specified, this indicates that uncertainty is unknown or
   unspecified.  If the intent is to indicate a specific point in space,
 
   <uval> MAY be set to zero.  Zero uncertainty and absent uncertainty
   are never the same thing.
 
   The single uncertainty value is applied to all dimensions given in
   the URI.
 
   Note: The number of digits of the values in <coordinates> MUST NOT be
   interpreted as an indication to the level of uncertainty.
 
https://tools.ietf.org/html/rfc5870#page-8
 
So of the things we’ve talked about:
 

GeoJSON does not include uncertainty/precision GeoURI does, and it’s optional with no default (or a default of “unspecified”)
 
I think it’s important to note though that our use case is different…we’re talking about location
specifically for CTI . Given that specific domain space, where IP geolocation is very common and is typically precise to a city, I also feel like optional with a default of 10km makes the most sense. Optional with no default also seems very reasonable
though.
 
John
 

From: <cti-stix@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org>
Date: Wednesday, July 19, 2017 at 10:43 AM
To: "Struse, Richard J." <rjs@mitre.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

Yeah I agree with Rich here, GeoJSON is far beyond a lat/lng with precision. In fact, looking through the GeoJSON specification, they don’t even include anything to indicate precision or uncertainty.
 

From: "Struse, Richard J." <rjs@mitre.org>
Date: Wednesday, July 19, 2017 at 10:36 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, John Wunder <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

In all fairness, GeoJSON is a big lift in terms of implementation complexity and isn’t really comparable to one additional precision property.
 
Given that, how would you respond to John’s original question regarding precision?
 

From: <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, July 19, 2017 at 10:32 AM
To: Richard Struse <rjs@mitre.org>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

As I stated a few days ago - if we are going to start including precision then I would rather we just go back to GeoJSON which is an existing RFC supported out of the box
by many products.

Folks pressed to not use GeoJSON because they would not use all the features, and now we're talking about re-inventing things it already gives us.

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

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




From:         "Struse, Richard J." <rjs@mitre.org>
To:         Bret Jordan <Bret_Jordan@symantec.com>, Trey Darley <trey@newcontext.com>
Cc:         "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>
Date:         07/19/2017 11:02 AM
Subject:         Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision
Sent by:         <cti-stix@lists.oasis-open.org>






Your opinion is noted. What do others on the list think?

On 7/19/17, 9:59 AM, "Bret Jordan" <Bret_Jordan@symantec.com> wrote:

   I disagree
   Bret
   
   
   Sent from my iPhone
   
   > On Jul 19, 2017, at 3:39 PM, Trey Darley <trey@newcontext.com> wrote:
   >
   >> On 19.07.2017 12:47:55, Struse, Richard J. wrote:
   >> I’ve come to believe that precision should be optional. The purist
   >> in me wants the text to say that if precision is omitted, the
   >> precision of the lat/long is unspecified. But I’m willing to live
   >> with text that says if precision is unspecified, it defaults to 10km
   >> as John-Mark originally proposed.
   >>
   >
   > Thanks, Rich.
   >
   > I think this is the correct approach.
   >
   > --
   > Cheers,
   > Trey
   > ++--------------------------------------------------------------------------++
   > Director of Standards Development, New Context
   > gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338
   > ++--------------------------------------------------------------------------++
   > --
   > "No matter how hard you try, you can't make a baby in much less than 9
   > months. Trying to speed this up *might* make it slower, but it won't
   > make it happen any quicker." --RFC 1925
   

I have to disagree RE "implementation
complexity". Either way it is a couple of dozen bytes
of JSON. If anything, "rolling our own"
is dramatically increasing our complexity because it means now I can no
longer use a prepared library or feed it into any third party product (ref:
http://wiki.geojson.org/Users ) - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security Without data, all you are is just another person with an opinion - Unknown
From:      
  "Wunder, John
A." <jwunder@mitre.org> To:      
  "Struse, Richard
J." <rjs@mitre.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com> Cc:      
  Bret Jordan <Bret_Jordan@symantec.com>,
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>,
Mark Davidson <Mark.Davidson@nc4.com>, "Trey Darley" <trey@newcontext.com> Date:      
  07/19/2017 11:43 AM Subject:    
    Re: [cti-stix]
Re: [EXT] [cti-stix] Location, latitude/longitude, and precision Yeah I agree with Rich here, GeoJSON is
far beyond a lat/lng with precision. In fact, looking through the GeoJSON
specification, they don’t even include anything to indicate precision
or uncertainty.   From: "Struse, Richard J."
<rjs@mitre.org> Date: Wednesday, July 19, 2017 at 10:36 AM To: Jason Keirstead <Jason.Keirstead@ca.ibm.com> Cc: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>,
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>,
John Wunder <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>,
Trey Darley <trey@newcontext.com> Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude,
and precision   In all fairness, GeoJSON is a big lift
in terms of implementation complexity and isn’t really comparable to one
additional precision property.   Given that, how would you respond to John’s
original question regarding precision?   From: <cti-stix@lists.oasis-open.org>
on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com> Date: Wednesday, July 19, 2017 at 10:32 AM To: Richard Struse <rjs@mitre.org> Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>,
Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com> Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude,
and precision   As I stated a few days ago - if we are
going to start including precision then I would rather we just go back
to GeoJSON which is an existing RFC supported out of the box by many products. Folks pressed to not use GeoJSON because they would not use all the features,
and now we're talking about re-inventing things it already gives us. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security Without data, all you are is just another person with an opinion - Unknown
From:         "Struse,
Richard J." <rjs@mitre.org> To:         Bret
Jordan <Bret_Jordan@symantec.com>, Trey Darley <trey@newcontext.com> Cc:         "Wunder,
John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>,
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date:         07/19/2017
11:02 AM Subject:         Re:
[cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision Sent by:         <cti-stix@lists.oasis-open.org> Your opinion is noted. What do others on the list think? On 7/19/17, 9:59 AM, "Bret Jordan" <Bret_Jordan@symantec.com>
wrote:   I disagree   Bret       Sent from my iPhone     > On Jul 19, 2017, at 3:39 PM, Trey Darley <trey@newcontext.com>
wrote:   >   >> On 19.07.2017 12:47:55, Struse, Richard J. wrote:   >> I’ve come to believe that precision should be optional.
The purist   >> in me wants the text to say that if precision is omitted,
the   >> precision of the lat/long is unspecified. But I’m willing
to live   >> with text that says if precision is unspecified, it defaults
to 10km   >> as John-Mark originally proposed.   >>   >   > Thanks, Rich.   >   > I think this is the correct approach.   >   > --   > Cheers,   > Trey   > ++--------------------------------------------------------------------------++   > Director of Standards Development, New Context   > gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A
270A 6C4F C338   > ++--------------------------------------------------------------------------++   > --   > "No matter how hard you try, you can't make a baby in
much less than 9   > months. Trying to speed this up *might* make it slower, but
it won't   > make it happen any quicker." --RFC 1925  

I’m not sure I agree that GeoJSON is a ‘big lift’. It’s a list of key/value pairs in JSON.

 
You can choose to implement a subset of what it provides to begin with, but have a consistent framework to implement more advanced features going forward without having to add numerous new fields everytime a new sub-feature is desired by
an org.
 

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 "Struse, Richard J." <rjs@mitre.org>
Date: Wednesday, July 19, 2017 at 7:36 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John" <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

In all fairness, GeoJSON is a big lift in terms of implementation complexity and isn’t really comparable to one additional precision property.
 
Given that, how would you respond to John’s original question regarding precision?
 

From: <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, July 19, 2017 at 10:32 AM
To: Richard Struse <rjs@mitre.org>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

As I stated a few days ago - if we are going to start including precision then I would rather we just go back to GeoJSON which is an existing RFC supported out of the box
by many products.

Folks pressed to not use GeoJSON because they would not use all the features, and now we're talking about re-inventing things it already gives us.

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

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




From:         "Struse, Richard J." <rjs@mitre.org>
To:         Bret Jordan <Bret_Jordan@symantec.com>, Trey Darley <trey@newcontext.com>
Cc:         "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>
Date:         07/19/2017 11:02 AM
Subject:         Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision
Sent by:         <cti-stix@lists.oasis-open.org>






Your opinion is noted. What do others on the list think?

On 7/19/17, 9:59 AM, "Bret Jordan" <Bret_Jordan@symantec.com> wrote:

   I disagree
   Bret
   
   
   Sent from my iPhone
   
   > On Jul 19, 2017, at 3:39 PM, Trey Darley <trey@newcontext.com> wrote:
   >
   >> On 19.07.2017 12:47:55, Struse, Richard J. wrote:
   >> I’ve come to believe that precision should be optional. The purist
   >> in me wants the text to say that if precision is omitted, the
   >> precision of the lat/long is unspecified. But I’m willing to live
   >> with text that says if precision is unspecified, it defaults to 10km
   >> as John-Mark originally proposed.
   >>
   >
   > Thanks, Rich.
   >
   > I think this is the correct approach.
   >
   > --
   > Cheers,
   > Trey
   > ++--------------------------------------------------------------------------++
   > Director of Standards Development, New Context
   > gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338
   > ++--------------------------------------------------------------------------++
   > --
   > "No matter how hard you try, you can't make a baby in much less than 9
   > months. Trying to speed this up *might* make it slower, but it won't
   > make it happen any quicker." --RFC 1925
   

I believe that the consensus has generally been that we do NOT want to include GeoJSON in the Location object for STIX 2.1.
 
So, it sounds like optional precision with an UNDEFINED precision if the property is omitted is your preference.
 

From: Allan Thomson <athomson@lookingglasscyber.com>
Date: Wednesday, July 19, 2017 at 11:00 AM
To: Richard Struse <rjs@mitre.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

I’m not sure I agree that GeoJSON is a ‘big lift’. It’s a list of key/value pairs in JSON.

 
You can choose to implement a subset of what it provides to begin with, but have a consistent framework to implement more advanced features going forward without having to add numerous new fields everytime a new sub-feature is desired by
an org.
 

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 "Struse, Richard J." <rjs@mitre.org>
Date: Wednesday, July 19, 2017 at 7:36 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John" <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

In all fairness, GeoJSON is a big lift in terms of implementation complexity and isn’t really comparable to one additional precision property.
 
Given that, how would you respond to John’s original question regarding precision?
 

From: <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, July 19, 2017 at 10:32 AM
To: Richard Struse <rjs@mitre.org>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

As I stated a few days ago - if we are going to start including precision then I would rather we just go back to GeoJSON which is an existing RFC supported out of the box
by many products.

Folks pressed to not use GeoJSON because they would not use all the features, and now we're talking about re-inventing things it already gives us.

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

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




From:         "Struse, Richard J." <rjs@mitre.org>
To:         Bret Jordan <Bret_Jordan@symantec.com>, Trey Darley <trey@newcontext.com>
Cc:         "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>
Date:         07/19/2017 11:02 AM
Subject:         Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision
Sent by:         <cti-stix@lists.oasis-open.org>






Your opinion is noted. What do others on the list think?

On 7/19/17, 9:59 AM, "Bret Jordan" <Bret_Jordan@symantec.com> wrote:

   I disagree
   Bret
   
   
   Sent from my iPhone
   
   > On Jul 19, 2017, at 3:39 PM, Trey Darley <trey@newcontext.com> wrote:
   >
   >> On 19.07.2017 12:47:55, Struse, Richard J. wrote:
   >> I’ve come to believe that precision should be optional. The purist
   >> in me wants the text to say that if precision is omitted, the
   >> precision of the lat/long is unspecified. But I’m willing to live
   >> with text that says if precision is unspecified, it defaults to 10km
   >> as John-Mark originally proposed.
   >>
   >
   > Thanks, Rich.
   >
   > I think this is the correct approach.
   >
   > --
   > Cheers,
   > Trey
   > ++--------------------------------------------------------------------------++
   > Director of Standards Development, New Context
   > gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338
   > ++--------------------------------------------------------------------------++
   > --
   > "No matter how hard you try, you can't make a baby in much less than 9
   > months. Trying to speed this up *might* make it slower, but it won't
   > make it happen any quicker." --RFC 1925
   

If GeoJSON is not included then correct.
 

Allan Thomson
CTO
+1-408-331-6646

LookingGlass Cyber Solutions
 

From: "Struse, Richard J." <rjs@mitre.org>
Date: Wednesday, July 19, 2017 at 8:03 AM
To: Allan Thomson <athomson@lookingglasscyber.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John" <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

I believe that the consensus has generally been that we do NOT want to include GeoJSON in the Location object for STIX 2.1.
 
So, it sounds like optional precision with an UNDEFINED precision if the property is omitted is your preference.
 

From: Allan Thomson <athomson@lookingglasscyber.com>
Date: Wednesday, July 19, 2017 at 11:00 AM
To: Richard Struse <rjs@mitre.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

I’m not sure I agree that GeoJSON is a ‘big lift’. It’s a list of key/value pairs in JSON.

 
You can choose to implement a subset of what it provides to begin with, but have a consistent framework to implement more advanced features going forward without having to add numerous new fields everytime a new sub-feature is desired by
an org.
 

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 "Struse, Richard J." <rjs@mitre.org>
Date: Wednesday, July 19, 2017 at 7:36 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John" <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

In all fairness, GeoJSON is a big lift in terms of implementation complexity and isn’t really comparable to one additional precision property.
 
Given that, how would you respond to John’s original question regarding precision?
 

From: <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, July 19, 2017 at 10:32 AM
To: Richard Struse <rjs@mitre.org>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

As I stated a few days ago - if we are going to start including precision then I would rather we just go back to GeoJSON which is an existing RFC supported out of the box
by many products.

Folks pressed to not use GeoJSON because they would not use all the features, and now we're talking about re-inventing things it already gives us.

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

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




From:         "Struse, Richard J." <rjs@mitre.org>
To:         Bret Jordan <Bret_Jordan@symantec.com>, Trey Darley <trey@newcontext.com>
Cc:         "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>
Date:         07/19/2017 11:02 AM
Subject:         Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision
Sent by:         <cti-stix@lists.oasis-open.org>






Your opinion is noted. What do others on the list think?

On 7/19/17, 9:59 AM, "Bret Jordan" <Bret_Jordan@symantec.com> wrote:

   I disagree
   Bret
   
   
   Sent from my iPhone
   
   > On Jul 19, 2017, at 3:39 PM, Trey Darley <trey@newcontext.com> wrote:
   >
   >> On 19.07.2017 12:47:55, Struse, Richard J. wrote:
   >> I’ve come to believe that precision should be optional. The purist
   >> in me wants the text to say that if precision is omitted, the
   >> precision of the lat/long is unspecified. But I’m willing to live
   >> with text that says if precision is unspecified, it defaults to 10km
   >> as John-Mark originally proposed.
   >>
   >
   > Thanks, Rich.
   >
   > I think this is the correct approach.
   >
   > --
   > Cheers,
   > Trey
   > ++--------------------------------------------------------------------------++
   > Director of Standards Development, New Context
   > gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338
   > ++--------------------------------------------------------------------------++
   > --
   > "No matter how hard you try, you can't make a baby in much less than 9
   > months. Trying to speed this up *might* make it slower, but it won't
   > make it happen any quicker." --RFC 1925
   

I personally prefer an optional precision field, and absence means that the precision is unspecified.
 
This is an area where implementations could be hemmed in by the spec. Let’s say I want to put locations on a map for my users. If the spec says “absence of precision means 10km”, I basically have to draw a 10km circle around the lat/long,
or else I’m misrepresenting the information I received. If/when users want something else, I’m stuck – I either misrepresent the spec data or make users unhappy. Note that this is about a 3/10 on my fictional pain scale (aka, slight discomfort).
 
My vote is for either no precision field, or optional precision field where absence means “unspecified”.
 
Thank you.
-Mark
 

From: Allan Thomson <athomson@lookingglasscyber.com>
Date: Wednesday, July 19, 2017 at 11:11 AM
To: "Struse, Richard J." <rjs@mitre.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

If GeoJSON is not included then correct.
 

Allan Thomson
CTO
+1-408-331-6646

LookingGlass Cyber Solutions
 

From: "Struse, Richard J." <rjs@mitre.org>
Date: Wednesday, July 19, 2017 at 8:03 AM
To: Allan Thomson <athomson@lookingglasscyber.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John" <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

I believe that the consensus has generally been that we do NOT want to include GeoJSON in the Location object for STIX 2.1.
 
So, it sounds like optional precision with an UNDEFINED precision if the property is omitted is your preference.
 

From: Allan Thomson <athomson@lookingglasscyber.com>
Date: Wednesday, July 19, 2017 at 11:00 AM
To: Richard Struse <rjs@mitre.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

I’m not sure I agree that GeoJSON is a ‘big lift’. It’s a list of key/value pairs in JSON.

 
You can choose to implement a subset of what it provides to begin with, but have a consistent framework to implement more advanced features going forward without having to add numerous new fields everytime a new sub-feature is desired by
an org.
 

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 "Struse, Richard J." <rjs@mitre.org>
Date: Wednesday, July 19, 2017 at 7:36 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John" <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

In all fairness, GeoJSON is a big lift in terms of implementation complexity and isn’t really comparable to one additional precision property.
 
Given that, how would you respond to John’s original question regarding precision?
 

From: <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, July 19, 2017 at 10:32 AM
To: Richard Struse <rjs@mitre.org>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

As I stated a few days ago - if we are going to start including precision then I would rather we just go back to GeoJSON which is an existing RFC supported out of the box by many products.

Folks pressed to not use GeoJSON because they would not use all the features, and now we're talking about re-inventing things it already gives us.

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

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




From:         "Struse, Richard J." <rjs@mitre.org>
To:         Bret Jordan <Bret_Jordan@symantec.com>, Trey Darley <trey@newcontext.com>
Cc:         "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date:         07/19/2017 11:02 AM
Subject:         Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision
Sent by:         <cti-stix@lists.oasis-open.org>






Your opinion is noted. What do others on the list think?

On 7/19/17, 9:59 AM, "Bret Jordan" <Bret_Jordan@symantec.com> wrote:

   I disagree
   Bret
   
   
   Sent from my iPhone
   
   > On Jul 19, 2017, at 3:39 PM, Trey Darley <trey@newcontext.com> wrote:
   >
   >> On 19.07.2017 12:47:55, Struse, Richard J. wrote:
   >> I’ve come to believe that precision should be optional. The purist
   >> in me wants the text to say that if precision is omitted, the
   >> precision of the lat/long is unspecified. But I’m willing to live
   >> with text that says if precision is unspecified, it defaults to 10km
   >> as John-Mark originally proposed.
   >>
   >
   > Thanks, Rich.
   >
   > I think this is the correct approach.
   >
   > --
   > Cheers,
   > Trey
   > ++--------------------------------------------------------------------------++
   > Director of Standards Development, New Context
   > gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338
   > ++--------------------------------------------------------------------------++
   > --
   > "No matter how hard you try, you can't make a baby in much less than 9
   > months. Trying to speed this up *might* make it slower, but it won't
   > make it happen any quicker." --RFC 1925
   











Disclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify
the sender and destroy and delete any copies you may have received.

Hi all, I'm with Mark on this one. I also prefer  an optional precision field, where absence means that the precision is unspecified. I feel (again) that we are getting wrapped up in the depths of a single detail that has a minor impact on the usefulness of CTI data to threat analysts and incident responders. The presence (or not) of this field will have VERY little effect on the ability of an organization to protect itself. I would far rather that we spent time on parts of the spec that will have great impact, such as victim targeting, IEP, and the like. Which reminds me.... Rich, how are those two design helper documents I mentioned at the last CTI TC meeting coming along? The two docs I suggested to help us avoid these sorts of arguments: - the doc outlining our design goals (the rules we use to evaluate new suggestions and to pick which one is better) - the doc outlining our STIX architectural design patterns (the rules on how we structure STIX in different scenarios) IIRC the drafts were under development by the co-chairs? Cheers Terry MacDonald Cosive On 20/07/2017 03:57, "Mark Davidson" < Mark.Davidson@nc4.com > wrote: I personally prefer an optional precision field, and absence means that the precision is unspecified.   This is an area where implementations could be hemmed in by the spec. Let’s say I want to put locations on a map for my users. If the spec says “absence of precision means 10km”, I basically have to draw a 10km circle around the lat/long, or else I’m misrepresenting the information I received. If/when users want something else, I’m stuck – I either misrepresent the spec data or make users unhappy. Note that this is about a 3/10 on my fictional pain scale (aka, slight discomfort).   My vote is for either no precision field, or optional precision field where absence means “unspecified”.   Thank you. -Mark   From: Allan Thomson < athomson@lookingglasscyber. com > Date: Wednesday, July 19, 2017 at 11:11 AM To: "Struse, Richard J." < rjs@mitre.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com > Cc: Bret Jordan < Bret_Jordan@symantec.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >, "Wunder, John A." < jwunder@mitre.org >, Mark Davidson < Mark.Davidson@nc4.com >, Trey Darley < trey@newcontext.com > Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision   If GeoJSON is not included then correct.   Allan Thomson CTO +1-408-331-6646 LookingGlass Cyber Solutions   From: "Struse, Richard J." < rjs@mitre.org > Date: Wednesday, July 19, 2017 at 8:03 AM To: Allan Thomson < athomson@lookingglasscyber. com >, Jason Keirstead < Jason.Keirstead@ca.ibm.com > Cc: Bret Jordan < Bret_Jordan@symantec.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >, "Wunder, John" < jwunder@mitre.org >, Mark Davidson < Mark.Davidson@nc4.com >, Trey Darley < trey@newcontext.com > Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision   I believe that the consensus has generally been that we do NOT want to include GeoJSON in the Location object for STIX 2.1.   So, it sounds like optional precision with an UNDEFINED precision if the property is omitted is your preference.   From: Allan Thomson < athomson@lookingglasscyber. com > Date: Wednesday, July 19, 2017 at 11:00 AM To: Richard Struse < rjs@mitre.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com > Cc: Bret Jordan < Bret_Jordan@symantec.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >, "Wunder, John A." < jwunder@mitre.org >, Mark Davidson < Mark.Davidson@nc4.com >, Trey Darley < trey@newcontext.com > Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision   I’m not sure I agree that GeoJSON is a ‘big lift’. It’s a list of key/value pairs in JSON.   You can choose to implement a subset of what it provides to begin with, but have a consistent framework to implement more advanced features going forward without having to add numerous new fields everytime a new sub-feature is desired by an org.   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 "Struse, Richard J." < rjs@mitre.org > Date: Wednesday, July 19, 2017 at 7:36 AM To: Jason Keirstead < Jason.Keirstead@ca.ibm.com > Cc: Bret Jordan < Bret_Jordan@symantec.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >, "Wunder, John" < jwunder@mitre.org >, Mark Davidson < Mark.Davidson@nc4.com >, Trey Darley < trey@newcontext.com > Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision   In all fairness, GeoJSON is a big lift in terms of implementation complexity and isn’t really comparable to one additional precision property.   Given that, how would you respond to John’s original question regarding precision?   From: < cti-stix@lists.oasis-open.org > on behalf of Jason Keirstead < Jason.Keirstead@ca.ibm.com > Date: Wednesday, July 19, 2017 at 10:32 AM To: Richard Struse < rjs@mitre.org > Cc: Bret Jordan < Bret_Jordan@symantec.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >, "Wunder, John A." < jwunder@mitre.org >, Mark Davidson < Mark.Davidson@nc4.com >, Trey Darley < trey@newcontext.com > Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision   As I stated a few days ago - if we are going to start including precision then I would rather we just go back to GeoJSON which is an existing RFC supported out of the box by many products. Folks pressed to not use GeoJSON because they would not use all the features, and now we're talking about re-inventing things it already gives us. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security Without data, all you are is just another person with an opinion - Unknown From:         "Struse, Richard J." < rjs@mitre.org > To:         Bret Jordan < Bret_Jordan@symantec.com >, Trey Darley < trey@newcontext.com > Cc:         "Wunder, John A." < jwunder@mitre.org >, Mark Davidson < Mark.Davidson@nc4.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Date:         07/19/2017 11:02 AM Subject:         Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision Sent by:         < cti-stix@lists.oasis-open. org > Your opinion is noted. What do others on the list think? On 7/19/17, 9:59 AM, "Bret Jordan" < Bret_Jordan@symantec.com > wrote:    I disagree    Bret            Sent from my iPhone        > On Jul 19, 2017, at 3:39 PM, Trey Darley < trey@newcontext.com > wrote:    >    >> On 19.07.2017 12:47:55, Struse, Richard J. wrote:    >> I’ve come to believe that precision should be optional. The purist    >> in me wants the text to say that if precision is omitted, the    >> precision of the lat/long is unspecified. But I’m willing to live    >> with text that says if precision is unspecified, it defaults to 10km    >> as John-Mark originally proposed.    >>    >    > Thanks, Rich.    >    > I think this is the correct approach.    >    > --    > Cheers,    > Trey    > ++---------------------------- ------------------------------ ----------------++    > Director of Standards Development, New Context    > gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338    > ++---------------------------- ------------------------------ ----------------++    > --    > "No matter how hard you try, you can't make a baby in much less than 9    > months. Trying to speed this up *might* make it slower, but it won't    > make it happen any quicker." --RFC 1925     Disclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.

+1 to your comments on focus…
 
During the TC meeting tomorrow we’ll briefly discuss our efforts to document those goals and patterns in an FAQ – it’s a start.
 

From: <cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
Date: Wednesday, July 19, 2017 at 4:30 PM
To: Mark Davidson <Mark.Davidson@nc4.com>
Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Allan Thomson <athomson@lookingglasscyber.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, Bret Jordan <Bret_Jordan@symantec.com>, Trey Darley <trey@newcontext.com>, "Wunder, John
A." <jwunder@mitre.org>, Richard Struse <rjs@mitre.org>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 



Hi all,

 


I'm with Mark on this one. I also prefer  an optional precision field, where absence means that the precision is unspecified.


 


I feel (again) that we are getting wrapped up in the depths of a single detail that has a minor impact on the usefulness of CTI data to threat analysts and incident responders. The presence
(or not) of this field will have VERY little effect on the ability of an organization to protect itself.


 


I would far rather that we spent time on parts of the spec that will have great impact, such as victim targeting, IEP, and the like.


 


Which reminds me.... Rich, how are those two design helper documents I mentioned at the last CTI TC meeting coming along? The two docs I suggested to help us avoid these sorts of arguments:


- the doc outlining our design goals (the rules we use to evaluate new suggestions and to pick which one is better)


- the doc outlining our STIX architectural design patterns (the rules on how we structure STIX in different scenarios)


IIRC the drafts were under development by the co-chairs?


 


Cheers


Terry MacDonald


Cosive


 

 

 

On 20/07/2017 03:57, "Mark Davidson" < Mark.Davidson@nc4.com > wrote:



I personally prefer an optional precision field, and absence means that the precision is unspecified.
 
This is an area where implementations could be hemmed in by the spec. Let’s say I want to put locations on a map for my users. If the spec says “absence of precision means 10km”,
I basically have to draw a 10km circle around the lat/long, or else I’m misrepresenting the information I received. If/when users want something else, I’m stuck – I either misrepresent the spec data or make users unhappy. Note that this is about a 3/10 on
my fictional pain scale (aka, slight discomfort).
 
My vote is for either no precision field, or optional precision field where absence means “unspecified”.
 
Thank you.
-Mark
 

From:
Allan Thomson < athomson@lookingglasscyber.com >
Date: Wednesday, July 19, 2017 at 11:11 AM
To: "Struse, Richard J." < rjs@mitre.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >


Cc: Bret Jordan < Bret_Jordan@symantec.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >,
"Wunder, John A." < jwunder@mitre.org >, Mark Davidson < Mark.Davidson@nc4.com >, Trey Darley < trey@newcontext.com >
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision




 

If GeoJSON is not included then correct.
 

Allan Thomson
CTO
+1-408-331-6646

LookingGlass Cyber Solutions
 

From:
"Struse, Richard J." < rjs@mitre.org >
Date: Wednesday, July 19, 2017 at 8:03 AM
To: Allan Thomson < athomson@lookingglasscyber.com >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Cc: Bret Jordan < Bret_Jordan@symantec.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >,
"Wunder, John" < jwunder@mitre.org >, Mark Davidson < Mark.Davidson@nc4.com >, Trey Darley < trey@newcontext.com >
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

I believe that the consensus has generally been that we do NOT want to include GeoJSON in the Location object for STIX 2.1.
 
So, it sounds like optional precision with an UNDEFINED precision if the property is omitted is your preference.
 

From:
Allan Thomson < athomson@lookingglasscyber.com >
Date: Wednesday, July 19, 2017 at 11:00 AM
To: Richard Struse < rjs@mitre.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Cc: Bret Jordan < Bret_Jordan@symantec.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >,
"Wunder, John A." < jwunder@mitre.org >, Mark Davidson < Mark.Davidson@nc4.com >, Trey Darley < trey@newcontext.com >
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

I’m not sure I agree that GeoJSON is a ‘big lift’. It’s a list of key/value pairs in JSON.

 
You can choose to implement a subset of what it provides to begin with, but have a consistent framework to implement more advanced features going forward without having to add numerous
new fields everytime a new sub-feature is desired by an org.
 

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 "Struse, Richard J." < rjs@mitre.org >
Date: Wednesday, July 19, 2017 at 7:36 AM
To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Cc: Bret Jordan < Bret_Jordan@symantec.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >,
"Wunder, John" < jwunder@mitre.org >, Mark Davidson < Mark.Davidson@nc4.com >, Trey Darley < trey@newcontext.com >
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

In all fairness, GeoJSON is a big lift in terms of implementation complexity and isn’t really comparable to one additional precision property.
 
Given that, how would you respond to John’s original question regarding precision?
 

From:
< cti-stix@lists.oasis-open.org > on behalf of Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Date: Wednesday, July 19, 2017 at 10:32 AM
To: Richard Struse < rjs@mitre.org >
Cc: Bret Jordan < Bret_Jordan@symantec.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >,
"Wunder, John A." < jwunder@mitre.org >, Mark Davidson < Mark.Davidson@nc4.com >, Trey Darley < trey@newcontext.com >
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

As I stated a few days ago - if we are going to start including precision then I would rather we just go back to
GeoJSON which is an existing RFC supported out of the box by many products.

Folks pressed to not use GeoJSON because they would not use all the features, and now we're talking about re-inventing things it already gives us.

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

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




From:         "Struse, Richard J." < rjs@mitre.org >
To:         Bret Jordan < Bret_Jordan@symantec.com >,
Trey Darley < trey@newcontext.com >
Cc:         "Wunder, John A." < jwunder@mitre.org >, Mark
Davidson < Mark.Davidson@nc4.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Date:         07/19/2017 11:02 AM
Subject:         Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision
Sent by:         < cti-stix@lists.oasis-open.org >






Your opinion is noted. What do others on the list think?

On 7/19/17, 9:59 AM, "Bret Jordan" < Bret_Jordan@symantec.com > wrote:

   I disagree
   Bret
   
   
   Sent from my iPhone
   
   > On Jul 19, 2017, at 3:39 PM, Trey Darley < trey@newcontext.com > wrote:
   >
   >> On 19.07.2017 12:47:55, Struse, Richard J. wrote:
   >> I’ve come to believe that precision should be optional. The purist
   >> in me wants the text to say that if precision is omitted, the
   >> precision of the lat/long is unspecified. But I’m willing to live
   >> with text that says if precision is unspecified, it defaults to 10km
   >> as John-Mark originally proposed.
   >>
   >
   > Thanks, Rich.
   >
   > I think this is the correct approach.
   >
   > --
   > Cheers,
   > Trey
   > ++--------------------------------------------------------------------------++
   > Director of Standards Development, New Context
   > gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338
   > ++--------------------------------------------------------------------------++
   > --
   > "No matter how hard you try, you can't make a baby in much less than 9
   > months. Trying to speed this up *might* make it slower, but it won't
   > make it happen any quicker." --RFC 1925
   












Disclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you
are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in
error, please notify the sender and destroy and delete any copies you may have received.





 

Agree with Jason on both GeoJSON and re-inventing the wheel.
 
That said, if the TC wants to continue to reinvent the wheel without using GeoJSON then my preference is

 

Precision is optional (but language in the spec states that orgs SHOULD use it) No default (but language in the spec states what is a best-practice value to include so that if orgs want to include the precision then they can follow some guidance).
 
 

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 Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, July 19, 2017 at 7:32 AM
To: "Struse, Richard J." <rjs@mitre.org>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Wunder, John" <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, Trey Darley <trey@newcontext.com>
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

As I stated a few days ago - if we are going to start including precision then I would rather we just go back to GeoJSON which is an existing RFC supported out of the box by
many products.

Folks pressed to not use GeoJSON because they would not use all the features, and now we're talking about re-inventing things it already gives us.

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

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




From:         "Struse, Richard J." <rjs@mitre.org>
To:         Bret Jordan <Bret_Jordan@symantec.com>, Trey Darley <trey@newcontext.com>
Cc:         "Wunder, John A." <jwunder@mitre.org>, Mark Davidson <Mark.Davidson@nc4.com>, "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>
Date:         07/19/2017 11:02 AM
Subject:         Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision
Sent by:         <cti-stix@lists.oasis-open.org>






Your opinion is noted. What do others on the list think?

On 7/19/17, 9:59 AM, "Bret Jordan" <Bret_Jordan@symantec.com> wrote:

   I disagree
   Bret
   
   
   Sent from my iPhone
   
   > On Jul 19, 2017, at 3:39 PM, Trey Darley <trey@newcontext.com> wrote:
   >
   >> On 19.07.2017 12:47:55, Struse, Richard J. wrote:
   >> I’ve come to believe that precision should be optional. The purist
   >> in me wants the text to say that if precision is omitted, the
   >> precision of the lat/long is unspecified. But I’m willing to live
   >> with text that says if precision is unspecified, it defaults to 10km
   >> as John-Mark originally proposed.
   >>
   >
   > Thanks, Rich.
   >
   > I think this is the correct approach.
   >
   > --
   > Cheers,
   > Trey
   > ++--------------------------------------------------------------------------++
   > Director of Standards Development, New Context
   > gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338
   > ++--------------------------------------------------------------------------++
   > --
   > "No matter how hard you try, you can't make a baby in much less than 9
   > months. Trying to speed this up *might* make it slower, but it won't
   > make it happen any quicker." --RFC 1925
   

Are we really saying that people should use lat/long with a precision to cover a city or state vs just using the city or state properties ???


I absolutely do not like adding information or metadata to data that is just made up. If you default to 10km then you are just making that up! You are potentially adding precision to something that was only valid to 30 km.  We can
not make up data.  


If we must add this field, then the default should be just unspecified. 




Bret 

Sent from my iPhone

On Jul 19, 2017, at 2:48 PM, Struse, Richard J. < rjs@mitre.org > wrote:









I’ve come to believe that precision should be optional.  The purist in me wants the text to say that if precision is omitted, the precision of the lat/long is unspecified.  But I’m willing to live with text
that says if precision is unspecified, it defaults to 10km as John-Mark originally proposed.
 

From: < cti-stix@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Wednesday, July 19, 2017 at 8:32 AM
To: Mark Davidson < Mark.Davidson@nc4.com >, Bret Jordan < Bret_Jordan@symantec.com >
Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

One quick note about our current Location SDO is that lat/lng are not required. You can say “US” or “Washington, DC, US” without giving a lat/lng, for example. Precision describes specifically precision of
lat/lng, though.
 
I’m also not sure how realistic a precision of 0 is. Even an address isn’t really precise to 0 meters, and this would mean that producers who can’t be bothered to populate precision are by default saying their
lat/lng is super precise, which is probably not accurate. If we do have optional with a default, I’d suggest we go with what New Context came up with (10km) in the absence of other compelling reasons.
 
John
 

From: Mark Davidson < Mark.Davidson@nc4.com >
Date: Wednesday, July 19, 2017 at 7:59 AM
To: "Bret Jordan (CS)" < Bret_Jordan@symantec.com >, John Wunder < jwunder@mitre.org >
Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision


 

Products are going to visually represent this information to users, so we need some concrete information around it.
 
Here are some examples, which are rental listings on
HomeAway.com for a non-CTI example. (They are Portland, ME, not Portland, OR)
 
In a product, visually, an “imprecise” location is reasonable to represent as a circle (e.g., lat/long + precision):
<image001.png>
 
Whereas a “precise” location could use a pin
<image002.png>
 
 
As a potential consumer of this information, I would go for:
 

Lat/long (required) Precision (optional, defaults to 0)


Alternatively we could just not have this field, and potentially add it in a later release
Some text describing that lat/long + precision define a geometric shape (e.g., a circle) that includes the location. This not only accounts for imprecision
in the source data, it enables the use case where somebody doesn’t want to be as specific as they could be. Maybe higher $$$ data sets are more precise.
 
When I think of Soltra’s use cases for location, it is displaying the information on screen for users, workflows (e.g., auto-route anything in APAC to team XYZ), and enrichment. The fields I list above support
all those. Anything that’s crazy big (e.g., lat/long, precision=1 AU) could get kicked out to a human for categorization or rejection.
 
Producers of CTI can weigh in on how useful the location property is or would be.
 
Thank you.
-Mark
 

From: < cti-stix@lists.oasis-open.org > on behalf of Bret Jordan < Bret_Jordan@symantec.com >
Date: Wednesday, July 19, 2017 at 12:51 AM
To: "Wunder, John A." < jwunder@mitre.org >
Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [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
 


Disclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure
under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received
this communication in error, please notify the sender and destroy and delete any copies you may have received.

On 19.07.2017 12:32:54, Wunder, John A. wrote: > > I’m also not sure how realistic a precision of 0 is. Even an address > isn’t really precise to 0 meters, and this would mean that producers > who can’t be bothered to populate precision are by default saying > their lat/lng is super precise, which is probably not accurate. If > we do have optional with a default, I’d suggest we go with what New > Context came up with (10km) in the absence of other compelling > reasons. > The only producers able to specify lat/long with 0m precision are probably in the business of expedited Hellfire missile delivery, not CTI feeds. The 10km precision default value was derived from analysis of MaxMind's dataset. 10km is *not* a WAG. -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "Anyone who isn't confused doesn't really understand the situation." --Edward R. Murrow Attachment: signature.asc Description: Digital signature