Allan,
I would suggest that the feed would best be represented as a source independently from the just the company itself.
Maybe something like doing this one time:
Identity
Id = id-1
name = Company X
Reference
Id = id-2
title = Company X Malware Reports Feed
Reference-url =""> http://example.com/taxii2/channels/malware-report-feed/
External-Identifier = malware-report-feed
Defining-context = Company X TAXII Server
Reference
Id = id-3
title = Company X New Domains Report Feed
Reference-url ="">
External-Identifier = new-domains-report-feed
Defining-context = Company X TAXII Server
Reference
Id = id-4
title = Company X Phishing Sources List Feed
Reference-url ="">
External-Identifier = phishing-sources-list-feed
Defining-context = Company X TAXII Server
Relationship
Id = id-5
From = id-2
To = id-1
Nature = has-source
Roles = Analysis Originator, Producer
Relationship
Id = id-5
From = id-3
To = id-1
Nature = has-source
Roles = Analysis Originator, Producer
Relationship
Id = id-5
From = id-4
To = id-1
Nature = has-source
Roles = Analysis Originator, Producer
And then having any STIX content refer to these as sources, like:
Report
Id = id-6
…
Created_by_ref = id-1
Relationship
Id = id-7
From = id-6
To = id-2
Nature = has-source
Roles = Aggregator
Relationship
Id = id-7
From = id-6
To = id-1
Nature = has-source
Roles = Producer
This lets you pivot on a given feed but also on Company X across any feeds they might have.
Does that make sense?
Do you see any issues with this approach?
sean
Sean/all -
Apologize if this question has been asked before and resolved. If it has then appreciate a pointer to the solution.
Issue: Many threat intelligence vendors have multiple ‘products’ or ‘feeds’ as separate deliverables the include intel reports, indicators, IOCs…etc.
Typically this would be thought of as the source being the
company/entity and the feed being the specific name of the feed containing a set of related information.
Example:
Source: Company X
Feed: Malware Reports
Source: Company X
Feed: New Domains Report
Source: Company X
Feed: Phishing Sources List
QUESTION: How would this information be represented in the new source model?
If it is not, then I would suggest we should represent this information somehow.
Should feed-name be an additional optional attribute of source?
Regards
Allan Thomson
LookingGlass CTO
>In other words make the Tool a global and interchangeable construct.
This is one of the side benefits of this approach for source. Breaking out tool helps us clarify and address the source use case but also gives us a foundation for addressing other tool-related issues as you point out here including the ability
to talk about tools from a malicious, benign or defensive perspective as well as tools used in relation to COAs.
Breaking out identity has similar benefits in setting us up for some of the issues to be tackled in next month’s tranche (identity-based abstraction for source, victim, actor (threat actor, defender, 3rd party), etc.
I had originally had these side benefits listed in my status email out of the call but removed them as I did not want to sidetrack the conversation around source.
I think we will tackle those issues at the right time and this proposed solution sets us up for better chances of success when we get there.
sean
I hesitate going too far down the rabbit-hole, but since I jumped in:
My thinking was that a "tool" sub-class should be an independent construct (perhaps within TTP? - presuming one subscribes to the notion of White Hat TTPs). Relationships to COA, Sightings, etc.
Therefore one can reference the "Tool" (i.e., Yara & Yara Rule) in the original assertion that I established the "badness" of "threat x" using "Tool".
...Then others can share sightings of "threat x" based on "Tool" : using "Tool" I 'sighted ' this activity.
....And others can report I mitigated "threat x" using COA "Tool"
In other words make the Tool a global and interchangeable construct. Note that the "Yara Rule" itself in this example would have a "Source", Versioning, and Provenance...
Pat, I would agree that sometimes when talking about a tool you are talking about a method. Other times a tool may be the source of the information itself (e.g. an ML scanning osint and creating STIX asserting that a particular TTP was leveraged
as part of a Campaign).
Can you help us see what would be gained by making a distinction a tool as method vs source here? Is the same information not captured either way?
I think we are looking to keep it as simple as possible and still support the necessary use cases.
Having identities, tools and references treated as types of “sources” seems to be simpler than breaking tools off into a new concept of “method”.
>Also note that I may use multiple "Tools" to establish the basis for my assertion(s).
I believe you can still do this with the current proposal simply by specifying each tool and asserting a “has-source” relationship (maybe with a new “role” value more specific to this sort of case) between your assertion and the tools.
Is there something we are missing by doing it the proposed way? I am genuinely interested in understanding.
Thanks,
sean
Isn't "Tool" better related to a Method (i.e.: ==Using==>) relationship? (I'm paraphrasing here)
In other words, an entity is still the Source of an assertion, the tool(s) used to make that assertion are the Method. Also note that I may use multiple "Tools" to establish the basis for my assertion(s).
_____________________________
From: Jordan, Bret < bret.jordan@bluecoat.com>
Sent: Tuesday, February 9, 2016 7:25 PM
Subject: Re: [cti] Results of today's CTI working call on the topic of refactoring "sources"
To: Terry MacDonald < terry@soltra.com>
Cc: < cti@lists.oasis-open.org>, Barnum, Sean D. < sbarnum@mitre.org>
"source-tool" does seem to be more clear.
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."
Hi Sean,
I think you meant Report rather than reference in the Relating TLOs to Identities, Tools and References section? Here is the updated structure reflecting that:
-
Identity
-
Report
-
ID = id-3
-
Title = FooBar Threat Report
-
Reference-url ="" href="http://mitre.org/foobarreport.html" class="" style="color:purple; text-decoration:underline">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
Also, the relationship of ‘has_source’ as described in the ‘Break Information Source into Individual Types’ dsection seems ambiguous to me. It’s too easy for people to misunderstand its
purpose with the name ‘has_source’. What do you think of changing the relationship ‘source-tool’? Then it is easy to understand what the relationship is expected to apply to.
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
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:
For STIX 2.0, we propose breaking information source into top-level objects, for example:
-
(created-by) = id-1 (shorthand does not imply how relationship should be represented)
-
(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:
-
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:
-
Name = CRITS 2.3
-
ID = id-2
-
(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.
-
ID = id-3
-
Title = FooBar Threat Report
-
Reference-url ="" href="http://mitre.org/foobarreport.html" class="" style="color:purple; text-decoration:underline">http://mitre.org/foobarreport.html
-
ID = id-4
-
created by ref => id-1
-
ID = id-5
-
From = id-4
-
To = id-1
-
Nature = Has Source
-
Role = Producer
-
ID = id-6
-
From = id-4
-
To = id-3
-
Nature = Has Source
-
Role = Derivation Resource
|