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] InformationSource

Originally I agreed with the simpler method strictly for the ease of use. However I realized during the call that the more complicated method using relationships could solve a use case that we have (that we might be the only ones that have).

The use case is this:

I’m entering information about a threat actor into my tool. I have three different reports from three different vendors that contain information about this threat actor group. We insist on being able to tie the information back to the report that we got it from (not just the vendor), so we have to maintain the vendor name and report name somewhere. Currently, what we do internally is just to add (to the description field) a “SOURCE:” tag, and list the reports. So it could say “SOURCE: Group1, Report1; Group2, Report2; Group 3, Report3”. 

Having a way to enter a published report into the tool as a source (not sure if that’s going to work with the revamping of the report object), and then tie it as a relationship to another TLO would actually be helpful, and would stop us from having to create our own ‘field’ inside the description field. (This is not the only time we do that, by the way. We have at least three different ‘fields’ we put into the description because they don’t currently have another place to go.)

I realize that this is likely not exactly what others are meaning by “source”, and that we might be the only people that have this scenario. Given that, I’m definitely ok with going with the simpler method if that is the correct solution for the majority of users.

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 "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Wednesday, February 3, 2016 at 11:45 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] InformationSource

While I understand the great flexibility that can exist with using a relationship object to tie a source to a TLO, I really question if the extra complexity is worth it.  

In an effort to target the 80% and to make STIX super easy to use, I am wondering if it would not be better for 2.0 to just use an optional created_by_id that points to some InformationSource Object.  In doing this I can see a lot of these InformationSource objects becoming "well known".

Then in some future release, if the community and tools need more flexibility, we could again look at using relationships.  But lets learn to walk before we try to run. Further, we have a tendency to flirt with the slipper slope of scope creep.  Lets focus on the minimum amount of things that actually need to be done to meet an 80% target.  We can always rev the standard and add stuff later.  



Bret Jordan CISSP
Director 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." 

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]