OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [cti] Quality of the specs

I feel your pain Mark. ;-)


From: <cti@lists.oasis-open.org> on behalf of Mark Clancy <mclancy@soltra.com>
Date: Thursday, February 4, 2016 at 5:21 PM
To: Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Quality of the specs

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.


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.

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
Sent: Thursday, February 4, 2016 9:02 AM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Quality of the specs
Unfortunately, I can’t say with 100% certainty. The STIX documents were sent via email, so I don’t have a clue what created the documents from a tool perspective. 

I feel like some of it is that people are just taking liberties with the language. For example, one error I just got when trying to validate a file said:

“The value ‘Domain Name’ is not an element of the set {‘FQDN’, ‘TLD’}”

This says to me, and I could just be wrong, that someone implemented something that didn’t like the options of FQDN or TLD, so they just put Domain Name there instead. 

However, some of the problems might be just an issue reading/interpreting the specs. I have also seen the error:

“Element ‘{http://stix.mitre.org/stix-1}Handling’ is not a member of…” however “{http://stix.mitre.org/Indicator-2}Handling” is one of the options in the list. Since I’m an analyst and not a spec writer or a tool developer, this error doesn’t mean much to me, but it might mean something to others. 

Sorry I can’t provide more specifics, but I really don’t know how these documents were generated. 

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)
Follow us @CISecurity

From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Thursday, February 4, 2016 at 8:48 AM
To: Eric Burger <Eric.Burger@georgetown.edu>
Cc: Sarah Kelley <sarah.kelley@cisecurity.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Quality of the specs

Furthermore - are the people creating this STIX using a tool provided by a vendor, or crafting it by hand (or using home grown tools).

Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown

Inactive hide details for Eric Burger ---02/04/2016 07:20:43 AM---In your experience is it that people are not reading the specEric Burger ---02/04/2016 07:20:43 AM---In your experience is it that people are not reading the specs, the specs are ambiguous, the specs a

From: Eric Burger <Eric.Burger@georgetown.edu>
To: Sarah Kelley <Sarah.Kelley@cisecurity.org>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 02/04/2016 07:20 AM
Subject: [cti] Quality of the specs
Sent by: <cti@lists.oasis-open.org>

In your experience is it that people are not reading the specs, the specs are ambiguous, the specs are wrong, or the validator is wrong?
      On Feb 2, 2016, at 2:53 PM, Sarah Kelley <Sarah.Kelley@cisecurity.org> wrote:

      Can I make a request that every training that takes place regarding STIX/TAXII/CybOX specifically mention/provide training on the STIX validator? We have had several different instances where people attempt to share information with us in STIX format, but the STIX doesn’t validate so we can’t actually use what they’re sending us.

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.
. . .

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]