[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Quality of the specs
+1
I feel your pain Mark. ;-)
sean
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
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)
Email: cert@cisecurity.org
www.cisecurity.org
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). 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?
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. ... . . . |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]