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

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

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


"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.