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: [cti-users] STIX 2.1 Propsal - Opinion Object


Hi Pat,

It appears from my reading of the text that you are proposing a focus on ensuring the source provider is kept up to date with as much feedback as possible to allow them to release updated quality threat intel.

My focus is on giving knowledgeable members in a community the ability to indicate their opinion about an assertion released by a provider. I believe this is a missing component that allows down the ability of other less expert community members to learn which threat intel assertions are the ones with paying attention to.

I agree that feedback to the original source is important, and I agree that providing feedback would allow the original source to update and release a corrected version of their threat intelligence (if they wanted to), but I also see a couple of challenges with that approach:

- you can't always convince the source provider to update the original assertion. There is no guarantee the source provider will change what they believe. We may have a situation where to providers think completely different things  and both believe they are 100% correct. The source provider may never update their original assertion. 

- there is no way for community members to learn about negatives, i.e. when the intel is wrong (in someone's opinion). This is what the on object is attempting to achieve. The ability to comment on someone else's assertion.

- it doesn't help new community members figure out which Intel providers are the ones that send out quality intel already and which ones send out less useful intel. It is critical for a recipient to quickly learn which intel can be relied on in order to allow the recipient to actually 'use' the threat intel to protect themselves. 

I think we need a few parts to make this overall process work smoothly:

- we need a way of agreeing or disagreeing with another assertion (Opinion object)

- we need a way of releasing a competing assertion (standard SDO  objects)

- we need a way of relating the new competing assertion to the original assertion. This bit can be done with a related relationship, but maybe it's worth adding a new global 'alternative_theory' relationship type?

Going back to your points about providing feedback to the source provider, I believe we already have the mechanisms in place to be able to do so if we do the STIX question/answer and the opinion object:

- Sightings allow positive sightings of indicators to be released to the community. This extra information would enable the provider to listen on the community and update their information.
- Other third party relationships that others create between two objects reinforces that relationship e.g. if there is a relationship between threat actors A and malware B and 12 different organisations create a relationship object between those two things then you know it's probably a strong relationship. (The problem here is that there is no way to say this relationship didn't exist - that's what opinion object fixes).
- STIX questions/answers are sent to all community members. The source provider would be able to pick up any new intel based on these questions and answers and add that to their own intel potentially triggering an update.
- The Opinion object allows other providers to provide disagreement with the objects that the source provider releases or any relationships they create. Again this is sent to all community members and again it is yet another trigger for the source provider to use to review the threat intel they released earlier.

I personally believe that the use of the opinion object, STIX answers and questions, and the existing STIX objects together cover the use case you have proposed (assuming I've understood it correctly), and that they go further, allowing for faster discussion of problems and quicker feedback to providers where there is contentious claims made in their threat intel. 

This is surely a good thing?

Cheers
Terry MacDonald
Cosive


On 16 Jan. 2017 04:53, "Patrick Maroney" <pmaroney@wapacklabs.com> wrote:
I'd like to propose a different approach to meeting this use case (the objectives of which I fully support).

Please consider the following:

Unless specifically acting as the role of aggregator (which requisite markings to maintain provenance of intelligence one is redistributing), then Sources should only be disseminating intelligence they have originally developed though their own analytic processes or sightings they have directly observed (which can include sightings of observables produced by other Sources).

Each Source should "show their work" to the extent possible without exposing "sources and methods" beyond a given Community of Trust.  In any case, Sources should include their subjective ratings for analysis driven conclusions. 

Sightings should be simple statement of facts:  "I observed this activity matching this pattern".  Sightings can of course include additional enriching analytic conclusions/assertions (i.e., we determined this targeting pattern exactly matches previous campaigns attributed with high certainty to Threat Actor "X"). 

Source "A" may provide packages with rich context, basis for assertions, etc.  Whereas, Source "B"  may just provide a list of a handful of Actionable IOCs.  While one might assume Source "A" is a "higher value/rating",  if the IOCs from Source "B" help to prevent a emerging attack package with new 0Day exploits, then they will receive a high rating until otherwise shown to be less reliable.

Over time Consumers will be able derive their own measures of the viability of intelligence (in and of itself) and from a given Source.  The measures of this will also, over time, accumulate other subjective factors like "relevance" (A given adversary and related intelligence may only be relevant to Sector "X").

Where I think we should focus in terms of CTI Specifications is on the areas required to enable non-attributional Source Traceability where a consumer can direct an RFI or "Opinion" back to the original Source.  A challenge to assertions, if ultimately proven valid, could/should lead to release of a revised package from that Source.  An RFI could similarly result in a re-release of a package (or element of same) with additional details, context, clarification, etc.

Again, over time Consumers will derive their own measures on a given piece of intelligence or Source.  These measures (Positive of Negative) are directly shared today between analysts in many "Communities of Trust".  

Empowering a channel for communication between Consumers and Producers (vs. a voting system between Consumers) would in my view better provide the outcomes we are seeking.

Patrick Maroney
Principle Engineer - Data Science & Analytics
Wapack Labs
(609)841-5104


On Jan 14, 2017, at 9:19 AM, Aharon Chernin <aharon@perchsecurity.com> wrote:

Terry,

 

Do you see the opinion object being used to agree/disagree with an indicator assertion? This could allow us to share false positive / true positive recommendations regarding indicators, which would be something that could immediately be used by most consumers.

 

Aharon

 

From: <cti-stix@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Friday, January 13, 2017 at 9:51 PM
To: Terry MacDonald <terry.macdonald@gmail.com>, Jason Hammerschmidt <Jason.Hammerschmidt@ieso.ca>
Cc: "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, Terry Macdonald <terry.macdonald@cosive.com>
Subject: Re: [cti-stix] RE: [cti-users] STIX 2.1 Propsal - Opinion Object

 

I see this being mostly used and maybe initially limited to providing opinions about a relationship.  If you try to do it against another SDO, how do you tell a tool the "part" of the SDO that you are agreeing with or not agreeing with.  This kind of gets in to the whole granular markings stuff, which I think we should avoid for the near-term.

 

Bret


From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@gmail.com>
Sent: Monday, January 9, 2017 12:20:25 PM
To: Jason Hammerschmidt
Cc: cti-users@lists.oasis-open.org; cti-stix@lists.oasis-open.org; Terry MacDonald
Subject: [cti-stix] RE: [cti-users] STIX 2.1 Propsal - Opinion Object

 

Hi Jason, 

 

To be clear this object isn't specifically for attribution if you were meaning attribution of attacks to certain threat actors. This object simply allows an organisation to agree or disagree with an 'assertion' that another organisation has made (i.e. object they have published).

 

I expect that it would be most commonly used to either agree or disagree with a relationship between two other STIX Data Objects (SDOs), as relationships between objects are likely to involve more uncertainty and guesswork. It can also be used to agree or disagree with a specific SDO (e.g. An identity object) but I believe this will be much less common.

 

The idea behind the object is to allow recipients within a threat intelligence sharing community to work out which threat intelligence objects are commonly agreed (and therefore can be potentially be more trusted), and which threat intelligence is more contentious and need to be treated more like a guess. It is important to remember that each original object published is a single organisations assertion of the truth, so providing a way for other organisations to comment as to if they agree/disagree with the original assertion of the truth adds the ability for multiple organisations to effectively agree with that assertion of truth, or disagree with it. In either case, that is valuable information for recipients. 

 

Cheers 

Terry MacDonald 

Cosive

 

On 10 Jan. 2017 05:08, "Jason Hammerschmidt" <Jason.Hammerschmidt@ieso.ca> wrote:

I believe this is a valuable addition.  Like other User Generated Content (UGC), attribution is a requirement for the content to be trusted and used, therefore, if added, attribution will be required in some manner for it to be adopted.  I know many people are concerned about attribution but I for one am happy to provide it in this field, in fact I think it will be required moving forward for full adoption, less we only rely a limited set of authoritative feeds.   

 

From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On Behalf Of Terry MacDonald
Sent: December 25, 2016 3:24 AM
To: cti-stix@lists.oasis-open.org; cti-users@lists.oasis-open.org
Subject: [cti-users] STIX 2.1 Propsal - Opinion Object

 

*** EXTERNAL email. Please be cautious and evaluate before you click on links, open attachments, or provide credentials. ***

Hi All,

I'd like to propose the Opinion Object for STIX 2.1.

The Opinion object is an object that allows the creator of the Opinion object to agree/disagree with any other STIX Data Object or STIX Relationship Object. It will allow an Organization to disagree with a relationship between a Threat Actor and a Campaign for example, or agree with the contents of an Course of Action.

This is the first step towards consumers being able to crowd-source the opinion of the community, which will help newcomers to the threat intelligence sharing groups better understand which threats have a high degree of community agreement and which are contentious.

 

Further details in the attached PDF.

 

Cheers

 

Terry MacDonald | Chief Product Officer

 

<image001.png>

 

 

This e-mail message and any files transmitted with it are intended only for the named recipient(s) above and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law.  If you are not the intended recipient(s), any dissemination, distribution or copying of this e-mail message or any files transmitted with it is strictly prohibited.  If you have received this message in error, or are not the named recipient(s), please notify the sender immediately and delete this e-mail message.

 

PERCH

Aharon Chernin / CEO and Founder
aharon@perchsecurity.com / +1 8133358965

PERCH
http://www.perchsecurity.com

Twitter LinkedIn

This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Perch Security is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.




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