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


The biggest use case I see is the human to human over STIX and TAXII.  We have a large threat research team and they do this sort of thing every day.  But they use free form data blobs over email and IM.  

It would be so nice if there was a TAXII server in the sky, amazon cloud or rackspace, that threat researchers could connect to and build micro eco-systems around.  Using our TAXII API Base concept we have talked about.  Then they could have a heavy client or web client hooked up to some tools.  As they document certain things they are finding they could push a button to share or ask your peers if they know something about this.  

Obviously some of this is spec related, some is implementation / deployment / process related.  


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Oct 30, 2015, at 08:52, Jason Keirstead <Jason.Keirstead@ca.ibm.com> wrote:

I feel like the use case around RFI is not clearly fleshed out.

What parties and systems would be issuing RFI requests and under what circumstances?
What parties and systems would be responding to said requests?

Only once those two things are well documented and understood by all can we understand how to best service such a request.

As an example of why this is important... I believe only a tiny fraction of potential TAXII client systems would ever have an ability to respond to historical RFI requests... Most would not. So maybe this RFI capability should be limited to only TAXII servers who implement a "repository" specification.

Sent from IBM Verse


Aharon Chernin --- Re: [cti-stix] RE: STIX Sightings --- 

From:"Aharon Chernin" <achernin@soltra.com>
To:"Trey Darley" <trey@soltra.com>, "Terry MacDonald" <terry@soltra.com>
Cc:"Barnum, Sean D." <sbarnum@mitre.org>, "Patrick Maroney" <Pmaroney@Specere.org>, "Davidson II, Mark S" <mdavidson@mitre.org>, "Joep Gommers" <joep@eclecticiq.com>, "Jonathan Bush (DTCC)" <jbush@dtcc.com>, cti-stix@lists.oasis-open.org
Date:Fri, Oct 30, 2015 11:38 AM
Subject:Re: [cti-stix] RE: STIX Sightings


As a community we need to figure out: are RFIs handled through TAXII query or are they handled via something like a STIX Request Package as Terry proposes. I do tend to lean towards TAXII query, but if the community likes the STIX Request Pack approach better then we should depreciate the functionality from TAXII Query. I would like to avoid having two different ways to do the same thing. Aharon On 10/30/15, 4:55 AM, "Trey Darley" wrote: >On 29.10.2015 21:45:21, Terry MacDonald wrote: >> >> PROBLEM: >> >> There is no real mechanism within STIX for a consumer of STIX data >> to ask a question from the rest of the threat sharing community that >> they are part of. This functionality is required if we are going to >> get good multi-directional threat intelligence sharing happening. >> > >Wow, this is good stuff, Terry! I hadn't fully thought through the >notion of a broadcast query. Good on ya, man! > >> >> This is different from the normal 'broadcast' style STIX message, >> where the message is just sent to all parties and no replies are >> expected. With STIX request/response there is a direct >> question/answer relationship required. >> >> Please note this request/response is also different to TAXII Query, >> as the question is being asked to all members of the channel, rather >> than just the single TAXII server you are locally connecting to >> (which is IMHO more where TAXII Query fits in). >> > >I'm biased, since I've been working on the notional query spec for >TAXII 2.0, but I think we can solve this via TAXII REST query instead >of creating two new top-level STIX objects. I've written up my >proposal for query scoping here [0]. > >The tl;dr is to add an optional 'broadcast' parameter to TAXII query. >If not specified, assume that a query is targeting just the local CTI >repository. If the flag is specified, the CTI repository receiving the >query acts as a proxy, forwarding the incoming query to all the hosts >implied by the specified trustgroup(s), collecting the query results, >and passing them back to the client. > >[0]: https://taxiiproject.github.io/taxii2/notional-query-api/#query-scoping > >-- >Cheers, >Trey >-- >Trey Darley >Senior Security Engineer >4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 >Soltra | An FS-ISAC & DTCC Company >www.soltra.com >-- >"There are only two hard things in Computer Science: cache >invalidation and naming things." --Phil Karlton

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



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