[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Quality of the specs
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]
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.
... . . . |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]