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
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: "Vargas-Gonzalez, Emmanuelle" <emmanuelle@mitre.org>
- Date: Thu, 7 Feb 2019 17:47:21 +0000
This makes sense to me, if the proponents
of this feature are happy to have it bound to be specific to a collection,
then this would be a fairly elegant approach and it fits the usage pattern
of "match" (that it is filtering the result set of the main endpoint),
and avoids making a new endpoint.
-
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:
"Vargas-Gonzalez,
Emmanuelle" <emmanuelle@mitre.org>
To:
"drew.varner@ninefx.com"
<drew.varner@ninefx.com>, Bret Jordan <Bret_Jordan@symantec.com>
Cc:
"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"
<cti@lists.oasis-open.org>, Shawn Riley <shawn.p.riley@darklight.ai>
Date:
02/07/2019 10:33 AM
Subject:
RE: [cti] Re:
[EXT] Re: [cti] Summary from Working Call
Sent by:
<cti@lists.oasis-open.org>
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]