Re: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs?

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

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.