OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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

 

sarah.kelley@cisecurity.org

518-266-3493

24x7 Security Operations Center

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

 

<image001.png>

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