CTI STIX Subcommittee

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.
 


From: Jason Keirstead [mailto:Jason.Keirstead@ca.ibm.com]

Sent: Tuesday, November 03, 2015 3:46 PM
To: Cory Casanave
Cc: Jordan, Bret; Sean D. Barnum; cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs?


 
> Consider that this kind of very limited device is of a special classification and it can send one of 5 special classes of notification.

That isn't true.. I can send many types of signatures to these devices... in fact some of them may (eventually) understand CybOX natively.

> The ID also does not have to dereference to the actual device, but it can still have information about it be visible to those privy to it.

You can't query an IPS or a Firewall or an Endpoint. These devices simply do not maintain historical data. Even a SIEM often can't de-refrerence an individual log via an ID.

> If not, perhaps it is not something that should be sending raw STIX data out

I think this would be a big mistake.. you'd be cutting out all of the most important sources of sighting information. Without these sources, who is going to generate sightings? Manual processes?

> .. but should be behind a smarter server that can add such context.


What is the context that needs to be added? "Producer X is sighting Indicator Y at Time Z". What else needs to be tracked...

I feel like people are conflating the idea of a sighting and an observable again.


The indicator is the object that has all of the interesting data that may be updated. The sighting record, has nothing of interest to update. A sighting is a relationship between an indicator and an observer at a point in time. There is nothing
to ever want to go back and update or de-reference... you can't swap out the indicator, you can't change the time, so what is there left to update... so what is the point of the ID?

-
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


Cory
Casanave ---2015/11/03 04:30:55 PM---Bret, Re: The way I see it, most devices that will be emitting a sighting will have no ability to:

From: Cory Casanave < cory-c@modeldriven.com >
To: "Jordan, Bret" < bret.jordan@bluecoat.com >, Jason Keirstead/CanEast/IBM@IBMCA
Cc: "Sean D. Barnum" < sbarnum@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Date: 2015/11/03 04:30 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 >






Bret,
Re: The way I see it, most devices that will be emitting a sighting will have no ability to:
1) store the data, OR
2) allow someone else to query them, OR
3) be de-referencable outside of the org they are in.

They don’t have to. Consider that this kind of very limited device is of a special classification and it can send one of 5 special classes of notification. Whoever deploys builds or deploys this
class of devise may have to post these categories, but to the devise they are fixed. You don’t query the devise, you query these category files posted by its manufacturer. The same is then true of IDs, the device must have some identifier (which is static
to it) and perhaps a clock or SOMETHING that can differentiate an event. If not, perhaps it is not something that should be sending raw STIX data out, but should be behind a smarter server that can add such context. The ID also does not have to dereference
to the actual device, but it can still have information about it be visible to those privy to it.

From:
cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Jordan, Bret
Sent: Tuesday, November 03, 2015 3:09 PM
To: Jason Keirstead
Cc: Sean D. Barnum; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs?

I completely agree with Jason. I would like to hear from other on the list that build products.


The way I see it, most devices that will be emitting a sighting will have no ability to:
1) store the data, OR
2) allow someone else to query them, OR
3) be de-referencable outside of the org they are in.


The only way I can see this working is:

Device 1 sees traffic ->
fires rule based on traffic it sees ->
generates a sighting / indicator / observable ->

sends that on a TAXII channel ->
collector / SOC tool is listening and collecting messages on the channel ->

SOC tool adds / modifies an ID based on some rule.


Then the SOC tool can either, via a rule or via human interaction push a sighting or an aggregate of the sightings to their public TAXII server's indicator channel or to a TAXII server in the cloud.



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 Nov 3, 2015, at 13:44, Jason Keirstead < Jason.Keirstead@ca.ibm.com >
wrote:

I think the main point is - if a mandatory ID is a requirement for Sightings, then we will be severely limiting the types entities that can produce sightings. You are cutting out all of those other device classes, because it is
simply not possible for them to do that and have the IDs be meaningful. If they are forced to comply with the spec, then they will be simply be random UUIDs taking up space in the message, which may break other tools expecting them to have meaning.

I would strongly advocate to not force IDs for instances of sightings. If they are going to be there, they should be optional.

" The ID stays the same over the lifetime of the object even if it is updated and the content changes. "

If a sighting is a vertex (as proposed earlier), then how does a sighting "change"? You can't have it both ways... are they point-in-time occurrences and each has their own record, or not... ? I am confused.

-
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 03:12:53 PM---The fourth sightings sub-topic I wanted to comment on is around the question of whether sightings sh

From: "Barnum, Sean D." < sbarnum@mitre.org >
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Date: 2015/11/03 03:12 PM
Subject: [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 fourth sightings sub-topic I wanted to comment on is around the question of
whether sightings should have IDs or not.
I think there have been some clear assertions (along with their rationale) from Jason and Bret that it does not make sense for sightings to have IDs but also some good clear arguments from John, Terry and others
for why unique and persistent IDs are relevant for consumers to be able to reference, correlate and analyze diverse sightings from diverse sighters.

Again, putting on my expert hat rather than my co-chair hat, I wanted to offer some thoughts on this which are primarily just stating agreement with the arguments made by John, Terry and others.








I do believe that it is important for sightings to have IDs for many of the reasons already expressed on the list.
Specifically, I would also agree with Terry’s assertion that:







·         
"We need an ID solution that:


·         
Includes the domain namespace in the ID so that recipients know where to ask for more information.

·         
The ID stays the same over the lifetime of the object even if it is updated and the content changes.

·         
Recognizes that IDs will be coming from many different companies and many different sources and that we need a way of easily understanding who produced the data."







On the sub-sub-topic ( :-) ) of Alternative_ID for Sightings,







·         
I think that Alternative_ID does make sense for Sightings. It would allow the capture and reference of things like alert IDs issued by particular detection tools. The sightings would still need a
STIX ID for effective referencing within STIX content but the external ID would help support the potential for seeking out more detailed information where appropriate.

sean

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 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. From: Jason Keirstead [ mailto:Jason.Keirstead@ca.ibm.com ] Sent: Tuesday, November 03, 2015 3:46 PM To: Cory Casanave Cc: Jordan, Bret; Sean D. Barnum; cti-stix@lists.oasis-open.org Subject: RE: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs? > Consider that this kind of very limited device is of a special classification and it can send one of 5 special classes of notification. That isn't true.. I can send many types of signatures to these devices... in fact some of them may (eventually) understand CybOX natively. > The ID also does not have to dereference to the actual device, but it can still have information about it be visible to those privy to it. You can't query an IPS or a Firewall or an Endpoint. These devices simply do not maintain historical data. Even a SIEM often can't de-refrerence an individual log via an ID. > If not, perhaps it is not something that should be sending raw STIX data out I think this would be a big mistake.. you'd be cutting out all of the most important sources of sighting information. Without these sources, who is going to generate sightings? Manual processes? > .. but should be behind a smarter server that can add such context. What is the context that needs to be added? "Producer X is sighting Indicator Y at Time Z". What else needs to be tracked... I feel like people are conflating the idea of a sighting and an observable again. The indicator is the object that has all of the interesting data that may be updated. The sighting record, has nothing of interest to update. A sighting is a relationship between an indicator and an observer at a point in time. There is nothing to ever want to go back and update or de-reference... you can't swap out the indicator, you can't change the time, so what is there left to update... so what is the point of the ID? - 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 Cory Casanave ---2015/11/03 04:30:55 PM---Bret, Re: The way I see it, most devices that will be emitting a sighting will have no ability to: From: Cory Casanave < cory-c@modeldriven.com > To: "Jordan, Bret" < bret.jordan@bluecoat.com >, Jason Keirstead/CanEast/IBM@IBMCA Cc: "Sean D. Barnum" < sbarnum@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Date: 2015/11/03 04:30 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 > Bret, Re: The way I see it, most devices that will be emitting a sighting will have no ability to: 1) store the data, OR 2) allow someone else to query them, OR 3) be de-referencable outside of the org they are in. They don’t have to. Consider that this kind of very limited device is of a special classification and it can send one of 5 special classes of notification. Whoever deploys builds or deploys this class of devise may have to post these categories, but to the devise they are fixed. You don’t query the devise, you query these category files posted by its manufacturer. The same is then true of IDs, the device must have some identifier (which is static to it) and perhaps a clock or SOMETHING that can differentiate an event. If not, perhaps it is not something that should be sending raw STIX data out, but should be behind a smarter server that can add such context. The ID also does not have to dereference to the actual device, but it can still have information about it be visible to those privy to it. From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Jordan, Bret Sent: Tuesday, November 03, 2015 3:09 PM To: Jason Keirstead Cc: Sean D. Barnum; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs? I completely agree with Jason. I would like to hear from other on the list that build products. The way I see it, most devices that will be emitting a sighting will have no ability to: 1) store the data, OR 2) allow someone else to query them, OR 3) be de-referencable outside of the org they are in. The only way I can see this working is: Device 1 sees traffic -> fires rule based on traffic it sees -> generates a sighting / indicator / observable -> sends that on a TAXII channel -> collector / SOC tool is listening and collecting messages on the channel -> SOC tool adds / modifies an ID based on some rule. Then the SOC tool can either, via a rule or via human interaction push a sighting or an aggregate of the sightings to their public TAXII server's indicator channel or to a TAXII server in the cloud. 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 Nov 3, 2015, at 13:44, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: I think the main point is - if a mandatory ID is a requirement for Sightings, then we will be severely limiting the types entities that can produce sightings. You are cutting out all of those other device classes, because it is simply not possible for them to do that and have the IDs be meaningful. If they are forced to comply with the spec, then they will be simply be random UUIDs taking up space in the message, which may break other tools expecting them to have meaning. I would strongly advocate to not force IDs for instances of sightings. If they are going to be there, they should be optional. " The ID stays the same over the lifetime of the object even if it is updated and the content changes. " If a sighting is a vertex (as proposed earlier), then how does a sighting "change"? You can't have it both ways... are they point-in-time occurrences and each has their own record, or not... ? I am confused. - 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 03:12:53 PM---The fourth sightings sub-topic I wanted to comment on is around the question of whether sightings sh From: "Barnum, Sean D." < sbarnum@mitre.org > To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Date: 2015/11/03 03:12 PM Subject: [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 fourth sightings sub-topic I wanted to comment on is around the question of whether sightings should have IDs or not. I think there have been some clear assertions (along with their rationale) from Jason and Bret that it does not make sense for sightings to have IDs but also some good clear arguments from John, Terry and others for why unique and persistent IDs are relevant for consumers to be able to reference, correlate and analyze diverse sightings from diverse sighters. Again, putting on my expert hat rather than my co-chair hat, I wanted to offer some thoughts on this which are primarily just stating agreement with the arguments made by John, Terry and others. I do believe that it is important for sightings to have IDs for many of the reasons already expressed on the list. Specifically, I would also agree with Terry’s assertion that: · "We need an ID solution that: · Includes the domain namespace in the ID so that recipients know where to ask for more information. · The ID stays the same over the lifetime of the object even if it is updated and the content changes. · Recognizes that IDs will be coming from many different companies and many different sources and that we need a way of easily understanding who produced the data."
On the sub-sub-topic ( :-) ) of Alternative_ID for Sightings, · I think that Alternative_ID does make sense for Sightings. It would allow the capture and reference of things like alert IDs issued by particular detection tools. The sightings would still need a STIX ID for effective referencing within STIX content but the external ID would help support the potential for seeking out more detailed information where appropriate. sean

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.

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.

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

Agree with Jason, in my opinion, a sighting should just say “+1 I saw this”. It may also send any other context required to say +1.


Aharon









From: < cti-stix@lists.oasis-open.org > on behalf of Jason Keirstead < Jason.Keirstead@CA.IBM.COM >
Date: Tuesday, November 3, 2015 at 4:09 PM
To: Cory Casanave < cory-c@modeldriven.com >
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 >
Subject: RE: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs?





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


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.

From: Jason Keirstead [ mailto:Jason.Keirstead@ca.ibm.com ]

Sent: Tuesday, November 03, 2015 3:46 PM
To: Cory Casanave
Cc: Jordan, Bret; Sean D. Barnum;
cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs?

> Consider that this kind of very limited device is of a special classification and it can send one of 5 special classes of notification.

That isn't true.. I can send many types of signatures to these devices... in fact some of them may (eventually) understand CybOX natively.

> The ID also does not have to dereference to the actual device, but it can still have information about it be visible to those privy to it.

You can't query an IPS or a Firewall or an Endpoint. These devices simply do not maintain historical data. Even a SIEM often can't de-refrerence an individual log via an ID.

> If not, perhaps it is not something that should be sending raw STIX data out

I think this would be a big mistake.. you'd be cutting out all of the most important sources of sighting information. Without these sources, who is going to generate sightings? Manual processes?

> .. but should be behind a smarter server that can add such context.

What is the context that needs to be added? "Producer X is sighting Indicator Y at Time Z". What else needs to be tracked...

I feel like people are conflating the idea of a sighting and an observable again.


The indicator is the object that has all of the interesting data that may be updated. The sighting record, has nothing of interest to update. A sighting
is a relationship between an indicator and an observer at a point in time. There is nothing to ever want to go back and update or de-reference... you can't swap out the indicator, you can't change the time, so what is there left to update... so what is the
point of the ID?

-
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


Cory
Casanave ---2015/11/03 04:30:55 PM---Bret, Re: The way I see it, most devices that will be emitting a sighting will have no ability to:

From: Cory Casanave < cory-c@modeldriven.com >
To: "Jordan, Bret" < bret.jordan@bluecoat.com >, Jason Keirstead/CanEast/IBM@IBMCA
Cc: "Sean D. Barnum" < sbarnum@mitre.org >, " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Date: 2015/11/03 04:30 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 >






Bret,
Re: The way I see it, most devices that will be emitting a sighting will have no ability to:
1) store the data, OR
2) allow someone else to query them, OR
3) be de-referencable outside of the org they are in.

They don’t have to. Consider that this kind of very limited device is of a special classification and it can send one of 5 special classes of notification. Whoever deploys builds or deploys this class of devise may have to post these categories, but to the
devise they are fixed. You don’t query the devise, you query these category files posted by its manufacturer. The same is then true of IDs, the device must have some identifier (which is static to it) and perhaps a clock or SOMETHING that can differentiate
an event. If not, perhaps it is not something that should be sending raw STIX data out, but should be behind a smarter server that can add such context. The ID also does not have to dereference to the actual device, but it can still have information about
it be visible to those privy to it.

From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Jordan, Bret
Sent: Tuesday, November 03, 2015 3:09 PM
To: Jason Keirstead
Cc: Sean D. Barnum; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Some thoughts on Sightings and conversations to date (Part #4): should sightings have IDs?

I completely agree with Jason. I would like to hear from other on the list that build products.


The way I see it, most devices that will be emitting a sighting will have no ability to:
1) store the data, OR
2) allow someone else to query them, OR
3) be de-referencable outside of the org they are in.


The only way I can see this working is:

Device 1 sees traffic ->
fires rule based on traffic it sees ->
generates a sighting / indicator / observable ->
sends that on a TAXII channel ->
collector / SOC tool is listening and collecting messages on the channel ->
SOC tool adds / modifies an ID based on some rule.

Then the SOC tool can either, via a rule or via human interaction push a sighting or an aggregate of the sightings to their public TAXII server's indicator channel or to a TAXII server in the cloud.



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 Nov 3, 2015, at 13:44, Jason Keirstead < Jason.Keirstead@ca.ibm.com >
wrote:

I think the main point is - if a mandatory ID is a requirement for Sightings, then we will be severely limiting the types entities that can produce sightings. You are cutting out all of those other device classes, because it is simply not possible for them
to do that and have the IDs be meaningful. If they are forced to comply with the spec, then they will be simply be random UUIDs taking up space in the message, which may break other tools expecting them to have meaning.

I would strongly advocate to not force IDs for instances of sightings. If they are going to be there, they should be optional.

" The ID stays the same over the lifetime of the object even if it is updated and the content changes. "

If a sighting is a vertex (as proposed earlier), then how does a sighting "change"? You can't have it both ways... are they point-in-time occurrences and each has their own record, or not... ? I am confused.

-
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 03:12:53 PM---The fourth sightings sub-topic I wanted to comment on is around the question of whether sightings sh

From: "Barnum, Sean D." < sbarnum@mitre.org >
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Date: 2015/11/03 03:12 PM
Subject: [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 fourth sightings sub-topic I wanted to comment on is around the question of
whether sightings should have IDs or not.
I think there have been some clear assertions (along with their rationale) from Jason and Bret that it does not make sense for sightings to have IDs but also some good clear arguments from John, Terry and others
for why unique and persistent IDs are relevant for consumers to be able to reference, correlate and analyze diverse sightings from diverse sighters.

Again, putting on my expert hat rather than my co-chair hat, I wanted to offer some thoughts on this which are primarily just stating agreement with the arguments made by John, Terry and others.









I do believe that it is important for sightings to have IDs for many of the reasons already expressed on the list. Specifically, I would also agree with Terry’s assertion that:









· "We need an ID solution that:









· Includes the domain namespace in the ID so that recipients know where to ask for more information.
· The ID stays the same over the lifetime of the object even if it is updated and the content changes.
· Recognizes that IDs will be coming from many different companies and many different sources and that we need a way of easily understanding who produced the data."















On the sub-sub-topic ( :-) ) of Alternative_ID for Sightings,









· I think that Alternative_ID does make sense for Sightings. It would allow the capture and reference of things like alert IDs issued by particular detection tools. The sightings would still need
a STIX ID for effective referencing within STIX content but the external ID would help support the potential for seeking out more detailed information where appropriate.
















sean