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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-taxii message

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


Subject: Re: [cti-stix][cti-taxii] STIX Sightings


+1


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 14:29, Terry MacDonald <terry@soltra.com> wrote:

Hi Jason,
 
Adding in cti-taxii…
 
Everything we are trying to do eventually winds up as Human to Human. It’s just a question of how that data is surfaced to the Human.
 
What we are trying to do is insert expert tools into the human to human flow, to reduce the complexity for the human end-user (it’s ALWAYS about the end-user) and bubble up things they should be looking at. 
 
Human <-> Email <-> Human does not scale. There is no repository function, there is no tooling that understands threat intelligence and no standard way to communicate or manage it. 
 
Human <-> TI Tool <-> STIX <-> TAXII <-> STIX <-> TI Tool <-> Human works much better. I see what we are trying to achieve as basically H2M2M2H communication with expert TI Tool filtering J.
 
Joep’s point, which I believe is a very excellent one, is that the TAXII step may not always be there – especially at this ‘early adopter’ stage of CTI sharing. We aren’t currently in the mainstream, so it is highly likely that there will be multiple different transport mechanisms used. We need to make sure the STIX still works over which ever transport mechanism is used i.e. Human <-> TI Tool <-> STIX <-> Email <-> STIX <-> TI Tool <-> Human.
 
This is where the loose coupling/tight cohesion of TAXII and STIX is important. Each needs to be responsible for its own job and do it well. We need to discuss the boundaries between the two protocols and ensure that there is no missing or overlapping functionality between them.
 
We need to remember that the ultimate goal is the enable Organizations (and the humans in them) to share and receive threat intelligence easier to help them better defend themselves. We have a responsibility to ensure that we are always looking at this from the end-users viewpoint, and not just doing things because it makes our lives as vendors and implementers easy (although that is a factor). If STIX/TAXII doesn’t provide what end users want, then vendors won’t use it, and STIX/TAXII dies.
 
Cheers
 
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | terry@soltra.com
 
 
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jason Keirstead
Sent: Saturday, 31 October 2015 3:36 AM
To: Jordan, Bret <bret.jordan@bluecoat.com>
Cc: Aharon Chernin <achernin@soltra.com>; cti-stix@lists.oasis-open.org; Jonathan Bush (DTCC) <jbush@dtcc.com>; Joep Gommers <joep@eclecticiq.com>; Mark Davidson <mdavidson@mitre.org>; Patrick Maroney <Pmaroney@Specere.org>; Sean D. Barnum <sbarnum@mitre.org>; Terry MacDonald <terry@soltra.com>; Trey Darley <trey@soltra.com>
Subject: Re: [cti-stix] STIX Sightings
 

(1) Analyst from member company of  ISAC "X" detects SpearPhish, DDOS, Scanning, etc. and want's more information from other members within ISAC "X" 

(2) ISAC "X" Analysts send an RFI through an intermediary like  the NCI (National Council of ISACs) to all other NCI Member Sector ISACs.  What do you know about "Y", Have you seen "Z",  etc.

(3) Analyst "A" has Malware sample and needs to submit it to Agency "B" to establish actionable IOCs ASAP.


So essentially the primary use case is H2H. AKA:
- Human A enters RFI
- It gets delivered to Human B,C,D into some type of inbox
- Eventually, Human B,C,D will see the request, and respond (or not)... minutes to hours to days later (?)
- Said replies go to Human A

It feels to me like it is a re-invention of Email?

"But they use free form data blobs over email and IM. "

Is the solution to simply use STIX over SMTP?

I am trying to envision what the protocol is here, that makes this data flow work any better than an encrypted email.

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

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


<image001.gif>"Jordan, Bret" ---2015/10/30 12:49:37 PM---The biggest use case I see is the human to human over STIX and TAXII. We have a large threat resear

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: Aharon Chernin <achernin@soltra.com>, Trey Darley <trey@soltra.com>, Terry MacDonald <terry@soltra.com>, "Sean D. Barnum" <sbarnum@mitre.org>, Patrick Maroney <Pmaroney@Specere.org>, Mark Davidson <mdavidson@mitre.org>, Joep Gommers <joep@eclecticiq.com>, "Jonathan Bush (DTCC)" <jbush@dtcc.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 2015/10/30 12:49 PM
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" deleted by Jason Keirstead/CanEast/IBM]


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



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