I don’t think of it as a man-in-the-middle, more man-on-the-side
J.
I see this information being shared on channels across the organization, and I can definitely see a conversation like this:
-
Firewall emits event in STIX, over TAXII
-
IDS emits in STIX, over TAXII
-
Threat Analysis system is listening to the event TAXII channel and pulls in the events
-
Threat Analysis system recognizes that the IP addresses referenced belong to Campaign which has 5 other related IP addresses,
2 domain names and 10 URLs.
-
Threat Analysis system has plugins that links it to various enterprise log/mgmt platforms, and it performs a search of those
log platforms looking for the bad IP address, 5 other related IP addresses, 2 domain names and 10 URLs.
-
Threat Analysis system detects 1 domain name and URL in log
-
Threat Analysis system has plugin for SIEM, and sends the SIEM an alert to tell monitoring staff to investigate.
-
The Threat Analysis system can then publish a STIX Incident out the same channel (or a different public one) notifying others
that there is an issue, and including the new Observations that have been made by the Firewall and IDS, and the relationship objects linking these all together.
The SIEM may have STIX processing capabilities, or it may not. I believe a lot of Organizations will require an independent Threat
Analysis system until the SIEMs add Threat Analysis functionality, or the Threat Analysis systems add SIEM functionality.
BTW – Threat Analysis system is supposed to be a Threat Intel organizing/investigation system that includes a TAXII Server and integrates
with various internal enterprise tools.
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: Thursday, 5 November 2015 3:12 AM
To: Taylor, Marlon <Marlon.Taylor@hq.dhs.gov>
Cc: Wunder, John A. <jwunder@mitre.org>; cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs?
Maybe this is where we're deviating. I am operating under the assumption that we actually want a firewall vendor to be able to produce sightings natively over TAXII.. at least, in the TAXII SC, this has been widely discussed as a goal - we want as many devices
able to participate and produce in threat intel as possible. IE, I don't want to have to have a "STIX System" in the middle, introducing delay, just to produce sightings... such a thing may used if desired in some environments, but I don't think we should
be assuming having a middle-man is a requirement and immediately limiting future possibilities...
-
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
"Taylor,
Marlon" ---2015/11/04 11:31:01 AM---The requirement for the hashed-based ID wouldn’t be placed on the FW vendor (or any frontline system
From: "Taylor, Marlon" <Marlon.Taylor@hq.dhs.gov>
To: Jason Keirstead/CanEast/IBM@IBMCA, "Wunder, John A." <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 2015/11/04 11:31 AM
Subject: RE: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs?
Sent by: <cti-stix@lists.oasis-open.org>
The requirement for the hashed-based ID wouldn’t be placed on the FW vendor (or any frontline system). It would be placed on whatever system responsible for speaking STIX.
See the scenario:
Firewall
·
Sees traffic
· Writes logs based on rules
o
A custom (or all rules) write to a log specific for STIX usage
At this time nothing is STIX
STIX system
·
Reads logs
· Stores(hash based)/updates DB (sightings count?)
· Sends STIX (via TAXII/Email/etc) at configured frequency*
* Not a required step in the workflow
Frontline products continue to functions without knowledge of STIX.
-Marlon
From:
cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Jason Keirstead
Sent: Wednesday, November 04, 2015 9:32 AM
To: Wunder, John A.
Cc: Taylor, Marlon; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs?
Another reason is, it will slow vendor adption.
Asking a firewall vendor to optionally emit a log in a specific format (a sighting) is probably not that difficult. Asking them to also include in that log a hash of data within, could make their job VERY difficult, as they may not have an accelerated hashing
function in their ASIC that can efficiently generate that log.. and doing anything like hashing in software only is not an option for a firewall vendor.
-
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
"Wunder,
John A." ---2015/11/04 10:21:54 AM---Way to ruin our agreement! (just kidding) Here’s why I don’t want to require hash-based IDs: it will
From: "Wunder, John A." <jwunder@mitre.org>
To: "Taylor, Marlon" <Marlon.Taylor@hq.dhs.gov>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 2015/11/04 10:21 AM
Subject: Re: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs?
Sent by: <cti-stix@lists.oasis-open.org>
Way to ruin our agreement! (just kidding)
Here’s why I don’t want to require hash-based IDs: it will require (sometimes embedded) systems to support specific hashing functions and have specific data available (the full indicator). That may not always be the case and so while it sounds nice in an ideal
world I’m not sure it’s actually practical. So I think it’s fine to allow some communities/tools to work with the hash-based IDs if they want but I don’t think we should force that particular implementation approach on everyone doing sightings.
I actually prefer mandatory IDs on sightings but I’m fine with them being optional, so I’ll step out of that argument.
John
On Nov 4, 2015, at 9:13 AM, Taylor, Marlon <Marlon.Taylor@hq.dhs.gov>
wrote:
I'm for hash-based and mandatory IDs. Could we accept both under the tiered approach?
While we(this community) want to embrace STIX to the fullest extent possible, we live in a world that, for a greater extent doesn't know (or would ever really need to know) STIX. With that said firewall, IDS and the-like might not implement STIX into the software
so we should focus on designing ways to leverage their existing outputs/features to STIX without their explicit participation. This allows vendors to continue their business while providing them "hooks" to incorporate STIX and as products grow other systems
(earlier in the chain) can adopt if they want.
Ultimately, as long as you get STIX from partner_A does it matter whether they generated it directly from their FW, Spam Filter, or the STIX solution integrated into those systems(assuming you confirm it came from partner_A)?
-Marlon
From: Wunder, John A. [mailto:jwunder@mitre.org]
Sent: Wednesday, November 04, 2015 08:55 AM
To: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs?
Uh oh…if you’re OK with ID being optional (and that it doesn’t have to be a hash of the indicator value) then I take back all of my comments over the past 2 days.
I’m not saying it should be required or that you can’t use a hash, just that it’s available and you can also use things other than a hash.
On Nov 4, 2015, at 8:40 AM, Jason Keirstead <Jason.Keirstead@CA.IBM.COM>
wrote:
I could get behind that idea...
(However, "alert" just seems like sighting without an ID and count to me... that's why I am simply proposing that ID (and count) be optional.)
-
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
<graycol.gif>"Wunder, John A." ---2015/11/04 09:33:50 AM---I agree on the Slack comment, these conversations are painful over e-mail. STIX needs to get with th
From: "Wunder, John A." <jwunder@mitre.org>
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 2015/11/04 09:33 AM
Subject: Re: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs?
Sent by: <cti-stix@lists.oasis-open.org>
I agree on the Slack comment, these conversations are painful over e-mail. STIX needs to get with the program :)
Anyway how about I throw a new (probably terrible) idea. What if we have two tiers of “sightings":
- sightings (I’d maybe call them alerts, but whatever), which are emitted by end systems and work as you’re saying. They probably wouldn’t have a count though, as the firewall would not be aggregating them? An aggregation of sightings would turn into an event.
These could not have an ID (I really prefer having IDs on everything, for consistency, but I’ll let it go).
- events(?), which are aggregated sightings. They would have a count, could be updated, would have an ID, etc. They could reference any number of alert sightings if systems are storing them, but wouldn’t necessarily have to. Threat intelligence systems manage
events, firewalls emit alert sightings.
My worry is that if we design the “sightings” model only for tools emitting sightings, the tools managing sightings in the context of an investigation, analysis, or information sharing arrangement between organizations will not be able to do what they need
to.
John
On Nov 4, 2015, at 8:09 AM, Jason Keirstead <Jason.Keirstead@CA.IBM.COM>
wrote:
Couple of comments
- In general - I wish we were having this debate on Slack or somewhere it could occur in a more sane manner than email :)
- Many of the comments below are in relation to SIEM. As I mentioned previously, it is a misnomer to believe that even a SIEM could de-reference a sighting by an ID. Some may be able to do this, but many will not. If someone wants to go into the technical details
as to why - I am happy to do this off list but it would desccend into a SIEM architecture discussion that wold probably bore most participants.
In fact, I have a hard time thinking of even a single security system that would both be able to emit sightings, as well as be able to de-reference them.
-
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
<graycol.gif>"Barnum, Sean D." ---2015/11/03 06:06:16 PM---I definitely agree with all of this, especially the validity and likelihood of #4 & #5. sean
From: "Barnum, Sean D." <sbarnum@mitre.org>
To: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>
Date: 2015/11/03 06:06 PM
Subject: Re: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs?
Sent by: <cti-stix@lists.oasis-open.org>
I definitely agree with all of this, especially the validity and likelihood of #4 & #5.
sean
From: "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org>
Date: Tuesday, November 3, 2015 at 4:37 PM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs?
A few thoughts:
1. Even recent discussion about top-level relationships have included an ID, so being an edge isn’t in and of itself a reason to not have an ID.
2. Let’s broaden our discussion beyond firewalls and tools emitting events. Let’s think too about SIEMs and threat intelligence repositories that may collect, filter, and analyze sightings.
3. For those tools, do we imagine consumers wanting to update particular sightings records (changing TLP to release particular instances of sightings, appending sightings with more observable information (maybe from multiple sensors))?
4. What about query particular sightings records? Say I only share “bare” sightings by default but allow people to ask for more information about what particularly was seen? So I would just send out “I saw this indicator at this time” but people can talk to
me directly and if I trust them I send them the full sighting containing that plus the observable for what I actually saw (network traffic for an IP or domain indicator, for example, or an e-mail with attachment for a phishing indicator).
5. What about to relate other things to that sighting? Maybe I kick off an incident investigation that starts with that sighting, so I want to include it in my “tag” or “investigation” that Terry has talked about. Or I want to include it in a report. Yes, you
can do all these things by duplicating the sighting (ind-id + observer + timestamp(s)) but I feel like we should follow the pattern we use everywhere else in STIX and just define an ID so people can use that.
I realize that firewalls will probably not care about use cases #3-#5. But I’d argue that firewalls are not the only emitter/manager of sightings records and so our solution needs to encompass both their needs as well as the needs of analysis/query tools like
SIEMs and threat intel platforms.
John
On Nov 3, 2015, at 4:09 PM, Jason Keirstead <Jason.Keirstead@CA.IBM.COM>
wrote:
If we want to send more information on the producer or the indicator being sighted... then we should be sending those objects.. not using sightings... no?
A sighting shouldn't be a transit object for updating an indicator - that's not it's purpose.
-
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
<graycol.gif>Cory Casanave ---2015/11/03 05:06:49 PM---Re: Producer X is sighting Indicator Y at Time Z Mostly more Information about X and Y.
From: Cory Casanave <cory-c@modeldriven.com>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: "Jordan, Bret" <bret.jordan@bluecoat.com>, "Sean D. Barnum"
<sbarnum@mitre.org>, "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>
Date: 2015/11/03 05:06 PM
Subject: RE: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs?
Sent by: <cti-stix@lists.oasis-open.org>
Re: Producer X is sighting Indicator Y at Time Z
Mostly more Information about X and Y.
My only point was that all this concern about dereferencing to the origin of information need not be a concern if it is architected smartly. Being able to dereference to “more” about anything is a viable design pattern, even for hidden information producers.
Also, being able to does not imply rights, or that such information is open. Perhaps in some cases there is no more, which is then also fine.