Requiring that security tools have to parse the entire STIX high level object structure, just to get the context that an indicator title used to contain, is likely a high barrier to entry for tool vendors. Most tools are literally going to just pull the
observables out of the indicator and build a signature. The title gives them some context for the signature. Also, most tools use Indicator title as a quick and easy way to browse indicator content or as a very brief summary of the object that can be displayed
within a tool when the indicator is detected. We have have had to auto-generate titles in the past when a user is not present to define them. In most cases, an auto-generated title is still better than an indicator with no title.
I am in favor of making indicator title mandatory.
Aharon
From: <
cti@lists.oasis-open.org > on behalf of "Wunder, John A." <
jwunder@mitre.org >
Date: Wednesday, February 10, 2016 at 8:38 AM
To: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Subject: Re: [cti] Quality of the specs
I’m still having trouble understanding what people want to put in to an indicator title. Can someone give us a few examples of what they would use it for, in particular when it’s not just capturing information that’s already in the indicated behavior (malware,
attack pattern, actor, campaign, etc) or in the pattern?
From: <
cti@lists.oasis-open.org > on behalf of "Jordan, Bret" <
bret.jordan@bluecoat.com >
Date: Tuesday, February 9, 2016 at 7:27 PM
To: Jason Keirstead <
Jason.Keirstead@ca.ibm.com >
Cc: Sean Barnum <
sbarnum@mitre.org >, Aharon Chernin <
achernin@soltra.com >, Sarah Kelley <
Sarah.Kelley@cisecurity.org >,
"
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Subject: Re: [cti] Quality of the specs
agreed
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 14:27, Jason Keirstead <
Jason.Keirstead@ca.ibm.com > wrote:
Keeping "title" as optional and removing it are two very different things.
There are many instances where there won't be a human at the keyboard to put a title on an indicator. If "title" is made mandatory, then in those situations the title will be auto generated from the content, and probably not very useful.
I do not think indicator title is the same class as TTP information. There are use cases for indicators without human created titles.
Sent from IBM Verse
Jordan, Bret --- Re: [cti] Quality of the specs ---
From:
"Jordan, Bret" <
bret.jordan@bluecoat.com >
To:
"Barnum, Sean D." <
sbarnum@mitre.org >
Cc:
"Jason Keirstead" <
Jason.Keirstead@ca.ibm.com >, "Aharon Chernin" <
achernin@soltra.com >,
"Sarah Kelley" <
Sarah.Kelley@cisecurity.org >,
cti@lists.oasis-open.org Date:
Fri, Feb 5, 2016 12:44 PM
Subject:
Re: [cti] Quality of the specs
I would love to hear from some of these "current users" on how and why they think the field is useful..
I would suggest that we have a design goal to not force TLOs to look and feel the same. If they happen to end up that way do to real need, then great. But lets not force a field on one TLO just because it is valid in 4 others.
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 5, 2016, at 13:38, Barnum, Sean D. <
sbarnum@mitre.org > wrote:
I would agree to some degree though I do not believe we can/should remove it.
I believe that Mark is far from unique in his desire to see this property consistently populated. Several other current users have talked about how they feel this field is useful and plan to use it.
That is completely aside from the desire to treat top-level objects consistently.
sean
From: <
cti@lists.oasis-open.org > on behalf of Jason Keirstead <
Jason.Keirstead@ca.ibm.com >
Date: Friday, February 5, 2016 at 3:24 PM
To: "Jordan, Bret" <
bret.jordan@bluecoat.com >
Cc: Aharon Chernin <
achernin@soltra.com >, Sarah Kelley <
Sarah.Kelley@cisecurity.org >, "
cti@lists.oasis-open.org "
<
cti@lists.oasis-open.org >
Subject: Re: [cti] Quality of the specs
I'm just going to put it out there that if "title" is made mandatory, the most likely outcome is you will end up with a lot of
garbage-ish auto generated titles.
Sent from IBM Verse
Jordan, Bret --- Re: [cti] Quality of the specs ---
From:
"Jordan, Bret" <
bret.jordan@bluecoat.com >
To:
"Aharon Chernin" <
achernin@soltra.com >
Cc:
"Sarah Kelley" <
Sarah.Kelley@cisecurity.org >,
cti@lists.oasis-open.org Date:
Fri, Feb 5, 2016 2:19 PM
Subject:
Re: [cti] Quality of the specs
+1 on both points Aharon. Point 1 is a good sanity check, and it is important to remember that just because there is a standard "somewhere" by some "standards body" does not mean it will be used or adopted. Lets make STIX easy to use and easy to write tools
for, so that it will actually be used everywhere. Lets not overly restrict things that we do not fully understand. Lets focus on what we know, and do it really well.
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 5, 2016, at 11:08, Aharon Chernin <
achernin@soltra.com > wrote:
Sarah, I support the relationship object creating relationships to any object type, for the same reasons you put in your message! We should not try to force people to use relationships the way we see fit within the spec. If we limit users abilities
to create relationships, then people will just move to proprietary products that don’t implement standards.
> And as to the Title field on indicators, I ’ ve
never really understood its purpose. We use it, but the title field of the indicator is just the indicator itself. So if we ’ re putting in a domain, the title will just be the domain name, which just seems like
duplication of effort.
The indicator could contain a little more context than just the observable :) And it should. I support Mr Wunder’s approach of either making the title field required or removing it.
Aharon
From: <
cti@lists.oasis-open.org > on behalf of Sarah Kelley <
Sarah.Kelley@cisecurity.org >
Date: Friday, February 5, 2016 at 12:12 PM
To: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Subject: Re: [cti] Quality of the specs
I would agree that a lot of the problem of putting things in the wrong TLO is likely due to a lack of ability to create the links/relationships that are necessary.
I would +1000 the need to be able to link indicators directly to threat actors. This one missing relationship has caused more issues than any other for us. We are currently doing something
similar to what was described below (on purpose). We create fake campaigns that are named the same as (and sometimes even contain the exact same information as) a threat actor just so we can create a threat actor -> Campaign -> indicator relationship and link
indicators to threat actors that way.
I have also put CVE information directly into the description field of a threat actor or a campaign because I can ’ t
currently link CVEs directly to either of these TLOs either. ( I do then create the CVE object, but it isn ’ t
then linked to anything, unless I happen to have the TTP, which I usually don't.)
This is would be two more relationships I would like to see added.
As far as the indicator/observable problem(s), I personally do not see the need to have to do both (though
we do because the Soltra Edge tool makes us). We use a 1-to-1 relationship here, so having both is just cumbersome.
And as to the Title field on indicators, I ’ ve
never really understood its purpose. We use it, but the title field of the indicator is just the indicator itself. So if we ’ re putting in a domain, the title will just be the domain name, which just seems like
duplication of effort.
Sarah Kelley
Senior CERT Analyst
Center for Internet Security (CIS)
Integrated Intelligence Center (IIC)
Multi-State Information Sharing and Analysis Center (MS-ISAC)
1-866-787-4722 (7×24 SOC)
Email:
cert@cisecurity.org www.cisecurity.org Follow us @CISecurity
From: <
cti@lists.oasis-open.org > on behalf of "Wunder, John A." <
jwunder@mitre.org >
Date: Friday, February 5, 2016 at 8:51 AM
To: Eric Burger <
Eric.Burger@georgetown.edu >, "
cti@lists.oasis-open.org " <
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 creatinglinking 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”.
John
From: <
cti@lists.oasis-open.org >, Eric Burger <
ewb25@georgetown.edu > on behalf of Eric Burger <
Eric.Burger@georgetown.edu >
Date: Friday, February 5, 2016 at 7:17 AM
To: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Subject: Re: [cti] Quality of the specs
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.
On Feb 5, 2016, at 7:00 AM, Mark Davidson <
mdavidson@soltra.com > wrote:
There is a place where suggested practices live:
http://stixproject.github.io/documentation/suggested-practices/ 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.
Thank you.
-Mark
From: <
cti@lists.oasis-open.org >, Eric Burger <
ewb25@georgetown.edu > on behalf of Eric Burger <
Eric.Burger@georgetown.edu >
Date: Thursday, February 4, 2016 at 11:19 PM
To: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Subject: Re: [cti] Quality of the specs
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.
On Feb 4, 2016, at 5:21 PM, Mark Clancy <
mclancy@soltra.com > wrote:
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 creatinglinking 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.
-Mark
Mark Clancy
Chief Executive Officer
SOLTRA An
FS-ISAC and DTCC Company
+1.813.470.2400 office +1.610.659.6671 US mobile +44 7823
626 535 UK mobile
mclancy@soltra.com soltra.com
One organization's
incident becomes everyone's defense.
...
This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify
the sender immediately and permanently delete the message and any attachments.
. . .