Comments inline below
Bret, what can we do to help you understand and feel more comfortable with this?
sean
From: "Jordan, Bret" <>
Date: Tuesday, February 9, 2016 at 7:24 PM
To: "Barnum, Sean D." <>
Cc: "" <>
Subject: Re: [cti] Results of today's CTI working call on the topic of refactoring "sources"
I can agree with items 1 and 2. But I do not yet agree with item 3. I am curious to know how it is a consensus proposal.
[sean]Item 1 has been widely discussed on the lists and at the F2f for quite a while and seems to have universal consensus (I don’t recall ever hearing anyone disagree with it).
Item 2 is somewhat new. It has consensus among the players who have been actively working on developing proposals for these issues and often do so from different perspectives (myself, John Wunder and I believe Terry). The intent of putting out the
revised proposal last week and talking about it on the call yesterday was to see if we could get broader consensus. My impression on the call was that specific details needed worked out but the high-level proposal seemed to have pretty good general consensus.
Item 3 is the topic of source referencing which has been talked about for a couple of months now. The two “strawman” proposals going into the F2F took different approaches on this (one using Relationships and the other using an embedded reference
for “producer” relationships). There really did not seem to be a lot of consensus between these two approaches at first but after a lot of discussion and exploration I think that the two sides realized that all non-producer sources would need to use Relationships
anyway and that having an embedded reference for “producer” did not preclude a Relationship being asserted for it as well to align with all the other source relationships. This led to a consensus among the two sides that the hybrid approach proposed here makes
the most sense. We still have details to work out but it also sounded like this had pretty good consensus support on the list, slack and the call from Sarah, Paul, Jason, Marlon and others. I don’t recall anyone other than yourself raising objections or concerns
on the high-level proposal. As I said, we still have details to work out though.
**If I have misunderstood anyone’s opinions and mischaracterized them here please feel free to correct me.**
For item 3, some of it makes sense, and other parts seem a bit complicated and non-intuitive.
[sean]From my perspective it is actually simpler due to consistency and it appears to align very well with the way that real world analysts think about and relate these things.
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 Feb 9, 2016, at 13:36, Barnum, Sean D. <> wrote:
We had a good constructive conversation on today’s CTI working call on the topic of refactoring source representations and relationships within STIX.
We Invite further comments and discussion on this topic with a goal of reaching official consensus this week.
On the call, a request was made to break the problem down into a clear high-level statement of what is being proposed, some of the value propositions asserted for the proposal, and a breakdown of separate more detailed sub-issues that will need
to be decided.
Here is my stab at a clear high-level statement of what is being proposed.
I will follow this email with a separate one focused on a breakdown of the detailed sub-issues to discuss/decide.
High level statement of what is being proposed:
Break information source out of Top-Level Objects
Break information source into individual types
Identities: who is the source of the information?
Tools: from what tool(s) did the information come?
References: what non-STIX resources were used directly or indirectly (background context) as sources for the information
Relate TLOs to identities, tools and references
For anyone who was unclear before, does this help?
Here is a little more detail if you find it useful. There is also a simple diagram attached showing some more various use case scenarios than just those presented below.
Break Information Source Out of Top-Level Objects
In STIX 1.x, Information Source was a field in each top-level object. For example:
Indicator
Information Source
Identity = MITRE
Indicator 2
Information Source
Identity = MITRE
For STIX 2.0, we propose breaking information source into top-level objects, for example:
Identity
ID = id-1
Name = MITRE
Indicator
(created-by) = id-1 (shorthand does not imply how relationship should be represented)
Indicator 2
(created-by) = id-1 (shorthand does not imply how relationship should be represented)
This allows for less repetition, helps prevent consumers from having to correlate identities on name, and allows people to easily pivot on sources.
Break Information Source into Individual Types
In STIX 1.x, Information Source covered Identity, Tools, and References. For example:
Indicator
Information Source
Identity = MITRE
Tool = CRITS
While this somewhat made sense since it was embedded in individual constructs, with the move to separating them out to top-level objects it would be nice to reference them separately. So, for STIX 2.0, we propose breaking it apart into individual
TLOs:
Identity
Name = MITRE
ID = id-1
Tool
Name = CRITS 2.3
ID = id-2
Indicator
(created by) => id-1 (shorthand does not imply how relationship should be represented)
(has source) => id-2 (shorthand does not imply how relationship should be represented)
This would allow you to track “MITRE” as a separate identity from “CRITS” as a tool, etc. If MITRE’s SOC later produced something with a different tool, you probably want to be able to separately pivot on “MITRE” as an identity and that tool that
we used.
Relating TLOs to Identities, Tools and References
In STIX 1.x, we used the “Role” field in information source to describe the role of that source in creating the construct.
For 2.x, we’ve developed a consensus proposal that uses a “Has Source” Relationship object to relate TLOs to their various sources. This “Has Source” relationship has an extended Roles property serving a similar function to the Role field in STIX
1.x.
In addition, strictly for the creator of the actual STIX content it also supports an optional “created_by_ref” property on each TLO.
Identity
ID = id-1
Name = MITRE
Reference
ID = id-3
Title = FooBar Threat Report
Reference-url ="" href="http://mitre.org/foobarreport.html" class="">http://mitre.org/foobarreport.html
Indicator
ID = id-4
created by ref => id-1
Relationship
ID = id-5
From = id-4
To = id-1
Nature = Has Source
Role = Producer
Relationship
ID = id-6
From = id-4
To = id-3
Nature = Has Source
Role = Derivation Resource
