Re: [cti-stix] Re: [EXT] [cti-stix] Location, latitude/longitude, and precision

[Terry MacDonald <terry.macdonald@cosive.com>]

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.