Agreed.
LookingGlass Cyber Solutions
From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Struse, Richard J." <rjs@mitre.org>
Date: Thursday, June 15, 2017 at 5:17 AM
To: Bret Jordan <Bret_Jordan@symantec.com>, "Piazza, Rich" <rpiazza@mitre.org>, John-Mark Gurney <jmg@newcontext.com>
Cc: "Wunder, John" <jwunder@mitre.org>, Patrick Maroney <pmaroney@wapacklabs.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "Back, Greg" <gback@mitre.org>, "Nathan.Reller@jhuapl.edu" <Nathan.Reller@jhuapl.edu>
Subject: Re: [cti] Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO
+1 to the idea of extending the use of hashes in the relationship object. While I believe that digitally-signed STIX content is something we need to do, I think it is also clear that it will take some work to get it right. So, perhaps
a good first step would be to use John-Mark Gurney’s canonicalization ideas to allow someone to compute a hash(es) for an SDO they are linking to and then store those in the relationship (this would be optional)? Then, later on when I de-reference that relationship
I have the option to generate the canonical version of the destination object, hash it and compare the hashes.
For those who haven’t been tracking this, in practice it might look like this:
- Analyst Jane wants to link to a threat actor definition for APT3.14 that is published by BigCo.
- Jane retrieves the definition of APT3.14 from BigCo’s TAXII server and reviews it to make sure that she agrees with their definition
- Seeing that it does, Jane creates a campaign object for an internally-tracked campaign and then creates a relationship to the UUID of the BigCo definition of APT3.14. As part of that relationship
creation process, the tool Jane is using generates the canonical representation of the APT3.14 object, hashes that and stores the hashes in the SRO maintained in their local repository.
- A few weeks later, the AngryBaker cr3w hacks into BigCo and subtly alters the definition of APT3.14 in BigCo’s repository.
- Subsequent to that, Jane runs an analytic she’s developed that entails their tools going to fetch the definition of APT3.14 from BigCo. The tool, seeing that a hash is present in the relationship
generates the canonical representation of the just-fetched APT3.14 and hashes it. When the tool sees that the hashes don’t match the tool flags the relationship in their local repository and sends an alert to Jane who notifies BigCo of the problem.
Rich
From: <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Wednesday, June 14, 2017 at 8:12 PM
To: "Piazza, Rich" <rpiazza@mitre.org>, John-Mark Gurney <jmg@newcontext.com>
Cc: "Wunder, John A." <jwunder@mitre.org>, Patrick Maroney <pmaroney@wapacklabs.com>, "Jason Mr. Keirstead" <Jason.Keirstead@ca.ibm.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "Back, Greg" <gback@mitre.org>, "Nathan.Reller@jhuapl.edu"
<Nathan.Reller@jhuapl.edu>
Subject: Re: [cti] Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO
My guess is that eventually we will need to add a "hash" value to the relationship object to store a digital hash of the object you are linking to. We have already started to do this in a few places, like external_references.
Bret
From: Piazza, Rich <rpiazza@mitre.org>
Sent: Wednesday, June 14, 2017 2:58:10 PM
To: John-Mark Gurney; Bret Jordan
Cc: Wunder, John A.; Patrick Maroney; Jason Mr. Keirstead; cti@lists.oasis-open.org; Back, Greg; Nathan.Reller@jhuapl.edu
Subject: Re: [cti] Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO
I don't think we should give up on the idea of reusing Locations so quickly. Assuming we go with Locations as SDOs, it certainly is a problem if you reuse someone's Location and
they change it from underneath you. I was first thinking that there should be immutable SDOs - in other words, the unique USA Location SDO CAN'T be changed. If we had a set of the common ones (defined in some library/repo somewhere) then we could just
use their ids. Duplicates are allowed, but hopefully few people would need to create their own USA Location SDO. I was thinking of an extra property (on all SDOs?) - final. If final is true for an SDO, then a new version couldn’t be created.
Adding immutable objects to the spec might be a good idea in general, but I think a simpler way to handle this is just to "trust" that the library/repo contains objects that will not change. In other words, locations created by a certain (well-known) identity
(SDO-Immutable-Library) could be reused with little concern that they are going to change. And if they DO change - maybe that is a feature - after all, all those Soviet-Union Location SDOs are no longer too useful...
|