As Greg states – the specification gives complete freedom to relate any SDO to any other SDO, using any relationship name, suggested or “custom’. It goes even further by saying the following:
Relationship types defined in the specification SHOULD be used to ensure consistency.
This implies (according to my reading) that the number of “suggested” relationship types should be kept to a small set whose semantics are not open to much interpretation.
I think the set we have is consistent with that idea. We should feel VERY resistant to added others, especially if it seems there isn’t a generally agreed upon use case.
Of course, on the other side of the ledger, the specification gives analysts the ability to “model” CTI using relationships in ways that make sense to them – including “shortcuts” (sorry Greg).
Rich
--
Rich Piazza
The MITRE Corporation
781-271-3760
From: <cti-stix@lists.oasis-open.org
> on behalf of John Wunder <jwunder@mitre.org>
Date: Thursday, August 31, 2017 at 3:28 PM
To: "Back, Greg" <gback@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org >
Cc: Allan Thomson <athomson@lookingglasscyber.com >, Bret Jordan <Bret_Jordan@symantec.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, Terry MacDonald <terry.macdonald@cosive.com>
Subject: Re: [cti-stix] Small changes from 2.0 - 2.1 - add relationship from indicator to vulnerability
I agree with this. Analysts will already be able to add this relationship (assuming their tooling supports it), so we don’t need to give them the ability to do so by defining it. I also worry about the overlap of this with the vulnerability management space (OVAL/SCAP), as Jason has mentioned.
From: <cti-stix@lists.oasis-open.org
> on behalf of Greg Back <gback@mitre.org>
Date: Thursday, August 31, 2017 at 10:46 AM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org >
Cc: Allan Thomson <athomson@lookingglasscyber.com >, "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, Terry MacDonald <terry.macdonald@cosive.com>
Subject: Re: [cti-stix] Small changes from 2.0 - 2.1 - add relationship from indicator to vulnerability
> I personally can’t see a reason to have a relationship between an indicator and a vulnerability, but I don’t want to stand in the way of someone else making that connection if they see value in it.
This is exactly my point. Nothing in the spec currently prohibits people from doing this, and if we can’t come up with a good example, then we shouldn’t suggest it in the spec. If we’re going to arbitrarily add new SDOs to the suggested relationship types, why not just remove all suggested SDO types on relationships and have just a list of recommended relationship names?
I feel like we’re falling into the trap of adding something to the spec because it’s easy to do so (it’s only a handful of characters), without considering the broader implications. The burden should be on the reason a change *needs* to be in the spec (you can’t currently do something that needs to be done), rather than on arguing why something shouldn’t be there.
Greg
On 2017-08-31, 12:28 UTC, "Sarah Kelley" <Sarah.Kelley@cisecurity.org> wrote:
I think I agree with Terry here.
I personally can’t see a reason to have a relationship between an indicator and a vulnerability, but I don’t want to stand in the way of someone else making that connection if they see value in it. I feel like if we say no to this, we’ll be right back to the problems I had when I started in this committee with STIX 1. Namely, I couldn’t connect an indicator directly to a threat actor because “there’s really a TTP in the middle somewhere”. My argument in response to that was two-fold. First, that wasn’t always true. (ex: A threat actor used an email address to register a domain. No real TTP to document, but two indicators to tie to a threat actor.) Second, there may have been a TTP, but I may not have known what it was.
Ultimately, I’m all for letting the analyst do what they need to do, because if we don’t allow it in the spec, they’re just going to do it anyway, however they need to.
Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-ISAC)
31 Tech Valley Drive
East Greenbush, NY 12061
518-266-3493
24x7 Security Operations Center
SOC@cisecurity.org - 1-866-787-4722
From: <cti-stix@lists.oasis-open.org
> on behalf of "terry.macdonald@cosive.com" <terry.macdonald@cosive.com>
Date: Wednesday, August 30, 2017 at 9:09 PM
To: "Back, Greg" <gback@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org >, Allan Thomson <athomson@lookingglasscyber. com >, Bret Jordan <Bret_Jordan@symantec.com>
Subject: [cti-stix] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - add relationship from indicator to vulnerability
Hi Greg,
I think its really important to encourage threat intelligence from organisations that only want to do the minimum. We need to make it as easy and as flexible as possible. I do understand your concerns, but this is an area where I feel strongly that allowing people the flexibility to build the threat intel their own way will encourage them to contribute the threat intel as it's being developed. It's about enabling people to share their partially finished workings, and crowd-sourcing information from the group, hypothesising and guessing relationships. I expect that in real use we could have an Indicator pointing to 10 different vulnerabilities and 5 different attack patterns, each with their own confidence weighting, and each with relationships created by different users. All of this information will be invaluable to consumers, who will need to find some way of weighting and balancing this information in a way that will let them decide which information they trust.
In my mind the more relationships we can have between SDOs the better, as it is all information that consumers can use.
Cheers
Terry MacDonald | Chief Product Officer
On Thu, Aug 31, 2017 at 12:50 PM, Back, Greg <gback@mitre.org> wrote:
I went back and read the relationships section of the spec. I forgot that it does explicitly mention that “shortcut” relationships are an integral part of STIX (which I’ve always disagreed with).
There’s nothing explicitly preventing someone from creating the relationship being proposed (I don’t think [1]). But I’m asserting that it’s a bad idea for us to explicitly declare that relationship because it encourages sloppy linkages (unless there’s another example besides eliding the Attack Pattern in Terry’s original example, or the vulnerabilty scanning example that Jason mentioned on GitHub). Without a good reason, I feel like explicitly promoting a “shortcut” relationship when there is a more explicit (or, some may say, pedantic) way to represent it counts as “two ways of doing the same thing”.
If I’m the only one who feels this way, I’ll accept the consensus, but I can’t promise I’ll agree with it. ;-)
Greg
[1] The spec says “STIX also allows relationships from any SDO to any SDO that have not been defined in this specification. These relationships MAY use the related-to relationship type or MAY use a custom relationship type.“ It doesn’t say explicitly that you can use a defined relationship between two SDOs where that specific defined relationship isn’t listed, but it doesn’t say that you can’t, either.
On 2017-08-30, 23:12 UTC, "Bret Jordan" <Bret_Jordan@symantec.com> wrote:
+1
Sent from my iPhone
On Aug 30, 2017, at 4:54 PM, Allan Thomson <athomson@lookingglasscyber.com > wrote:+1
Allan Thomson.
CTO, lookingglass cyber solutions.
Www.lookingglasscyber.com. This electronic message transmission contains information from LookingGlass Cyber Solutions, Inc. which may be attorney-client privileged, proprietary and/or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe that you have received this message in error, please contact the sender, delete this message, and be aware that any review, use, disclosure, copying or distribution of the contents contained within is strictly prohibited.
From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org
> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
Sent: Wednesday, August 30, 2017 3:51:10 PM
To: Back, Greg
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Small changes from 2.0 - 2.1 - add relationship from indicator to vulnerability
Hi Greg,
I think we should allow Analysts to track whatever makes sense to them. We should not constrain the model (and we do not) - it should be up to people to use the building blocks we provide them where they see it makes sense.
My reasoning for this is that during an investigation you are putting together information, and trying to figure out whats occurring. It is entirely possible that an organisation hasn't actually analysed the attack pattern at all, but instead just knows from media reports that if you see this packet, then its heartbleed scanning attempt. They may not even care which attack pattern it is, because they may not track attack patterns at all.
We don't lose anything by adding this relationship to the model. They already have a way of relating this using the related-to relationship type. This just adds more description a relationship that is already possible.
This of course also means that if the analyst periodically goes through mapping vulnerabilities to attack_pattern SDOs (or someone else in the community does), then they are free to map that relationship as well.
The whole point of STIX 2.x series to to free ourselves from the constraints imposed by a limited set of relationships, and to allow the threat analysts to use the parts of STIX that make sense to them. I view it like LEGO(R). We provide simple building blocks and ways of connecting all the bits together, then we let the Analysts build the structures that make most sense to them.
Cheers
Terry MacDonald | Chief Product Officer
On Thu, Aug 31, 2017 at 10:13 AM, Back, Greg <gback@mitre.org> wrote:
So, I think of that as actually being “Scanning for and attempting to exploit Heartbleed” as an Attack Pattern, and you can have Indicator -> (indicates)-> Attack Pattern -> (targets) -> Vulnerability. I don’t think the “shortcut” Indicator -> (indicates) -> Vulnerability is useful enough to justify the new relationship.
Jason brought up the idea of vulnerability scanning on GitHub, but as he suggested (and I totally agree) OVAL covers that use case pretty well, and it seems outside the scope of CTI.
Greg
On 2017-08-30, 22:06 UTC, "Terry MacDonald" <terry.macdonald@cosive.com> wrote:
Hi Greg,
Heartbleed springs to mind. If there is a vulnerability that affects a large portion, and people start scanning for it, then this relationship would allow a TIP to show this fact in our data model.
It makes sense in my mind.
Cheers
Terry MacDonald
Cosive
On 31/08/2017 08:03, "Back, Greg" <gback@mitre.org> wrote:
From my comment [1]:
Can someone give a practical example of a vulnerability and an indicator for that vulnerability (actual STIX JSON)? It would be beneficial to have this in the spec (or an associated implementation guidance document), and would help me understand to make sure we aren't introducing multiple ways of doing something.
I recognize that sometimes "shortcut" relationships are necessary, rather than the more pedantic but accurate ones, but want to make sure we take that into account (my standard example from STIX 1/CybOX 2 is that malware doesn't really connect to a Domain name, but you connect to whatever IP address that domain happens to resolve to).
Greg
[1] https://github.com/oasis-tcs/
cti-stix2/issues/15# issuecomment-326067773
On 2017-08-30, 19:36 UTC, "cti-stix@lists.oasis-open.org on behalf of Terry MacDonald" <cti-stix@lists.oasis-open.org on behalf of terry.macdonald@cosive.com> wrote:
Makes a lot of sense. I vote to make the change.
On 31/08/2017 05:01, "Allan Thomson" <athomson@lookingglasscyber.
com > wrote:We should add.
STIX already has a fallback that allows to create a relationship between 2 SDOs and this just provides an explicit naming of that relationship instead of relying on the generic reln.
Allan
From: "cti-stix@lists.oasis-open.org
" <cti-stix@lists.oasis-open.org > on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
Date: Wednesday, August 30, 2017 at 7:39 AM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Small changes from 2.0 - 2.1 - add relationship from indicator to vulnerability
GITHUB issue # 15 (https://github.com/oasis-tcs/
cti-stix2/issues/15 )
During the STIX 2.0 CSD comment period, we received a suggestion to add a relationship from an indicator to a vulnerability saying that an indicator “indicates” the vulnerability.
The relationship table for indicator would then look like this (with the change highlighted in yellow):
Embedded Relationships
created_by_ref
identifier (of type identity)
object_marking_refs
identifier (of type marking-definition)
Common Relationships
duplicate-of, derived-from, related-to
Source
Relationship Type
Target
Description
indicator
indicates
attack-pattern, campaign,
intrusion-set,
malware,
threat-actor, tool, vulnerability
This Relationship describes that the Indicator can detect evidence of the related Campaign, Intrusion Set, or Threat Actor. This evidence may not be direct: for example, the Indicator may detect secondary evidence of the Campaign, such as malware or behavior commonly used by that Campaign.
For example, an indicates Relationship from an Indicator to a Campaign object representing Glass Gazelle means that the Indicator is capable of detecting evidence of Glass Gazelle, such as command and control IPs commonly used by that Campaign.
Reverse Relationships
—
—
—
—
Are there any objections to making this change?
Thanks,
Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-ISAC)
31 Tech Valley Drive
East Greenbush, NY 12061
518-266-3493
24x7 Security Operations Center
SOC@cisecurity.org - 1-866-787-4722
<image002.png> <image003.
png> <image004.png> <image005.png> 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.
. . . . .
.....
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.
. . . . .
