It seems like all of this can and will be fixed as we improve the tooling.
Thanks,
Bret Bret Jordan CISSPDirector 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."
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 One organization's incident becomes everyone's defense.
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:
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
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. . . .
|