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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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


Subject: RE: [cti] Re: [EXT] Re: [cti] Summary from Working Call


Bret,

 

You are right it seems kind of weird to add a new match parameter just for relationship, but what I had presented originally made use of basic match[type]. The example I posted on the chat similar to the following:

 

<taxii_server>/{api-root}/collections/{id}/objects?match[type]=relationship&match[source_ref]=<identifier>

<taxii_server>/{api-root}/collections/{id}/objects?match[type]=relationship&match[target_ref]=<identifier>

 

Of course, for this idea to work it requires text that says you could match on an arbitrary property. Now, I do recognize does present complexities with objects that are embedded/nested since it would involve more depth while searching for that property.

 

- Emmanuelle

 

From: drew.varner@ninefx.com <drew.varner@ninefx.com>
Sent: Wednesday, February 6, 2019 5:40 PM
To: Bret Jordan <Bret_Jordan@symantec.com>
Cc: Vargas-Gonzalez, Emmanuelle <emmanuelle@mitre.org>; Piazza, Rich <rpiazza@mitre.org>; Struse, Richard J. <rjs@mitre.org>; Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Gary Jay Katz <gary.katz@fireeye.com>; Allan Thomson <athomson@lookingglasscyber.com>; cti@lists.oasis-open.org; Shawn Riley <shawn.p.riley@darklight.ai>
Subject: Re: [cti] Re: [EXT] Re: [cti] Summary from Working Call

 

I think it would be really confusing if you had this special set of match options that ONLY worked on certain objects at the generic endpoint.

 

We already have this issue. We have a `versions` match parameter that does not apply to Marking Definitions on the endpoint.

 

- Drew
On Feb 6, 2019, at 4:16 PM, Bret Jordan <Bret_Jordan@symantec.com> wrote:

First off, no one has suggested that this be a required feature.  I even mentioned on the working call that we might need a separate conformance target for it. 

 

Second, Emmanuelle, I think this idea is really weird when you think of how we treat the objects endpoint.  This is really confusing two totally different interactions in to the same thing.  Because we have the ?match[type]=relationship already.  I think it would be really confusing if you had this special set of match options that ONLY worked on certain objects at the generic endpoint.

 

Let me get a written proposal put together that you can all see, so we can stop the heart burn about what it is or what it is not.  

 

Thanks

Bret

 


From: Vargas-Gonzalez, Emmanuelle <emmanuelle@mitre.org>
Sent: Wednesday, February 6, 2019 12:31 PM
To: Piazza, Rich; Struse, Richard J.; Jason Keirstead; Gary Jay Katz
Cc: Allan Thomson; Bret Jordan;
cti@lists.oasis-open.org; Shawn Riley
Subject: RE: [cti] Re: [EXT] Re: [cti] Summary from Working Call

 

Building on what I said on the Working Call. My point of view is that a new API Endpoint just to retrieve relationships that match a given ID was redundant. Note that I am not against option #2, I think we do need that baseline functionality. Now, I felt that the Filtering capabilities already built would work for this purpose. It would just be a matter of defining the behavior of that new field. I know Bretâs comments in regards to that idea was that Filtering was meant to be a holistic solution to filtering, but this is a basic operation given the nature of STIX being graph based.

 

Match Field

Description

<choose-a-name>

The identifier of the object(s) that are being requested. When searching for a STIX Object, this is a STIX ID. The

Server MUST return all relationship objects where source_ref = identifier OR target_ref = identifier


Example
?match[<choose-a-name>]=indicator--3600ad1b-fff1-4c98-bcc9-4de3bc2e2ffb

 

- Emmanuelle

 

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Piazza, Rich
Sent: Wednesday, February 6, 2019 1:06 PM
To: Struse, Richard J. <rjs@mitre.org>; Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Gary Jay Katz <gary.katz@FireEye.com>
Cc: Allan Thomson <athomson@lookingglasscyber.com>; Bret Jordan <Bret_Jordan@symantec.com>; cti@lists.oasis-open.org; Shawn Riley <shawn.p.riley@darklight.ai>
Subject: Re: [cti] Re: [EXT] Re: [cti] Summary from Working Call

 

Three cheers for an âoptionalâ option 2 (although I think Emmanuelle should investigate using the current filtering mechanism, instead of a new endpoint, at the same time)!!!

 

Going with option 2 I think gets us closer to getting 2.1 out â which was the main point of my earlier âscreedâ â

 

From: "Struse, Richard J." <rjs@mitre.org>
Date: Wednesday, February 6, 2019 at 12:53 PM
To: Jason Keirstead <
Jason.Keirstead@ca.ibm.com>, Gary Jay Katz <gary.katz@FireEye.com>
Cc: Allan Thomson <
athomson@lookingglasscyber.com>, Bret Jordan <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Rich Piazza <rpiazza@mitre.org>, Shawn Riley <shawn.p.riley@darklight.ai>
Subject: Re: [cti] Re: [EXT] Re: [cti] Summary from Working Call

 

Is anyone insisting that this feature be mandatory? If so, can they explain their thinking? If not, can we just proceed with this as an optional feature?

 

From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, February 6, 2019 at 12:46 PM
To: Gary Jay Katz <
gary.katz@FireEye.com>
Cc: Allan Thomson <
athomson@lookingglasscyber.com>, Bret Jordan <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "Piazza, Rich" <rpiazza@mitre.org>, Shawn Riley <shawn.p.riley@darklight.ai>
Subject: Re: [cti] Re: [EXT] Re: [cti] Summary from Working Call

 

Gary I think this very much depends. If we look at how things work today, the enormous, enormous majority of intel data shared falls into one of two buckets

a) A feed of things to look for, which is mainly simple IOCs
b) Soup-to-nuts Intel reports.. usually in either a custom format, or PDF. These may be on a feed, or delivered piecemeal / on demand.

In either of these use cases - all of the information required to action the data is normally contained in the envelope. You don't send a client a PDF threat report and have half of the context hyperlinks outside the PDF. Thats not how reports are structured. As such, when we look to encode said reports in STIX, the same paradigms would apply. People would not routinely share intel reports with references to things, and yet not include those things in the report itself. Doing so would be foolhardy for many reasons - the most basic of which, is that I don't even know what TAXII server might house the information in the first place, what it's address is, or if I would even have access to it.

I still believe this is a TIP-only use case... and it makes assumptions about an awful lot of things to be useful - including that the TAXII server from which you pull a piece of intel, is a master repository of all intel information (which isn't necessarily true), and that the TAXII server "acts as a database" as Allan says. I point out all the time - the vast majority of people who are implementing TAXII are bolting it onto already existing security products, they are not building net-new graph databases from scratch. This is why, in Terry and Mine's proposal - which includes this exact use case - the query definition is modular... so that TAXII servers who are not databases don't have to mess around with things like this.

I also still believe that doing this without thinking through the other filtering use cases is a big mistake, because *you will* want to combine this with other filters.

We could not vote to support TAXII 2.1 if this was made mandatory as part of it.

-
Jason Keirstead
Lead Architect - IBM Security Connect
www.ibm.com/security

"Things may come to those who wait, but only the things left by those who hustle." - Unknown




From:        Gary Jay Katz <gary.katz@FireEye.com>
To:        Shawn Riley <shawn.p.riley@darklight.ai>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Piazza, Rich" <rpiazza@mitre.org>
Cc:        Allan Thomson <athomson@lookingglasscyber.com>, Bret Jordan <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date:        02/06/2019 01:24 PM
Subject:        Re: [cti] Re: [EXT] Re: [cti] Summary from Working Call
Sent by:        <cti@lists.oasis-open.org>





Shawn, this isnât directed at you, but at the general path this thread is going.
 
I donât think anyone is disagreeing with that point.  But to bring us back, right now it is not possible to hit a TAXII server and ask what objects relate to this other object.  If you want to work with relationships (and this is a graph based data model, so we should!!), you have to just download all the data from the server in bulk, ingest and process it yourself.  This does not make TAXII a very practical approach for accessing data.  Weâre basically saying in STIX that relationships between data is really important, hence why you need STIX rather than just a bunch of indicators and then weâre not providing any way to actually access data based upon relationships.  
 
Option 2 is just providing baseline functionality.  Side tracking the discussion is exactly how we wind up with year+ delays on releasing an update.  
 
-Gary
 
From: <cti@lists.oasis-open.org> on behalf of Shawn Riley <shawn.p.riley@darklight.ai>
Date:
Wednesday, February 6, 2019 at 11:01 AM
To:
Jason Keirstead <
Jason.Keirstead@ca.ibm.com>, "Piazza, Rich" <rpiazza@mitre.org>
Cc:
Allan Thomson <
athomson@lookingglasscyber.com>, Bret Jordan <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject:
RE: [cti] Re: [EXT] Re: [cti] Summary from Working Call

 
Great reminder Rich. âRemember, STIX and TAXII is for sharing data â not processing it.â
 
There is a another community out at the DHS and NSA sponsored Integrated Adaptive Cyber Defense effort at JHU-APL and while the focus on orchestration is wrapping up there is increasing focus on automated processing of CTI using Analytic Standards called out in ICD-203 such as the automation of argument-driven inquiry to build out logical arguments in semantic graphs or integrating the CTI using frameworks like the ODNI Cyber Threat Framework or the NSA/CSS Technical Cyber Threat Framework depending on the community youâre supporting.
 
Best,
Shawn
 
Shawn Riley
CDO & CISO
DarkLight
Email:  shawn@darklight.ai
www.darklight.ai

 
From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Jason Keirstead
Sent:
Wednesday, February 6, 2019 8:42 AM
To:
Piazza, Rich <
rpiazza@mitre.org>
Cc:
Allan Thomson <
athomson@lookingglasscyber.com>; Bret Jordan <Bret_Jordan@symantec.com>; cti@lists.oasis-open.org
Subject:
Re: [cti] Re: [EXT] Re: [cti] Summary from Working Call
 
Well said Rich. +1.


-
Jason Keirstead
Lead Architect - IBM Security Connect

www.ibm.com/security

"Things may come to those who wait, but only the things left by those who hustle." - Unknown





From:        
"Piazza, Rich" <rpiazza@mitre.org>
To:        
Allan Thomson <
athomson@lookingglasscyber.com>, Bret Jordan <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date:        
02/06/2019 10:55 AM
Subject:        
[cti] Re: [EXT] Re: [cti] Summary from Working Call
Sent by:        
<
cti@lists.oasis-open.org>






FWIW, I have to agree with Allanâs concerns.  I am in favor of option 2, because people seem to need it, and it seems sort of harmless.  But I think trying to make TAXII a âswiss army knifeâ is not wise.  

If you remember, I âledâ the push to release STIX 2.1 last spring, as it âwasâ.  Some might argue that the discussions and changes we have made since then have shown that this was a bad idea.  I donât know if I agree, but that is water under the bridge.  

But here we are, 10 months later and getting something released is even more imperative.  For instance, would have it been so terrible if the changes to cyber observables took place in STIX 2.2, which if we had already released 2.1 would be the version that we were about to release now? No one in the community should be expecting each release to be perfect and complete.

If I remember correctly, we started on STIX/TAXII 2.1 during the Obama administration!  

Going forward, I think we need to be more âagileâ in our work.  I know developing standards arenât the same as developing software, and having a new version too often has its downsides.  There will always be another SDO we want to eventually be in the standard.  There is always going to be a new feature that we want a TAXII server to have.  But adding feature after feature means that the release date is always 6 months in the future.  And we donât want the standards to be bloated.  Remember, STIX and TAXII is for sharing data â not processing it.

The market will develop and indicate the new features that should be included in future releases, as Allen said.

I know many will violently disagree this â but I think I speak for many in the committee.  

Cheers!

               Rich P.

From:
<cti@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date:
Tuesday, February 5, 2019 at 5:36 PM
To:
Bret Jordan <
Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject:
[EXT] Re: [cti] Summary from Working Call


Bret â I wasnât able to attend the call but an input I have would be that this new capability (whatever option you prefer) should be optional and not required.

This might help remove some objections to having to implement Option 1) vs 2) temporarily.

It also helps remove one of my primary objections which is that we should avoid treating TAXII as a database or interface to a database. That is a slippery slope to duplicating a lot of functionality that databases/indexing and other query engines were designed/excel at.

So Iâm supportive of organizations that want to implement this in a TAXII server but it should not be mandatory for *all* TAXII servers to do so.

Let the market decide what TAXII server capabilities matter and relevant to buying decisions.

Allan

From:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date:
Tuesday, February 5, 2019 at 1:10 PM
To:
"
cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject:
[cti] Summary from Working Call


All,

On today's working call we talked about TAXII query, search, and pivoting.  We had 17 participants on the call today.  The consensus on the call was to move forward with adding a simple RESTful endpoint (option 2) to allow pivoting on relationships. We will also look at a more fully fleshed out query/search solution in a future version of TAXII.  Six people on the call voiced support for this option (Rich, Trey, Jeff, John-Mark, Sean, Ryan), and no one objected to moving forward with this direction.

It is also important to note that Marlon / DHS might have a proposal for how we could address some of the other query use cases using a similar approach to what we are proposing (option 2) for relationships. Once that proposal is submitted to the TC, the TC can review it and determine if and when it should be adopted.

Thanks everyone for attending the call today.  We made a lot of progress.  Drew and I will start implementing this in to TAXII 2.1 Working Draft 07.

Thanks
Bret


This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. [attachment "image001.png" deleted by Jason Keirstead/CanEast/IBM]

 



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