Yeah that’s a good point.
I do 100% agree with spending more time defining exactly what we need, building off of real work. The couple of sporadic fields we had were probably a mistake.
John
From:
Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, September 15, 2016 at 11:20 AM
To: "Wunder, John A." <jwunder@mitre.org>, Paul Patrick <Paul.Patrick@FireEye.com>, Terry MacDonald <terry.macdonald@cosive.com>
Cc: Eric Burger <Eric.Burger@georgetown.edu>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] F2F Topic - Location Object.
I lean to making it a separate SDO and then it has the advantage of being related to many other objects that have the same location.
But I was going to focus on definition what the object will contain as a start and whether its an object that can be an attribute or a related object is a separate discussion.
allan
From:
"Wunder, John" <jwunder@mitre.org>
Date: Thursday, September 15, 2016 at 6:42 AM
To: Paul Patrick <Paul.Patrick@FireEye.com>, Terry MacDonald <terry.macdonald@cosive.com>, Allan Thomson <athomson@lookingglasscyber.com>
Cc: Eric Burger <Eric.Burger@georgetown.edu>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] F2F Topic - Location Object.
I like the idea of trimming down an existing standard. We tend to have less extensive needs than a lot of geolocation-specific data formats (GeoJSON, CIQ, etc.)
My bigger question is whether location should be a separate STIX Object or just a common set of attributes across relevant other objects. It seems like a lot of location correlations won’t
be based on exact matches (location id = 1234 and other location id = 1234 therefore they’re in the same place) but rather on some ad-hoc correlation rules (location country is US and other location country is US therefore they’re in the same country). Kind
of like CybOX really…it’s data that can be used for correlation rather than some domain entity you want to track over time.
John
From:
<cti-stix@lists.oasis-open.org> on behalf of Paul Patrick <Paul.Patrick@FireEye.com>
Date: Thursday, September 15, 2016 at 7:00 AM
To: Terry MacDonald <terry.macdonald@cosive.com>, Allan Thomson <athomson@lookingglasscyber.com>
Cc: Eric Burger <Eric.Burger@georgetown.edu>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] F2F Topic - Location Object.
If you look at what I put together for the RSA conference, I took a stab at location based on CIQ. Could definitely be trimmed down it would at least provide a start for location that auppports both civil and gps
From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald
<terry.macdonald@cosive.com>
Sent: Thursday, September 15, 2016 6:49:34 AM
To: Allan Thomson
Cc: cti-stix@lists.oasis-open.org; Eric Burger
Subject: Re: [cti-stix] F2F Topic - Location Object.
Is this something that CIQ could help us with?
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ciq
We might be able to get some ideas from it at least...
Cheers
Terry MacDonald
Cosive
On 15 Sep 2016 11:56 AM, "Allan Thomson" <athomson@lookingglasscyber.com> wrote:
The intent will be to allow both civic and gps as options.
Depending on the creator of the intel depends what they are capable and willing to provide for location. Some may be willing to
provide just a country, just a country and region, a city+state+country, a building address+city+state+country, an internal location within a building+building address+city+state+country…..etc.
STIX will provide a mechanism to convey location. That’s all.
I wouldn’t recommend any normative statements on location granularity or accuracy. That is a both a product and business issue
that is best left to customers/orgs using the standard.
Allan
Kind of a can of worms. I fully support the idea of using a location element. The thing that can become a rathole is how to
identify a location. Is it civil location? If so, what country is Taipei in? Is it GPS coordinates? If so, how do you denote “somewhere in the Czech Republic”? Is it what3words? If so, is there IPR around it?
I’ve run into this conundrum in a different context, merging databases that talk about things that happen at locations with databases that talk about crimes that happen in buildings
with databases that talk about people near cell towers. The three have different codings for location, and joining them is a hard problem. Much easier to get everyone to agree in a single representation and translate out from there.
I think we need a starting point... I have not spend a lot of time yet thinking through this, so I am not the best one to seed the discussion. My topics I am working on are Malware,
Infrastructure, and Incident and how they use Observed Data.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
Bret – were you looking for a text proposal to be submitted?
I was one of the proponents (not the only one) so happy to work together with any other interested parties on a submission for it.
Another topic that was brought up at the F2F was instead of having Country and Region and what not located on some of the Objects, maybe there should be a "Location" object. The rational, from what I heard, was this would allow you to easily see and pivot
in a graph UI all of the objects connected to a certain country or region. It would also get us out of duplicating some of that content on multiple objects. Not sure how this would fit in with Identity though.
While this would not really be a breaking change, it would result in the immediate depreciation of some properties (assuming we moved the current CSD to a CS). As such, it might be good to have that discussion now and if needed, we can release another CSD
as 2.0-rc3 before we go to public review and a CS..
As I was not one of the ones pushing for this, I will turn the floor over to those that wanted it.
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is
strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
|