Re: [cti-stix] Small changes from 2.0 - 2.1 - add relationship from indicator to vulnerability

[Terry MacDonald <terry.macdonald@cosive.com>]

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

M: +64 211 918 814

E: terry.macdonald@cosive.com

W: www.cosive.com

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

 

sarah.kelley@cisecurity.org

518-266-3493

24x7 Security Operations Center

SOC@cisecurity.org - 1-866-787-4722

 

                  

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.

. . . . .