I am working on a document that lays out the thinking on this and other design issues.
<email@example.com> on behalf of Nicholas Hayden <firstname.lastname@example.org>
Date: Tuesday, June 13, 2017 at 8:47 AM
To: "Wunder, John A." <email@example.com>
Cc: Patrick Maroney <firstname.lastname@example.org>, Bret Jordan <Bret_Jordan@symantec.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, John-Mark Gurney <email@example.com>, CTI OASIS GROUP <firstname.lastname@example.org>, "Back, Greg" <email@example.com>, "Nathan
S. Reller" <Nathan.Reller@jhuapl.edu>
Subject: Re: [cti] [EXT] [cti] Location as a Top-Level SDO
Can we derive a "Go No GO” checklist for SDO’s? This might help us in resolving this and to John’s point future scenarios. My proposal is we clearly define what the characteristics are which “Qualifies” something that needs to be an SDO.
So for example does it requiring versioning “Yes” ok thats a +1 toward making it an SDO.
Nicholas Hayden, CISSP, GICSP, CNDA, CEH, Sec+
808 Winslow St Redwood City, CA 94063
Phone: (650) 257-0867 | Twitter: @anomali
Yeah +1 to Pat…we’re a CTI org, let’s not maintain a database of geolocations.
More generally I also agree w/ Allan that this doesn’t really impact the SDO question. Either you:
- Have the library and duplicate it in the embedded types
- Have the library and reference it by UUID (if we generate STIX UUIDs for it)
- Have the library and copy it into the referenced types (if we don’t generate UUIDs for it)
It would be nice to enumerate these types of scenarios and see how we can deal with each of them in each approach. I talked to Allan and I think he has the beginnings of that
document started, I’ll get with him to push it to Google docs so we can all look over it.
My .02: If we're building, publishing, maintaining our own Geo-Location Data, we're doing something wrong. This is one wheel we do not need to re-invent...again just my .02.
Principal Engineer - Data Science & Analytics
So if we were going to do this, we would probably need to build a library of locations by country and regions and publish them as a Committee Note and hope people just use the them for locations
at the granularity of a country or group of countries.
You are assuming that we don't create a repository of "standard" location SDOs for things like continent and country names - IE the things that people would want to share in
the first place. Which, I don't see why we would not do this, seeing how we're doing it for things like CAPEC.
STSM, Product Architect, Security Intelligence, IBM Security Systems
Without data, all you are is just another person with an opinion - Unknown
Back, Greg wrote this message on Fri, Jun 09, 2017 at 20:18 +0000:
> If Location is an SDO, does that make it possible to “move” another object by versioning the Location object? That seems like a bad idea. Especially if you effectively “move” other, unrelated objects that also refer to the same Location. Even if we did make
Location a TLO, we would have to mandate that people update the “_ref” fields to move an SDO, not the Location itself.
> (I haven’t made up my mind on whether I like the Location SDO in general, just pointing out one consideration).
Interesting point. Which effectively means that if you create a
relationship to a location, that location should be one you own, not
one that was created by someone else (unless you can trust the creator
not to do what you just described)...
This means that by definition, there will be many Location SDO's for
the same location to prevent this from happeneing...
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at: