Re: [cti] InformationSource

["Wunder, John A." <jwunder@mitre.org>]

I don’t think this use case is really that uncommon. I do think that there’s an important distinction though (as we say in our proposal) between “source” in the sense of what you used to build the report and “source” in the sense of who is publishing the actual report (bibliography vs. author, I guess?). We touched on it in our proposal and it would look something like this:

• STIX Report
  • created_by_ref: whoever creates the STIX object itself (MS-ISAC)
  • References (list)
    • First item
    • reference_type: ‘derived-from’
    • URL/Name: points to original report 1
    • created_by_ref: author of original report 1
    • Second item
      • reference_type: ‘derived-from’
      • URL/Name: points to original report 2
      • created_by_ref: author of original report 2

This way we track in a definitive way, attached to the object itself, both who is responsible for the STIX object and what information they used to create that object. I think a solution like this may be necessary anyway because the relationship approach just points to a source, not an actual report reference.

Obviously if you derive your data from existing STIX reports then you would want to use a relationship. But for referencing non-STIX encoded data it seems to me like this references list approach makes sense. I don’t love that it’s two ways to do things depending on whether the data you derived it from is in STIX, but I also don’t want another TLO to represent non-STIX reports. Kind of a tradeoff there.

John

From: <cti@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
Date: Wednesday, February 3, 2016 at 1:22 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
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)

Email: cert@cisecurity.org

www.cisecurity.org

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.  

Thanks,

Bret

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.
. . .