Hi Bret – The spreadsheet was a good way to document the technical approaches in both SDO/Embedded scheme and allowed focused attention.
Generally a word/google document is not ideal for those considerations and comparisons.
If there are any use cases in the 2.1 concepts document that should be added to the spreadsheet then let me know.
Allan Thomson
CTO
+1-408-331-6646
LookingGlass Cyber Solutions
From:
Bret Jordan <>
Date: Tuesday, June 13, 2017 at 8:46 AM
To: Allan Thomson <>, Jason Keirstead <>, Mark Davidson <>
Cc: "" <>, "Back, Greg" <>, John-Mark Gurney <>, "Wunder, John" <>, "Nathan S. Reller" <>, Nicholas Hayden <>,
Patrick Maroney <>
Subject: Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO
What about all of the use cases and comments and suggestions that are in the 2.1 Concepts document? Why are we not just putting them all in one place?
Bret
From: Allan Thomson <>
Sent: Tuesday, June 13, 2017 7:14:16 AM
To: Jason Keirstead; Mark Davidson
Cc: Bret Jordan; CTI OASIS GROUP; Back, Greg; John-Mark Gurney; John A Wunder; Nathan S. Reller; Nicholas Hayden; Patrick Maroney
Subject: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO
To assist understanding all of the aspects the following google sheet was created.
https://docs.google.com/spreadsheets/d/1JgQ31PRK3txpMYduABdvJP1vSJBj2Y5o8faQM55Wym8/edit?usp=sharing
It defines the use cases, technical details on what it would mean to implement that use case using the SDO vs Embedded approach and an assessment of each use case.
Please review and suggest/capture any additional use cases and any additional feedback on the use cases.
Allan Thomson
CTO
+1-408-331-6646
LookingGlass
Cyber Solutions
From:
"" <> on behalf of Jason Keirstead <>
Date: Tuesday, June 13, 2017 at 6:01 AM
To: Mark Davidson <>
Cc: Bret Jordan <>, "" <>, "Back, Greg" <>, John-Mark Gurney <>, "Wunder, John" <>, "Nathan S. Reller" <>,
Nicholas Hayden <>, Patrick Maroney <>
Subject: Re: [cti] [EXT] [cti] Location as a Top-Level SDO
This is a good point as well.
While deconstructing an event, an analyst might have to use many location relationships for an indicator. "registered_from" and "originated_from" are very different things when looking at attacks
utilizing DNS fast flux.
-
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: Mark Davidson <>
To: Nicholas Hayden <>, John A Wunder <>
Cc: Patrick Maroney <>, Bret Jordan <>, Jason Keirstead
<>, John-Mark Gurney <>, CTI OASIS GROUP <>, "Back, Greg" <>, "Nathan S. Reller" <>
Date: 06/13/2017 09:50 AM
Subject: Re: [cti] [EXT] [cti] Location as a Top-Level SDO
Sent by: <>
In the interest of achieving principled negotiation, I’ll articulate my needs for this solution:
Changing the location structure later on does not require significant modification to all STIX objects.
For instance, if we made location a common property with a simple location=STRING, and then transitioned to location=JSON_OBJECT, that would require a lot of engineering re-work and I’d like to
avoid it.
I need to use location on any SDO, not just the ones that have been pre-ordained at design time (aka “now”).
We saw this problem in spades in STIX 1.x, let’s not repeat it.
So far I’ve seen examples of what location-as-a-property (LAAP, for short) would look like. Is there a more concrete proposal?
As something of a side note (but directly to Nicholas’ point), I think they key factor here is that a substantial subset of this community perceives there to be one and only one valid relationship
from any SDO to a location, that of “located at” (e.g., Threat Actor located at “Joe’s Pizza”). My sense is that the count of relationships is a distinguishing factor between whether an SDO is needed, or whether the information can be represented as a property.
If there is one and only one valid relationship type, that information can be effectively encoded in the property reference. If there is more than one valid relationship type, then
the Relationship Object is needed to indicate the relationship type.
Thank you.
-Mark
From: <> on behalf of Nicholas Hayden <>
Date: Tuesday, June 13, 2017 at 8:47 AM
To: John A Wunder <>
Cc: Patrick Maroney <>, Bret Jordan <>, Jason Keirstead <>, John-Mark Gurney <>, CTI OASIS GROUP <>, "Back, Greg" <>, "Nathan
S. Reller" <>
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.
Best Regards,
Nicholas Hayden, CISSP, GICSP, CNDA, CEH, Sec+
Director of Engineering Anomali |
anomali.com
808 Winslow St Redwood City, CA 94063
Phone: (650) 257-0867 | Twitter: @anomali
PastedGraphic-2.tiff
On Jun 12, 2017, at 4:12 PM, Wunder, John A. <> wrote:
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.
John
From: <>
on behalf of Patrick Maroney <>
Date: Monday, June 12, 2017 at 3:16 PM
To: "Bret Jordan (CS)" <>
Cc: "Jason Mr. Keirstead" <>, "John-Mark Mr. Gurney" <>,
"" <>,
Greg Back <>, ""
<>
Subject: Re: [cti] [EXT] [cti] Location as a Top-Level SDO
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.
Patrick Maroney
Principal Engineer - Data Science & Analytics
Wapack Labs LLC
(609)841-5104
Public Key:
http://pgp.mit.edu/pks/lookup?op=get&search=0x7C810C9769BD29AF
On Jun 11, 2017, at 11:58 PM, Bret Jordan <> wrote:
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.
Bret
From:
<>
on behalf of Jason Keirstead <>
Sent: Sunday, June 11, 2017 7:35:18 PM
To:
Cc: Bret Jordan;
;
;
Subject: Re: [cti] Re: [EXT] [cti] Location as a Top-Level SDO
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.
-
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
----- Original message -----
From: John-Mark Gurney <>
Sent by: <>
To: "Back, Greg" <>
Cc: Bret Jordan <>, "Reller, Nathan S." <>,
"" <>
Subject: Re: [cti] Re: [EXT] [cti] Location as a Top-Level SDO
Date: Fri, Jun 9, 2017 8:36 PM
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...
--
John-Mark
---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--------------------------------------------------------------------- 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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
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.
