Maybe a compromise is to use created_by_ref for the STIX producer and use relationships for the derived-by references that we currently directly embed? That makes much more sense to me, so long as we provide a way (maybe via extended relationship properties)
to solve Sarah’s use case of also providing the link to the source document itself (not just the identity). I’m not 100% sure how that would work in Proposal #1 (in proposal #2 it would go in the URL or name field).
This is one of the issues I feel pretty strongly about, for these three main reasons:
Take a look at the example in proposal 1: 3 objects…a source, an indicator, and a relationship
We know someone is claiming that the source is the source of the indicator because there’s a relationship there But who is asserting that? We don’t know who created that relationship, as far as I can tell, because it doesn’t have its own source relationship I guess we can assume that for “has source” relationships the target source also created the relationship? Is that the intent? Or should we add a second relationship there to assert that the source for the “has source” relationship is also US-CERT? The
first seems inconsistent (source is USUALLY a separate relationship, except for this one case) and the second seems burdensome (and still has the problem of that second relationship not having a source, and so on).
My other concern is that we’re moving from a world where producer was directly embedded in the ID to a world where producer isn’t anywhere in the object. That seems like a big move and it makes me nervous. This will either cause a bandwidth explosion or it requires relationships to not be 1:1 anymore
Ie. If I publish 100 indicators, I need either 100 relationships to indicate source (or 200, depending on the decision above) or I need 1 relationship with 100 targets. The latter is certainly doable, I just makes things a bit more complicated IMO because
one STIX object will represent many edges in their database (since most/all graph databases an edge is 1:1).
I do see what you mean though for tracking derived sources, and IMO that’s a good use case for relationships. I would still prefer the simplicity of #2 for that but can see the reasoning behind #1.
John
From: Marlon Taylor <
Marlon.Taylor@hq.dhs.gov >
Date: Thursday, February 4, 2016 at 2:51 AM
To: "'Jordan, Bret'" <
bret.jordan@bluecoat.com >, "Wunder, John A." <
jwunder@mitre.org >
Cc: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >, "
marlon.taylor@us-cert.gov "
<
marlon.taylor@us-cert.gov >
Subject: RE: [cti] InformationSource
@Sarah, others have similar scenarios so you’re not the only one.
@John, I completely agree with you “ these are all challenges
today and will be challenges tomorrow. One of the catch-22s in threat intel is that people often want to be anonymous but those same people also want to build up source reputation . ”
@Bret, I also agree with you “ Lets do what we know and understand, and do it well. ”
Professionals within the cybersecurity and intel fields know and understand the benefits of analysis on the information along with the source(s) attributed
(or not) to that information. This type of analysis can make the difference in implementing a hot-fix for a zero-day or being a bot in the biggest cyber-terrorism campaign known(or unknown). This is what helps them do their jobs well.
While there may be more complex expressions out there…having Source and Information linked together via a separate Relationship [as mentioned in Proposal
1] is not overly complicated and provides much needed analytical power to STIX, this community, and those in this field.
[
https://github.com/STIXProject/specifications/wiki/Active-Issue:-Relating-Source#proposal-1 ]
Marlon Taylor
Technology Services Section (TSS)
National Cybersecurity & Communications Integration Center (NCCIC)
U.S. Department of Homeland Security
From:
cti@lists.oasis-open.org [ mailto:
cti@lists.oasis-open.org ]
On Behalf Of Jordan, Bret
Sent: Wednesday, February 03, 2016 9:31 PM
To: Wunder, John A.
Cc:
cti@lists.oasis-open.org Subject: Re: [cti] InformationSource
I am fully on board with that. Lets do what we know and understand, and do it well. We can always improve or rev the standard 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."
On Feb 3, 2016, at 19:11, Wunder, John A. <
jwunder@mitre.org > wrote:
So to just throw out my opinion (I know you’re probably tired of it by now)…these are all challenges today and will be challenges tomorrow. One of the catch-22s in threat
intel is that people often want to be anonymous but those same people also want to build up source reputation. IMO we shouldn’t try to model and describe these complex relationships 100%, at least for now. Let’s just solve the simpler cases (a single producer,
or a single producer with a list of references), prove it works, and expand later once we get that working.
From:
"Jordan, Bret" <
bret.jordan@bluecoat.com >
Date: Wednesday, February 3, 2016 at 5:16 PM
To: Rich Piazza <
rpiazza@MITRE.ORG >
Cc: "Wunder, John A." <
jwunder@mitre.org >, "
cti@lists.oasis-open.org "
<
cti@lists.oasis-open.org >
Subject: Re: [cti] InformationSource
Great question Rich P.
First, we have this problem today. I can leave the information source data out of the XML blob and send it to you, and you would have no way of knowing where it came from.
So you would need to trust the method of delivery. Did you get it via a CD in the mail? Did you download it form a web page you trust? Did you get it form a TAXII server you trust?
Going forward I kind of see TAXII servers solving a lot of these issues. I know some want to maintain artificial tear lines between STIX and TAXII, but I do not see those
long term. I see TAXII servers doing much more than they did in the past.
Work flow example:
1) You get a TAXII message with some STIX data in it via a TAXII server. Either via a channel or a data collection.
2) You parse the STIX and find a SourceID that you do not have.
3) You ask the TAXII server or the channel via a TAXII message, for help resolving this ID.
I see TAXII servers operating as a data collection requiring people to send the information source object if they do not already have it.. Here is the work flow I see:
1) Analyst 1 sends a STIX Indicator to a TAXII data collection.
2) The TAXII server parses that STIX packages and sees a SourceID that it does not know.
3) The TAXII server sends back a status message to the client saying, send me this Information Source Object.
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."
On Feb 3, 2016, at 12:16, Piazza, Rich <
rpiazza@MITRE.ORG >
wrote:
Help me thru my confusion J
Looking into the Source issue, I keep coming back to the unresolved ID reference issue.
Let’s take this example below – there is no requirement that MS-ISAC sends me the information source/identity objects referred to in the two items
in the References list, is there?
However, MS-ISAC probably has those objects. I really don’t know that MS-ISAC sent me this report unless they include their identity object in the
STIX report (or maybe they sent the identity ID previously), just the ID is worthless, but let’s assume I have it somehow. Let’s also assume that the identity object has some URI/L that helps me get this object from MS-ISAC.
So far so good.
But this falls apart if the creator wants to be anonymous (i.e., created_by_ref is optional for this reason). I now have this report, but I have
no idea of the source, so no way to know how much confidence to have in it. Assuming the references were NOT URLs, I can’t even look at them – since I have no way to find them – because I don’t know who created them.
Maybe I get all this missing information some authoritative TAXII server somewhere. Maybe this is not a specification issue, but just an implementation
issue.
But I don’t see how this works without some guidance from us on to how to handle unresolved ID references.
Rich
From:
cti@lists.oasis-open.org [ mailto:
cti@lists.oasis-open.org ] On
Behalf Of Wunder, John A.
Sent: Wednesday, February 03, 2016 1:35 PM
To:
cti@lists.oasis-open.org Subject: Re: [cti] InformationSource
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
o created_by_ref:
whoever creates the STIX object itself (MS-ISAC)
o 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.
. . .