Jason:
Here are some thoughts as to why H2H communications through a Threat Intel Platform works better than through encrypted email:
1. Trust circle conditions have already been worked out in advance for each of the members that have been onboarded onto a platform... therefore the human analyst can stay focused (in real time) on the problem at hand (e.g., incident response, data enrichment, TTP analysis, attribution elements synthesis, etc..) and once he/she has some information (or data) for responding to an RFI...he/she can just do it, without having to create a distribution list.
2. Trust circle conditions that have been worked out on advance may include such things as: security level data classifications (i.e., data markings), confidence intervals (stemming from the reliability and credibility of the source), classifications for the type of information being shared (e.g., situational awareness reports, IoCs, malware artifacts, etc...). Again... if all of this is worked out in advance it saves the analyst time and energy and makes the process more efficient.
3. The size of the membership of an ISAC or ISAO may be such that an email with a large distribution list may be detected as spam ... and filtered out of a recipient's in-box.
4. The Threat Intelligence Platform can be designed to have streamlined interfaces with other network tools so findings from an RFI can be immediately uploaded to a network device (e.g., a Snort snippet).
There are other reasons, as well, I'm sure. These are just a few off the top of my head.
Jane Ginn, MSIA, MRP
Cyber Threat Intelligence Network, Inc.
-------- Original Message --------
From: Jason Keirstead <>
Sent: Friday, October 30, 2015 10:36 AM
To: "Jordan, Bret" <>
Subject: Re: [cti-stix] STIX Sightings
CC: Aharon Chernin <>,,"Jonathan Bush (DTCC)" <>,Joep Gommers <>,Mark Davidson <>,Patrick Maroney <>,"Sean D. Barnum" <>,Terry MacDonald <>,Trey Darley <>
(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
"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" <>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: Aharon Chernin <>, Trey Darley <>, Terry MacDonald <>, "Sean D. Barnum" <>, Patrick Maroney <>, Mark Davidson <>, Joep Gommers <>, "Jonathan Bush (DTCC)" <>, "" <>
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 <> 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" <>
To:"Trey Darley" <>, "Terry MacDonald" <>
Cc:"Barnum, Sean D." <>, "Patrick Maroney" <>, "Davidson II, Mark S" <>, "Joep Gommers" <>, "Jonathan Bush (DTCC)" <>,
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]
