Hi John,
“3a. Is each occurrence of a piece of malware that has Indicators/Observables with the same Victim Targeting a new and different TTP or should it really link back
to the same TTP object? What I was seeing at one point was each Zeus Trojan targeting customer of Bank X getting its own TTP every time there was a new C2 as an Indicator. It really should have been Zeus Trojan TTP with Victim Targeting of bank X, with C2 Indicators
linked to the same TTP + Victim Targeting object again and again for each new C2 Indicator/Observable
I don’t really have any recommendations here…anyone on the implementor side have advice? How can we make sure that people do this, or at least encourage them
as much as possible to do it?”
I think we coulod go a long way towards this by separating the TTP objects into its various objects (attack-pattern’ being one of them)
and then creating an attack-pattern library that records each CAPEC attack pattern Object ID. Implementors can then all use the centrally stored attack-pattern library, and we can ensure that CAPEC attack pattern has a single global objectID that all implementations
will use.
For the other parts of the TTP object (i.e. exploits, malware , etc) we’ll still have the problem that you and Marc have brought up,
but with the ability to share relationships with third-party objects we should be able to share the TTP objects more easily at a global level. I would hope that in the same way people start referring to certain malware with names such as Dridex, we’ll start
all linking our malware and exploits to certain ‘popular’ objects within STIX.
The difficulty will be in how to surface that ‘popular name’ up to the user interface for the user to select…
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 |
terry@soltra.com
From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Wunder, John A.
Sent: Saturday, 6 February 2016 12:52 AM
To: Eric Burger <Eric.Burger@georgetown.edu>; cti@lists.oasis-open.org
Subject: Re: [cti] Quality of the specs
Thinking forward to STIX 2.0, how would we address Mark C's’s concerns in STIX 2.0 to make sure we don’t repeat the same mistakes?
[Sorry for the inevitable mangling of formatting that Outlook for mac will do to this]
1. Not adding titles to Indicators (ok personal pet peeve perhaps, but one of my favorite CTI sources still doesn't do this)
IMO title fields should either be absent or required. Having optional title fields makes it hard for consumers because there MIGHT be useful information in there
that they need to display/track, but might not so they need to make something up.
2. Adding attribution information in a description for an Indicator object or describing Threat Actor as an Indicator object and not creating\linking to a Threat Actor
object instead.
Part of this is probably just growing pains. Part of it is probably that you can’t currently go directly from indicator to threat actor. Should we add an explicit
“indicated actor” relationship?
2a. ...or for that matter jamming TTP information in an Indicator description without a TTP object.
This is probably also growing pains, but maybe our move to separate TTP objects will help? Maybe we can also (in the spec) document defined relationships in a
way that makes it very clear exactly what you’re supposed to do.
3. Using an Incident Object to describe a TTP or a TTP object to describe an incident. (Is a malware variant an Incident or a TTP specific example/case vs general instance
problem)
Better definitions in the specs?
3a. Is each occurrence of a piece of malware that has Indicators/Observables with the same Victim Targeting a new and different TTP or should it really link back to
the same TTP object? What I was seeing at one point was each Zeus Trojan targeting customer of Bank X getting its own TTP every time there was a new C2 as an Indicator. It really should have been Zeus Trojan TTP with Victim Targeting of bank X, with C2 Indicators
linked to the same TTP + Victim Targeting object again and again for each new C2 Indicator/Observable
I don’t really have any recommendations here…anyone on the implementor side have advice? How can we make sure that people do this, or at least encourage them
as much as possible to do it?
4. Creating Observables with no Indicators linked to them.
This could be fine if they were creating observable instances. But, in STIX 2.0, by having explicit separation between instances (Observations) and patterns (non-TLOs
that must appear nested within an indicator) I think we can avoid it.
5. Creating Indicators with no Observables and having the observable data in the description.
Require indicator pattern.
What else? Are there other problems in 1.2 that we can try to head off in 2.0?
For 1.2, these are things we tried to address via the idioms. They have examples and descriptions for most of these topics. Will people be more likely to read a
top 5 than our giant list? It would be easy enough to create a new page for “things not to do in STIX 1.2”.
The suggested practices page is a good start for an implementor’s guide. However, looking at Mark C.’s list, I do not think anyone would easily see where they went
wrong.
Maybe a version or section on the page that reads like the SANS 20? Mark C.’s top five, with their corresponding “right ways” would go a long way.
If this maps to what you are thinking, I’d recommend adding/commenting on the suggested practices. MITRE can comment on how contributions (e.g., pull requests)
would be handled.
I would offer we start with a FAQ (on a wiki) that eventually (but not yet!) becomes the bulk of an implementor’s guide.
Not yet because the tail will start wagging the dog.
Start now because STIX
will get a black eye if people are saying they cannot exchange data with it.
I have seen a bunch of this equally across government sources, from commercial sources, and individual threat analysts and they were taking some script
they used to make CTI in home grown formats and then did a swag at turning the CTI data into STIX. They did not know about the STIX validator. When I talked to them about the validator they went back and tweaked their home grown script until it made technically
valid STIX at least as the validator is concerned. However this rarely lead to them making "useful" STIX however at the first redo.
A few repeat problems I have seen for STIX that validates , but still frustrates...
1. Not adding titles to Indicators (ok personal pet peeve perhaps, but one of my favorite CTI sources still doesn't do this)
2. Adding attribution information in a description for an Indicator object or describing Threat Actor as an Indicator object and not creating\linking to
a Threat Actor object instead.
2a. ...or for that matter jamming TTP information in an Indicator description without a TTP object.
3. Using an Incident Object to describe a TTP or a TTP object to describe an incident. (Is a malware variant an Incident or a TTP specific example/case
vs general instance problem)
3a. Is each occurrence of a piece of malware that has Indicators/Observables with the same Victim Targeting a new and different TTP or should it really
link back to the same TTP object? What I was seeing at one point was each Zeus Trojan targeting customer of Bank X getting its own TTP every time there was a new C2 as an Indicator. It really should have been Zeus Trojan TTP with Victim Targeting of bank X,
with C2 Indicators linked to the same TTP + Victim Targeting object again and again for each new C2 Indicator/Observable
4. Creating Observables with no Indicators linked to them.
5. Creating Indicators with no Observables and having the observable data in the description.
Maybe we should have FAQ of common STIX mistakes to avoid or "Common usage convention" for STIX 1.x.
SOLTRA | An
FS-ISAC and DTCC Company
+1.813.470.2400 office | +1.610.659.6671 US mobile | +44 7823
626 535 UK mobile
One organization's incident becomes everyone's defense.
|