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

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.

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 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
One organization's incident becomes everyone's defense.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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