Love the description and write up. I think what would be helpful for people to really understand this is if we could build a logic diagram showing the actual information that would flow. This will help everyone realize the need for certain fields in
certain messages.
Bret
Sent from my Commodore 64
On Aug 20, 2015, at 6:13 PM, Terry MacDonald <
terry.macdonald@threatloop.com > wrote:
I have to admit I am still a fan of a separate Sightings object and Relationship object. The reason is specifically 'graph' based - nodes and edges. As I've said for more than a year now we need to separate the 'data' nodes describing 'things'
from the edge nodes (the assertions that people make). If we conflate these things together as we do currently with the Sightings within the Indicator object, we lose flexibility, and the ability to do some interesting things in the future, such as:
-----
Use Case:
Company A is being attacked. They wish to find out from their friends in TrustGroupAlpha if anyone else has seen this before. CompanyA send out a CompanyA Sighting object containing the IP address (IPAddress X) that the malicious actor used along with a (new theoretical) STIX Query object, with a relationship object joining them together. The broadcast is sent to the TrustGroupAlpha
TAXII channel. Company B is listening to the TrustGroupAlpha TAXII channel, and had seen IPAddress X before during a previous attack it had received. CompanyB creates a (new theoretical) STIX Response object containing the CompanyB Sighting object that matched the CompanyA Sighting object, along with every STIX object that it thinks CompanyA would benefit from knowing. It adds the the related CompanyB
ThreatActor, the related Indicators (observable patterns only) that helped CompanyB detect this ThreatActor, and all the relationships that map the CompanyB objects together. And finally it adds a relationship object between CompanyB Sighting object and CompanyA
sighting object inferring that it is the same IPAddressX
CompanyB sends that back to the TrustGroupAlpha TAXII channel. CompanyA receives the (new theoretical) STIX Response object and now can add the new information it received into its database if it thinks the information is worth adding.
Company A now has more information about the attacker that is attacking it. It now has additional Indicators that will allow it to check if this is really an attack from that ThreatActor, and if so, CompanyA will be able to send out a STIX Package (broadcast)
out to the TrustGroupAlpha indicating that the CompanyA Incident is related to the CompanyB Incident and that CompanyA thinks it was the same ThreatActor in both cases.
This also allows all organizations listening to the TrustGroupAlpha trust group to keep track of this conversation and compile their own lists of Indicators/Incidents/ThreatActors/etc such that they are better prepared if the ThreatActor targets them.
-----
Keeping relationships completely separate from data objects will allow us to retain flexibility for the future, and will allow producers and consumers to describe relationships that we haven't even thought of yet.
STIX should provide people the building blocks to describe what they are seeing in the real world. Just like Lego tm people should be able to build what they want out of those building blocks. We just need to provide enough building
blocks to be useful, and the ability to put those building blocks together (i.e relationships).
Cheers
Terry MacDonald STIX, TAXII, CybOX Consultant
M: +61-407-203-026
E:
terry.macdonald@threatloop.com W:
www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those
of my employers.
On 21 August 2015 at 06:04, Aharon Chernin
<
achernin@soltra.com > wrote:
Bret, I agree. I personally am not a fan of embedded content.
Aharon Chernin
CTO
SOLTRA
An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647
813.470.2173
achernin@soltra.com www.soltra.com From: Jordan, Bret <
bret.jordan@bluecoat.com >
Sent: Thursday, August 20, 2015 2:58 PM
To: Jonathan Bush (DTCC)
Cc: Wunder, John A.; Aharon Chernin; Davidson II, Mark S;
cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] STIX 2.0 - Sightings object
Sorry my bad.....
I am hoping we can get rid of the idea of things like the report object having either embedded data or referenced data. I think it should be one or the other, and I would lean to the idea of the report object just using referenced data.
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards Office of the CTO
Blue Coat Systems
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."
On Aug 20, 2015, at 11:36, Bush, Jonathan <
jbush@dtcc.com > wrote:
Bret – Can you explain this a little?
Going from a database design perspective, wouldn’t you have objects that have primary keys and also foreign keys that relate it to other objects? What am I missing?
From:
cti-stix@lists.oasis-open.org [ mailto:
cti-stix@lists.oasis-open.org ] On
Behalf Of Jordan, Bret
Sent: Thursday, August 20, 2015 12:36 PM
To: Wunder, John A.
Cc: Aharon Chernin; Davidson II, Mark S;
cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] STIX 2.0 - Sightings object
And my hope is that in in STIX 2.0 we can get rid of the idea of having both ID and IDREF in the same object. It is either one or the other. It is either a container of data, thus having an ID. Or it is an object like Report that just contains IDREFs.
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards Office of the CTO
Blue Coat Systems
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."
On Aug 20, 2015, at 10:27, Wunder, John A. <
jwunder@mitre.org > wrote:
As a place to start, how about in the current STIX model anything that extends from Related___Type is a relationship object, anything with a normal @idref is not?
Sighting wasn’t top-level before so we get to make it up.
On Aug 20, 2015, at 12:19 PM, Aharon Chernin <
achernin@soltra.com > wrote:
We need to make sure it's very clear where the relationship object starts and ends. If I am not forced to use the relationship object for a sighting relationship, then I go back to supporting an
atomic sighting object.
Aharon
Sent using OWA for iPhone
From: Wunder, John A. <
jwunder@mitre.org >
Sent: Thursday, August 20, 2015 12:07:08 PM
To: Aharon Chernin
Cc: Jordan, Bret; Davidson II, Mark S;
cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] STIX 2.0 - Sightings object
Are you actually forced to use the relationship object to have sighting work there? I see that as a separate use case from relationships, and in cases like this we can still have the target_id
field directly there without the need for a new object. Same thing for an indicator pattern, for example.
While those are references between top-level constructs they seem different than the normal type of relationships we’ve been discussing.
John
BTW: Any thoughts on setting up a slack channel for STIX dev discussions? Sometimes I think that would be more conducive to these questions than e-mail.
On Aug 20, 2015, at 11:58 AM, Aharon Chernin <
achernin@soltra.com > wrote:
Bret, I almost always prefer atomic objects.
If we do both a relationship object and a Sightings atomic object together, it just seems... well weird.... (not very scientific I know)
Example Sightings Object -
ID: Sighting GUID
Marking: Sighting TLP
Producer: Who made the sighting
Timestamp:
Target_ID: Replaced by Relationship Object
Now I am going to be forced to use the relationship object to make the Sighting work. I am also going to be forced to make a potentially large number of new Sighting Objects (since there is a timestamp). Also, a
sighting by itself, without the looking into the Relationship object is kind of useless.
We can eliminate this extra complexity by eliminating the atomic Sightings object and replacing it with a relationship type.
Just debating <OutlookEmoji-