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: [cti-stix] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - add relationship from indicator to vulnerability


I commented on Github so I guess I will copy/paste it here (for the record I *REALLY* dislike this cross posting and wish we would stick to one or the other - if the TC is going to use GHE for issues I wish we would move the discussions there, otherwise lets not use GHE)

I think there are more fundamental issues at play here and I don't think this idea (having an "indicator to vulnerability") is something we even want to get into. Everyone already uses OVAL for this. Vulnerability scanner vendors are not going to switch to SCO pattern to look for vulnerabilities. So perhaps instead of this request we should be looking first at how to use OVAL in STIX indicators, and if we even want to get into that.

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security

Without data, all you are is just another person with an opinion - Unknown




From:        Terry MacDonald <terry.macdonald@cosive.com>
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>
Date:        08/30/2017 10:09 PM
Subject:        [cti-stix] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - add relationship from indicator to vulnerability
Sent by:        <cti-stix@lists.oasis-open.org>




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



M: +64 211 918 814
E: terry.macdonald@cosive.com
W: www.cosive.com




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

 

 

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 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_refidentifier (of type identity)
object_marking_refsidentifier (of type marking-definition)
Common Relationships
duplicate-of, derived-from, related-to
SourceRelationship TypeTarget Description
indicatorindicatesattack-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]