[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - add relationship from indicator to vulnerability
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-torelationship 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 reallyconnect to a Domain name, but you connect to whateverIP 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.orgon behalf of Terry MacDonald" <cti-stix@lists.oasis-open.orgon 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.
. . . . .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]