CTI STIX Subcommittee

In the meeting today “sighting” was discussed. Below is the sighting component of a conceptual model we are developing for threats and risks. Note that this is a level more general than STIX (the model is being mapped to STIX), but perhaps we can share some ideas. Regards, Cory Casanave  

I think a better place to start is how people or devices are going to interact with an IOC-Indicator.   1) Human: I am going to see a list of IOCs in my work bench tool and have the ability to query that list for certain things as I do stuff.  Perhaps as I start documenting an issue I am seeing in my network it could show a list of potential IOCs that match it.  I could then:  a) click a button that says share a sighting or  b) the software could be configured to emit a sighting every time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a report. 2) Device: A network device / security tool might be watching the network and either looking for IOCs based on a feed it gets from somewhere or it might find bad stuff on its own and generate an IOC then query the repo to see if the IOC is already known.  In either case, the device could emit a sighting.   While I appreciate the desire to cover every esoteric corner case that might ever come up, I think we should take a minimalistic approach to the first generation of the Sighting object..  It is always easy to add stuff, but it is really hard to take it away.   I would argue that the bare minimum we need is: 1) Reference to what it is we are sighting 2) The person / organization that is making the sighting 3) A count of the number of times it was seen. Now yes, there is a LOT more things that COULD be added, and all of them could be added over time.  For example (yes this will rub people the wrong way), data markings.  I would personally leave them out for now.  I would love if we could get to the point where we had to rev the sightings object spec to support data markings or something else because we had so many people using it and begging for the feature.   By taking the minimalistic approach we can more quicker and get people using it.   Think: { type : sighting , id : foo.com :sighting-1234-1234-1234-1234 , idref : abc.com :indicator-4321-4321-4321-4321 , count : 1222 producer : tom and jerry } 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 21, 2015, at 15:17, Cory Casanave < cory-c@modeldriven.com > wrote: In the meeting today “sighting” was discussed. Below is the sighting component of a conceptual model we are developing for threats and risks. Note that this is a level more general than STIX (the model is being mapped to STIX), but perhaps we can share some ideas. Regards, Cory Casanave   <image003.jpg> Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

I definitely like the “state the use case first” approach here.  We can’t implement a data design until we know what we plan on doing with it.
 
On the simplicity suggestion – YES!!  Simple, simple, simple.  We can always add fields later.  Let’s just get this implemented, baked into our products, and then
we can see what we are missing.
 
On the data structure – Seems to me that the big decision on this is whether or not we have a sighting object or EACH sighting (meaning, it references something
and adds context like who saw it, date, etc…) or have a combined object that carries a count.  The former will offer more flexibility, but will mean more object instances.  The later is really just a summary of the former, which will be much smaller from a
db size perspective, but we won’t be able to identify individual characteristics of each sighting instance.
 
Personally, I favor flexibility.  We can solve the size issue with technical implementation.
 


From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Jordan, Bret
Sent: Wednesday, October 21, 2015 5:42 PM
To: Cory Casanave
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Conceptul model for sighting


 
I think a better place to start is how people or devices are going to interact with an IOC-Indicator.  

 


1) Human: I am going to see a list of IOCs in my work bench tool and have the ability to query that list for certain things as I do stuff.  Perhaps as I start documenting an issue I am seeing in my network it could show a
list of potential IOCs that match it.  I could then: 


            a) click a button that says "share a sighting" or 


            b) the software could be configured to emit a sighting every time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a report.


 


2) Device: A network device / security tool might be watching the network and either looking for IOCs based on a feed it gets from somewhere or it might find bad stuff on its own and generate an IOC then query the repo to
see if the IOC is already known.  In either case, the device could emit a sighting.  


 


While I appreciate the desire to cover every esoteric corner case that might ever come up, I think we should take a minimalistic approach to the first generation of the Sighting object..  It is always easy to add stuff, but it is really
hard to take it away.  


 


I would argue that the bare minimum we need is:


 


1) Reference to what it is we are sighting


2) The person / organization that is making the sighting


3) A count of the number of times it was seen.


 


Now yes, there is a LOT more things that COULD be added, and all of them could be added over time.  For example (yes this will rub people the wrong way), data markings.  I would personally leave them out for now.  I would love if we could
get to the point where we had to rev the sightings object spec to support data markings or something else because we had so many people using it and begging for the feature.  


 


By taking the minimalistic approach we can more quicker and get people using it.  


 


Think:


 


{


            "type": "sighting",


            "id": " foo.com :sighting-1234-1234-1234-1234",


            "idref": " abc.com :indicator-4321-4321-4321-4321",


            "count": "1222"


            "producer": "tom and jerry"


}


 


 







 


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 21, 2015, at 15:17, Cory Casanave < cory-c@modeldriven.com > wrote:

 


In the meeting today “sighting” was discussed. Below is the sighting component of a conceptual model we are developing for threats and risks. Note that this is a level more
general than STIX (the model is being mapped to STIX), but perhaps we can share some ideas.


Regards,
Cory Casanave


 


<image003.jpg>




 


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.

Bret & Jonathan,
In my experience combining a bottom-up and top-down approach yields the best result. Particularly in a system as complex as STIX which must satisfy multiple
use cases and implementation style, “simple” is not always the same from one stakeholder to the next. What is important from both perspectives is clarity on meaning and a consistent and logical representation. Having a map of the concepts helps with clarity,
consistency and solving multiple use cases. Bottom up analysis makes sure critical needs are met in as simple a way as possible. Top-down alone can get overly general where as bottom-up alone can get fragmented and limiting. So both is best. The conceptual
model I showed is not intended as the CTI schema model, but such a map of the concepts.
 
With respect to “sighting”, I found the 1.x STIX representation confusing and lacking some of the links I would expect. The proposition represented in the conceptual
model is that a sighting is a specific observation corresponding to an indicator that provides evidence for some situation of interest. Such a sighting would take place at a specific time and be reported by identified parties. The expectation is of a single
event, if “multiple sightings” are within one sighting report then this changes the meaning as well as the data structure somewhat – for example we would need to allow for a timespan, not just a point in time.
 
-Cory Casanave
 


From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Bush, Jonathan
Sent: Thursday, October 22, 2015 8:48 AM
To: 'Jordan, Bret'; Cory Casanave
Cc: cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Conceptul model for sighting


 
I definitely like the “state the use case first” approach here.  We can’t implement a data design until we know what we plan on doing with it.
 
On the simplicity suggestion – YES!!  Simple, simple, simple.  We can always add fields later.  Let’s just get this implemented, baked into our products, and then
we can see what we are missing.
 
On the data structure – Seems to me that the big decision on this is whether or not we have a sighting object or EACH sighting (meaning, it references something
and adds context like who saw it, date, etc…) or have a combined object that carries a count.  The former will offer more flexibility, but will mean more object instances.  The later is really just a summary of the former, which will be much smaller from a
db size perspective, but we won’t be able to identify individual characteristics of each sighting instance.
 
Personally, I favor flexibility.  We can solve the size issue with technical implementation.
 


From:
cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Jordan, Bret
Sent: Wednesday, October 21, 2015 5:42 PM
To: Cory Casanave
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Conceptul model for sighting


 
I think a better place to start is how people or devices are going to interact with an IOC-Indicator.  

 


1) Human: I am going to see a list of IOCs in my work bench tool and have the ability to query that list for certain things as I do stuff.  Perhaps as I start documenting an issue I am seeing in my network it could show a
list of potential IOCs that match it.  I could then: 


            a) click a button that says "share a sighting" or 


            b) the software could be configured to emit a sighting every time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a report.


 


2) Device: A network device / security tool might be watching the network and either looking for IOCs based on a feed it gets from somewhere or it might find bad stuff on its own and generate an IOC then query the repo to
see if the IOC is already known.  In either case, the device could emit a sighting.  


 


While I appreciate the desire to cover every esoteric corner case that might ever come up, I think we should take a minimalistic approach to the first generation of the Sighting object..  It is always easy to add stuff, but it is really
hard to take it away.  


 


I would argue that the bare minimum we need is:


 


1) Reference to what it is we are sighting


2) The person / organization that is making the sighting


3) A count of the number of times it was seen.


 


Now yes, there is a LOT more things that COULD be added, and all of them could be added over time.  For example (yes this will rub people the wrong way), data markings.  I would personally leave them out for now.  I would love if we could
get to the point where we had to rev the sightings object spec to support data markings or something else because we had so many people using it and begging for the feature.  


 


By taking the minimalistic approach we can more quicker and get people using it.  


 


Think:


 


{


            "type": "sighting",


            "id": " foo.com :sighting-1234-1234-1234-1234",


            "idref": " abc.com :indicator-4321-4321-4321-4321",


            "count": "1222"


            "producer": "tom and jerry"


}


 


 







 


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 21, 2015, at 15:17, Cory Casanave < cory-c@modeldriven.com > wrote:

 


In the meeting today “sighting” was discussed. Below is the sighting component of a conceptual model we are developing for threats and risks. Note that this is a level more
general than STIX (the model is being mapped to STIX), but perhaps we can share some ideas.


Regards,
Cory Casanave


 


<image003.jpg>




 


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email
and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.

Agreed on all of this Cory.  I especially like your thoughts on “simple means something different to everyone”.  We need to keep everyone’s base case in mind… so
people need to make sure they are speaking up.  What is absolutely critical, what is everyone’s minimum viable product (MVP) here?
 
Also, on data structure, I think that trying to accommodate things like timespan could get very complicated very quickly, and it changes the problem domain significantly.
 


From: Cory Casanave [mailto:cory-c@modeldriven.com]

Sent: Thursday, October 22, 2015 10:06 AM
To: Bush, Jonathan; 'Jordan, Bret'
Cc: cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Conceptul model for sighting


 
Bret & Jonathan,
In my experience combining a bottom-up and top-down approach yields the best result. Particularly in a system as complex as STIX which must satisfy multiple
use cases and implementation style, “simple” is not always the same from one stakeholder to the next. What is important from both perspectives is clarity on meaning and a consistent and logical representation. Having a map of the concepts helps with clarity,
consistency and solving multiple use cases. Bottom up analysis makes sure critical needs are met in as simple a way as possible. Top-down alone can get overly general where as bottom-up alone can get fragmented and limiting. So both is best. The conceptual
model I showed is not intended as the CTI schema model, but such a map of the concepts.
 
With respect to “sighting”, I found the 1.x STIX representation confusing and lacking some of the links I would expect. The proposition represented in the conceptual
model is that a sighting is a specific observation corresponding to an indicator that provides evidence for some situation of interest. Such a sighting would take place at a specific time and be reported by identified parties. The expectation is of a single
event, if “multiple sightings” are within one sighting report then this changes the meaning as well as the data structure somewhat – for example we would need to allow for a timespan, not just a point in time.
 
-Cory Casanave
 


From:
cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Bush, Jonathan
Sent: Thursday, October 22, 2015 8:48 AM
To: 'Jordan, Bret'; Cory Casanave
Cc: cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Conceptul model for sighting


 
I definitely like the “state the use case first” approach here.  We can’t implement a data design until we know what we plan on doing with it.
 
On the simplicity suggestion – YES!!  Simple, simple, simple.  We can always add fields later.  Let’s just get this implemented, baked into our products, and then
we can see what we are missing.
 
On the data structure – Seems to me that the big decision on this is whether or not we have a sighting object or EACH sighting (meaning, it references something
and adds context like who saw it, date, etc…) or have a combined object that carries a count.  The former will offer more flexibility, but will mean more object instances.  The later is really just a summary of the former, which will be much smaller from a
db size perspective, but we won’t be able to identify individual characteristics of each sighting instance.
 
Personally, I favor flexibility.  We can solve the size issue with technical implementation.
 


From:
cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Jordan, Bret
Sent: Wednesday, October 21, 2015 5:42 PM
To: Cory Casanave
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Conceptul model for sighting


 
I think a better place to start is how people or devices are going to interact with an IOC-Indicator.  

 


1) Human: I am going to see a list of IOCs in my work bench tool and have the ability to query that list for certain things as I do stuff.  Perhaps as I start documenting an issue I am seeing in my network it could show a
list of potential IOCs that match it.  I could then: 


            a) click a button that says "share a sighting" or 


            b) the software could be configured to emit a sighting every time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a report.


 


2) Device: A network device / security tool might be watching the network and either looking for IOCs based on a feed it gets from somewhere or it might find bad stuff on its own and generate an IOC then query the repo to
see if the IOC is already known.  In either case, the device could emit a sighting.  


 


While I appreciate the desire to cover every esoteric corner case that might ever come up, I think we should take a minimalistic approach to the first generation of the Sighting object..  It is always easy to add stuff, but it is really
hard to take it away.  


 


I would argue that the bare minimum we need is:


 


1) Reference to what it is we are sighting


2) The person / organization that is making the sighting


3) A count of the number of times it was seen.


 


Now yes, there is a LOT more things that COULD be added, and all of them could be added over time.  For example (yes this will rub people the wrong way), data markings.  I would personally leave them out for now.  I would love if we could
get to the point where we had to rev the sightings object spec to support data markings or something else because we had so many people using it and begging for the feature.  


 


By taking the minimalistic approach we can more quicker and get people using it.  


 


Think:


 


{


            "type": "sighting",


            "id": " foo.com :sighting-1234-1234-1234-1234",


            "idref": " abc.com :indicator-4321-4321-4321-4321",


            "count": "1222"


            "producer": "tom and jerry"


}


 


 







 


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 21, 2015, at 15:17, Cory Casanave < cory-c@modeldriven.com > wrote:

 


In the meeting today “sighting” was discussed. Below is the sighting component of a conceptual model we are developing for threats and risks. Note that this is a level more
general than STIX (the model is being mapped to STIX), but perhaps we can share some ideas.


Regards,
Cory Casanave


 


<image003.jpg>




 


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email
and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.

DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.

I agree, but I also caution about scope creep.  It is really easy to start adding this and that to the soup, without realizing that it has turned to salt.  I fully understand that some features are very valuable to certain groups, but in the initial release need to focus on the 80-20 rule. I would like us to constantly ask our selves, what is the value of this feature versus what is the cost to implement that feature .  Cost can come in the forms of code, complexity, understanding, day-to-day use, interoperability, etc.    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 22, 2015, at 08:27, Bush, Jonathan < jbush@dtcc.com > wrote: Agreed on all of this Cory.  I especially like your thoughts on “simple means something different to everyone”.  We need to keep everyone’s base case in mind… so people need to make sure they are speaking up.  What is absolutely critical, what is everyone’s minimum viable product (MVP) here?   Also, on data structure, I think that trying to accommodate things like timespan could get very complicated very quickly, and it changes the problem domain significantly.   From:   Cory Casanave [ mailto:cory-c@modeldriven.com ]   Sent:   Thursday, October 22, 2015 10:06 AM To:   Bush, Jonathan; 'Jordan, Bret' Cc:   cti-stix@lists.oasis-open.org Subject:   RE: [cti-stix] Conceptul model for sighting   Bret & Jonathan, In my experience combining a bottom-up and top-down approach yields the best result. Particularly in a system as complex as STIX which must satisfy multiple use cases and implementation style, “simple” is not always the same from one stakeholder to the next. What is important from both perspectives is clarity on meaning and a consistent and logical representation. Having a map of the concepts helps with clarity, consistency and solving multiple use cases. Bottom up analysis makes sure critical needs are met in as simple a way as possible. Top-down alone can get overly general where as bottom-up alone can get fragmented and limiting. So both is best. The conceptual model I showed is not intended as the CTI schema model, but such a map of the concepts.   With respect to “sighting”, I found the 1.x STIX representation confusing and lacking some of the links I would expect. The proposition represented in the conceptual model is that a sighting is a specific observation corresponding to an indicator that provides evidence for some situation of interest. Such a sighting would take place at a specific time and be reported by identified parties. The expectation is of a single event, if “multiple sightings” are within one sighting report then this changes the meaning as well as the data structure somewhat – for example we would need to allow for a timespan, not just a point in time.   -Cory Casanave   From:   cti-stix@lists.oasis-open.org   [ mailto:cti-stix@lists.oasis-open.org ]   On Behalf Of   Bush, Jonathan Sent:   Thursday, October 22, 2015 8:48 AM To:   'Jordan, Bret'; Cory Casanave Cc:   cti-stix@lists.oasis-open.org Subject:   RE: [cti-stix] Conceptul model for sighting   I definitely like the “state the use case first” approach here.  We can’t implement a data design until we know what we plan on doing with it.   On the simplicity suggestion – YES!!  Simple, simple, simple.  We can always add fields later.  Let’s just get this implemented, baked into our products, and then we can see what we are missing.   On the data structure – Seems to me that the big decision on this is whether or not we have a sighting object or EACH sighting (meaning, it references something and adds context like who saw it, date, etc…) or have a combined object that carries a count.  The former will offer more flexibility, but will mean more object instances.  The later is really just a summary of the former, which will be much smaller from a db size perspective, but we won’t be able to identify individual characteristics of each sighting instance.   Personally, I favor flexibility.  We can solve the size issue with technical implementation.   From:   cti-stix@lists.oasis-open.org   [ mailto:cti-stix@lists.oasis-open.org ]   On Behalf Of   Jordan, Bret Sent:   Wednesday, October 21, 2015 5:42 PM To:   Cory Casanave Cc:   cti-stix@lists.oasis-open.org Subject:   Re: [cti-stix] Conceptul model for sighting   I think a better place to start is how people or devices are going to interact with an IOC-Indicator.     1)   Human:   I am going to see a list of IOCs in my work bench tool and have the ability to query that list for certain things as I do stuff.  Perhaps as I start documenting an issue I am seeing in my network it could show a list of potential IOCs that match it.  I could then:                a) click a button that says share a sighting or                b) the software could be configured to emit a sighting every time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a report.   2)   Device:   A network device / security tool might be watching the network and either looking for IOCs based on a feed it gets from somewhere or it might find bad stuff on its own and generate an IOC then query the repo to see if the IOC is already known.  In either case, the device could emit a sighting.     While I appreciate the desire to cover every esoteric corner case that might ever come up, I think we should take a minimalistic approach to the first generation of the Sighting object..  It is always easy to add stuff, but it is really hard to take it away.     I would argue that the bare minimum we need is:   1) Reference to what it is we are sighting 2) The person / organization that is making the sighting 3) A count of the number of times it was seen.   Now yes, there is a LOT more things that COULD be added, and all of them could be added over time.  For example (yes this will rub people the wrong way), data markings.  I would personally leave them out for now.  I would love if we could get to the point where we had to rev the sightings object spec to support data markings or something else because we had so many people using it and begging for the feature.     By taking the minimalistic approach we can more quicker and get people using it.     Think:   {               type : sighting ,               id : foo.com :sighting-1234-1234-1234-1234 ,               idref : abc.com :indicator-4321-4321-4321-4321 ,               count : 1222               producer : tom and jerry }       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 21, 2015, at 15:17, Cory Casanave < cory-c@modeldriven.com > wrote:   In the meeting today “sighting” was discussed. Below is the sighting component of a conceptual model we are developing for threats and risks. Note that this is a level more general than STIX (the model is being mapped to STIX), but perhaps we can share some ideas. Regards, Cory Casanave   <image003.jpg>   DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email. DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email. Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

So for the reflection on where to put/attached the sighting (one top level 'object' or each objects), I think this should be linked to the CybOX discussion regarding Observables instances vs patterns and the clarification of the Observation concept (thanks Cory ;-)) would make it easier. To Bret's approach, I would like to add the time* 1) What: Reference to what it is we are sighting 2) Who: The person / organization that is making the sighting 3) A count of the number of times it was seen. 4) When* KISS: { "type": "sighting", "id": "foo.com:sighting-1234-1234-1234-1234", "idref": "abc.com:indicator-4321-4321-4321-4321", "count": "1222" "producer": "tom and jerry" "timeframe": between monday and tuesday } 2015-10-22 17:27 GMT+03:00 Bush, Jonathan <jbush@dtcc.com>: > Agreed on all of this Cory. I especially like your thoughts on “simple > means something different to everyone”. We need to keep everyone’s base > case in mind… so people need to make sure they are speaking up. What is > absolutely critical, what is everyone’s minimum viable product (MVP) here? > > > > Also, on data structure, I think that trying to accommodate things like > timespan could get very complicated very quickly, and it changes the problem > domain significantly. > > > > From: Cory Casanave [ mailto:cory-c@modeldriven.com ] > Sent: Thursday, October 22, 2015 10:06 AM > To: Bush, Jonathan; 'Jordan, Bret' > > > Cc: cti-stix@lists.oasis-open.org > Subject: RE: [cti-stix] Conceptul model for sighting > > > > Bret & Jonathan, > > In my experience combining a bottom-up and top-down approach yields the best > result. Particularly in a system as complex as STIX which must satisfy > multiple use cases and implementation style, “simple” is not always the same > from one stakeholder to the next. What is important from both perspectives > is clarity on meaning and a consistent and logical representation. Having a > map of the concepts helps with clarity, consistency and solving multiple use > cases. Bottom up analysis makes sure critical needs are met in as simple a > way as possible. Top-down alone can get overly general where as bottom-up > alone can get fragmented and limiting. So both is best. The conceptual model > I showed is not intended as the CTI schema model, but such a map of the > concepts. > > > > With respect to “sighting”, I found the 1.x STIX representation confusing > and lacking some of the links I would expect. The proposition represented in > the conceptual model is that a sighting is a specific observation > corresponding to an indicator that provides evidence for some situation of > interest. Such a sighting would take place at a specific time and be > reported by identified parties. The expectation is of a single event, if > “multiple sightings” are within one sighting report then this changes the > meaning as well as the data structure somewhat – for example we would need > to allow for a timespan, not just a point in time. > > > > -Cory Casanave > > > > From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] > On Behalf Of Bush, Jonathan > Sent: Thursday, October 22, 2015 8:48 AM > To: 'Jordan, Bret'; Cory Casanave > Cc: cti-stix@lists.oasis-open.org > Subject: RE: [cti-stix] Conceptul model for sighting > > > > I definitely like the “state the use case first” approach here. We can’t > implement a data design until we know what we plan on doing with it. > > > > On the simplicity suggestion – YES!! Simple, simple, simple. We can always > add fields later. Let’s just get this implemented, baked into our products, > and then we can see what we are missing. > > > > On the data structure – Seems to me that the big decision on this is whether > or not we have a sighting object or EACH sighting (meaning, it references > something and adds context like who saw it, date, etc…) or have a combined > object that carries a count. The former will offer more flexibility, but > will mean more object instances. The later is really just a summary of the > former, which will be much smaller from a db size perspective, but we won’t > be able to identify individual characteristics of each sighting instance. > > > > Personally, I favor flexibility. We can solve the size issue with technical > implementation. > > > > From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] > On Behalf Of Jordan, Bret > Sent: Wednesday, October 21, 2015 5:42 PM > To: Cory Casanave > Cc: cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Conceptul model for sighting > > > > I think a better place to start is how people or devices are going to > interact with an IOC-Indicator. > > > > 1) Human: I am going to see a list of IOCs in my work bench tool and have > the ability to query that list for certain things as I do stuff. Perhaps as > I start documenting an issue I am seeing in my network it could show a list > of potential IOCs that match it. I could then: > > a) click a button that says "share a sighting" or > > b) the software could be configured to emit a sighting every > time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a > report. > > > > 2) Device: A network device / security tool might be watching the network > and either looking for IOCs based on a feed it gets from somewhere or it > might find bad stuff on its own and generate an IOC then query the repo to > see if the IOC is already known. In either case, the device could emit a > sighting. > > > > While I appreciate the desire to cover every esoteric corner case that might > ever come up, I think we should take a minimalistic approach to the first > generation of the Sighting object.. It is always easy to add stuff, but it > is really hard to take it away. > > > > I would argue that the bare minimum we need is: > > > > 1) Reference to what it is we are sighting > > 2) The person / organization that is making the sighting > > 3) A count of the number of times it was seen. > > > > Now yes, there is a LOT more things that COULD be added, and all of them > could be added over time. For example (yes this will rub people the wrong > way), data markings. I would personally leave them out for now. I would > love if we could get to the point where we had to rev the sightings object > spec to support data markings or something else because we had so many > people using it and begging for the feature. > > > > By taking the minimalistic approach we can more quicker and get people using > it. > > > > Think: > > > > { > > "type": "sighting", > > "id": "foo.com:sighting-1234-1234-1234-1234", > > "idref": "abc.com:indicator-4321-4321-4321-4321", > > "count": "1222" > > "producer": "tom and jerry" > > } > > > > > > > > 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 21, 2015, at 15:17, Cory Casanave <cory-c@modeldriven.com> wrote: > > > > In the meeting today “sighting” was discussed. Below is the sighting > component of a conceptual model we are developing for threats and risks. > Note that this is a level more general than STIX (the model is being mapped > to STIX), but perhaps we can share some ideas. > > Regards, > Cory Casanave > > > > <image003.jpg> > > > > > DTCC DISCLAIMER: This email and any files transmitted with it are > confidential and intended solely for the use of the individual or entity to > whom they are addressed. If you have received this email in error, please > notify us immediately and delete the email and any attachments from your > system. The recipient should check this email and any attachments for the > presence of viruses. The company accepts no liability for any damage caused > by any virus transmitted by this email. > > > DTCC DISCLAIMER: This email and any files transmitted with it are > confidential and intended solely for the use of the individual or entity to > whom they are addressed. If you have received this email in error, please > notify us immediately and delete the email and any attachments from your > system. The recipient should check this email and any attachments for the > presence of viruses. The company accepts no liability for any damage caused > by any virus transmitted by this email.

I can go with that... 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 22, 2015, at 09:10, Jerome Athias < athiasjerome@GMAIL.COM > wrote: So for the reflection on where to put/attached the sighting (one top level 'object' or each objects), I think this should be linked to the CybOX discussion regarding Observables instances vs patterns and the clarification of the Observation concept (thanks Cory ;-)) would make it easier. To Bret's approach, I would like to add the time* 1) What: Reference to what it is we are sighting 2) Who: The person / organization that is making the sighting 3) A count of the number of times it was seen. 4) When* KISS: { type : sighting , id : foo.com:sighting-1234-1234-1234-1234 , idref : abc.com:indicator-4321-4321-4321-4321 , count : 1222 producer : tom and jerry timeframe : between monday and tuesday } 2015-10-22 17:27 GMT+03:00 Bush, Jonathan < jbush@dtcc.com >: Agreed on all of this Cory.  I especially like your thoughts on “simple means something different to everyone”.  We need to keep everyone’s base case in mind… so people need to make sure they are speaking up.  What is absolutely critical, what is everyone’s minimum viable product (MVP) here? Also, on data structure, I think that trying to accommodate things like timespan could get very complicated very quickly, and it changes the problem domain significantly. From: Cory Casanave [ mailto:cory-c@modeldriven.com ] Sent: Thursday, October 22, 2015 10:06 AM To: Bush, Jonathan; 'Jordan, Bret' Cc: cti-stix@lists.oasis-open.org Subject: RE: [cti-stix] Conceptul model for sighting Bret & Jonathan, In my experience combining a bottom-up and top-down approach yields the best result. Particularly in a system as complex as STIX which must satisfy multiple use cases and implementation style, “simple” is not always the same from one stakeholder to the next. What is important from both perspectives is clarity on meaning and a consistent and logical representation. Having a map of the concepts helps with clarity, consistency and solving multiple use cases. Bottom up analysis makes sure critical needs are met in as simple a way as possible. Top-down alone can get overly general where as bottom-up alone can get fragmented and limiting. So both is best. The conceptual model I showed is not intended as the CTI schema model, but such a map of the concepts. With respect to “sighting”, I found the 1.x STIX representation confusing and lacking some of the links I would expect. The proposition represented in the conceptual model is that a sighting is a specific observation corresponding to an indicator that provides evidence for some situation of interest. Such a sighting would take place at a specific time and be reported by identified parties. The expectation is of a single event, if “multiple sightings” are within one sighting report then this changes the meaning as well as the data structure somewhat – for example we would need to allow for a timespan, not just a point in time. -Cory Casanave From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Bush, Jonathan Sent: Thursday, October 22, 2015 8:48 AM To: 'Jordan, Bret'; Cory Casanave Cc: cti-stix@lists.oasis-open.org Subject: RE: [cti-stix] Conceptul model for sighting I definitely like the “state the use case first” approach here.  We can’t implement a data design until we know what we plan on doing with it. On the simplicity suggestion – YES!!  Simple, simple, simple.  We can always add fields later.  Let’s just get this implemented, baked into our products, and then we can see what we are missing. On the data structure – Seems to me that the big decision on this is whether or not we have a sighting object or EACH sighting (meaning, it references something and adds context like who saw it, date, etc…) or have a combined object that carries a count.  The former will offer more flexibility, but will mean more object instances.  The later is really just a summary of the former, which will be much smaller from a db size perspective, but we won’t be able to identify individual characteristics of each sighting instance. Personally, I favor flexibility.  We can solve the size issue with technical implementation. From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Jordan, Bret Sent: Wednesday, October 21, 2015 5:42 PM To: Cory Casanave Cc: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Conceptul model for sighting I think a better place to start is how people or devices are going to interact with an IOC-Indicator. 1) Human: I am going to see a list of IOCs in my work bench tool and have the ability to query that list for certain things as I do stuff.  Perhaps as I start documenting an issue I am seeing in my network it could show a list of potential IOCs that match it.  I could then:            a) click a button that says share a sighting or            b) the software could be configured to emit a sighting every time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a report. 2) Device: A network device / security tool might be watching the network and either looking for IOCs based on a feed it gets from somewhere or it might find bad stuff on its own and generate an IOC then query the repo to see if the IOC is already known.  In either case, the device could emit a sighting. While I appreciate the desire to cover every esoteric corner case that might ever come up, I think we should take a minimalistic approach to the first generation of the Sighting object..  It is always easy to add stuff, but it is really hard to take it away. I would argue that the bare minimum we need is: 1) Reference to what it is we are sighting 2) The person / organization that is making the sighting 3) A count of the number of times it was seen. Now yes, there is a LOT more things that COULD be added, and all of them could be added over time.  For example (yes this will rub people the wrong way), data markings.  I would personally leave them out for now.  I would love if we could get to the point where we had to rev the sightings object spec to support data markings or something else because we had so many people using it and begging for the feature. By taking the minimalistic approach we can more quicker and get people using it. Think: {             type : sighting ,             id : foo.com:sighting-1234-1234-1234-1234 ,             idref : abc.com:indicator-4321-4321-4321-4321 ,             count : 1222             producer : tom and jerry } 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 21, 2015, at 15:17, Cory Casanave < cory-c@modeldriven.com > wrote: In the meeting today “sighting” was discussed. Below is the sighting component of a conceptual model we are developing for threats and risks. Note that this is a level more general than STIX (the model is being mapped to STIX), but perhaps we can share some ideas. Regards, Cory Casanave <image003.jpg> DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email. DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email. Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

The sightings conversation has historically suffered from a lack of shared understand of the sightings use cases and an attempt to address all the related sightings
use cases with one complex model that does not really satisfy any single use case very well. I guess I am a fan of a bottom up approach focused on the use cases that are seen in the wild today.

 
At a high-level I think that we can talk about sightings in several ways:

-          
Sensor Alerts – As an example, an IDS or other sensor reports a match on some indicator. You will likely have some contextual information like times,
ip addresses, host names, what indictor was matched, what was really seen, which IDS or sensor reported the alert, etc..  You probably don’t care about data markings, aggregate sighting information, and other fields. You probably do care about having compact
efficient messages due to high volume.

-          
Organizational Sighting Reports – As an example, consider what is needed when an organization reports back to an ISAC/ISAO that an indicator has been
matched (or sighted).

-          
Aggregate Sightings Analysis – Consider the information structure that is needed to enable effective analysis of aggregate data from both of the above
examples.
 
There are probably others perspectives on sightings to consider as well. My recommendation is that we clearly state (use case)  each of the different kinds of
sightings and that we independently flesh out the information requirements.

 
At the same time we need to consider what is done today in each of these cases and what we think needs to be done in the future. I would like us to focus on developing
a model for sightings that satisfies today’s needs and allows for expansion to what we think the future state should be. When it comes to sightings we simply don’t have enough experience to know what is really needed beyond supporting what people already do
today.
 
Thanks,
 

Jon
 
============================================
Jonathan O. Baker
J83D - Cyber Security Partnerships, Sharing, and Automation
The MITRE Corporation
Email:
bakerj@mitre.org

 



From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Bush, Jonathan
Sent: Thursday, October 22, 2015 8:48 AM
To: 'Jordan, Bret' <bret.jordan@bluecoat.com>; Cory Casanave <cory-c@modeldriven.com>
Cc: cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Conceptul model for sighting


 
I definitely like the “state the use case first” approach here.  We can’t implement a data design until we know what we plan on doing with it.
 
On the simplicity suggestion – YES!!  Simple, simple, simple.  We can always add fields later.  Let’s just get this implemented, baked into our products, and then
we can see what we are missing.
 
On the data structure – Seems to me that the big decision on this is whether or not we have a sighting object or EACH sighting (meaning, it references something and
adds context like who saw it, date, etc…) or have a combined object that carries a count.  The former will offer more flexibility, but will mean more object instances.  The later is really just a summary of the former, which will be much smaller from a db
size perspective, but we won’t be able to identify individual characteristics of each sighting instance.
 
Personally, I favor flexibility.  We can solve the size issue with technical implementation.
 


From:
cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Jordan, Bret
Sent: Wednesday, October 21, 2015 5:42 PM
To: Cory Casanave
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Conceptul model for sighting


 
I think a better place to start is how people or devices are going to interact with an IOC-Indicator.  

 


1) Human: I am going to see a list of IOCs in my work bench tool and have the ability to query that list for certain things as I do stuff.  Perhaps as I start documenting an issue I am seeing in my network it could show a
list of potential IOCs that match it.  I could then: 


            a) click a button that says "share a sighting" or 


            b) the software could be configured to emit a sighting every time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a report.


 


2) Device: A network device / security tool might be watching the network and either looking for IOCs based on a feed it gets from somewhere or it might find bad stuff on its own and generate an IOC then query the repo to
see if the IOC is already known.  In either case, the device could emit a sighting.  


 


While I appreciate the desire to cover every esoteric corner case that might ever come up, I think we should take a minimalistic approach to the first generation of the Sighting object..  It is always easy to add stuff, but it is really
hard to take it away.  


 


I would argue that the bare minimum we need is:


 


1) Reference to what it is we are sighting


2) The person / organization that is making the sighting


3) A count of the number of times it was seen.


 


Now yes, there is a LOT more things that COULD be added, and all of them could be added over time.  For example (yes this will rub people the wrong way), data markings.  I would personally leave them out for now.  I would love if we could
get to the point where we had to rev the sightings object spec to support data markings or something else because we had so many people using it and begging for the feature.  


 


By taking the minimalistic approach we can more quicker and get people using it.  


 


Think:


 


{


            "type": "sighting",


            "id": " foo.com :sighting-1234-1234-1234-1234",


            "idref": " abc.com :indicator-4321-4321-4321-4321",


            "count": "1222"


            "producer": "tom and jerry"


}


 


 







 


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 21, 2015, at 15:17, Cory Casanave < cory-c@modeldriven.com > wrote:

 


In the meeting today “sighting” was discussed. Below is the sighting component of a conceptual model we are developing for threats and risks. Note that this is a level more
general than STIX (the model is being mapped to STIX), but perhaps we can share some ideas.


Regards,
Cory Casanave


 


<image003.jpg>




 


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email
and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.

Hi Jon
 
 
 

-          
Sensor Alerts – As an example, an IDS or other sensor reports a match on some indicator. You will likely have some contextual information like times,
ip addresses, host names, what indictor was matched, what was really seen, which IDS or sensor reported the alert, etc..  You probably don’t care about data markings, aggregate sighting information, and other fields. You probably do care about having compact
efficient messages due to high volume.
 
This is what I personally (speaking as myself) think of when I think of a Sighting. A description of an Observable Instance with some
basic extra context.
 

-          
Organizational Sighting Reports – As an example, consider what is needed when an organization reports back to an ISAC/ISAO that an indicator has been
matched (or sighted).
 
To me this is no different to the first case. If an Indicator has been matched then a new Sighting object will be created under the
namespace of the Organization. The Organization will then share that Sighting object back to the ISAC/ISAO (if the Org wants to) along with a Relationship object (also under the  namespace of the Org) that maps the ISAC Indicator to the Org’s Sighting Object.
This can potentially be accompanied with an Incident object or Report object to give extra context if required.
 

-          
Aggregate Sightings Analysis – Consider the information structure that is needed to enable effective analysis of aggregate data from both of the above
examples.
 
In my personal opinion it is up to consumers to use the collected data to make their own decisions. Every Organization has their own
institutional idea of trust. They alone know which sources of information make sense for them, their management’s risk appetite, the verticals they operate in and so forth. The analysis that one Organization performs to come to the conclusion of ‘High’ risk
may actually be a ‘Low’ risk in another organization. Each Org must be ultimately responsible for its own analysis.
 
But, that’s not to say that they can’t outsource that function to other organizations. Dedicated third-parties specializing in analyzing
Sightings to extract TTPs and match those to Campaigns and Actors will become more prevalent. These third-party analysis services will provide analysis customized to the Organization’s structure/vertical/risk appetite which will help them extract the ‘why
and ‘how’ from the ‘what’.
 
I believe that the separate top-level Sighting object will provide us with the basic structure to begin the higher level analysis.
I believe that this will then help third-parties to generate more ‘upper-level’ STIX data – Threat Actors, Campaigns and higher-order TTP in particular.
 
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 Baker, Jon
Sent: Saturday, 24 October 2015 2:10 AM
To: Jonathan Bush (DTCC) <jbush@dtcc.com>; 'Jordan, Bret' <bret.jordan@bluecoat.com>; Cory Casanave <cory-c@modeldriven.com>
Cc: cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Conceptul model for sighting


 
The sightings conversation has historically suffered from a lack of shared understand of the sightings use cases and an attempt to address all the
related sightings use cases with one complex model that does not really satisfy any single use case very well. I guess I am a fan of a bottom up approach focused on the use cases that are seen in the wild today.

 
At a high-level I think that we can talk about sightings in several ways:
There are probably others perspectives on sightings to consider as well. My recommendation is that we clearly state (use case)  each of the different
kinds of sightings and that we independently flesh out the information requirements.

 
At the same time we need to consider what is done today in each of these cases and what we think needs to be done in the future. I would like us
to focus on developing a model for sightings that satisfies today’s needs and allows for expansion to what we think the future state should be. When it comes to sightings we simply don’t have enough experience to know what is really needed beyond supporting
what people already do today.
 
Thanks,
 

Jon
 
============================================
Jonathan O. Baker
J83D - Cyber Security Partnerships, Sharing, and Automation
The MITRE Corporation
Email:
bakerj@mitre.org

 



From:
cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Bush, Jonathan
Sent: Thursday, October 22, 2015 8:48 AM
To: 'Jordan, Bret' < bret.jordan@bluecoat.com >;
Cory Casanave < cory-c@modeldriven.com >
Cc: cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Conceptul model for sighting


 
I definitely like the “state the use case first” approach here.  We can’t implement a data design until we know what we plan on doing with it.
 
On the simplicity suggestion – YES!!  Simple, simple, simple.  We can always add fields later.  Let’s just get this implemented, baked into our products,
and then we can see what we are missing.
 
On the data structure – Seems to me that the big decision on this is whether or not we have a sighting object or EACH sighting (meaning, it references
something and adds context like who saw it, date, etc…) or have a combined object that carries a count.  The former will offer more flexibility, but will mean more object instances.  The later is really just a summary of the former, which will be much smaller
from a db size perspective, but we won’t be able to identify individual characteristics of each sighting instance.
 
Personally, I favor flexibility.  We can solve the size issue with technical implementation.
 


From:
cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Jordan, Bret
Sent: Wednesday, October 21, 2015 5:42 PM
To: Cory Casanave
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Conceptul model for sighting


 
I think a better place to start is how people or devices are going to interact with an IOC-Indicator.  

 


1) Human: I am going to see a list of IOCs in my work bench tool and have the ability to query that list for certain things as I do stuff.  Perhaps as I start documenting an issue I am seeing in my network
it could show a list of potential IOCs that match it.  I could then: 


           
a) click a button that says "share a sighting" or 


           
b) the software could be configured to emit a sighting every time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a report.


 


2) Device: A network device / security tool might be watching the network and either looking for IOCs based on a feed it gets from somewhere or it might find bad stuff on its own and generate an IOC then
query the repo to see if the IOC is already known.  In either case, the device could emit a sighting.  


 


While I appreciate the desire to cover every esoteric corner case that might ever come up, I think we should take a minimalistic approach to the first generation of the Sighting object..  It is always easy to add stuff,
but it is really hard to take it away.  


 


I would argue that the bare minimum we need is:


 


1) Reference to what it is we are sighting


2) The person / organization that is making the sighting


3) A count of the number of times it was seen.


 


Now yes, there is a LOT more things that COULD be added, and all of them could be added over time.  For example (yes this will rub people the wrong way), data markings.  I would personally leave them out for now.  I would
love if we could get to the point where we had to rev the sightings object spec to support data markings or something else because we had so many people using it and begging for the feature.  


 


By taking the minimalistic approach we can more quicker and get people using it.  


 


Think:


 


{


           
"type": "sighting",


           
"id": " foo.com :sighting-1234-1234-1234-1234",


           
"idref": " abc.com :indicator-4321-4321-4321-4321",


           
"count": "1222"


           
"producer": "tom and jerry"


}


 


 







 


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 21, 2015, at 15:17, Cory Casanave < cory-c@modeldriven.com > wrote:

 


In the meeting today “sighting” was discussed. Below is the sighting component of a conceptual model we are developing for threats and risks. Note that this is
a level more general than STIX (the model is being mapped to STIX), but perhaps we can share some ideas.


Regards,
Cory Casanave


 


<image003.jpg>




 


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email
and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.

In terms of volume, I see the Sighting object dwarfing all others, probably by several orders of magnitude.  Following the sighting object I see the relationship object being the next largest consumer of TAXII volume.  I also see the Sighting object along with the relationship object and its assertions working in a very social side of threat analysis and discovery, where a lot of back and forth takes place. Another option I can see is the Sighting object as being a seed for additional exploration or automated data enrichment.   So let's make sure we get this and the relationship object figured out and done well.  Bret  Sent from my Commodore 64 On Oct 26, 2015, at 1:45 PM, Terry MacDonald < terry@soltra.com > wrote: Hi Jon       -           Sensor Alerts – As an example, an IDS or other sensor reports a match on some indicator. You will likely have some contextual information like times, ip addresses, host names, what indictor was matched, what was really seen, which IDS or sensor reported the alert, etc..  You probably don’t care about data markings, aggregate sighting information, and other fields. You probably do care about having compact efficient messages due to high volume.   This is what I personally (speaking as myself) think of when I think of a Sighting. A description of an Observable Instance with some basic extra context.   -           Organizational Sighting Reports – As an example, consider what is needed when an organization reports back to an ISAC/ISAO that an indicator has been matched (or sighted).   To me this is no different to the first case. If an Indicator has been matched then a new Sighting object will be created under the namespace of the Organization. The Organization will then share that Sighting object back to the ISAC/ISAO (if the Org wants to) along with a Relationship object (also under the  namespace of the Org) that maps the ISAC Indicator to the Org’s Sighting Object. This can potentially be accompanied with an Incident object or Report object to give extra context if required.   -           Aggregate Sightings Analysis – Consider the information structure that is needed to enable effective analysis of aggregate data from both of the above examples.   In my personal opinion it is up to consumers to use the collected data to make their own decisions. Every Organization has their own institutional idea of trust. They alone know which sources of information make sense for them, their management’s risk appetite, the verticals they operate in and so forth. The analysis that one Organization performs to come to the conclusion of ‘High’ risk may actually be a ‘Low’ risk in another organization. Each Org must be ultimately responsible for its own analysis.   But, that’s not to say that they can’t outsource that function to other organizations. Dedicated third-parties specializing in analyzing Sightings to extract TTPs and match those to Campaigns and Actors will become more prevalent. These third-party analysis services will provide analysis customized to the Organization’s structure/vertical/risk appetite which will help them extract the ‘why and ‘how’ from the ‘what’.   I believe that the separate top-level Sighting object will provide us with the basic structure to begin the higher level analysis. I believe that this will then help third-parties to generate more ‘upper-level’ STIX data – Threat Actors, Campaigns and higher-order TTP in particular.   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 Baker, Jon Sent: Saturday, 24 October 2015 2:10 AM To: Jonathan Bush (DTCC) < jbush@dtcc.com >; 'Jordan, Bret' < bret.jordan@bluecoat.com >; Cory Casanave < cory-c@modeldriven.com > Cc: cti-stix@lists.oasis-open.org Subject: RE: [cti-stix] Conceptul model for sighting   The sightings conversation has historically suffered from a lack of shared understand of the sightings use cases and an attempt to address all the related sightings use cases with one complex model that does not really satisfy any single use case very well. I guess I am a fan of a bottom up approach focused on the use cases that are seen in the wild today.   At a high-level I think that we can talk about sightings in several ways: There are probably others perspectives on sightings to consider as well. My recommendation is that we clearly state (use case)  each of the different kinds of sightings and that we independently flesh out the information requirements.   At the same time we need to consider what is done today in each of these cases and what we think needs to be done in the future. I would like us to focus on developing a model for sightings that satisfies today’s needs and allows for expansion to what we think the future state should be. When it comes to sightings we simply don’t have enough experience to know what is really needed beyond supporting what people already do today.   Thanks,   Jon   ============================================ Jonathan O. Baker J83D - Cyber Security Partnerships, Sharing, and Automation The MITRE Corporation Email: bakerj@mitre.org   From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Bush, Jonathan Sent: Thursday, October 22, 2015 8:48 AM To: 'Jordan, Bret' < bret.jordan@bluecoat.com >; Cory Casanave < cory-c@modeldriven.com > Cc: cti-stix@lists.oasis-open.org Subject: RE: [cti-stix] Conceptul model for sighting   I definitely like the “state the use case first” approach here.  We can’t implement a data design until we know what we plan on doing with it.   On the simplicity suggestion – YES!!  Simple, simple, simple.  We can always add fields later.  Let’s just get this implemented, baked into our products, and then we can see what we are missing.   On the data structure – Seems to me that the big decision on this is whether or not we have a sighting object or EACH sighting (meaning, it references something and adds context like who saw it, date, etc…) or have a combined object that carries a count.  The former will offer more flexibility, but will mean more object instances.  The later is really just a summary of the former, which will be much smaller from a db size perspective, but we won’t be able to identify individual characteristics of each sighting instance.   Personally, I favor flexibility.  We can solve the size issue with technical implementation.   From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Jordan, Bret Sent: Wednesday, October 21, 2015 5:42 PM To: Cory Casanave Cc: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Conceptul model for sighting   I think a better place to start is how people or devices are going to interact with an IOC-Indicator.     1) Human: I am going to see a list of IOCs in my work bench tool and have the ability to query that list for certain things as I do stuff.  Perhaps as I start documenting an issue I am seeing in my network it could show a list of potential IOCs that match it.  I could then:              a) click a button that says "share a sighting" or              b) the software could be configured to emit a sighting every time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a report.   2) Device: A network device / security tool might be watching the network and either looking for IOCs based on a feed it gets from somewhere or it might find bad stuff on its own and generate an IOC then query the repo to see if the IOC is already known.  In either case, the device could emit a sighting.     While I appreciate the desire to cover every esoteric corner case that might ever come up, I think we should take a minimalistic approach to the first generation of the Sighting object..  It is always easy to add stuff, but it is really hard to take it away.     I would argue that the bare minimum we need is:   1) Reference to what it is we are sighting 2) The person / organization that is making the sighting 3) A count of the number of times it was seen.   Now yes, there is a LOT more things that COULD be added, and all of them could be added over time.  For example (yes this will rub people the wrong way), data markings.  I would personally leave them out for now.  I would love if we could get to the point where we had to rev the sightings object spec to support data markings or something else because we had so many people using it and begging for the feature.     By taking the minimalistic approach we can more quicker and get people using it.     Think:   {             "type": "sighting",             "id": " foo.com :sighting-1234-1234-1234-1234",             "idref": " abc.com :indicator-4321-4321-4321-4321",             "count": "1222"             "producer": "tom and jerry" }       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 21, 2015, at 15:17, Cory Casanave < cory-c@modeldriven.com > wrote:   In the meeting today “sighting” was discussed. Below is the sighting component of a conceptual model we are developing for threats and risks. Note that this is a level more general than STIX (the model is being mapped to STIX), but perhaps we can share some ideas. Regards, Cory Casanave   <image003.jpg>   DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.

I do agree with Terry and Bret last emails and find the thread constructive Some use cases for bottom up (without full context for now): My org observed 12 instances of this malware artifact today (after AV signatures update) My org observed 100000 hits from this ip address in the last hours (all against ssh) My org observed 5000 times this excel file with macro (coming in emails) in the last 10 minutes My org observed 1 hit of exploitation of this new ssl vuln CVE-2015-007 (against our VPN portal) this week-end My org observed 3 binaires signed with this stolen certificate this month On Tuesday, 27 October 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: In terms of volume, I see the Sighting object dwarfing all others, probably by several orders of magnitude.  Following the sighting object I see the relationship object being the next largest consumer of TAXII volume.  I also see the Sighting object along with the relationship object and its assertions working in a very social side of threat analysis and discovery, where a lot of back and forth takes place. Another option I can see is the Sighting object as being a seed for additional exploration or automated data enrichment.   So let's make sure we get this and the relationship object figured out and done well.  Bret  Sent from my Commodore 64 On Oct 26, 2015, at 1:45 PM, Terry MacDonald < terry@soltra.com > wrote: Hi Jon       -           Sensor Alerts – As an example, an IDS or other sensor reports a match on some indicator. You will likely have some contextual information like times, ip addresses, host names, what indictor was matched, what was really seen, which IDS or sensor reported the alert, etc..  You probably don’t care about data markings, aggregate sighting information, and other fields. You probably do care about having compact efficient messages due to high volume.   This is what I personally (speaking as myself) think of when I think of a Sighting. A description of an Observable Instance with some basic extra context.   -           Organizational Sighting Reports – As an example, consider what is needed when an organization reports back to an ISAC/ISAO that an indicator has been matched (or sighted).   To me this is no different to the first case. If an Indicator has been matched then a new Sighting object will be created under the namespace of the Organization. The Organization will then share that Sighting object back to the ISAC/ISAO (if the Org wants to) along with a Relationship object (also under the  namespace of the Org) that maps the ISAC Indicator to the Org’s Sighting Object. This can potentially be accompanied with an Incident object or Report object to give extra context if required.   -           Aggregate Sightings Analysis – Consider the information structure that is needed to enable effective analysis of aggregate data from both of the above examples.   In my personal opinion it is up to consumers to use the collected data to make their own decisions. Every Organization has their own institutional idea of trust. They alone know which sources of information make sense for them, their management’s risk appetite, the verticals they operate in and so forth. The analysis that one Organization performs to come to the conclusion of ‘High’ risk may actually be a ‘Low’ risk in another organization. Each Org must be ultimately responsible for its own analysis.   But, that’s not to say that they can’t outsource that function to other organizations. Dedicated third-parties specializing in analyzing Sightings to extract TTPs and match those to Campaigns and Actors will become more prevalent. These third-party analysis services will provide analysis customized to the Organization’s structure/vertical/risk appetite which will help them extract the ‘why and ‘how’ from the ‘what’.   I believe that the separate top-level Sighting object will provide us with the basic structure to begin the higher level analysis. I believe that this will then help third-parties to generate more ‘upper-level’ STIX data – Threat Actors, Campaigns and higher-order TTP in particular.   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 Baker, Jon Sent: Saturday, 24 October 2015 2:10 AM To: Jonathan Bush (DTCC) < jbush@dtcc.com >; 'Jordan, Bret' < bret.jordan@bluecoat.com >; Cory Casanave < cory-c@modeldriven.com > Cc: cti-stix@lists.oasis-open.org Subject: RE: [cti-stix] Conceptul model for sighting   The sightings conversation has historically suffered from a lack of shared understand of the sightings use cases and an attempt to address all the related sightings use cases with one complex model that does not really satisfy any single use case very well. I guess I am a fan of a bottom up approach focused on the use cases that are seen in the wild today.   At a high-level I think that we can talk about sightings in several ways: There are probably others perspectives on sightings to consider as well. My recommendation is that we clearly state (use case)  each of the different kinds of sightings and that we independently flesh out the information requirements.   At the same time we need to consider what is done today in each of these cases and what we think needs to be done in the future. I would like us to focus on developing a model for sightings that satisfies today’s needs and allows for expansion to what we think the future state should be. When it comes to sightings we simply don’t have enough experience to know what is really needed beyond supporting what people already do today.   Thanks,   Jon   ============================================ Jonathan O. Baker J83D - Cyber Security Partnerships, Sharing, and Automation The MITRE Corporation Email: bakerj@mitre.org   From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Bush, Jonathan Sent: Thursday, October 22, 2015 8:48 AM To: 'Jordan, Bret' < bret.jordan@bluecoat.com >; Cory Casanave < cory-c@modeldriven.com > Cc: cti-stix@lists.oasis-open.org Subject: RE: [cti-stix] Conceptul model for sighting   I definitely like the “state the use case first” approach here.  We can’t implement a data design until we know what we plan on doing with it.   On the simplicity suggestion – YES!!  Simple, simple, simple.  We can always add fields later.  Let’s just get this implemented, baked into our products, and then we can see what we are missing.   On the data structure – Seems to me that the big decision on this is whether or not we have a sighting object or EACH sighting (meaning, it references something and adds context like who saw it, date, etc…) or have a combined object that carries a count.  The former will offer more flexibility, but will mean more object instances.  The later is really just a summary of the former, which will be much smaller from a db size perspective, but we won’t be able to identify individual characteristics of each sighting instance.   Personally, I favor flexibility.  We can solve the size issue with technical implementation.   From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Jordan, Bret Sent: Wednesday, October 21, 2015 5:42 PM To: Cory Casanave Cc: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Conceptul model for sighting   I think a better place to start is how people or devices are going to interact with an IOC-Indicator.     1) Human: I am going to see a list of IOCs in my work bench tool and have the ability to query that list for certain things as I do stuff.  Perhaps as I start documenting an issue I am seeing in my network it could show a list of potential IOCs that match it.  I could then:              a) click a button that says "share a sighting" or              b) the software could be configured to emit a sighting every time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a report.   2) Device: A network device / security tool might be watching the network and either looking for IOCs based on a feed it gets from somewhere or it might find bad stuff on its own and generate an IOC then query the repo to see if the IOC is already known.  In either case, the device could emit a sighting.     While I appreciate the desire to cover every esoteric corner case that might ever come up, I think we should take a minimalistic approach to the first generation of the Sighting object..  It is always easy to add stuff, but it is really hard to take it away.     I would argue that the bare minimum we need is:   1) Reference to what it is we are sighting 2) The person / organization that is making the sighting 3) A count of the number of times it was seen.   Now yes, there is a LOT more things that COULD be added, and all of them could be added over time.  For example (yes this will rub people the wrong way), data markings.  I would personally leave them out for now.  I would love if we could get to the point where we had to rev the sightings object spec to support data markings or something else because we had so many people using it and begging for the feature.     By taking the minimalistic approach we can more quicker and get people using it.     Think:   {             "type": "sighting",             "id": " foo.com :sighting-1234-1234-1234-1234",             "idref": " abc.com :indicator-4321-4321-4321-4321",             "count": "1222"             "producer": "tom and jerry" }       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 21, 2015, at 15:17, Cory Casanave < cory-c@modeldriven.com > wrote:   In the meeting today “sighting” was discussed. Below is the sighting component of a conceptual model we are developing for threats and risks. Note that this is a level more general than STIX (the model is being mapped to STIX), but perhaps we can share some ideas. Regards, Cory Casanave   <image003.jpg>   DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.

I am a huge proponent of letting (almost) anything link to anything. In fact, limiting what can have an association/link/relationship with what is my current biggest frustration with Stix (we use workarounds to get around this limitation).  I would add the possible use cases: My org observed 3 instances of this threat actor hitting our network My org observed 12 instances of the Poison Ivy TTP on our network Or even (though weaker): My org was hit by this particular campaign 27 times Sarah Kelley Senior CERT Analyst Center for Internet Security (CIS) Integrated Intelligence Center (IIC) Multi-State Information Sharing and Analysis Center (MS-ISAC) 1-866-787-4722 (7×24 SOC) Email:  cert@cisecurity.org www.cisecurity.org Follow us @CISecurity From: < cti-stix@lists.oasis-open.org > on behalf of Jerome Athias < athiasjerome@gmail.com > Date: Monday, October 26, 2015 at 10:29 PM To: "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: Terry MacDonald < terry@soltra.com >, "Baker, Jon" < bakerj@mitre.org >, "Jonathan Bush (DTCC)" < jbush@dtcc.com >, Cory Casanave < cory-c@modeldriven.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Conceptul model for sighting I do agree with Terry and Bret last emails and find the thread constructive Some use cases for bottom up (without full context for now): My org observed 12 instances of this malware artifact today (after AV signatures update) My org observed 100000 hits from this ip address in the last hours (all against ssh) My org observed 5000 times this excel file with macro (coming in emails) in the last 10 minutes My org observed 1 hit of exploitation of this new ssl vuln CVE-2015-007 (against our VPN portal) this week-end My org observed 3 binaires signed with this stolen certificate this month On Tuesday, 27 October 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: In terms of volume, I see the Sighting object dwarfing all others, probably by several orders of magnitude.  Following the sighting object I see the relationship object being the next largest consumer of TAXII volume.  I also see the Sighting object along with the relationship object and its assertions working in a very social side of threat analysis and discovery, where a lot of back and forth takes place. Another option I can see is the Sighting object as being a seed for additional exploration or automated data enrichment.   So let's make sure we get this and the relationship object figured out and done well.  Bret  Sent from my Commodore 64 On Oct 26, 2015, at 1:45 PM, Terry MacDonald < terry@soltra.com > wrote: Hi Jon       -           Sensor Alerts – As an example, an IDS or other sensor reports a match on some indicator. You will likely have some contextual information like times, ip addresses, host names, what indictor was matched, what was really seen, which IDS or sensor reported the alert, etc..  You probably don’t care about data markings, aggregate sighting information, and other fields. You probably do care about having compact efficient messages due to high volume.   This is what I personally (speaking as myself) think of when I think of a Sighting. A description of an Observable Instance with some basic extra context.   -           Organizational Sighting Reports – As an example, consider what is needed when an organization reports back to an ISAC/ISAO that an indicator has been matched (or sighted).   To me this is no different to the first case. If an Indicator has been matched then a new Sighting object will be created under the namespace of the Organization. The Organization will then share that Sighting object back to the ISAC/ISAO (if the Org wants to) along with a Relationship object (also under the  namespace of the Org) that maps the ISAC Indicator to the Org’s Sighting Object. This can potentially be accompanied with an Incident object or Report object to give extra context if required.   -           Aggregate Sightings Analysis – Consider the information structure that is needed to enable effective analysis of aggregate data from both of the above examples.   In my personal opinion it is up to consumers to use the collected data to make their own decisions. Every Organization has their own institutional idea of trust. They alone know which sources of information make sense for them, their management’s risk appetite, the verticals they operate in and so forth. The analysis that one Organization performs to come to the conclusion of ‘High’ risk may actually be a ‘Low’ risk in another organization. Each Org must be ultimately responsible for its own analysis.   But, that’s not to say that they can’t outsource that function to other organizations. Dedicated third-parties specializing in analyzing Sightings to extract TTPs and match those to Campaigns and Actors will become more prevalent. These third-party analysis services will provide analysis customized to the Organization’s structure/vertical/risk appetite which will help them extract the ‘why and ‘how’ from the ‘what’.   I believe that the separate top-level Sighting object will provide us with the basic structure to begin the higher level analysis. I believe that this will then help third-parties to generate more ‘upper-level’ STIX data – Threat Actors, Campaigns and higher-order TTP in particular.   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 Baker, Jon Sent: Saturday, 24 October 2015 2:10 AM To: Jonathan Bush (DTCC) < jbush@dtcc.com >; 'Jordan, Bret' < bret.jordan@bluecoat.com >; Cory Casanave < cory-c@modeldriven.com > Cc: cti-stix@lists.oasis-open.org Subject: RE: [cti-stix] Conceptul model for sighting   The sightings conversation has historically suffered from a lack of shared understand of the sightings use cases and an attempt to address all the related sightings use cases with one complex model that does not really satisfy any single use case very well. I guess I am a fan of a bottom up approach focused on the use cases that are seen in the wild today.   At a high-level I think that we can talk about sightings in several ways: There are probably others perspectives on sightings to consider as well. My recommendation is that we clearly state (use case)  each of the different kinds of sightings and that we independently flesh out the information requirements.   At the same time we need to consider what is done today in each of these cases and what we think needs to be done in the future. I would like us to focus on developing a model for sightings that satisfies today’s needs and allows for expansion to what we think the future state should be. When it comes to sightings we simply don’t have enough experience to know what is really needed beyond supporting what people already do today.   Thanks,   Jon   ============================================ Jonathan O. Baker J83D - Cyber Security Partnerships, Sharing, and Automation The MITRE Corporation Email: bakerj@mitre.org   From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Bush, Jonathan Sent: Thursday, October 22, 2015 8:48 AM To: 'Jordan, Bret' < bret.jordan@bluecoat.com >; Cory Casanave < cory-c@modeldriven.com > Cc: cti-stix@lists.oasis-open.org Subject: RE: [cti-stix] Conceptul model for sighting   I definitely like the “state the use case first” approach here.  We can’t implement a data design until we know what we plan on doing with it.   On the simplicity suggestion – YES!!  Simple, simple, simple.  We can always add fields later.  Let’s just get this implemented, baked into our products, and then we can see what we are missing.   On the data structure – Seems to me that the big decision on this is whether or not we have a sighting object or EACH sighting (meaning, it references something and adds context like who saw it, date, etc…) or have a combined object that carries a count.  The former will offer more flexibility, but will mean more object instances.  The later is really just a summary of the former, which will be much smaller from a db size perspective, but we won’t be able to identify individual characteristics of each sighting instance.   Personally, I favor flexibility.  We can solve the size issue with technical implementation.   From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Jordan, Bret Sent: Wednesday, October 21, 2015 5:42 PM To: Cory Casanave Cc: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Conceptul model for sighting   I think a better place to start is how people or devices are going to interact with an IOC-Indicator.     1) Human: I am going to see a list of IOCs in my work bench tool and have the ability to query that list for certain things as I do stuff.  Perhaps as I start documenting an issue I am seeing in my network it could show a list of potential IOCs that match it.  I could then:              a) click a button that says "share a sighting" or              b) the software could be configured to emit a sighting every time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a report.   2) Device: A network device / security tool might be watching the network and either looking for IOCs based on a feed it gets from somewhere or it might find bad stuff on its own and generate an IOC then query the repo to see if the IOC is already known.  In either case, the device could emit a sighting.     While I appreciate the desire to cover every esoteric corner case that might ever come up, I think we should take a minimalistic approach to the first generation of the Sighting object..  It is always easy to add stuff, but it is really hard to take it away.     I would argue that the bare minimum we need is:   1) Reference to what it is we are sighting 2) The person / organization that is making the sighting 3) A count of the number of times it was seen.   Now yes, there is a LOT more things that COULD be added, and all of them could be added over time.  For example (yes this will rub people the wrong way), data markings.  I would personally leave them out for now.  I would love if we could get to the point where we had to rev the sightings object spec to support data markings or something else because we had so many people using it and begging for the feature.     By taking the minimalistic approach we can more quicker and get people using it.     Think:   {             "type": "sighting",             "id": " foo.com :sighting-1234-1234-1234-1234",             "idref": " abc.com :indicator-4321-4321-4321-4321",             "count": "1222"             "producer": "tom and jerry" }       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 21, 2015, at 15:17, Cory Casanave < cory-c@modeldriven.com > wrote:   In the meeting today “sighting” was discussed. Below is the sighting component of a conceptual model we are developing for threats and risks. Note that this is a level more general than STIX (the model is being mapped to STIX), but perhaps we can share some ideas. Regards, Cory Casanave   <image003.jpg>   DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email. ... This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. . . .

I’m feeling like the possible use cases mentioned so far might be condensable into the following sentence structure:   “<source> observed <x> instances of <object> at <location>, <time-range>, via <detection-method>”   This has decent (but not complete) overlap with Terry’s proposed fields, so maybe it means we are on the right track?   As a side note, do we know how we are we capturing the outcome of this discussion? In the TAXII SC, we’ve been keeping a “Decisions” list [1], with links out to more detail as necessary. (Note that decisions does not mean that everything in there is set in stone – it just means the TAXII SC has general agreement on the principle. For e.g., the REST API, there’s still plenty to work on). Once we get most people agreeing on most things for a particular discussion, we could document them in a similar fashion and keep track of the open items; e.g., if we can’t agree on <Some-Field>, let’s mark it as an open question and move on to another topic.   Thank you. -Mark   [1] http://taxiiproject.github.io/taxii2/#decisions   From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Sarah Kelley Sent: Tuesday, October 27, 2015 7:18 AM To: Unknown Unknown <athiasjerome@gmail.com>; Jordan, Bret <bret.jordan@bluecoat.com> Cc: Terry MacDonald <terry@soltra.com>; Baker, Jon <bakerj@mitre.org>; Jonathan Bush (DTCC) <jbush@dtcc.com>; Cory Casanave <cory-c@modeldriven.com>; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Conceptul model for sighting   I am a huge proponent of letting (almost) anything link to anything. In fact, limiting what can have an association/link/relationship with what is my current biggest frustration with Stix (we use workarounds to get around this limitation).    I would add the possible use cases:   My org observed 3 instances of this threat actor hitting our network My org observed 12 instances of the Poison Ivy TTP on our network Or even (though weaker): My org was hit by this particular campaign 27 times       Sarah Kelley Senior CERT Analyst Center for Internet Security (CIS) Integrated Intelligence Center (IIC) Multi-State Information Sharing and Analysis Center (MS-ISAC) 1-866-787-4722 (7×24 SOC) Email:  cert@cisecurity.org www.cisecurity.org Follow us @CISecurity     From: < cti-stix@lists.oasis-open.org > on behalf of Jerome Athias < athiasjerome@gmail.com > Date: Monday, October 26, 2015 at 10:29 PM To: "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: Terry MacDonald < terry@soltra.com >, "Baker, Jon" < bakerj@mitre.org >, "Jonathan Bush (DTCC)" < jbush@dtcc.com >, Cory Casanave < cory-c@modeldriven.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Conceptul model for sighting   I do agree with Terry and Bret last emails and find the thread constructive   Some use cases for bottom up (without full context for now):   My org observed 12 instances of this malware artifact today (after AV signatures update) My org observed 100000 hits from this ip address in the last hours (all against ssh) My org observed 5000 times this excel file with macro (coming in emails) in the last 10 minutes My org observed 1 hit of exploitation of this new ssl vuln CVE-2015-007 (against our VPN portal) this week-end My org observed 3 binaires signed with this stolen certificate this month   On Tuesday, 27 October 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: In terms of volume, I see the Sighting object dwarfing all others, probably by several orders of magnitude.  Following the sighting object I see the relationship object being the next largest consumer of TAXII volume.  I also see the Sighting object along with the relationship object and its assertions working in a very social side of threat analysis and discovery, where a lot of back and forth takes place.   Another option I can see is the Sighting object as being a seed for additional exploration or automated data enrichment.     So let's make sure we get this and the relationship object figured out and done well.    Bret  Sent from my Commodore 64 On Oct 26, 2015, at 1:45 PM, Terry MacDonald < terry@soltra.com > wrote: Hi Jon       -           Sensor Alerts – As an example, an IDS or other sensor reports a match on some indicator. You will likely have some contextual information like times, ip addresses, host names, what indictor was matched, what was really seen, which IDS or sensor reported the alert, etc..  You probably don’t care about data markings, aggregate sighting information, and other fields. You probably do care about having compact efficient messages due to high volume.   This is what I personally (speaking as myself) think of when I think of a Sighting. A description of an Observable Instance with some basic extra context.   -           Organizational Sighting Reports – As an example, consider what is needed when an organization reports back to an ISAC/ISAO that an indicator has been matched (or sighted).   To me this is no different to the first case. If an Indicator has been matched then a new Sighting object will be created under the namespace of the Organization. The Organization will then share that Sighting object back to the ISAC/ISAO (if the Org wants to) along with a Relationship object (also under the  namespace of the Org) that maps the ISAC Indicator to the Org’s Sighting Object. This can potentially be accompanied with an Incident object or Report object to give extra context if required.   -           Aggregate Sightings Analysis – Consider the information structure that is needed to enable effective analysis of aggregate data from both of the above examples.   In my personal opinion it is up to consumers to use the collected data to make their own decisions. Every Organization has their own institutional idea of trust. They alone know which sources of information make sense for them, their management’s risk appetite, the verticals they operate in and so forth. The analysis that one Organization performs to come to the conclusion of ‘High’ risk may actually be a ‘Low’ risk in another organization. Each Org must be ultimately responsible for its own analysis.   But, that’s not to say that they can’t outsource that function to other organizations. Dedicated third-parties specializing in analyzing Sightings to extract TTPs and match those to Campaigns and Actors will become more prevalent. These third-party analysis services will provide analysis customized to the Organization’s structure/vertical/risk appetite which will help them extract the ‘why and ‘how’ from the ‘what’.   I believe that the separate top-level Sighting object will provide us with the basic structure to begin the higher level analysis. I believe that this will then help third-parties to generate more ‘upper-level’ STIX data – Threat Actors, Campaigns and higher-order TTP in particular.   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 Baker, Jon Sent: Saturday, 24 October 2015 2:10 AM To: Jonathan Bush (DTCC) < jbush@dtcc.com >; 'Jordan, Bret' < bret.jordan@bluecoat.com >; Cory Casanave < cory-c@modeldriven.com > Cc: cti-stix@lists.oasis-open.org Subject: RE: [cti-stix] Conceptul model for sighting   The sightings conversation has historically suffered from a lack of shared understand of the sightings use cases and an attempt to address all the related sightings use cases with one complex model that does not really satisfy any single use case very well. I guess I am a fan of a bottom up approach focused on the use cases that are seen in the wild today.   At a high-level I think that we can talk about sightings in several ways: There are probably others perspectives on sightings to consider as well. My recommendation is that we clearly state (use case)  each of the different kinds of sightings and that we independently flesh out the information requirements.   At the same time we need to consider what is done today in each of these cases and what we think needs to be done in the future. I would like us to focus on developing a model for sightings that satisfies today’s needs and allows for expansion to what we think the future state should be. When it comes to sightings we simply don’t have enough experience to know what is really needed beyond supporting what people already do today.   Thanks,   Jon   ============================================ Jonathan O. Baker J83D - Cyber Security Partnerships, Sharing, and Automation The MITRE Corporation Email: bakerj@mitre.org   From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Bush, Jonathan Sent: Thursday, October 22, 2015 8:48 AM To: 'Jordan, Bret' < bret.jordan@bluecoat.com >; Cory Casanave < cory-c@modeldriven.com > Cc: cti-stix@lists.oasis-open.org Subject: RE: [cti-stix] Conceptul model for sighting   I definitely like the “state the use case first” approach here.  We can’t implement a data design until we know what we plan on doing with it.   On the simplicity suggestion – YES!!  Simple, simple, simple.  We can always add fields later.  Let’s just get this implemented, baked into our products, and then we can see what we are missing.   On the data structure – Seems to me that the big decision on this is whether or not we have a sighting object or EACH sighting (meaning, it references something and adds context like who saw it, date, etc…) or have a combined object that carries a count.  The former will offer more flexibility, but will mean more object instances.  The later is really just a summary of the former, which will be much smaller from a db size perspective, but we won’t be able to identify individual characteristics of each sighting instance.   Personally, I favor flexibility.  We can solve the size issue with technical implementation.   From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Jordan, Bret Sent: Wednesday, October 21, 2015 5:42 PM To: Cory Casanave Cc: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Conceptul model for sighting   I think a better place to start is how people or devices are going to interact with an IOC-Indicator.     1) Human: I am going to see a list of IOCs in my work bench tool and have the ability to query that list for certain things as I do stuff.  Perhaps as I start documenting an issue I am seeing in my network it could show a list of potential IOCs that match it.  I could then:              a) click a button that says "share a sighting" or              b) the software could be configured to emit a sighting every time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a report.   2) Device: A network device / security tool might be watching the network and either looking for IOCs based on a feed it gets from somewhere or it might find bad stuff on its own and generate an IOC then query the repo to see if the IOC is already known.  In either case, the device could emit a sighting.     While I appreciate the desire to cover every esoteric corner case that might ever come up, I think we should take a minimalistic approach to the first generation of the Sighting object..  It is always easy to add stuff, but it is really hard to take it away.     I would argue that the bare minimum we need is:   1) Reference to what it is we are sighting 2) The person / organization that is making the sighting 3) A count of the number of times it was seen.   Now yes, there is a LOT more things that COULD be added, and all of them could be added over time.  For example (yes this will rub people the wrong way), data markings.  I would personally leave them out for now.  I would love if we could get to the point where we had to rev the sightings object spec to support data markings or something else because we had so many people using it and begging for the feature.     By taking the minimalistic approach we can more quicker and get people using it.     Think:   {             "type": "sighting",             "id": " foo.com :sighting-1234-1234-1234-1234",             "idref": " abc.com :indicator-4321-4321-4321-4321",             "count": "1222"             "producer": "tom and jerry" }       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 21, 2015, at 15:17, Cory Casanave < cory-c@modeldriven.com > wrote:   In the meeting today “sighting” was discussed. Below is the sighting component of a conceptual model we are developing for threats and risks. Note that this is a level more general than STIX (the model is being mapped to STIX), but perhaps we can share some ideas. Regards, Cory Casanave   <image003.jpg>   DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email. ... This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. . . .

I think we're doing well. I think the location and detection-method could be optional (in an effort of keeping things as simple as possible) <source> observed <x> instances of <object>, <time-range> (via <detection-method>) (at <location>) (with <confidence>) (...) After let's say two weeks of open discussions in the list, we could update the github and ask the TC Chairs to present the current conclusion/proposition during the next meeting. Then submitting it for an open request for comments for a period of, let's say 1 month before potential definitive agreement/validation @Sarah: regarding the relationships 'issue', there's an open discussion going on to know if we make it as a construct. I will just add, for now, that if you can't find a 'workaround', that I assume right now being finding the -relationship path- between top level object A and the underlying object B, this should be highlighted @Sarah (and all): did you run the statistics tool? :-) 2015-10-27 14:56 GMT+03:00 Davidson II, Mark S <mdavidson@mitre.org>: > I’m feeling like the possible use cases mentioned so far might be > condensable into the following sentence structure: > > > > “<source> observed <x> instances of <object> at <location>, <time-range>, > via <detection-method>” > > > > This has decent (but not complete) overlap with Terry’s proposed fields, so > maybe it means we are on the right track? > > > > As a side note, do we know how we are we capturing the outcome of this > discussion? In the TAXII SC, we’ve been keeping a “Decisions” list [1], with > links out to more detail as necessary. (Note that decisions does not mean > that everything in there is set in stone – it just means the TAXII SC has > general agreement on the principle. For e.g., the REST API, there’s still > plenty to work on). Once we get most people agreeing on most things for a > particular discussion, we could document them in a similar fashion and keep > track of the open items; e.g., if we can’t agree on <Some-Field>, let’s mark > it as an open question and move on to another topic. > > > > Thank you. > > -Mark > > > > [1] http://taxiiproject.github.io/taxii2/#decisions > > > > From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] > On Behalf Of Sarah Kelley > Sent: Tuesday, October 27, 2015 7:18 AM > To: Unknown Unknown <athiasjerome@gmail.com>; Jordan, Bret > <bret.jordan@bluecoat.com> > Cc: Terry MacDonald <terry@soltra.com>; Baker, Jon <bakerj@mitre.org>; > Jonathan Bush (DTCC) <jbush@dtcc.com>; Cory Casanave > <cory-c@modeldriven.com>; cti-stix@lists.oasis-open.org > > > Subject: Re: [cti-stix] Conceptul model for sighting > > > > I am a huge proponent of letting (almost) anything link to anything. In > fact, limiting what can have an association/link/relationship with what is > my current biggest frustration with Stix (we use workarounds to get around > this limitation). > > > > I would add the possible use cases: > > > > My org observed 3 instances of this threat actor hitting our network > > My org observed 12 instances of the Poison Ivy TTP on our network > > Or even (though weaker): > > My org was hit by this particular campaign 27 times > > > > > > > > Sarah Kelley > > Senior CERT Analyst > > Center for Internet Security (CIS) > > Integrated Intelligence Center (IIC) > > Multi-State Information Sharing and Analysis Center (MS-ISAC) > > 1-866-787-4722 (7×24 SOC) > > Email: cert@cisecurity.org > > www.cisecurity.org > > Follow us @CISecurity > > > > > > From: <cti-stix@lists.oasis-open.org> on behalf of Jerome Athias > <athiasjerome@gmail.com> > Date: Monday, October 26, 2015 at 10:29 PM > To: "Jordan, Bret" <bret.jordan@bluecoat.com> > Cc: Terry MacDonald <terry@soltra.com>, "Baker, Jon" <bakerj@mitre.org>, > "Jonathan Bush (DTCC)" <jbush@dtcc.com>, Cory Casanave > <cory-c@modeldriven.com>, "cti-stix@lists.oasis-open.org" > <cti-stix@lists.oasis-open.org> > Subject: Re: [cti-stix] Conceptul model for sighting > > > > I do agree with Terry and Bret last emails and find the thread constructive > > > > Some use cases for bottom up (without full context for now): > > > > My org observed 12 instances of this malware artifact today (after AV > signatures update) > > My org observed 100000 hits from this ip address in the last hours (all > against ssh) > > My org observed 5000 times this excel file with macro (coming in emails) in > the last 10 minutes > > My org observed 1 hit of exploitation of this new ssl vuln CVE-2015-007 > (against our VPN portal) this week-end > > My org observed 3 binaires signed with this stolen certificate this month > > > > > On Tuesday, 27 October 2015, Jordan, Bret <bret.jordan@bluecoat.com> wrote: > > In terms of volume, I see the Sighting object dwarfing all others, probably > by several orders of magnitude. Following the sighting object I see the > relationship object being the next largest consumer of TAXII volume. I also > see the Sighting object along with the relationship object and its > assertions working in a very social side of threat analysis and discovery, > where a lot of back and forth takes place. > > > > Another option I can see is the Sighting object as being a seed for > additional exploration or automated data enrichment. > > > > So let's make sure we get this and the relationship object figured out and > done well. > > > > Bret > > Sent from my Commodore 64 > > > On Oct 26, 2015, at 1:45 PM, Terry MacDonald <terry@soltra.com> wrote: > > Hi Jon > > > > > > > > - Sensor Alerts – As an example, an IDS or other sensor reports a > match on some indicator. You will likely have some contextual information > like times, ip addresses, host names, what indictor was matched, what was > really seen, which IDS or sensor reported the alert, etc.. You probably > don’t care about data markings, aggregate sighting information, and other > fields. You probably do care about having compact efficient messages due to > high volume. > > > > This is what I personally (speaking as myself) think of when I think of a > Sighting. A description of an Observable Instance with some basic extra > context. > > > > - Organizational Sighting Reports – As an example, consider what is > needed when an organization reports back to an ISAC/ISAO that an indicator > has been matched (or sighted). > > > > To me this is no different to the first case. If an Indicator has been > matched then a new Sighting object will be created under the namespace of > the Organization. The Organization will then share that Sighting object back > to the ISAC/ISAO (if the Org wants to) along with a Relationship object > (also under the namespace of the Org) that maps the ISAC Indicator to the > Org’s Sighting Object. This can potentially be accompanied with an Incident > object or Report object to give extra context if required. > > > > - Aggregate Sightings Analysis – Consider the information structure > that is needed to enable effective analysis of aggregate data from both of > the above examples. > > > > In my personal opinion it is up to consumers to use the collected data to > make their own decisions. Every Organization has their own institutional > idea of trust. They alone know which sources of information make sense for > them, their management’s risk appetite, the verticals they operate in and so > forth. The analysis that one Organization performs to come to the conclusion > of ‘High’ risk may actually be a ‘Low’ risk in another organization. Each > Org must be ultimately responsible for its own analysis. > > > > But, that’s not to say that they can’t outsource that function to other > organizations. Dedicated third-parties specializing in analyzing Sightings > to extract TTPs and match those to Campaigns and Actors will become more > prevalent. These third-party analysis services will provide analysis > customized to the Organization’s structure/vertical/risk appetite which will > help them extract the ‘why and ‘how’ from the ‘what’. > > > > I believe that the separate top-level Sighting object will provide us with > the basic structure to begin the higher level analysis. I believe that this > will then help third-parties to generate more ‘upper-level’ STIX data – > Threat Actors, Campaigns and higher-order TTP in particular. > > > > 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 Baker, Jon > Sent: Saturday, 24 October 2015 2:10 AM > To: Jonathan Bush (DTCC) <jbush@dtcc.com>; 'Jordan, Bret' > <bret.jordan@bluecoat.com>; Cory Casanave <cory-c@modeldriven.com> > Cc: cti-stix@lists.oasis-open.org > Subject: RE: [cti-stix] Conceptul model for sighting > > > > The sightings conversation has historically suffered from a lack of shared > understand of the sightings use cases and an attempt to address all the > related sightings use cases with one complex model that does not really > satisfy any single use case very well. I guess I am a fan of a bottom up > approach focused on the use cases that are seen in the wild today. > > > > At a high-level I think that we can talk about sightings in several ways: > > There are probably others perspectives on sightings to consider as well. My > recommendation is that we clearly state (use case) each of the different > kinds of sightings and that we independently flesh out the information > requirements. > > > > At the same time we need to consider what is done today in each of these > cases and what we think needs to be done in the future. I would like us to > focus on developing a model for sightings that satisfies today’s needs and > allows for expansion to what we think the future state should be. When it > comes to sightings we simply don’t have enough experience to know what is > really needed beyond supporting what people already do today. > > > > Thanks, > > > > Jon > > > > ============================================ > > Jonathan O. Baker > > J83D - Cyber Security Partnerships, Sharing, and Automation > > The MITRE Corporation > > Email: bakerj@mitre.org > > > > From:cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On > Behalf Of Bush, Jonathan > Sent: Thursday, October 22, 2015 8:48 AM > To: 'Jordan, Bret' <bret.jordan@bluecoat.com>; Cory Casanave > <cory-c@modeldriven.com> > Cc: cti-stix@lists.oasis-open.org > Subject: RE: [cti-stix] Conceptul model for sighting > > > > I definitely like the “state the use case first” approach here. We can’t > implement a data design until we know what we plan on doing with it. > > > > On the simplicity suggestion – YES!! Simple, simple, simple. We can always > add fields later. Let’s just get this implemented, baked into our products, > and then we can see what we are missing. > > > > On the data structure – Seems to me that the big decision on this is whether > or not we have a sighting object or EACH sighting (meaning, it references > something and adds context like who saw it, date, etc…) or have a combined > object that carries a count. The former will offer more flexibility, but > will mean more object instances. The later is really just a summary of the > former, which will be much smaller from a db size perspective, but we won’t > be able to identify individual characteristics of each sighting instance. > > > > Personally, I favor flexibility. We can solve the size issue with technical > implementation. > > > > From:cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On > Behalf Of Jordan, Bret > Sent: Wednesday, October 21, 2015 5:42 PM > To: Cory Casanave > Cc: cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Conceptul model for sighting > > > > I think a better place to start is how people or devices are going to > interact with an IOC-Indicator. > > > > 1) Human: I am going to see a list of IOCs in my work bench tool and have > the ability to query that list for certain things as I do stuff. Perhaps as > I start documenting an issue I am seeing in my network it could show a list > of potential IOCs that match it. I could then: > > a) click a button that says "share a sighting" or > > b) the software could be configured to emit a sighting every > time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a > report. > > > > 2) Device: A network device / security tool might be watching the network > and either looking for IOCs based on a feed it gets from somewhere or it > might find bad stuff on its own and generate an IOC then query the repo to > see if the IOC is already known. In either case, the device could emit a > sighting. > > > > While I appreciate the desire to cover every esoteric corner case that might > ever come up, I think we should take a minimalistic approach to the first > generation of the Sighting object.. It is always easy to add stuff, but it > is really hard to take it away. > > > > I would argue that the bare minimum we need is: > > > > 1) Reference to what it is we are sighting > > 2) The person / organization that is making the sighting > > 3) A count of the number of times it was seen. > > > > Now yes, there is a LOT more things that COULD be added, and all of them > could be added over time. For example (yes this will rub people the wrong > way), data markings. I would personally leave them out for now. I would > love if we could get to the point where we had to rev the sightings object > spec to support data markings or something else because we had so many > people using it and begging for the feature. > > > > By taking the minimalistic approach we can more quicker and get people using > it. > > > > Think: > > > > { > > "type": "sighting", > > "id": "foo.com:sighting-1234-1234-1234-1234", > > "idref": "abc.com:indicator-4321-4321-4321-4321", > > "count": "1222" > > "producer": "tom and jerry" > > } > > > > > > > > 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 21, 2015, at 15:17, Cory Casanave <cory-c@modeldriven.com> wrote: > > > > In the meeting today “sighting” was discussed. Below is the sighting > component of a conceptual model we are developing for threats and risks. > Note that this is a level more general than STIX (the model is being mapped > to STIX), but perhaps we can share some ideas. > > Regards, > Cory Casanave > > > > <image003.jpg> > > > > > DTCC DISCLAIMER: This email and any files transmitted with it are > confidential and intended solely for the use of the individual or entity to > whom they are addressed. If you have received this email in error, please > notify us immediately and delete the email and any attachments from your > system. The recipient should check this email and any attachments for the > presence of viruses. The company accepts no liability for any damage caused > by any virus transmitted by this email. > > > ... > > This message and attachments may contain confidential information. If it > appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments is > strictly prohibited. Please notify the sender immediately and permanently > delete the message and any attachments. > . . .

@Jerome - we did attempt to run the statistics tool (three times). We’re running Soltra Edge, and we’re getting an error. Below is the error and the command my team used (with password and user and host changed). We followed the install instructions on git hub. ./cti-stats —user=noone --pass=‘password' —host=soltra --port=80 --use-ssl=False --validate-cert=False --taxii-stats Traceback (most recent call last): File "./cti-stats", line 69, in <module> main() File "./cti-stats", line 63, in main args['--use-ssl'], args['--validate-cert']) File "/home/dwallmeyer/soltra_edge/cti-stats/lib/cti.py", line 115, in taxii_poll process_stix_pkg(stix_package) File "/home/dwallmeyer/soltra_edge/cti-stats/lib/cti.py", line 74, in process_stix_pkg obs_type = str(type(i.object_.properties)).split('.')[-1:][0].split("'")[0] AttributeError: 'NoneType' object has no attribute ‘properties' Can anyone help troubleshoot? Sarah Kelley Senior CERT Analyst Center for Internet Security (CIS) Integrated Intelligence Center (IIC) Multi-State Information Sharing and Analysis Center (MS-ISAC) 1-866-787-4722 (7×24 SOC) Email: cert@cisecurity.org www.cisecurity.org Follow us @CISecurity On 10/27/15, 10:26 AM, "Jerome Athias" <athiasjerome@gmail.com> wrote: >I think we're doing well. >I think the location and detection-method could be optional (in an >effort of keeping things as simple as possible) > ><source> observed <x> instances of <object>, <time-range> (via ><detection-method>) (at <location>) (with <confidence>) (...) > > >After let's say two weeks of open discussions in the list, we could >update the github and ask the TC Chairs to present the current >conclusion/proposition during the next meeting. Then submitting it for >an open request for comments for a period of, let's say 1 month before >potential definitive agreement/validation > >@Sarah: regarding the relationships 'issue', there's an open >discussion going on to know if we make it as a construct. I will just >add, for now, that if you can't find a 'workaround', that I assume >right now being finding the -relationship path- between top level >object A and the underlying object B, this should be highlighted > >@Sarah (and all): did you run the statistics tool? :-) > > > >2015-10-27 14:56 GMT+03:00 Davidson II, Mark S <mdavidson@mitre.org>: >> I’m feeling like the possible use cases mentioned so far might be >> condensable into the following sentence structure: >> >> >> >> “<source> observed <x> instances of <object> at <location>, >><time-range>, >> via <detection-method>” >> >> >> >> This has decent (but not complete) overlap with Terry’s proposed >>fields, so >> maybe it means we are on the right track? >> >> >> >> As a side note, do we know how we are we capturing the outcome of this >> discussion? In the TAXII SC, we’ve been keeping a “Decisions” list [1], >>with >> links out to more detail as necessary. (Note that decisions does not >>mean >> that everything in there is set in stone – it just means the TAXII SC >>has >> general agreement on the principle. For e.g., the REST API, there’s >>still >> plenty to work on). Once we get most people agreeing on most things for >>a >> particular discussion, we could document them in a similar fashion and >>keep >> track of the open items; e.g., if we can’t agree on <Some-Field>, let’s >>mark >> it as an open question and move on to another topic. >> >> >> >> Thank you. >> >> -Mark >> >> >> >> [1] http://taxiiproject.github.io/taxii2/#decisions >> >> >> >> From: cti-stix@lists.oasis-open.org >>[ mailto:cti-stix@lists.oasis-open.org ] >> On Behalf Of Sarah Kelley >> Sent: Tuesday, October 27, 2015 7:18 AM >> To: Unknown Unknown <athiasjerome@gmail.com>; Jordan, Bret >> <bret.jordan@bluecoat.com> >> Cc: Terry MacDonald <terry@soltra.com>; Baker, Jon <bakerj@mitre.org>; >> Jonathan Bush (DTCC) <jbush@dtcc.com>; Cory Casanave >> <cory-c@modeldriven.com>; cti-stix@lists.oasis-open.org >> >> >> Subject: Re: [cti-stix] Conceptul model for sighting >> >> >> >> I am a huge proponent of letting (almost) anything link to anything. In >> fact, limiting what can have an association/link/relationship with what >>is >> my current biggest frustration with Stix (we use workarounds to get >>around >> this limitation). >> >> >> >> I would add the possible use cases: >> >> >> >> My org observed 3 instances of this threat actor hitting our network >> >> My org observed 12 instances of the Poison Ivy TTP on our network >> >> Or even (though weaker): >> >> My org was hit by this particular campaign 27 times >> >> >> >> >> >> >> >> Sarah Kelley >> >> Senior CERT Analyst >> >> Center for Internet Security (CIS) >> >> Integrated Intelligence Center (IIC) >> >> Multi-State Information Sharing and Analysis Center (MS-ISAC) >> >> 1-866-787-4722 (7×24 SOC) >> >> Email: cert@cisecurity.org >> >> www.cisecurity.org >> >> Follow us @CISecurity >> >> >> >> >> >> From: <cti-stix@lists.oasis-open.org> on behalf of Jerome Athias >> <athiasjerome@gmail.com> >> Date: Monday, October 26, 2015 at 10:29 PM >> To: "Jordan, Bret" <bret.jordan@bluecoat.com> >> Cc: Terry MacDonald <terry@soltra.com>, "Baker, Jon" <bakerj@mitre.org>, >> "Jonathan Bush (DTCC)" <jbush@dtcc.com>, Cory Casanave >> <cory-c@modeldriven.com>, "cti-stix@lists.oasis-open.org" >> <cti-stix@lists.oasis-open.org> >> Subject: Re: [cti-stix] Conceptul model for sighting >> >> >> >> I do agree with Terry and Bret last emails and find the thread >>constructive >> >> >> >> Some use cases for bottom up (without full context for now): >> >> >> >> My org observed 12 instances of this malware artifact today (after AV >> signatures update) >> >> My org observed 100000 hits from this ip address in the last hours (all >> against ssh) >> >> My org observed 5000 times this excel file with macro (coming in >>emails) in >> the last 10 minutes >> >> My org observed 1 hit of exploitation of this new ssl vuln CVE-2015-007 >> (against our VPN portal) this week-end >> >> My org observed 3 binaires signed with this stolen certificate this >>month >> >> >> >> >> On Tuesday, 27 October 2015, Jordan, Bret <bret.jordan@bluecoat.com> >>wrote: >> >> In terms of volume, I see the Sighting object dwarfing all others, >>probably >> by several orders of magnitude. Following the sighting object I see the >> relationship object being the next largest consumer of TAXII volume. I >>also >> see the Sighting object along with the relationship object and its >> assertions working in a very social side of threat analysis and >>discovery, >> where a lot of back and forth takes place. >> >> >> >> Another option I can see is the Sighting object as being a seed for >> additional exploration or automated data enrichment. >> >> >> >> So let's make sure we get this and the relationship object figured out >>and >> done well. >> >> >> >> Bret >> >> Sent from my Commodore 64 >> >> >> On Oct 26, 2015, at 1:45 PM, Terry MacDonald <terry@soltra.com> wrote: >> >> Hi Jon >> >> >> >> >> >> >> >> - Sensor Alerts – As an example, an IDS or other sensor >>reports a >> match on some indicator. You will likely have some contextual >>information >> like times, ip addresses, host names, what indictor was matched, what >>was >> really seen, which IDS or sensor reported the alert, etc.. You probably >> don’t care about data markings, aggregate sighting information, and >>other >> fields. You probably do care about having compact efficient messages >>due to >> high volume. >> >> >> >> This is what I personally (speaking as myself) think of when I think of >>a >> Sighting. A description of an Observable Instance with some basic extra >> context. >> >> >> >> - Organizational Sighting Reports – As an example, consider >>what is >> needed when an organization reports back to an ISAC/ISAO that an >>indicator >> has been matched (or sighted). >> >> >> >> To me this is no different to the first case. If an Indicator has been >> matched then a new Sighting object will be created under the namespace >>of >> the Organization. The Organization will then share that Sighting object >>back >> to the ISAC/ISAO (if the Org wants to) along with a Relationship object >> (also under the namespace of the Org) that maps the ISAC Indicator to >>the >> Org’s Sighting Object. This can potentially be accompanied with an >>Incident >> object or Report object to give extra context if required. >> >> >> >> - Aggregate Sightings Analysis – Consider the information >>structure >> that is needed to enable effective analysis of aggregate data from both >>of >> the above examples. >> >> >> >> In my personal opinion it is up to consumers to use the collected data >>to >> make their own decisions. Every Organization has their own institutional >> idea of trust. They alone know which sources of information make sense >>for >> them, their management’s risk appetite, the verticals they operate in >>and so >> forth. The analysis that one Organization performs to come to the >>conclusion >> of ‘High’ risk may actually be a ‘Low’ risk in another organization. >>Each >> Org must be ultimately responsible for its own analysis. >> >> >> >> But, that’s not to say that they can’t outsource that function to other >> organizations. Dedicated third-parties specializing in analyzing >>Sightings >> to extract TTPs and match those to Campaigns and Actors will become more >> prevalent. These third-party analysis services will provide analysis >> customized to the Organization’s structure/vertical/risk appetite which >>will >> help them extract the ‘why and ‘how’ from the ‘what’. >> >> >> >> I believe that the separate top-level Sighting object will provide us >>with >> the basic structure to begin the higher level analysis. I believe that >>this >> will then help third-parties to generate more ‘upper-level’ STIX data – >> Threat Actors, Campaigns and higher-order TTP in particular. >> >> >> >> 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 Baker, Jon >> Sent: Saturday, 24 October 2015 2:10 AM >> To: Jonathan Bush (DTCC) <jbush@dtcc.com>; 'Jordan, Bret' >> <bret.jordan@bluecoat.com>; Cory Casanave <cory-c@modeldriven.com> >> Cc: cti-stix@lists.oasis-open.org >> Subject: RE: [cti-stix] Conceptul model for sighting >> >> >> >> The sightings conversation has historically suffered from a lack of >>shared >> understand of the sightings use cases and an attempt to address all the >> related sightings use cases with one complex model that does not really >> satisfy any single use case very well. I guess I am a fan of a bottom up >> approach focused on the use cases that are seen in the wild today. >> >> >> >> At a high-level I think that we can talk about sightings in several >>ways: >> >> There are probably others perspectives on sightings to consider as >>well. My >> recommendation is that we clearly state (use case) each of the >>different >> kinds of sightings and that we independently flesh out the information >> requirements. >> >> >> >> At the same time we need to consider what is done today in each of these >> cases and what we think needs to be done in the future. I would like us >>to >> focus on developing a model for sightings that satisfies today’s needs >>and >> allows for expansion to what we think the future state should be. When >>it >> comes to sightings we simply don’t have enough experience to know what >>is >> really needed beyond supporting what people already do today. >> >> >> >> Thanks, >> >> >> >> Jon >> >> >> >> ============================================ >> >> Jonathan O. Baker >> >> J83D - Cyber Security Partnerships, Sharing, and Automation >> >> The MITRE Corporation >> >> Email: bakerj@mitre.org >> >> >> >> From:cti-stix@lists.oasis-open.org >>[ mailto:cti-stix@lists.oasis-open.org ] On >> Behalf Of Bush, Jonathan >> Sent: Thursday, October 22, 2015 8:48 AM >> To: 'Jordan, Bret' <bret.jordan@bluecoat.com>; Cory Casanave >> <cory-c@modeldriven.com> >> Cc: cti-stix@lists.oasis-open.org >> Subject: RE: [cti-stix] Conceptul model for sighting >> >> >> >> I definitely like the “state the use case first” approach here. We >>can’t >> implement a data design until we know what we plan on doing with it. >> >> >> >> On the simplicity suggestion – YES!! Simple, simple, simple. We can >>always >> add fields later. Let’s just get this implemented, baked into our >>products, >> and then we can see what we are missing. >> >> >> >> On the data structure – Seems to me that the big decision on this is >>whether >> or not we have a sighting object or EACH sighting (meaning, it >>references >> something and adds context like who saw it, date, etc…) or have a >>combined >> object that carries a count. The former will offer more flexibility, >>but >> will mean more object instances. The later is really just a summary of >>the >> former, which will be much smaller from a db size perspective, but we >>won’t >> be able to identify individual characteristics of each sighting >>instance. >> >> >> >> Personally, I favor flexibility. We can solve the size issue with >>technical >> implementation. >> >> >> >> From:cti-stix@lists.oasis-open.org >>[ mailto:cti-stix@lists.oasis-open.org ] On >> Behalf Of Jordan, Bret >> Sent: Wednesday, October 21, 2015 5:42 PM >> To: Cory Casanave >> Cc: cti-stix@lists.oasis-open.org >> Subject: Re: [cti-stix] Conceptul model for sighting >> >> >> >> I think a better place to start is how people or devices are going to >> interact with an IOC-Indicator. >> >> >> >> 1) Human: I am going to see a list of IOCs in my work bench tool and >>have >> the ability to query that list for certain things as I do stuff. >>Perhaps as >> I start documenting an issue I am seeing in my network it could show a >>list >> of potential IOCs that match it. I could then: >> >> a) click a button that says "share a sighting" or >> >> b) the software could be configured to emit a sighting every >> time the IOC (think URL, IP address, Hash, filename, etc) is referenced >>in a >> report. >> >> >> >> 2) Device: A network device / security tool might be watching the >>network >> and either looking for IOCs based on a feed it gets from somewhere or it >> might find bad stuff on its own and generate an IOC then query the repo >>to >> see if the IOC is already known. In either case, the device could emit >>a >> sighting. >> >> >> >> While I appreciate the desire to cover every esoteric corner case that >>might >> ever come up, I think we should take a minimalistic approach to the >>first >> generation of the Sighting object.. It is always easy to add stuff, >>but it >> is really hard to take it away. >> >> >> >> I would argue that the bare minimum we need is: >> >> >> >> 1) Reference to what it is we are sighting >> >> 2) The person / organization that is making the sighting >> >> 3) A count of the number of times it was seen. >> >> >> >> Now yes, there is a LOT more things that COULD be added, and all of them >> could be added over time. For example (yes this will rub people the >>wrong >> way), data markings. I would personally leave them out for now. I >>would >> love if we could get to the point where we had to rev the sightings >>object >> spec to support data markings or something else because we had so many >> people using it and begging for the feature. >> >> >> >> By taking the minimalistic approach we can more quicker and get people >>using >> it. >> >> >> >> Think: >> >> >> >> { >> >> "type": "sighting", >> >> "id": "foo.com:sighting-1234-1234-1234-1234", >> >> "idref": "abc.com:indicator-4321-4321-4321-4321", >> >> "count": "1222" >> >> "producer": "tom and jerry" >> >> } >> >> >> >> >> >> >> >> 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 21, 2015, at 15:17, Cory Casanave <cory-c@modeldriven.com> wrote: >> >> >> >> In the meeting today “sighting” was discussed. Below is the sighting >> component of a conceptual model we are developing for threats and risks. >> Note that this is a level more general than STIX (the model is being >>mapped >> to STIX), but perhaps we can share some ideas. >> >> Regards, >> Cory Casanave >> >> >> >> <image003.jpg> >> >> >> >> >> DTCC DISCLAIMER: This email and any files transmitted with it are >> confidential and intended solely for the use of the individual or >>entity to >> whom they are addressed. If you have received this email in error, >>please >> notify us immediately and delete the email and any attachments from your >> system. The recipient should check this email and any attachments for >>the >> presence of viruses. The company accepts no liability for any damage >>caused >> by any virus transmitted by this email. >> >> >> ... >> >> This message and attachments may contain confidential information. If it >> appears that this message was sent to you by mistake, any retention, >> dissemination, distribution or copying of this message and attachments >>is >> strictly prohibited. Please notify the sender immediately and >>permanently >> delete the message and any attachments. >> . . . > >... This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. . . .

Thanks for the error report, Sarah. Trey and I will take a look and see if we can track it down. Regards, Ivan On 10/27/15, 10:53 AM, "cti-stix@lists.oasis-open.org on behalf of Sarah Kelley" <cti-stix@lists.oasis-open.org on behalf of Sarah.Kelley@cisecurity.org> wrote: >@Jerome - we did attempt to run the statistics tool (three times). We’re >running Soltra Edge, and we’re getting an error. > >Below is the error and the command my team used (with password and user >and host >changed). We followed the install instructions on git hub. > >./cti-stats —user=noone --pass=‘password' —host=soltra --port=80 >--use-ssl=False --validate-cert=False --taxii-stats >Traceback (most recent call last): > File "./cti-stats", line 69, in <module> > main() > File "./cti-stats", line 63, in main > args['--use-ssl'], args['--validate-cert']) > File "/home/dwallmeyer/soltra_edge/cti-stats/lib/cti.py", line 115, in >taxii_poll > process_stix_pkg(stix_package) > File "/home/dwallmeyer/soltra_edge/cti-stats/lib/cti.py", line 74, in >process_stix_pkg > obs_type = >str(type(i.object_.properties)).split('.')[-1:][0].split("'")[0] >AttributeError: 'NoneType' object has no attribute ‘properties' > > >Can anyone help troubleshoot? > >Sarah Kelley >Senior CERT Analyst >Center for Internet Security (CIS) >Integrated Intelligence Center (IIC) >Multi-State Information Sharing and Analysis Center (MS-ISAC) >1-866-787-4722 (7×24 SOC) >Email: cert@cisecurity.org >www.cisecurity.org >Follow us @CISecurity > > > > > > >On 10/27/15, 10:26 AM, "Jerome Athias" <athiasjerome@gmail.com> wrote: > >>I think we're doing well. >>I think the location and detection-method could be optional (in an >>effort of keeping things as simple as possible) >> >><source> observed <x> instances of <object>, <time-range> (via >><detection-method>) (at <location>) (with <confidence>) (...) >> >> >>After let's say two weeks of open discussions in the list, we could >>update the github and ask the TC Chairs to present the current >>conclusion/proposition during the next meeting. Then submitting it for >>an open request for comments for a period of, let's say 1 month before >>potential definitive agreement/validation >> >>@Sarah: regarding the relationships 'issue', there's an open >>discussion going on to know if we make it as a construct. I will just >>add, for now, that if you can't find a 'workaround', that I assume >>right now being finding the -relationship path- between top level >>object A and the underlying object B, this should be highlighted >> >>@Sarah (and all): did you run the statistics tool? :-) >> >> >> >>2015-10-27 14:56 GMT+03:00 Davidson II, Mark S <mdavidson@mitre.org>: >>> I’m feeling like the possible use cases mentioned so far might be >>> condensable into the following sentence structure: >>> >>> >>> >>> “<source> observed <x> instances of <object> at <location>, >>><time-range>, >>> via <detection-method>” >>> >>> >>> >>> This has decent (but not complete) overlap with Terry’s proposed >>>fields, so >>> maybe it means we are on the right track? >>> >>> >>> >>> As a side note, do we know how we are we capturing the outcome of this >>> discussion? In the TAXII SC, we’ve been keeping a “Decisions” list [1], >>>with >>> links out to more detail as necessary. (Note that decisions does not >>>mean >>> that everything in there is set in stone – it just means the TAXII SC >>>has >>> general agreement on the principle. For e.g., the REST API, there’s >>>still >>> plenty to work on). Once we get most people agreeing on most things for >>>a >>> particular discussion, we could document them in a similar fashion and >>>keep >>> track of the open items; e.g., if we can’t agree on <Some-Field>, let’s >>>mark >>> it as an open question and move on to another topic. >>> >>> >>> >>> Thank you. >>> >>> -Mark >>> >>> >>> >>> [1] http://taxiiproject.github.io/taxii2/#decisions >>> >>> >>> >>> From: cti-stix@lists.oasis-open.org >>>[ mailto:cti-stix@lists.oasis-open.org ] >>> On Behalf Of Sarah Kelley >>> Sent: Tuesday, October 27, 2015 7:18 AM >>> To: Unknown Unknown <athiasjerome@gmail.com>; Jordan, Bret >>> <bret.jordan@bluecoat.com> >>> Cc: Terry MacDonald <terry@soltra.com>; Baker, Jon <bakerj@mitre.org>; >>> Jonathan Bush (DTCC) <jbush@dtcc.com>; Cory Casanave >>> <cory-c@modeldriven.com>; cti-stix@lists.oasis-open.org >>> >>> >>> Subject: Re: [cti-stix] Conceptul model for sighting >>> >>> >>> >>> I am a huge proponent of letting (almost) anything link to anything. In >>> fact, limiting what can have an association/link/relationship with what >>>is >>> my current biggest frustration with Stix (we use workarounds to get >>>around >>> this limitation). >>> >>> >>> >>> I would add the possible use cases: >>> >>> >>> >>> My org observed 3 instances of this threat actor hitting our network >>> >>> My org observed 12 instances of the Poison Ivy TTP on our network >>> >>> Or even (though weaker): >>> >>> My org was hit by this particular campaign 27 times >>> >>> >>> >>> >>> >>> >>> >>> Sarah Kelley >>> >>> Senior CERT Analyst >>> >>> Center for Internet Security (CIS) >>> >>> Integrated Intelligence Center (IIC) >>> >>> Multi-State Information Sharing and Analysis Center (MS-ISAC) >>> >>> 1-866-787-4722 (7×24 SOC) >>> >>> Email: cert@cisecurity.org >>> >>> www.cisecurity.org >>> >>> Follow us @CISecurity >>> >>> >>> >>> >>> >>> From: <cti-stix@lists.oasis-open.org> on behalf of Jerome Athias >>> <athiasjerome@gmail.com> >>> Date: Monday, October 26, 2015 at 10:29 PM >>> To: "Jordan, Bret" <bret.jordan@bluecoat.com> >>> Cc: Terry MacDonald <terry@soltra.com>, "Baker, Jon" <bakerj@mitre.org>, >>> "Jonathan Bush (DTCC)" <jbush@dtcc.com>, Cory Casanave >>> <cory-c@modeldriven.com>, "cti-stix@lists.oasis-open.org" >>> <cti-stix@lists.oasis-open.org> >>> Subject: Re: [cti-stix] Conceptul model for sighting >>> >>> >>> >>> I do agree with Terry and Bret last emails and find the thread >>>constructive >>> >>> >>> >>> Some use cases for bottom up (without full context for now): >>> >>> >>> >>> My org observed 12 instances of this malware artifact today (after AV >>> signatures update) >>> >>> My org observed 100000 hits from this ip address in the last hours (all >>> against ssh) >>> >>> My org observed 5000 times this excel file with macro (coming in >>>emails) in >>> the last 10 minutes >>> >>> My org observed 1 hit of exploitation of this new ssl vuln CVE-2015-007 >>> (against our VPN portal) this week-end >>> >>> My org observed 3 binaires signed with this stolen certificate this >>>month >>> >>> >>> >>> >>> On Tuesday, 27 October 2015, Jordan, Bret <bret.jordan@bluecoat.com> >>>wrote: >>> >>> In terms of volume, I see the Sighting object dwarfing all others, >>>probably >>> by several orders of magnitude. Following the sighting object I see the >>> relationship object being the next largest consumer of TAXII volume. I >>>also >>> see the Sighting object along with the relationship object and its >>> assertions working in a very social side of threat analysis and >>>discovery, >>> where a lot of back and forth takes place. >>> >>> >>> >>> Another option I can see is the Sighting object as being a seed for >>> additional exploration or automated data enrichment. >>> >>> >>> >>> So let's make sure we get this and the relationship object figured out >>>and >>> done well. >>> >>> >>> >>> Bret >>> >>> Sent from my Commodore 64 >>> >>> >>> On Oct 26, 2015, at 1:45 PM, Terry MacDonald <terry@soltra.com> wrote: >>> >>> Hi Jon >>> >>> >>> >>> >>> >>> >>> >>> - Sensor Alerts – As an example, an IDS or other sensor >>>reports a >>> match on some indicator. You will likely have some contextual >>>information >>> like times, ip addresses, host names, what indictor was matched, what >>>was >>> really seen, which IDS or sensor reported the alert, etc.. You probably >>> don’t care about data markings, aggregate sighting information, and >>>other >>> fields. You probably do care about having compact efficient messages >>>due to >>> high volume. >>> >>> >>> >>> This is what I personally (speaking as myself) think of when I think of >>>a >>> Sighting. A description of an Observable Instance with some basic extra >>> context. >>> >>> >>> >>> - Organizational Sighting Reports – As an example, consider >>>what is >>> needed when an organization reports back to an ISAC/ISAO that an >>>indicator >>> has been matched (or sighted). >>> >>> >>> >>> To me this is no different to the first case. If an Indicator has been >>> matched then a new Sighting object will be created under the namespace >>>of >>> the Organization. The Organization will then share that Sighting object >>>back >>> to the ISAC/ISAO (if the Org wants to) along with a Relationship object >>> (also under the namespace of the Org) that maps the ISAC Indicator to >>>the >>> Org’s Sighting Object. This can potentially be accompanied with an >>>Incident >>> object or Report object to give extra context if required. >>> >>> >>> >>> - Aggregate Sightings Analysis – Consider the information >>>structure >>> that is needed to enable effective analysis of aggregate data from both >>>of >>> the above examples. >>> >>> >>> >>> In my personal opinion it is up to consumers to use the collected data >>>to >>> make their own decisions. Every Organization has their own institutional >>> idea of trust. They alone know which sources of information make sense >>>for >>> them, their management’s risk appetite, the verticals they operate in >>>and so >>> forth. The analysis that one Organization performs to come to the >>>conclusion >>> of ‘High’ risk may actually be a ‘Low’ risk in another organization. >>>Each >>> Org must be ultimately responsible for its own analysis. >>> >>> >>> >>> But, that’s not to say that they can’t outsource that function to other >>> organizations. Dedicated third-parties specializing in analyzing >>>Sightings >>> to extract TTPs and match those to Campaigns and Actors will become more >>> prevalent. These third-party analysis services will provide analysis >>> customized to the Organization’s structure/vertical/risk appetite which >>>will >>> help them extract the ‘why and ‘how’ from the ‘what’. >>> >>> >>> >>> I believe that the separate top-level Sighting object will provide us >>>with >>> the basic structure to begin the higher level analysis. I believe that >>>this >>> will then help third-parties to generate more ‘upper-level’ STIX data – >>> Threat Actors, Campaigns and higher-order TTP in particular. >>> >>> >>> >>> 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 Baker, Jon >>> Sent: Saturday, 24 October 2015 2:10 AM >>> To: Jonathan Bush (DTCC) <jbush@dtcc.com>; 'Jordan, Bret' >>> <bret.jordan@bluecoat.com>; Cory Casanave <cory-c@modeldriven.com> >>> Cc: cti-stix@lists.oasis-open.org >>> Subject: RE: [cti-stix] Conceptul model for sighting >>> >>> >>> >>> The sightings conversation has historically suffered from a lack of >>>shared >>> understand of the sightings use cases and an attempt to address all the >>> related sightings use cases with one complex model that does not really >>> satisfy any single use case very well. I guess I am a fan of a bottom up >>> approach focused on the use cases that are seen in the wild today. >>> >>> >>> >>> At a high-level I think that we can talk about sightings in several >>>ways: >>> >>> There are probably others perspectives on sightings to consider as >>>well. My >>> recommendation is that we clearly state (use case) each of the >>>different >>> kinds of sightings and that we independently flesh out the information >>> requirements. >>> >>> >>> >>> At the same time we need to consider what is done today in each of these >>> cases and what we think needs to be done in the future. I would like us >>>to >>> focus on developing a model for sightings that satisfies today’s needs >>>and >>> allows for expansion to what we think the future state should be. When >>>it >>> comes to sightings we simply don’t have enough experience to know what >>>is >>> really needed beyond supporting what people already do today. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Jon >>> >>> >>> >>> ============================================ >>> >>> Jonathan O. Baker >>> >>> J83D - Cyber Security Partnerships, Sharing, and Automation >>> >>> The MITRE Corporation >>> >>> Email: bakerj@mitre.org >>> >>> >>> >>> From:cti-stix@lists.oasis-open.org >>>[ mailto:cti-stix@lists.oasis-open.org ] On >>> Behalf Of Bush, Jonathan >>> Sent: Thursday, October 22, 2015 8:48 AM >>> To: 'Jordan, Bret' <bret.jordan@bluecoat.com>; Cory Casanave >>> <cory-c@modeldriven.com> >>> Cc: cti-stix@lists.oasis-open.org >>> Subject: RE: [cti-stix] Conceptul model for sighting >>> >>> >>> >>> I definitely like the “state the use case first” approach here. We >>>can’t >>> implement a data design until we know what we plan on doing with it. >>> >>> >>> >>> On the simplicity suggestion – YES!! Simple, simple, simple. We can >>>always >>> add fields later. Let’s just get this implemented, baked into our >>>products, >>> and then we can see what we are missing. >>> >>> >>> >>> On the data structure – Seems to me that the big decision on this is >>>whether >>> or not we have a sighting object or EACH sighting (meaning, it >>>references >>> something and adds context like who saw it, date, etc…) or have a >>>combined >>> object that carries a count. The former will offer more flexibility, >>>but >>> will mean more object instances. The later is really just a summary of >>>the >>> former, which will be much smaller from a db size perspective, but we >>>won’t >>> be able to identify individual characteristics of each sighting >>>instance. >>> >>> >>> >>> Personally, I favor flexibility. We can solve the size issue with >>>technical >>> implementation. >>> >>> >>> >>> From:cti-stix@lists.oasis-open.org >>>[ mailto:cti-stix@lists.oasis-open.org ] On >>> Behalf Of Jordan, Bret >>> Sent: Wednesday, October 21, 2015 5:42 PM >>> To: Cory Casanave >>> Cc: cti-stix@lists.oasis-open.org >>> Subject: Re: [cti-stix] Conceptul model for sighting >>> >>> >>> >>> I think a better place to start is how people or devices are going to >>> interact with an IOC-Indicator. >>> >>> >>> >>> 1) Human: I am going to see a list of IOCs in my work bench tool and >>>have >>> the ability to query that list for certain things as I do stuff. >>>Perhaps as >>> I start documenting an issue I am seeing in my network it could show a >>>list >>> of potential IOCs that match it. I could then: >>> >>> a) click a button that says "share a sighting" or >>> >>> b) the software could be configured to emit a sighting every >>> time the IOC (think URL, IP address, Hash, filename, etc) is referenced >>>in a >>> report. >>> >>> >>> >>> 2) Device: A network device / security tool might be watching the >>>network >>> and either looking for IOCs based on a feed it gets from somewhere or it >>> might find bad stuff on its own and generate an IOC then query the repo >>>to >>> see if the IOC is already known. In either case, the device could emit >>>a >>> sighting. >>> >>> >>> >>> While I appreciate the desire to cover every esoteric corner case that >>>might >>> ever come up, I think we should take a minimalistic approach to the >>>first >>> generation of the Sighting object.. It is always easy to add stuff, >>>but it >>> is really hard to take it away. >>> >>> >>> >>> I would argue that the bare minimum we need is: >>> >>> >>> >>> 1) Reference to what it is we are sighting >>> >>> 2) The person / organization that is making the sighting >>> >>> 3) A count of the number of times it was seen. >>> >>> >>> >>> Now yes, there is a LOT more things that COULD be added, and all of them >>> could be added over time. For example (yes this will rub people the >>>wrong >>> way), data markings. I would personally leave them out for now. I >>>would >>> love if we could get to the point where we had to rev the sightings >>>object >>> spec to support data markings or something else because we had so many >>> people using it and begging for the feature. >>> >>> >>> >>> By taking the minimalistic approach we can more quicker and get people >>>using >>> it. >>> >>> >>> >>> Think: >>> >>> >>> >>> { >>> >>> "type": "sighting", >>> >>> "id": "foo.com:sighting-1234-1234-1234-1234", >>> >>> "idref": "abc.com:indicator-4321-4321-4321-4321", >>> >>> "count": "1222" >>> >>> "producer": "tom and jerry" >>> >>> } >>> >>> >>> >>> >>> >>> >>> >>> 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 21, 2015, at 15:17, Cory Casanave <cory-c@modeldriven.com> wrote: >>> >>> >>> >>> In the meeting today “sighting” was discussed. Below is the sighting >>> component of a conceptual model we are developing for threats and risks. >>> Note that this is a level more general than STIX (the model is being >>>mapped >>> to STIX), but perhaps we can share some ideas. >>> >>> Regards, >>> Cory Casanave >>> >>> >>> >>> <image003.jpg> >>> >>> >>> >>> >>> DTCC DISCLAIMER: This email and any files transmitted with it are >>> confidential and intended solely for the use of the individual or >>>entity to >>> whom they are addressed. If you have received this email in error, >>>please >>> notify us immediately and delete the email and any attachments from your >>> system. The recipient should check this email and any attachments for >>>the >>> presence of viruses. The company accepts no liability for any damage >>>caused >>> by any virus transmitted by this email. >>> >>> >>> ... >>> >>> This message and attachments may contain confidential information. If it >>> appears that this message was sent to you by mistake, any retention, >>> dissemination, distribution or copying of this message and attachments >>>is >>> strictly prohibited. Please notify the sender immediately and >>>permanently >>> delete the message and any attachments. >>> . . . >> >>... > >This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. > >. . .

I hope this is just a copy and paste issue, where the computer software tries to be smart, but make sure the user and host values are a double dash "--host" not "—host" Bret Sent from my Commodore 64 > On Oct 27, 2015, at 7:53 AM, Sarah Kelley <Sarah.Kelley@cisecurity.org> wrote: > > @Jerome - we did attempt to run the statistics tool (three times). We’re > running Soltra Edge, and we’re getting an error. > > Below is the error and the command my team used (with password and user > and host > changed). We followed the install instructions on git hub. > > ./cti-stats —user=noone --pass=‘password' —host=soltra --port=80 > --use-ssl=False --validate-cert=False --taxii-stats > Traceback (most recent call last): > File "./cti-stats", line 69, in <module> > main() > File "./cti-stats", line 63, in main > args['--use-ssl'], args['--validate-cert']) > File "/home/dwallmeyer/soltra_edge/cti-stats/lib/cti.py", line 115, in > taxii_poll > process_stix_pkg(stix_package) > File "/home/dwallmeyer/soltra_edge/cti-stats/lib/cti.py", line 74, in > process_stix_pkg > obs_type = > str(type(i.object_.properties)).split('.')[-1:][0].split("'")[0] > AttributeError: 'NoneType' object has no attribute ‘properties' > > > Can anyone help troubleshoot? > > Sarah Kelley > Senior CERT Analyst > Center for Internet Security (CIS) > Integrated Intelligence Center (IIC) > Multi-State Information Sharing and Analysis Center (MS-ISAC) > 1-866-787-4722 (7×24 SOC) > Email: cert@cisecurity.org > www.cisecurity.org > Follow us @CISecurity > > > > > > >> On 10/27/15, 10:26 AM, "Jerome Athias" <athiasjerome@gmail.com> wrote: >> >> I think we're doing well. >> I think the location and detection-method could be optional (in an >> effort of keeping things as simple as possible) >> >> <source> observed <x> instances of <object>, <time-range> (via >> <detection-method>) (at <location>) (with <confidence>) (...) >> >> >> After let's say two weeks of open discussions in the list, we could >> update the github and ask the TC Chairs to present the current >> conclusion/proposition during the next meeting. Then submitting it for >> an open request for comments for a period of, let's say 1 month before >> potential definitive agreement/validation >> >> @Sarah: regarding the relationships 'issue', there's an open >> discussion going on to know if we make it as a construct. I will just >> add, for now, that if you can't find a 'workaround', that I assume >> right now being finding the -relationship path- between top level >> object A and the underlying object B, this should be highlighted >> >> @Sarah (and all): did you run the statistics tool? :-) >> >> >> >> 2015-10-27 14:56 GMT+03:00 Davidson II, Mark S <mdavidson@mitre.org>: >>> I’m feeling like the possible use cases mentioned so far might be >>> condensable into the following sentence structure: >>> >>> >>> >>> “<source> observed <x> instances of <object> at <location>, >>> <time-range>, >>> via <detection-method>” >>> >>> >>> >>> This has decent (but not complete) overlap with Terry’s proposed >>> fields, so >>> maybe it means we are on the right track? >>> >>> >>> >>> As a side note, do we know how we are we capturing the outcome of this >>> discussion? In the TAXII SC, we’ve been keeping a “Decisions” list [1], >>> with >>> links out to more detail as necessary. (Note that decisions does not >>> mean >>> that everything in there is set in stone – it just means the TAXII SC >>> has >>> general agreement on the principle. For e.g., the REST API, there’s >>> still >>> plenty to work on). Once we get most people agreeing on most things for >>> a >>> particular discussion, we could document them in a similar fashion and >>> keep >>> track of the open items; e.g., if we can’t agree on <Some-Field>, let’s >>> mark >>> it as an open question and move on to another topic. >>> >>> >>> >>> Thank you. >>> >>> -Mark >>> >>> >>> >>> [1] http://taxiiproject.github.io/taxii2/#decisions >>> >>> >>> >>> From: cti-stix@lists.oasis-open.org >>> [ mailto:cti-stix@lists.oasis-open.org ] >>> On Behalf Of Sarah Kelley >>> Sent: Tuesday, October 27, 2015 7:18 AM >>> To: Unknown Unknown <athiasjerome@gmail.com>; Jordan, Bret >>> <bret.jordan@bluecoat.com> >>> Cc: Terry MacDonald <terry@soltra.com>; Baker, Jon <bakerj@mitre.org>; >>> Jonathan Bush (DTCC) <jbush@dtcc.com>; Cory Casanave >>> <cory-c@modeldriven.com>; cti-stix@lists.oasis-open.org >>> >>> >>> Subject: Re: [cti-stix] Conceptul model for sighting >>> >>> >>> >>> I am a huge proponent of letting (almost) anything link to anything. In >>> fact, limiting what can have an association/link/relationship with what >>> is >>> my current biggest frustration with Stix (we use workarounds to get >>> around >>> this limitation). >>> >>> >>> >>> I would add the possible use cases: >>> >>> >>> >>> My org observed 3 instances of this threat actor hitting our network >>> >>> My org observed 12 instances of the Poison Ivy TTP on our network >>> >>> Or even (though weaker): >>> >>> My org was hit by this particular campaign 27 times >>> >>> >>> >>> >>> >>> >>> >>> Sarah Kelley >>> >>> Senior CERT Analyst >>> >>> Center for Internet Security (CIS) >>> >>> Integrated Intelligence Center (IIC) >>> >>> Multi-State Information Sharing and Analysis Center (MS-ISAC) >>> >>> 1-866-787-4722 (7×24 SOC) >>> >>> Email: cert@cisecurity.org >>> >>> www.cisecurity.org >>> >>> Follow us @CISecurity >>> >>> >>> >>> >>> >>> From: <cti-stix@lists.oasis-open.org> on behalf of Jerome Athias >>> <athiasjerome@gmail.com> >>> Date: Monday, October 26, 2015 at 10:29 PM >>> To: "Jordan, Bret" <bret.jordan@bluecoat.com> >>> Cc: Terry MacDonald <terry@soltra.com>, "Baker, Jon" <bakerj@mitre.org>, >>> "Jonathan Bush (DTCC)" <jbush@dtcc.com>, Cory Casanave >>> <cory-c@modeldriven.com>, "cti-stix@lists.oasis-open.org" >>> <cti-stix@lists.oasis-open.org> >>> Subject: Re: [cti-stix] Conceptul model for sighting >>> >>> >>> >>> I do agree with Terry and Bret last emails and find the thread >>> constructive >>> >>> >>> >>> Some use cases for bottom up (without full context for now): >>> >>> >>> >>> My org observed 12 instances of this malware artifact today (after AV >>> signatures update) >>> >>> My org observed 100000 hits from this ip address in the last hours (all >>> against ssh) >>> >>> My org observed 5000 times this excel file with macro (coming in >>> emails) in >>> the last 10 minutes >>> >>> My org observed 1 hit of exploitation of this new ssl vuln CVE-2015-007 >>> (against our VPN portal) this week-end >>> >>> My org observed 3 binaires signed with this stolen certificate this >>> month >>> >>> >>> >>> >>> On Tuesday, 27 October 2015, Jordan, Bret <bret.jordan@bluecoat.com> >>> wrote: >>> >>> In terms of volume, I see the Sighting object dwarfing all others, >>> probably >>> by several orders of magnitude. Following the sighting object I see the >>> relationship object being the next largest consumer of TAXII volume. I >>> also >>> see the Sighting object along with the relationship object and its >>> assertions working in a very social side of threat analysis and >>> discovery, >>> where a lot of back and forth takes place. >>> >>> >>> >>> Another option I can see is the Sighting object as being a seed for >>> additional exploration or automated data enrichment. >>> >>> >>> >>> So let's make sure we get this and the relationship object figured out >>> and >>> done well. >>> >>> >>> >>> Bret >>> >>> Sent from my Commodore 64 >>> >>> >>> On Oct 26, 2015, at 1:45 PM, Terry MacDonald <terry@soltra.com> wrote: >>> >>> Hi Jon >>> >>> >>> >>> >>> >>> >>> >>> - Sensor Alerts – As an example, an IDS or other sensor >>> reports a >>> match on some indicator. You will likely have some contextual >>> information >>> like times, ip addresses, host names, what indictor was matched, what >>> was >>> really seen, which IDS or sensor reported the alert, etc.. You probably >>> don’t care about data markings, aggregate sighting information, and >>> other >>> fields. You probably do care about having compact efficient messages >>> due to >>> high volume. >>> >>> >>> >>> This is what I personally (speaking as myself) think of when I think of >>> a >>> Sighting. A description of an Observable Instance with some basic extra >>> context. >>> >>> >>> >>> - Organizational Sighting Reports – As an example, consider >>> what is >>> needed when an organization reports back to an ISAC/ISAO that an >>> indicator >>> has been matched (or sighted). >>> >>> >>> >>> To me this is no different to the first case. If an Indicator has been >>> matched then a new Sighting object will be created under the namespace >>> of >>> the Organization. The Organization will then share that Sighting object >>> back >>> to the ISAC/ISAO (if the Org wants to) along with a Relationship object >>> (also under the namespace of the Org) that maps the ISAC Indicator to >>> the >>> Org’s Sighting Object. This can potentially be accompanied with an >>> Incident >>> object or Report object to give extra context if required. >>> >>> >>> >>> - Aggregate Sightings Analysis – Consider the information >>> structure >>> that is needed to enable effective analysis of aggregate data from both >>> of >>> the above examples. >>> >>> >>> >>> In my personal opinion it is up to consumers to use the collected data >>> to >>> make their own decisions. Every Organization has their own institutional >>> idea of trust. They alone know which sources of information make sense >>> for >>> them, their management’s risk appetite, the verticals they operate in >>> and so >>> forth. The analysis that one Organization performs to come to the >>> conclusion >>> of ‘High’ risk may actually be a ‘Low’ risk in another organization. >>> Each >>> Org must be ultimately responsible for its own analysis. >>> >>> >>> >>> But, that’s not to say that they can’t outsource that function to other >>> organizations. Dedicated third-parties specializing in analyzing >>> Sightings >>> to extract TTPs and match those to Campaigns and Actors will become more >>> prevalent. These third-party analysis services will provide analysis >>> customized to the Organization’s structure/vertical/risk appetite which >>> will >>> help them extract the ‘why and ‘how’ from the ‘what’. >>> >>> >>> >>> I believe that the separate top-level Sighting object will provide us >>> with >>> the basic structure to begin the higher level analysis. I believe that >>> this >>> will then help third-parties to generate more ‘upper-level’ STIX data – >>> Threat Actors, Campaigns and higher-order TTP in particular. >>> >>> >>> >>> 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 Baker, Jon >>> Sent: Saturday, 24 October 2015 2:10 AM >>> To: Jonathan Bush (DTCC) <jbush@dtcc.com>; 'Jordan, Bret' >>> <bret.jordan@bluecoat.com>; Cory Casanave <cory-c@modeldriven.com> >>> Cc: cti-stix@lists.oasis-open.org >>> Subject: RE: [cti-stix] Conceptul model for sighting >>> >>> >>> >>> The sightings conversation has historically suffered from a lack of >>> shared >>> understand of the sightings use cases and an attempt to address all the >>> related sightings use cases with one complex model that does not really >>> satisfy any single use case very well. I guess I am a fan of a bottom up >>> approach focused on the use cases that are seen in the wild today. >>> >>> >>> >>> At a high-level I think that we can talk about sightings in several >>> ways: >>> >>> There are probably others perspectives on sightings to consider as >>> well. My >>> recommendation is that we clearly state (use case) each of the >>> different >>> kinds of sightings and that we independently flesh out the information >>> requirements. >>> >>> >>> >>> At the same time we need to consider what is done today in each of these >>> cases and what we think needs to be done in the future. I would like us >>> to >>> focus on developing a model for sightings that satisfies today’s needs >>> and >>> allows for expansion to what we think the future state should be. When >>> it >>> comes to sightings we simply don’t have enough experience to know what >>> is >>> really needed beyond supporting what people already do today. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Jon >>> >>> >>> >>> ============================================ >>> >>> Jonathan O. Baker >>> >>> J83D - Cyber Security Partnerships, Sharing, and Automation >>> >>> The MITRE Corporation >>> >>> Email: bakerj@mitre.org >>> >>> >>> >>> From:cti-stix@lists.oasis-open.org >>> [ mailto:cti-stix@lists.oasis-open.org ] On >>> Behalf Of Bush, Jonathan >>> Sent: Thursday, October 22, 2015 8:48 AM >>> To: 'Jordan, Bret' <bret.jordan@bluecoat.com>; Cory Casanave >>> <cory-c@modeldriven.com> >>> Cc: cti-stix@lists.oasis-open.org >>> Subject: RE: [cti-stix] Conceptul model for sighting >>> >>> >>> >>> I definitely like the “state the use case first” approach here. We >>> can’t >>> implement a data design until we know what we plan on doing with it. >>> >>> >>> >>> On the simplicity suggestion – YES!! Simple, simple, simple. We can >>> always >>> add fields later. Let’s just get this implemented, baked into our >>> products, >>> and then we can see what we are missing. >>> >>> >>> >>> On the data structure – Seems to me that the big decision on this is >>> whether >>> or not we have a sighting object or EACH sighting (meaning, it >>> references >>> something and adds context like who saw it, date, etc…) or have a >>> combined >>> object that carries a count. The former will offer more flexibility, >>> but >>> will mean more object instances. The later is really just a summary of >>> the >>> former, which will be much smaller from a db size perspective, but we >>> won’t >>> be able to identify individual characteristics of each sighting >>> instance. >>> >>> >>> >>> Personally, I favor flexibility. We can solve the size issue with >>> technical >>> implementation. >>> >>> >>> >>> From:cti-stix@lists.oasis-open.org >>> [ mailto:cti-stix@lists.oasis-open.org ] On >>> Behalf Of Jordan, Bret >>> Sent: Wednesday, October 21, 2015 5:42 PM >>> To: Cory Casanave >>> Cc: cti-stix@lists.oasis-open.org >>> Subject: Re: [cti-stix] Conceptul model for sighting >>> >>> >>> >>> I think a better place to start is how people or devices are going to >>> interact with an IOC-Indicator. >>> >>> >>> >>> 1) Human: I am going to see a list of IOCs in my work bench tool and >>> have >>> the ability to query that list for certain things as I do stuff. >>> Perhaps as >>> I start documenting an issue I am seeing in my network it could show a >>> list >>> of potential IOCs that match it. I could then: >>> >>> a) click a button that says "share a sighting" or >>> >>> b) the software could be configured to emit a sighting every >>> time the IOC (think URL, IP address, Hash, filename, etc) is referenced >>> in a >>> report. >>> >>> >>> >>> 2) Device: A network device / security tool might be watching the >>> network >>> and either looking for IOCs based on a feed it gets from somewhere or it >>> might find bad stuff on its own and generate an IOC then query the repo >>> to >>> see if the IOC is already known. In either case, the device could emit >>> a >>> sighting. >>> >>> >>> >>> While I appreciate the desire to cover every esoteric corner case that >>> might >>> ever come up, I think we should take a minimalistic approach to the >>> first >>> generation of the Sighting object.. It is always easy to add stuff, >>> but it >>> is really hard to take it away. >>> >>> >>> >>> I would argue that the bare minimum we need is: >>> >>> >>> >>> 1) Reference to what it is we are sighting >>> >>> 2) The person / organization that is making the sighting >>> >>> 3) A count of the number of times it was seen. >>> >>> >>> >>> Now yes, there is a LOT more things that COULD be added, and all of them >>> could be added over time. For example (yes this will rub people the >>> wrong >>> way), data markings. I would personally leave them out for now. I >>> would >>> love if we could get to the point where we had to rev the sightings >>> object >>> spec to support data markings or something else because we had so many >>> people using it and begging for the feature. >>> >>> >>> >>> By taking the minimalistic approach we can more quicker and get people >>> using >>> it. >>> >>> >>> >>> Think: >>> >>> >>> >>> { >>> >>> "type": "sighting", >>> >>> "id": "foo.com:sighting-1234-1234-1234-1234", >>> >>> "idref": "abc.com:indicator-4321-4321-4321-4321", >>> >>> "count": "1222" >>> >>> "producer": "tom and jerry" >>> >>> } >>> >>> >>> >>> >>> >>> >>> >>> 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 21, 2015, at 15:17, Cory Casanave <cory-c@modeldriven.com> wrote: >>> >>> >>> >>> In the meeting today “sighting” was discussed. Below is the sighting >>> component of a conceptual model we are developing for threats and risks. >>> Note that this is a level more general than STIX (the model is being >>> mapped >>> to STIX), but perhaps we can share some ideas. >>> >>> Regards, >>> Cory Casanave >>> >>> >>> >>> <image003.jpg> >>> >>> >>> >>> >>> DTCC DISCLAIMER: This email and any files transmitted with it are >>> confidential and intended solely for the use of the individual or >>> entity to >>> whom they are addressed. If you have received this email in error, >>> please >>> notify us immediately and delete the email and any attachments from your >>> system. The recipient should check this email and any attachments for >>> the >>> presence of viruses. The company accepts no liability for any damage >>> caused >>> by any virus transmitted by this email. >>> >>> >>> ... >>> >>> This message and attachments may contain confidential information. If it >>> appears that this message was sent to you by mistake, any retention, >>> dissemination, distribution or copying of this message and attachments >>> is >>> strictly prohibited. Please notify the sender immediately and >>> permanently >>> delete the message and any attachments. >>> . . . >> >> ... > > This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments. > > . . .

On 27.10.2015 14:53:30, Sarah Kelley wrote: > @Jerome - we did attempt to run the statistics tool (three times). > We’re running Soltra Edge, and we’re getting an error. > Hey, y'all - I've already reached out to Sarah privately regarding the issue she encountered with cti-stats [0] but it's worth replying back to the list as well. When I initially released cti-stats, I knew there would be issues. Early guinea pigs^W^Wparticipants have provided valuable feedback, which has precipitated some rapid development. (In some ways, this is a great case study in CTI interoperability!) If you've tried running cti-stats and encountered issues, please: 0) Double-check that you're running the latest code (`git pull`). 1) If that doesn't fix it, please open an issue on the cti-stats issue-tracker [1] and I'll get to it ASAP. ***NOTE*** Pull-requests always welcome! ^_^ [0]: https://github.com/soltra/cti-stats [1]: https://github.com/soltra/cti-stats/issues -- 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 -- "Good, Fast, Cheap: Pick any two (you can't have all three)." --RFC 1925 Attachment: signature.asc Description: PGP signature

Question I have been pondering, with respect to trying to keep the mandatory fields as minimal as possible.... If it is assumed that the sighting is going to be reported via TAXII, which I would expect should be the majority of the cases - why do we need to have the producer as part of the message, when it should be able to be implied? - 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 Jerome Athias ---2015/10/27 11:26:13 AM---I think we're doing well. I think the location and detection-method could be optional (in an From: Jerome Athias <athiasjerome@gmail.com> To: "Davidson II, Mark S" <mdavidson@mitre.org> Cc: Sarah Kelley <Sarah.Kelley@cisecurity.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, Terry MacDonald <terry@soltra.com>, "Baker, Jon" <bakerj@mitre.org>, "Jonathan Bush (DTCC)" <jbush@dtcc.com>, Cory Casanave <cory-c@modeldriven.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 2015/10/27 11:26 AM Subject: Re: [cti-stix] Conceptul model for sighting Sent by: <cti-stix@lists.oasis-open.org> I think we're doing well. I think the location and detection-method could be optional (in an effort of keeping things as simple as possible) <source> observed <x> instances of <object>, <time-range> (via <detection-method>) (at <location>) (with <confidence>) (...) After let's say two weeks of open discussions in the list, we could update the github and ask the TC Chairs to present the current conclusion/proposition during the next meeting. Then submitting it for an open request for comments for a period of, let's say 1 month before potential definitive agreement/validation @Sarah: regarding the relationships 'issue', there's an open discussion going on to know if we make it as a construct. I will just add, for now, that if you can't find a 'workaround', that I assume right now being finding the -relationship path- between top level object A and the underlying object B, this should be highlighted @Sarah (and all): did you run the statistics tool? :-) 2015-10-27 14:56 GMT+03:00 Davidson II, Mark S <mdavidson@mitre.org>: > I’m feeling like the possible use cases mentioned so far might be > condensable into the following sentence structure: > > > > “<source> observed <x> instances of <object> at <location>, <time-range>, > via <detection-method>” > > > > This has decent (but not complete) overlap with Terry’s proposed fields, so > maybe it means we are on the right track? > > > > As a side note, do we know how we are we capturing the outcome of this > discussion? In the TAXII SC, we’ve been keeping a “Decisions” list [1], with > links out to more detail as necessary. (Note that decisions does not mean > that everything in there is set in stone – it just means the TAXII SC has > general agreement on the principle. For e.g., the REST API, there’s still > plenty to work on). Once we get most people agreeing on most things for a > particular discussion, we could document them in a similar fashion and keep > track of the open items; e.g., if we can’t agree on <Some-Field>, let’s mark > it as an open question and move on to another topic. > > > > Thank you. > > -Mark > > > > [1] http://taxiiproject.github.io/taxii2/#decisions > > > > From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] > On Behalf Of Sarah Kelley > Sent: Tuesday, October 27, 2015 7:18 AM > To: Unknown Unknown <athiasjerome@gmail.com>; Jordan, Bret > <bret.jordan@bluecoat.com> > Cc: Terry MacDonald <terry@soltra.com>; Baker, Jon <bakerj@mitre.org>; > Jonathan Bush (DTCC) <jbush@dtcc.com>; Cory Casanave > <cory-c@modeldriven.com>; cti-stix@lists.oasis-open.org > > > Subject: Re: [cti-stix] Conceptul model for sighting > > > > I am a huge proponent of letting (almost) anything link to anything. In > fact, limiting what can have an association/link/relationship with what is > my current biggest frustration with Stix (we use workarounds to get around > this limitation). > > > > I would add the possible use cases: > > > > My org observed 3 instances of this threat actor hitting our network > > My org observed 12 instances of the Poison Ivy TTP on our network > > Or even (though weaker): > > My org was hit by this particular campaign 27 times > > > > > > > > Sarah Kelley > > Senior CERT Analyst > > Center for Internet Security (CIS) > > Integrated Intelligence Center (IIC) > > Multi-State Information Sharing and Analysis Center (MS-ISAC) > > 1-866-787-4722 (7×24 SOC) > > Email: cert@cisecurity.org > > www.cisecurity.org > > Follow us @CISecurity > > > > > > From: <cti-stix@lists.oasis-open.org> on behalf of Jerome Athias > <athiasjerome@gmail.com> > Date: Monday, October 26, 2015 at 10:29 PM > To: "Jordan, Bret" <bret.jordan@bluecoat.com> > Cc: Terry MacDonald <terry@soltra.com>, "Baker, Jon" <bakerj@mitre.org>, > "Jonathan Bush (DTCC)" <jbush@dtcc.com>, Cory Casanave > <cory-c@modeldriven.com>, "cti-stix@lists.oasis-open.org" > <cti-stix@lists.oasis-open.org> > Subject: Re: [cti-stix] Conceptul model for sighting > > > > I do agree with Terry and Bret last emails and find the thread constructive > > > > Some use cases for bottom up (without full context for now): > > > > My org observed 12 instances of this malware artifact today (after AV > signatures update) > > My org observed 100000 hits from this ip address in the last hours (all > against ssh) > > My org observed 5000 times this excel file with macro (coming in emails) in > the last 10 minutes > > My org observed 1 hit of exploitation of this new ssl vuln CVE-2015-007 > (against our VPN portal) this week-end > > My org observed 3 binaires signed with this stolen certificate this month > > > > > On Tuesday, 27 October 2015, Jordan, Bret <bret.jordan@bluecoat.com> wrote: > > In terms of volume, I see the Sighting object dwarfing all others, probably > by several orders of magnitude.  Following the sighting object I see the > relationship object being the next largest consumer of TAXII volume.  I also > see the Sighting object along with the relationship object and its > assertions working in a very social side of threat analysis and discovery, > where a lot of back and forth takes place. > > > > Another option I can see is the Sighting object as being a seed for > additional exploration or automated data enrichment. > > > > So let's make sure we get this and the relationship object figured out and > done well. > > > > Bret > > Sent from my Commodore 64 > > > On Oct 26, 2015, at 1:45 PM, Terry MacDonald <terry@soltra.com> wrote: > > Hi Jon > > > > > > > > -          Sensor Alerts – As an example, an IDS or other sensor reports a > match on some indicator. You will likely have some contextual information > like times, ip addresses, host names, what indictor was matched, what was > really seen, which IDS or sensor reported the alert, etc..  You probably > don’t care about data markings, aggregate sighting information, and other > fields. You probably do care about having compact efficient messages due to > high volume. > > > > This is what I personally (speaking as myself) think of when I think of a > Sighting. A description of an Observable Instance with some basic extra > context. > > > > -          Organizational Sighting Reports – As an example, consider what is > needed when an organization reports back to an ISAC/ISAO that an indicator > has been matched (or sighted). > > > > To me this is no different to the first case. If an Indicator has been > matched then a new Sighting object will be created under the namespace of > the Organization. The Organization will then share that Sighting object back > to the ISAC/ISAO (if the Org wants to) along with a Relationship object > (also under the  namespace of the Org) that maps the ISAC Indicator to the > Org’s Sighting Object. This can potentially be accompanied with an Incident > object or Report object to give extra context if required. > > > > -          Aggregate Sightings Analysis – Consider the information structure > that is needed to enable effective analysis of aggregate data from both of > the above examples. > > > > In my personal opinion it is up to consumers to use the collected data to > make their own decisions. Every Organization has their own institutional > idea of trust. They alone know which sources of information make sense for > them, their management’s risk appetite, the verticals they operate in and so > forth. The analysis that one Organization performs to come to the conclusion > of ‘High’ risk may actually be a ‘Low’ risk in another organization. Each > Org must be ultimately responsible for its own analysis. > > > > But, that’s not to say that they can’t outsource that function to other > organizations. Dedicated third-parties specializing in analyzing Sightings > to extract TTPs and match those to Campaigns and Actors will become more > prevalent. These third-party analysis services will provide analysis > customized to the Organization’s structure/vertical/risk appetite which will > help them extract the ‘why and ‘how’ from the ‘what’. > > > > I believe that the separate top-level Sighting object will provide us with > the basic structure to begin the higher level analysis. I believe that this > will then help third-parties to generate more ‘upper-level’ STIX data – > Threat Actors, Campaigns and higher-order TTP in particular. > > > > 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 Baker, Jon > Sent: Saturday, 24 October 2015 2:10 AM > To: Jonathan Bush (DTCC) <jbush@dtcc.com>; 'Jordan, Bret' > <bret.jordan@bluecoat.com>; Cory Casanave <cory-c@modeldriven.com> > Cc: cti-stix@lists.oasis-open.org > Subject: RE: [cti-stix] Conceptul model for sighting > > > > The sightings conversation has historically suffered from a lack of shared > understand of the sightings use cases and an attempt to address all the > related sightings use cases with one complex model that does not really > satisfy any single use case very well. I guess I am a fan of a bottom up > approach focused on the use cases that are seen in the wild today. > > > > At a high-level I think that we can talk about sightings in several ways: > > There are probably others perspectives on sightings to consider as well. My > recommendation is that we clearly state (use case)  each of the different > kinds of sightings and that we independently flesh out the information > requirements. > > > > At the same time we need to consider what is done today in each of these > cases and what we think needs to be done in the future. I would like us to > focus on developing a model for sightings that satisfies today’s needs and > allows for expansion to what we think the future state should be. When it > comes to sightings we simply don’t have enough experience to know what is > really needed beyond supporting what people already do today. > > > > Thanks, > > > > Jon > > > > ============================================ > > Jonathan O. Baker > > J83D - Cyber Security Partnerships, Sharing, and Automation > > The MITRE Corporation > > Email: bakerj@mitre.org > > > > From:cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On > Behalf Of Bush, Jonathan > Sent: Thursday, October 22, 2015 8:48 AM > To: 'Jordan, Bret' <bret.jordan@bluecoat.com>; Cory Casanave > <cory-c@modeldriven.com> > Cc: cti-stix@lists.oasis-open.org > Subject: RE: [cti-stix] Conceptul model for sighting > > > > I definitely like the “state the use case first” approach here.  We can’t > implement a data design until we know what we plan on doing with it. > > > > On the simplicity suggestion – YES!!  Simple, simple, simple.  We can always > add fields later.  Let’s just get this implemented, baked into our products, > and then we can see what we are missing. > > > > On the data structure – Seems to me that the big decision on this is whether > or not we have a sighting object or EACH sighting (meaning, it references > something and adds context like who saw it, date, etc…) or have a combined > object that carries a count.  The former will offer more flexibility, but > will mean more object instances.  The later is really just a summary of the > former, which will be much smaller from a db size perspective, but we won’t > be able to identify individual characteristics of each sighting instance. > > > > Personally, I favor flexibility.  We can solve the size issue with technical > implementation. > > > > From:cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On > Behalf Of Jordan, Bret > Sent: Wednesday, October 21, 2015 5:42 PM > To: Cory Casanave > Cc: cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Conceptul model for sighting > > > > I think a better place to start is how people or devices are going to > interact with an IOC-Indicator. > > > > 1) Human: I am going to see a list of IOCs in my work bench tool and have > the ability to query that list for certain things as I do stuff.  Perhaps as > I start documenting an issue I am seeing in my network it could show a list > of potential IOCs that match it.  I could then: > >             a) click a button that says "share a sighting" or > >             b) the software could be configured to emit a sighting every > time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a > report. > > > > 2) Device: A network device / security tool might be watching the network > and either looking for IOCs based on a feed it gets from somewhere or it > might find bad stuff on its own and generate an IOC then query the repo to > see if the IOC is already known.  In either case, the device could emit a > sighting. > > > > While I appreciate the desire to cover every esoteric corner case that might > ever come up, I think we should take a minimalistic approach to the first > generation of the Sighting object..  It is always easy to add stuff, but it > is really hard to take it away. > > > > I would argue that the bare minimum we need is: > > > > 1) Reference to what it is we are sighting > > 2) The person / organization that is making the sighting > > 3) A count of the number of times it was seen. > > > > Now yes, there is a LOT more things that COULD be added, and all of them > could be added over time.  For example (yes this will rub people the wrong > way), data markings.  I would personally leave them out for now.  I would > love if we could get to the point where we had to rev the sightings object > spec to support data markings or something else because we had so many > people using it and begging for the feature. > > > > By taking the minimalistic approach we can more quicker and get people using > it. > > > > Think: > > > > { > >             "type": "sighting", > >             "id": "foo.com:sighting-1234-1234-1234-1234", > >             "idref": "abc.com:indicator-4321-4321-4321-4321", > >             "count": "1222" > >             "producer": "tom and jerry" > > } > > > > > > > > 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 21, 2015, at 15:17, Cory Casanave <cory-c@modeldriven.com> wrote: > > > > In the meeting today “sighting” was discussed. Below is the sighting > component of a conceptual model we are developing for threats and risks. > Note that this is a level more general than STIX (the model is being mapped > to STIX), but perhaps we can share some ideas. > > Regards, > Cory Casanave > > > > <image003.jpg> > > > > > DTCC DISCLAIMER: This email and any files transmitted with it are > confidential and intended solely for the use of the individual or entity to > whom they are addressed. If you have received this email in error, please > notify us immediately and delete the email and any attachments from your > system. The recipient should check this email and any attachments for the > presence of viruses.  The company accepts no liability for any damage caused > by any virus transmitted by this email. > > > ... > > This message and attachments may contain confidential information. If it > appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments is > strictly prohibited. Please notify the sender immediately and permanently > delete the message and any attachments. > . . . --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php  

You’ll know the server you got it from, but does that tell you who sent it?
 
Let’s say you have a TAXII Server for a sharing group. Org1 puts up a sighting, Org2 receives the sighting. How does Org2 know what organization produced the
sighting if the sighting information is not contained in the data?
 
Thank you.
-Mark
 


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

Sent: Thursday, October 29, 2015 9:26 AM
To: Jerome Athias <athiasjerome@gmail.com>
Cc: Davidson II, Mark S <mdavidson@mitre.org>; Sarah Kelley <Sarah.Kelley@cisecurity.org>; Jordan, Bret <bret.jordan@bluecoat.com>; Terry MacDonald <terry@soltra.com>; Baker, Jon <bakerj@mitre.org>; Jonathan Bush (DTCC) <jbush@dtcc.com>; Cory Casanave
<cory-c@modeldriven.com>; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Conceptul model for sighting


 
Question I have been pondering, with respect to trying to keep the mandatory fields as minimal as possible....

If it is assumed that the sighting is going to be reported via TAXII, which I would expect should be the majority of the cases - why do we need to have the producer as part of the message, when it should be able to be implied?


-
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


Jerome
Athias ---2015/10/27 11:26:13 AM---I think we're doing well. I think the location and detection-method could be optional (in an

From: Jerome Athias < athiasjerome@gmail.com >
To: "Davidson II, Mark S" < mdavidson@mitre.org >
Cc: Sarah Kelley < Sarah.Kelley@cisecurity.org >, "Jordan, Bret" < bret.jordan@bluecoat.com >,
Terry MacDonald < terry@soltra.com >, "Baker, Jon" < bakerj@mitre.org >, "Jonathan Bush (DTCC)" < jbush@dtcc.com >, Cory Casanave < cory-c@modeldriven.com >,
" cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Date: 2015/10/27 11:26 AM
Subject: Re: [cti-stix] Conceptul model for sighting
Sent by: < cti-stix@lists.oasis-open.org >







I think we're doing well.
I think the location and detection-method could be optional (in an
effort of keeping things as simple as possible)

<source> observed <x> instances of <object>, <time-range> (via
<detection-method>) (at <location>) (with <confidence>) (...)


After let's say two weeks of open discussions in the list, we could
update the github and ask the TC Chairs to present the current
conclusion/proposition during the next meeting. Then submitting it for
an open request for comments for a period of, let's say 1 month before
potential definitive agreement/validation

@Sarah: regarding the relationships 'issue', there's an open
discussion going on to know if we make it as a construct. I will just
add, for now, that if you can't find a 'workaround', that I assume
right now being finding the -relationship path- between top level
object A and the underlying object B, this should be highlighted

@Sarah (and all): did you run the statistics tool? :-)



2015-10-27 14:56 GMT+03:00 Davidson II, Mark S < mdavidson@mitre.org >:
> I’m feeling like the possible use cases mentioned so far might be
> condensable into the following sentence structure:
>
>
>
> “<source> observed <x> instances of <object> at <location>, <time-range>,
> via <detection-method>”
>
>
>
> This has decent (but not complete) overlap with Terry’s proposed fields, so
> maybe it means we are on the right track?
>
>
>
> As a side note, do we know how we are we capturing the outcome of this
> discussion? In the TAXII SC, we’ve been keeping a “Decisions” list [1], with
> links out to more detail as necessary. (Note that decisions does not mean
> that everything in there is set in stone – it just means the TAXII SC has
> general agreement on the principle. For e.g., the REST API, there’s still
> plenty to work on). Once we get most people agreeing on most things for a
> particular discussion, we could document them in a similar fashion and keep
> track of the open items; e.g., if we can’t agree on <Some-Field>, let’s mark
> it as an open question and move on to another topic.
>
>
>
> Thank you.
>
> -Mark
>
>
>
> [1] http://taxiiproject.github.io/taxii2/#decisions
>
>
>
> From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
> On Behalf Of Sarah Kelley
> Sent: Tuesday, October 27, 2015 7:18 AM
> To: Unknown Unknown < athiasjerome@gmail.com >; Jordan, Bret
> < bret.jordan@bluecoat.com >
> Cc: Terry MacDonald < terry@soltra.com >; Baker, Jon < bakerj@mitre.org >;
> Jonathan Bush (DTCC) < jbush@dtcc.com >; Cory Casanave
> < cory-c@modeldriven.com >;
cti-stix@lists.oasis-open.org
>
>
> Subject: Re: [cti-stix] Conceptul model for sighting
>
>
>
> I am a huge proponent of letting (almost) anything link to anything. In
> fact, limiting what can have an association/link/relationship with what is
> my current biggest frustration with Stix (we use workarounds to get around
> this limitation).
>
>
>
> I would add the possible use cases:
>
>
>
> My org observed 3 instances of this threat actor hitting our network
>
> My org observed 12 instances of the Poison Ivy TTP on our network
>
> Or even (though weaker):
>
> My org was hit by this particular campaign 27 times
>
>
>
>
>
>
>
> Sarah Kelley
>
> Senior CERT Analyst
>
> Center for Internet Security (CIS)
>
> Integrated Intelligence Center (IIC)
>
> Multi-State Information Sharing and Analysis Center (MS-ISAC)
>
> 1-866-787-4722 (7×24 SOC)
>
> Email: cert@cisecurity.org
>
> www.cisecurity.org
>
> Follow us @CISecurity
>
>
>
>
>
> From: < cti-stix@lists.oasis-open.org > on behalf of Jerome Athias
> < athiasjerome@gmail.com >
> Date: Monday, October 26, 2015 at 10:29 PM
> To: "Jordan, Bret" < bret.jordan@bluecoat.com >
> Cc: Terry MacDonald < terry@soltra.com >, "Baker, Jon" < bakerj@mitre.org >,
> "Jonathan Bush (DTCC)" < jbush@dtcc.com >, Cory Casanave
> < cory-c@modeldriven.com >, " cti-stix@lists.oasis-open.org "
> < cti-stix@lists.oasis-open.org >
> Subject: Re: [cti-stix] Conceptul model for sighting
>
>
>
> I do agree with Terry and Bret last emails and find the thread constructive
>
>
>
> Some use cases for bottom up (without full context for now):
>
>
>
> My org observed 12 instances of this malware artifact today (after AV
> signatures update)
>
> My org observed 100000 hits from this ip address in the last hours (all
> against ssh)
>
> My org observed 5000 times this excel file with macro (coming in emails) in
> the last 10 minutes
>
> My org observed 1 hit of exploitation of this new ssl vuln CVE-2015-007
> (against our VPN portal) this week-end
>
> My org observed 3 binaires signed with this stolen certificate this month
>
>
>
>
> On Tuesday, 27 October 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote:
>
> In terms of volume, I see the Sighting object dwarfing all others, probably
> by several orders of magnitude.  Following the sighting object I see the
> relationship object being the next largest consumer of TAXII volume.  I also
> see the Sighting object along with the relationship object and its
> assertions working in a very social side of threat analysis and discovery,
> where a lot of back and forth takes place.
>
>
>
> Another option I can see is the Sighting object as being a seed for
> additional exploration or automated data enrichment.
>
>
>
> So let's make sure we get this and the relationship object figured out and
> done well.
>
>
>
> Bret
>
> Sent from my Commodore 64
>
>
> On Oct 26, 2015, at 1:45 PM, Terry MacDonald < terry@soltra.com > wrote:
>
> Hi Jon
>
>
>
>
>
>
>
> -          Sensor Alerts – As an example, an IDS or other sensor reports a
> match on some indicator. You will likely have some contextual information
> like times, ip addresses, host names, what indictor was matched, what was
> really seen, which IDS or sensor reported the alert, etc..  You probably
> don’t care about data markings, aggregate sighting information, and other
> fields. You probably do care about having compact efficient messages due to
> high volume.
>
>
>
> This is what I personally (speaking as myself) think of when I think of a
> Sighting. A description of an Observable Instance with some basic extra
> context.
>
>
>
> -          Organizational Sighting Reports – As an example, consider what is
> needed when an organization reports back to an ISAC/ISAO that an indicator
> has been matched (or sighted).
>
>
>
> To me this is no different to the first case. If an Indicator has been
> matched then a new Sighting object will be created under the namespace of
> the Organization. The Organization will then share that Sighting object back
> to the ISAC/ISAO (if the Org wants to) along with a Relationship object
> (also under the  namespace of the Org) that maps the ISAC Indicator to the
> Org’s Sighting Object. This can potentially be accompanied with an Incident
> object or Report object to give extra context if required.
>
>
>
> -          Aggregate Sightings Analysis – Consider the information structure
> that is needed to enable effective analysis of aggregate data from both of
> the above examples.
>
>
>
> In my personal opinion it is up to consumers to use the collected data to
> make their own decisions. Every Organization has their own institutional
> idea of trust. They alone know which sources of information make sense for
> them, their management’s risk appetite, the verticals they operate in and so
> forth. The analysis that one Organization performs to come to the conclusion
> of ‘High’ risk may actually be a ‘Low’ risk in another organization. Each
> Org must be ultimately responsible for its own analysis.
>
>
>
> But, that’s not to say that they can’t outsource that function to other
> organizations. Dedicated third-parties specializing in analyzing Sightings
> to extract TTPs and match those to Campaigns and Actors will become more
> prevalent. These third-party analysis services will provide analysis
> customized to the Organization’s structure/vertical/risk appetite which will
> help them extract the ‘why and ‘how’ from the ‘what’.
>
>
>
> I believe that the separate top-level Sighting object will provide us with
> the basic structure to begin the higher level analysis. I believe that this
> will then help third-parties to generate more ‘upper-level’ STIX data –
> Threat Actors, Campaigns and higher-order TTP in particular.
>
>
>
> 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 Baker, Jon
> Sent: Saturday, 24 October 2015 2:10 AM
> To: Jonathan Bush (DTCC) < jbush@dtcc.com >; 'Jordan, Bret'
> < bret.jordan@bluecoat.com >; Cory Casanave < cory-c@modeldriven.com >
> Cc: cti-stix@lists.oasis-open.org
> Subject: RE: [cti-stix] Conceptul model for sighting
>
>
>
> The sightings conversation has historically suffered from a lack of shared
> understand of the sightings use cases and an attempt to address all the
> related sightings use cases with one complex model that does not really
> satisfy any single use case very well. I guess I am a fan of a bottom up
> approach focused on the use cases that are seen in the wild today.
>
>
>
> At a high-level I think that we can talk about sightings in several ways:
>
> There are probably others perspectives on sightings to consider as well. My
> recommendation is that we clearly state (use case)  each of the different
> kinds of sightings and that we independently flesh out the information
> requirements.
>
>
>
> At the same time we need to consider what is done today in each of these
> cases and what we think needs to be done in the future. I would like us to
> focus on developing a model for sightings that satisfies today’s needs and
> allows for expansion to what we think the future state should be. When it
> comes to sightings we simply don’t have enough experience to know what is
> really needed beyond supporting what people already do today.
>
>
>
> Thanks,
>
>
>
> Jon
>
>
>
> ============================================
>
> Jonathan O. Baker
>
> J83D - Cyber Security Partnerships, Sharing, and Automation
>
> The MITRE Corporation
>
> Email: bakerj@mitre.org
>
>
>
> From:cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On
> Behalf Of Bush, Jonathan
> Sent: Thursday, October 22, 2015 8:48 AM
> To: 'Jordan, Bret' < bret.jordan@bluecoat.com >; Cory Casanave
> < cory-c@modeldriven.com >
> Cc: cti-stix@lists.oasis-open.org
> Subject: RE: [cti-stix] Conceptul model for sighting
>
>
>
> I definitely like the “state the use case first” approach here.  We can’t
> implement a data design until we know what we plan on doing with it.
>
>
>
> On the simplicity suggestion – YES!!  Simple, simple, simple.  We can always
> add fields later.  Let’s just get this implemented, baked into our products,
> and then we can see what we are missing.
>
>
>
> On the data structure – Seems to me that the big decision on this is whether
> or not we have a sighting object or EACH sighting (meaning, it references
> something and adds context like who saw it, date, etc…) or have a combined
> object that carries a count.  The former will offer more flexibility, but
> will mean more object instances.  The later is really just a summary of the
> former, which will be much smaller from a db size perspective, but we won’t
> be able to identify individual characteristics of each sighting instance.
>
>
>
> Personally, I favor flexibility.  We can solve the size issue with technical
> implementation.
>
>
>
> From:cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On
> Behalf Of Jordan, Bret
> Sent: Wednesday, October 21, 2015 5:42 PM
> To: Cory Casanave
> Cc: cti-stix@lists.oasis-open.org
> Subject: Re: [cti-stix] Conceptul model for sighting
>
>
>
> I think a better place to start is how people or devices are going to
> interact with an IOC-Indicator.
>
>
>
> 1) Human: I am going to see a list of IOCs in my work bench tool and have
> the ability to query that list for certain things as I do stuff.  Perhaps as
> I start documenting an issue I am seeing in my network it could show a list
> of potential IOCs that match it.  I could then:
>
>             a) click a button that says "share a sighting" or
>
>             b) the software could be configured to emit a sighting every
> time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a
> report.
>
>
>
> 2) Device: A network device / security tool might be watching the network
> and either looking for IOCs based on a feed it gets from somewhere or it
> might find bad stuff on its own and generate an IOC then query the repo to
> see if the IOC is already known.  In either case, the device could emit a
> sighting.
>
>
>
> While I appreciate the desire to cover every esoteric corner case that might
> ever come up, I think we should take a minimalistic approach to the first
> generation of the Sighting object..  It is always easy to add stuff, but it
> is really hard to take it away.
>
>
>
> I would argue that the bare minimum we need is:
>
>
>
> 1) Reference to what it is we are sighting
>
> 2) The person / organization that is making the sighting
>
> 3) A count of the number of times it was seen.
>
>
>
> Now yes, there is a LOT more things that COULD be added, and all of them
> could be added over time.  For example (yes this will rub people the wrong
> way), data markings.  I would personally leave them out for now.  I would
> love if we could get to the point where we had to rev the sightings object
> spec to support data markings or something else because we had so many
> people using it and begging for the feature.
>
>
>
> By taking the minimalistic approach we can more quicker and get people using
> it.
>
>
>
> Think:
>
>
>
> {
>
>             "type": "sighting",
>
>             "id": "foo.com:sighting-1234-1234-1234-1234",
>
>             "idref": "abc.com:indicator-4321-4321-4321-4321",
>
>             "count": "1222"
>
>             "producer": "tom and jerry"
>
> }
>
>
>
>
>
>
>
> 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 21, 2015, at 15:17, Cory Casanave < cory-c@modeldriven.com > wrote:
>
>
>
> In the meeting today “sighting” was discussed. Below is the sighting
> component of a conceptual model we are developing for threats and risks.
> Note that this is a level more general than STIX (the model is being mapped
> to STIX), but perhaps we can share some ideas.
>
> Regards,
> Cory Casanave
>
>
>
> <image003.jpg>
>
>
>
>
> DTCC DISCLAIMER: This email and any files transmitted with it are
> confidential and intended solely for the use of the individual or entity to
> whom they are addressed. If you have received this email in error, please
> notify us immediately and delete the email and any attachments from your
> system. The recipient should check this email and any attachments for the
> presence of viruses.  The company accepts no liability for any damage caused
> by any virus transmitted by this email.
>
>
> ...
>
> This message and attachments may contain confidential information. If it
> appears that this message was sent to you by mistake, any retention,
> dissemination, distribution or copying of this message and attachments is
> strictly prohibited. Please notify the sender immediately and permanently
> delete the message and any attachments.
> . . .

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php  

I concur And me to say 'ObservedSighting' vs ´ReportedSighting' Thing we should not want for now to avoid ´complexity' On Thursday, 29 October 2015, Davidson II, Mark S < mdavidson@mitre.org > wrote: You’ll know the server you got it from, but does that tell you who sent it?   Let’s say you have a TAXII Server for a sharing group. Org1 puts up a sighting, Org2 receives the sighting. How does Org2 know what organization produced the sighting if the sighting information is not contained in the data?   Thank you. -Mark   From: Jason Keirstead [mailto: Jason.Keirstead@ca.ibm.com ] Sent: Thursday, October 29, 2015 9:26 AM To: Jerome Athias < athiasjerome@gmail.com > Cc: Davidson II, Mark S < mdavidson@mitre.org >; Sarah Kelley < Sarah.Kelley@cisecurity.org >; Jordan, Bret < bret.jordan@bluecoat.com >; Terry MacDonald < terry@soltra.com >; Baker, Jon < bakerj@mitre.org >; Jonathan Bush (DTCC) < jbush@dtcc.com >; Cory Casanave < cory-c@modeldriven.com >; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Conceptul model for sighting   Question I have been pondering, with respect to trying to keep the mandatory fields as minimal as possible.... If it is assumed that the sighting is going to be reported via TAXII, which I would expect should be the majority of the cases - why do we need to have the producer as part of the message, when it should be able to be implied? - 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 Jerome Athias ---2015/10/27 11:26:13 AM---I think we're doing well. I think the location and detection-method could be optional (in an From: Jerome Athias < athiasjerome@gmail.com > To: "Davidson II, Mark S" < mdavidson@mitre.org > Cc: Sarah Kelley < Sarah.Kelley@cisecurity.org >, "Jordan, Bret" < bret.jordan@bluecoat.com >, Terry MacDonald < terry@soltra.com >, "Baker, Jon" < bakerj@mitre.org >, "Jonathan Bush (DTCC)" < jbush@dtcc.com >, Cory Casanave < cory-c@modeldriven.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Date: 2015/10/27 11:26 AM Subject: Re: [cti-stix] Conceptul model for sighting Sent by: < cti-stix@lists.oasis-open.org > I think we're doing well. I think the location and detection-method could be optional (in an effort of keeping things as simple as possible) <source> observed <x> instances of <object>, <time-range> (via <detection-method>) (at <location>) (with <confidence>) (...) After let's say two weeks of open discussions in the list, we could update the github and ask the TC Chairs to present the current conclusion/proposition during the next meeting. Then submitting it for an open request for comments for a period of, let's say 1 month before potential definitive agreement/validation @Sarah: regarding the relationships 'issue', there's an open discussion going on to know if we make it as a construct. I will just add, for now, that if you can't find a 'workaround', that I assume right now being finding the -relationship path- between top level object A and the underlying object B, this should be highlighted @Sarah (and all): did you run the statistics tool? :-) 2015-10-27 14:56 GMT+03:00 Davidson II, Mark S < mdavidson@mitre.org >: > I’m feeling like the possible use cases mentioned so far might be > condensable into the following sentence structure: > > > > “<source> observed <x> instances of <object> at <location>, <time-range>, > via <detection-method>” > > > > This has decent (but not complete) overlap with Terry’s proposed fields, so > maybe it means we are on the right track? > > > > As a side note, do we know how we are we capturing the outcome of this > discussion? In the TAXII SC, we’ve been keeping a “Decisions” list [1], with > links out to more detail as necessary. (Note that decisions does not mean > that everything in there is set in stone – it just means the TAXII SC has > general agreement on the principle. For e.g., the REST API, there’s still > plenty to work on). Once we get most people agreeing on most things for a > particular discussion, we could document them in a similar fashion and keep > track of the open items; e.g., if we can’t agree on <Some-Field>, let’s mark > it as an open question and move on to another topic. > > > > Thank you. > > -Mark > > > > [1] http://taxiiproject.github.io/taxii2/#decisions > > > > From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] > On Behalf Of Sarah Kelley > Sent: Tuesday, October 27, 2015 7:18 AM > To: Unknown Unknown < athiasjerome@gmail.com >; Jordan, Bret > < bret.jordan@bluecoat.com > > Cc: Terry MacDonald < terry@soltra.com >; Baker, Jon < bakerj@mitre.org >; > Jonathan Bush (DTCC) < jbush@dtcc.com >; Cory Casanave > < cory-c@modeldriven.com >; cti-stix@lists.oasis-open.org > > > Subject: Re: [cti-stix] Conceptul model for sighting > > > > I am a huge proponent of letting (almost) anything link to anything. In > fact, limiting what can have an association/link/relationship with what is > my current biggest frustration with Stix (we use workarounds to get around > this limitation). > > > > I would add the possible use cases: > > > > My org observed 3 instances of this threat actor hitting our network > > My org observed 12 instances of the Poison Ivy TTP on our network > > Or even (though weaker): > > My org was hit by this particular campaign 27 times > > > > > > > > Sarah Kelley > > Senior CERT Analyst > > Center for Internet Security (CIS) > > Integrated Intelligence Center (IIC) > > Multi-State Information Sharing and Analysis Center (MS-ISAC) > > 1-866-787-4722 (7×24 SOC) > > Email: cert@cisecurity.org > > www.cisecurity.org > > Follow us @CISecurity > > > > > > From: < cti-stix@lists.oasis-open.org > on behalf of Jerome Athias > < athiasjerome@gmail.com > > Date: Monday, October 26, 2015 at 10:29 PM > To: "Jordan, Bret" < bret.jordan@bluecoat.com > > Cc: Terry MacDonald < terry@soltra.com >, "Baker, Jon" < bakerj@mitre.org >, > "Jonathan Bush (DTCC)" < jbush@dtcc.com >, Cory Casanave > < cory-c@modeldriven.com >, " cti-stix@lists.oasis-open.org " > < cti-stix@lists.oasis-open.org > > Subject: Re: [cti-stix] Conceptul model for sighting > > > > I do agree with Terry and Bret last emails and find the thread constructive > > > > Some use cases for bottom up (without full context for now): > > > > My org observed 12 instances of this malware artifact today (after AV > signatures update) > > My org observed 100000 hits from this ip address in the last hours (all > against ssh) > > My org observed 5000 times this excel file with macro (coming in emails) in > the last 10 minutes > > My org observed 1 hit of exploitation of this new ssl vuln CVE-2015-007 > (against our VPN portal) this week-end > > My org observed 3 binaires signed with this stolen certificate this month > > > > > On Tuesday, 27 October 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: > > In terms of volume, I see the Sighting object dwarfing all others, probably > by several orders of magnitude.  Following the sighting object I see the > relationship object being the next largest consumer of TAXII volume.  I also > see the Sighting object along with the relationship object and its > assertions working in a very social side of threat analysis and discovery, > where a lot of back and forth takes place. > > > > Another option I can see is the Sighting object as being a seed for > additional exploration or automated data enrichment. > > > > So let's make sure we get this and the relationship object figured out and > done well. > > > > Bret > > Sent from my Commodore 64 > > > On Oct 26, 2015, at 1:45 PM, Terry MacDonald < terry@soltra.com > wrote: > > Hi Jon > > > > > > > > -          Sensor Alerts – As an example, an IDS or other sensor reports a > match on some indicator. You will likely have some contextual information > like times, ip addresses, host names, what indictor was matched, what was > really seen, which IDS or sensor reported the alert, etc..  You probably > don’t care about data markings, aggregate sighting information, and other > fields. You probably do care about having compact efficient messages due to > high volume. > > > > This is what I personally (speaking as myself) think of when I think of a > Sighting. A description of an Observable Instance with some basic extra > context. > > > > -          Organizational Sighting Reports – As an example, consider what is > needed when an organization reports back to an ISAC/ISAO that an indicator > has been matched (or sighted). > > > > To me this is no different to the first case. If an Indicator has been > matched then a new Sighting object will be created under the namespace of > the Organization. The Organization will then share that Sighting object back > to the ISAC/ISAO (if the Org wants to) along with a Relationship object > (also under the  namespace of the Org) that maps the ISAC Indicator to the > Org’s Sighting Object. This can potentially be accompanied with an Incident > object or Report object to give extra context if required. > > > > -          Aggregate Sightings Analysis – Consider the information structure > that is needed to enable effective analysis of aggregate data from both of > the above examples. > > > > In my personal opinion it is up to consumers to use the collected data to > make their own decisions. Every Organization has their own institutional > idea of trust. They alone know which sources of information make sense for > them, their management’s risk appetite, the verticals they operate in and so > forth. The analysis that one Organization performs to come to the conclusion > of ‘High’ risk may actually be a ‘Low’ risk in another organization. Each > Org must be ultimately responsible for its own analysis. > > > > But, that’s not to say that they can’t outsource that function to other > organizations. Dedicated third-parties specializing in analyzing Sightings > to extract TTPs and match those to Campaigns and Actors will become more > prevalent. These third-party analysis services will provide analysis > customized to the Organization’s structure/vertical/risk appetite which will > help them extract the ‘why and ‘how’ from the ‘what’. > > > > I believe that the separate top-level Sighting object will provide us with > the basic structure to begin the higher level analysis. I believe that this > will then help third-parties to generate more ‘upper-level’ STIX data – > Threat Actors, Campaigns and higher-order TTP in particular. > > > > 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 Baker, Jon > Sent: Saturday, 24 October 2015 2:10 AM > To: Jonathan Bush (DTCC) < jbush@dtcc.com >; 'Jordan, Bret' > < bret.jordan@bluecoat.com >; Cory Casanave < cory-c@modeldriven.com > > Cc: cti-stix@lists.oasis-open.org > Subject: RE: [cti-stix] Conceptul model for sighting > > > > The sightings conversation has historically suffered from a lack of shared > understand of the sightings use cases and an attempt to address all the > related sightings use cases with one complex model that does not really > satisfy any single use case very well. I guess I am a fan of a bottom up > approach focused on the use cases that are seen in the wild today. > > > > At a high-level I think that we can talk about sightings in several ways: > > There are probably others perspectives on sightings to consider as well. My > recommendation is that we clearly state (use case)  each of the different > kinds of sightings and that we independently flesh out the information > requirements. > > > > At the same time we need to consider what is done today in each of these > cases and what we think needs to be done in the future. I would like us to > focus on developing a model for sightings that satisfies today’s needs and > allows for expansion to what we think the future state should be. When it > comes to sightings we simply don’t have enough experience to know what is > really needed beyond supporting what people already do today. > > > > Thanks, > > > > Jon > > > > ============================================ > > Jonathan O. Baker > > J83D - Cyber Security Partnerships, Sharing, and Automation > > The MITRE Corporation > > Email: bakerj@mitre.org > > > > From:cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On > Behalf Of Bush, Jonathan > Sent: Thursday, October 22, 2015 8:48 AM > To: 'Jordan, Bret' < bret.jordan@bluecoat.com >; Cory Casanave > < cory-c@modeldriven.com > > Cc: cti-stix@lists.oasis-open.org > Subject: RE: [cti-stix] Conceptul model for sighting > > > > I definitely like the “state the use case first” approach here.  We can’t > implement a data design until we know what we plan on doing with it. > > > > On the simplicity suggestion – YES!!  Simple, simple, simple.  We can always > add fields later.  Let’s just get this implemented, baked into our products, > and then we can see what we are missing. > > > > On the data structure – Seems to me that the big decision on this is whether > or not we have a sighting object or EACH sighting (meaning, it references > something and adds context like who saw it, date, etc…) or have a combined > object that carries a count.  The former will offer more flexibility, but > will mean more object instances.  The later is really just a summary of the > former, which will be much smaller from a db size perspective, but we won’t > be able to identify individual characteristics of each sighting instance. > > > > Personally, I favor flexibility.  We can solve the size issue with technical > implementation. > > > > From:cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On > Behalf Of Jordan, Bret > Sent: Wednesday, October 21, 2015 5:42 PM > To: Cory Casanave > Cc: cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Conceptul model for sighting > > > > I think a better place to start is how people or devices are going to > interact with an IOC-Indicator. > > > > 1) Human: I am going to see a list of IOCs in my work bench tool and have > the ability to query that list for certain things as I do stuff.  Perhaps as > I start documenting an issue I am seeing in my network it could show a list > of potential IOCs that match it.  I could then: > >             a) click a button that says "share a sighting" or > >             b) the software could be configured to emit a sighting every > time the IOC (think URL, IP address, Hash, filename, etc) is referenced in a > report. > > > > 2) Device: A network device / security tool might be watching the network > and either looking for IOCs based on a feed it gets from somewhere or it > might find bad stuff on its own and generate an IOC then query the repo to > see if the IOC is already known.  In either case, the device could emit a > sighting. > > > > While I appreciate the desire to cover every esoteric corner case that might > ever come up, I think we should take a minimalistic approach to the first > generation of the Sighting object..  It is always easy to add stuff, but it > is really hard to take it away. > > > > I would argue that the bare minimum we need is: > > > > 1) Reference to what it is we are sighting > > 2) The person / organization that is making the sighting > > 3) A count of the number of times it was seen. > > > > Now yes, there is a LOT more things that COULD be added, and all of them > could be added over time.  For example (yes this will rub people the wrong > way), data markings.  I would personally leave them out for now.  I would > love if we could get to the point where we had to rev the sightings object > spec to support data markings or something else because we had so many > people using it and begging for the feature. > > > > By taking the minimalistic approach we can more quicker and get people using > it. > > > > Think: > > > > { > >             "type": "sighting", > >             "id": "foo.com:sighting-1234-1234-1234-1234", > >             "idref": "abc.com:indicator-4321-4321-4321-4321", > >             "count": "1222" > >             "producer": "tom and jerry" > > } > > > > > > > > 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 21, 2015, at 15:17, Cory Casanave < cory-c@modeldriven.com > wrote: > > > > In the meeting today “sighting” was discussed. Below is the sighting > component of a conceptual model we are developing for threats and risks. > Note that this is a level more general than STIX (the model is being mapped > to STIX), but perhaps we can share some ideas. > > Regards, > Cory Casanave > > > > <image003.jpg> > > > > > DTCC DISCLAIMER: This email and any files transmitted with it are > confidential and intended solely for the use of the individual or entity to > whom they are addressed. If you have received this email in error, please > notify us immediately and delete the email and any attachments from your > system. The recipient should check this email and any attachments for the > presence of viruses.  The company accepts no liability for any damage caused > by any virus transmitted by this email. > > > ... > > This message and attachments may contain confidential information. If it > appears that this message was sent to you by mistake, any retention, > dissemination, distribution or copying of this message and attachments is > strictly prohibited. Please notify the sender immediately and permanently > delete the message and any attachments. > . . . --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php