CTI STIX Subcommittee

Sarah – thanks for sending the summary of different use cases.
 

I agree Object 1 is close to a sighting. We may want to just make sure Object2/3 have ways to reference Object1/Sighting and that might be sufficient
to address the use case. Object 2 & 3 – I have a slight preference for making them the same object with suitable properties to identify when its one or the other. But could live
with them being separate. Object 4 – this is a very common use case today but I’m convinced that it needs to be a separate object. This could potentially be solved by either a
Report or Object 5. Object 5 – Agree that this should exist and is separate from a Report object.
 
Regards
 
Allan
 

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
Date: Monday, September 11, 2017 at 6:41 AM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Current thoughts on Event Object


 

CTI-TC,
 
I have made an attempt to summarize the discussion to date surrounding the Event object. I have tried to use the diagrams that we’ve been referencing that show several workflows and where I see the various
SDOs we have been discussing.
 
I think there are five separate things that we’ve been talking about with regards to “Event”:
 
Object 1) Some sort of front end device sensing something. You could call this an alert, an event, a log line, etc. 
Object 2) A somewhat more mature version of the thing above. It
may be one to one, but it may not be. There may be many of Object #1 that make up one Object #2. 
Object 3) A way to document an incident/investigation that is either ongoing or concluded. This may (or may not) have come from an evolution out of an Object 1 or 2. Likely, most IR tools will not use Object
3 directly, so it should probably be a sort of summary object that can allow the results of an IR investigation to be linked back to all the related data (like Objects 1 and 2, but also Actors, malware, etc)
Object 4) Some sort of automated method of reporting, for cases such as mandatory reporting (like to US CERT). 
Object 5) A way to group a bunch of related data together. 
 
I see these as five distinct SDOs. Objects 1 and 2 are very similar, and
could be represented by one SDO, but if that was the case, then the SDO would need to have a relationship type of “this arglebargle is one of many arglebargles that make up this larger arglebargle”.
 
Object 1 has a lot of logistical overlap with a Sighting. There would need to be some sort of deconfliction between what properties were trying to be represented by Object 1 to make sure it wasn’t just a duplicate
of Sighting (which, by definition, is something that was ‘seen’, just as Object 1 was described to be). This could also just be an Observed Data object, if the it wasn’t actually “sighted”.

 
Object 2 is something that would likely be looked at by a SOC analyst. It isn’t really something that involves IR, but rather “is this thing my sensor generated good or bad?”
 
Object 3 is for your IR people or your CERT. 
 
Object 4 is likely distinct from the Report object as we have it now, as it’s not likely to be in the same vein as a ‘published report’, but rather, “Here are the series of questions that US CERT makes me
answer every time we have an ‘incident’”. 
 
Object 5 is basically what MISP has been asking for. 
 
I believe Objects 1-3 roughly correlate to the first three objects from the FireEye proposal of “Event”, “Alert”, and “Investigation”. Object 5 is closer to their “Grouping” object. 
 
All that being said, many of these tasks are not currently done in STIX (if not most of them). In the diagram, we have the TIP (in green) as being a separate object that lives alongside the workflow, but isn’t
really IN the workflow. That being said, if we added objects 1, 2, 4, and 5, I think it could allow for easier data flow into/out of a TIP. (I don’t think the IR object will ever be used directly by the types of tools that produce that data, but maybe
I’m wrong.) 
 
Personally, I think the Event object as it currently stands is somewhat of a combination of Object 2 and Object 3. If people agree that these are really separate objects, I think we could scope out a few properties
and turn the current Event object into Object 2 or Object 3 fairly easily (or easily split it into two objects). I think Object 1 is out of scope for 2.1 (unless it’s already covered by sighting/Observed Data). I think Object 4 is out of scope for 2.1. I think
Object 5 will be covered by the “collection vs. report” debate/object, for which we should soon have a proposal.

 
 

 
 
Thoughts are appreciated.

 
Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-ISAC)                   
31 Tech Valley Drive
East Greenbush, NY 12061
 
sarah.kelley@cisecurity.org
518-266-3493
24x7 Security Operations Center
SOC@cisecurity.org  - 1-866-787-4722
 

      
             
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.


. . . . .

So last we talked, on the working call, we had pretty strong consensus that the path forward for Object 5 was to roll it in to the report object. I’ve been working with a few people to get that integrated
in and will have a proposal to do so within the next day or two. At that point I think we can either reinforce that consensus or decide on a separate object.
 

From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Monday, September 11, 2017 at 10:52 AM
To: Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Current thoughts on Event Object


 

Sarah – thanks for sending the summary of different use cases.
 

I agree Object 1 is close to a sighting. We may want to just make sure Object2/3 have ways to reference Object1/Sighting and that might be sufficient to address
the use case. Object 2 & 3 – I have a slight preference for making them the same object with suitable properties to identify when its one or the other. But could live with
them being separate. Object 4 – this is a very common use case today but I’m convinced that it needs to be a separate object. This could potentially be solved by either a Report
or Object 5. Object 5 – Agree that this should exist and is separate from a Report object.
 
Regards
 
Allan
 

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
Date: Monday, September 11, 2017 at 6:41 AM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Current thoughts on Event Object


 

CTI-TC,
 
I have made an attempt to summarize the discussion to date surrounding the Event object. I have tried to use the diagrams that we’ve been referencing that show several workflows and where I see the various
SDOs we have been discussing.
 
I think there are five separate things that we’ve been talking about with regards to “Event”:
 
Object 1) Some sort of front end device sensing something. You could call this an alert, an event, a log line, etc. 
Object 2) A somewhat more mature version of the thing above. It
may be one to one, but it may not be. There may be many of Object #1 that make up one Object #2. 
Object 3) A way to document an incident/investigation that is either ongoing or concluded. This may (or may not) have come from an evolution out of an Object 1 or 2. Likely, most IR tools will not use Object
3 directly, so it should probably be a sort of summary object that can allow the results of an IR investigation to be linked back to all the related data (like Objects 1 and 2, but also Actors, malware, etc)
Object 4) Some sort of automated method of reporting, for cases such as mandatory reporting (like to US CERT). 
Object 5) A way to group a bunch of related data together. 
 
I see these as five distinct SDOs. Objects 1 and 2 are very similar, and
could be represented by one SDO, but if that was the case, then the SDO would need to have a relationship type of “this arglebargle is one of many arglebargles that make up this larger arglebargle”.
 
Object 1 has a lot of logistical overlap with a Sighting. There would need to be some sort of deconfliction between what properties were trying to be represented by Object 1 to make sure it wasn’t just a duplicate
of Sighting (which, by definition, is something that was ‘seen’, just as Object 1 was described to be). This could also just be an Observed Data object, if the it wasn’t actually “sighted”.

 
Object 2 is something that would likely be looked at by a SOC analyst. It isn’t really something that involves IR, but rather “is this thing my sensor generated good or bad?”
 
Object 3 is for your IR people or your CERT. 
 
Object 4 is likely distinct from the Report object as we have it now, as it’s not likely to be in the same vein as a ‘published report’, but rather, “Here are the series of questions that US CERT makes me
answer every time we have an ‘incident’”. 
 
Object 5 is basically what MISP has been asking for. 
 
I believe Objects 1-3 roughly correlate to the first three objects from the FireEye proposal of “Event”, “Alert”, and “Investigation”. Object 5 is closer to their “Grouping” object. 
 
All that being said, many of these tasks are not currently done in STIX (if not most of them). In the diagram, we have the TIP (in green) as being a separate object that lives alongside the workflow, but isn’t
really IN the workflow. That being said, if we added objects 1, 2, 4, and 5, I think it could allow for easier data flow into/out of a TIP. (I don’t think the IR object will ever be used directly by the types of tools that produce that data, but maybe
I’m wrong.) 
 
Personally, I think the Event object as it currently stands is somewhat of a combination of Object 2 and Object 3. If people agree that these are really separate objects, I think we could scope out a few properties
and turn the current Event object into Object 2 or Object 3 fairly easily (or easily split it into two objects). I think Object 1 is out of scope for 2.1 (unless it’s already covered by sighting/Observed Data). I think Object 4 is out of scope for 2.1. I think
Object 5 will be covered by the “collection vs. report” debate/object, for which we should soon have a proposal.

 
 

 
 
Thoughts are appreciated.

 
Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-ISAC)                   
31 Tech Valley Drive
East Greenbush, NY 12061
 
sarah.kelley@cisecurity.org
518-266-3493
24x7 Security Operations Center
SOC@cisecurity.org  - 1-866-787-4722
 

      
             
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.


. . . . .

Hmm. I missed the last working call due to conflicting meetings.
Before that I do not recall strong consensus for rolling Object 5 into the Report object.
We would object to this approach.
We would suggest that the use cases for an object to convey a general grouping of content with some shared context that is fully mutable and the use cases for an object to convey a “report” of some content
including any relevant conclusions that is immutable are significantly distinct and would best be served with distinct named objects.
After chatting with Andras and Alexandre on Friday to get a better understanding of what MISP is looking for in such an object, I believe that they would agree with the above suggestion but will obviously
let them speak for themselves.
 

Sean Barnum
Principal Architect
FireEye
M: 703.473.8262

E: sean.barnum@fireeye.com
 

From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Monday, September 11, 2017 at 10:56 AM
To: Allan Thomson <athomson@lookingglasscyber.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Current thoughts on Event Object


 

So last we talked, on the working call, we had pretty strong consensus that the path forward for Object 5 was to roll it in to the report object. I’ve been working with a few people to get that integrated
in and will have a proposal to do so within the next day or two. At that point I think we can either reinforce that consensus or decide on a separate object.
 

From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Monday, September 11, 2017 at 10:52 AM
To: Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Current thoughts on Event Object


 

Sarah – thanks for sending the summary of different use cases.
 

I agree Object 1 is close to a sighting. We may want to just make sure Object2/3 have ways to reference Object1/Sighting and that might be sufficient to address
the use case. Object 2 & 3 – I have a slight preference for making them the same object with suitable properties to identify when its one or the other. But could live with
them being separate. Object 4 – this is a very common use case today but I’m convinced that it needs to be a separate object. This could potentially be solved by either a Report
or Object 5. Object 5 – Agree that this should exist and is separate from a Report object.
 
Regards
 
Allan
 

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
Date: Monday, September 11, 2017 at 6:41 AM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Current thoughts on Event Object


 

CTI-TC,
 
I have made an attempt to summarize the discussion to date surrounding the Event object. I have tried to use the diagrams that we’ve been referencing that show several workflows and where I see the various
SDOs we have been discussing.
 
I think there are five separate things that we’ve been talking about with regards to “Event”:
 
Object 1) Some sort of front end device sensing something. You could call this an alert, an event, a log line, etc. 
Object 2) A somewhat more mature version of the thing above. It
may be one to one, but it may not be. There may be many of Object #1 that make up one Object #2. 
Object 3) A way to document an incident/investigation that is either ongoing or concluded. This may (or may not) have come from an evolution out of an Object 1 or 2. Likely, most IR tools will not use Object
3 directly, so it should probably be a sort of summary object that can allow the results of an IR investigation to be linked back to all the related data (like Objects 1 and 2, but also Actors, malware, etc)
Object 4) Some sort of automated method of reporting, for cases such as mandatory reporting (like to US CERT). 
Object 5) A way to group a bunch of related data together. 
 
I see these as five distinct SDOs. Objects 1 and 2 are very similar, and
could be represented by one SDO, but if that was the case, then the SDO would need to have a relationship type of “this arglebargle is one of many arglebargles that make up this larger arglebargle”.
 
Object 1 has a lot of logistical overlap with a Sighting. There would need to be some sort of deconfliction between what properties were trying to be represented by Object 1 to make sure it wasn’t just a duplicate
of Sighting (which, by definition, is something that was ‘seen’, just as Object 1 was described to be). This could also just be an Observed Data object, if the it wasn’t actually “sighted”.

 
Object 2 is something that would likely be looked at by a SOC analyst. It isn’t really something that involves IR, but rather “is this thing my sensor generated good or bad?”
 
Object 3 is for your IR people or your CERT. 
 
Object 4 is likely distinct from the Report object as we have it now, as it’s not likely to be in the same vein as a ‘published report’, but rather, “Here are the series of questions that US CERT makes me
answer every time we have an ‘incident’”. 
 
Object 5 is basically what MISP has been asking for. 
 
I believe Objects 1-3 roughly correlate to the first three objects from the FireEye proposal of “Event”, “Alert”, and “Investigation”. Object 5 is closer to their “Grouping” object. 
 
All that being said, many of these tasks are not currently done in STIX (if not most of them). In the diagram, we have the TIP (in green) as being a separate object that lives alongside the workflow, but isn’t
really IN the workflow. That being said, if we added objects 1, 2, 4, and 5, I think it could allow for easier data flow into/out of a TIP. (I don’t think the IR object will ever be used directly by the types of tools that produce that data, but maybe
I’m wrong.) 
 
Personally, I think the Event object as it currently stands is somewhat of a combination of Object 2 and Object 3. If people agree that these are really separate objects, I think we could scope out a few properties
and turn the current Event object into Object 2 or Object 3 fairly easily (or easily split it into two objects). I think Object 1 is out of scope for 2.1 (unless it’s already covered by sighting/Observed Data). I think Object 4 is out of scope for 2.1. I think
Object 5 will be covered by the “collection vs. report” debate/object, for which we should soon have a proposal.

 
 

 
 
Thoughts are appreciated.

 
Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-ISAC)                   
31 Tech Valley Drive
East Greenbush, NY 12061
 
sarah.kelley@cisecurity.org
518-266-3493
24x7 Security Operations Center
SOC@cisecurity.org  - 1-866-787-4722
 

      
             
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.


. . . . .

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited.
If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

Yep, indeed, for us Report works, but anything new would do too, as long as we get the option to bundle related data together and attach some context to it. Our biggest limitation is being able to convey that it is not a finished report of sorts, but something that could potentially be evolving over time (for example a regularly updated blacklist is also a valid use-case). We're not attached to using a retro-fitted Report at all, it was just one of the options that would have worked for us among many. Richard's suggestion for a collection object was great, though I understand the name is a bit loaded. Best regards, Andras On 11. sep. 2017 17:12, Sean Barnum wrote: > Hmm. I missed the last working call due to conflicting meetings. > > Before that I do not recall strong consensus for rolling Object 5 into > the Report object. > > We would object to this approach. > > We would suggest that the use cases for an object to convey a general > grouping of content with some shared context that is fully mutable and > the use cases for an object to convey a “report” of some content > including any relevant conclusions that is immutable are significantly > distinct and would best be served with distinct named objects. > > After chatting with Andras and Alexandre on Friday to get a better > understanding of what MISP is looking for in such an object, I believe > that they would agree with the above suggestion but will obviously let > them speak for themselves. > > > > Sean Barnum > > Principal Architect > > FireEye > > M: 703.473.8262 > > E: sean.barnum@fireeye.com > > > > *From: *<cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." > <jwunder@mitre.org> > *Date: *Monday, September 11, 2017 at 10:56 AM > *To: *Allan Thomson <athomson@lookingglasscyber.com>, Sarah Kelley > <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" > <cti-stix@lists.oasis-open.org> > *Subject: *Re: [cti-stix] Current thoughts on Event Object > > > > So last we talked, on the working call, we had pretty strong consensus > that the path forward for Object 5 was to roll it in to the report > object. I’ve been working with a few people to get that integrated in > and will have a proposal to do so within the next day or two. At that > point I think we can either reinforce that consensus or decide on a > separate object. > > > > *From: *<cti-stix@lists.oasis-open.org> on behalf of Allan Thomson > <athomson@lookingglasscyber.com> > *Date: *Monday, September 11, 2017 at 10:52 AM > *To: *Sarah Kelley <Sarah.Kelley@cisecurity.org>, > "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> > *Subject: *Re: [cti-stix] Current thoughts on Event Object > > > > Sarah – thanks for sending the summary of different use cases. > > > > * I agree Object 1 is close to a sighting. We may want to just make > sure Object2/3 have ways to reference Object1/Sighting and that > might be sufficient to address the use case. > * Object 2 & 3 – I have a slight preference for making them the same > object with suitable properties to identify when its one or the > other. But could live with them being separate. > * Object 4 – this is a very common use case today but I’m convinced > that it needs to be a separate object. This could potentially be > solved by either a Report or Object 5. > * Object 5 – Agree that this should exist and is separate from a > Report object. > > > > Regards > > > > Allan > > > > *From: *"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> > on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org> > *Date: *Monday, September 11, 2017 at 6:41 AM > *To: *"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> > *Subject: *[cti-stix] Current thoughts on Event Object > > > > CTI-TC, > > > > I have made an attempt to summarize the discussion to date surrounding > the Event object. I have tried to use the diagrams that we’ve been > referencing that show several workflows and where I see the various SDOs > we have been discussing. > > > > I think there are five separate things that we’ve been talking about > with regards to “Event”: > > > > Object 1) Some sort of front end device sensing something. You could > call this an alert, an event, a log line, etc. > > Object 2) A somewhat more mature version of the thing above. It /may/ be > one to one, but it may not be. There may be many of Object #1 that make > up one Object #2. > > Object 3) A way to document an incident/investigation that is either > ongoing or concluded. This may (or may not) have come from an evolution > out of an Object 1 or 2. Likely, most IR tools will not use Object 3 > directly, so it should probably be a sort of summary object that can > allow the results of an IR investigation to be linked back to all the > related data (like Objects 1 and 2, but also Actors, malware, etc) > > Object 4) Some sort of automated method of reporting, for cases such as > mandatory reporting (like to US CERT). > > Object 5) A way to group a bunch of related data together. > > > > I see these as five distinct SDOs. Objects 1 and 2 are very similar, and > /could/ be represented by one SDO, but if that was the case, then the > SDO would need to have a relationship type of “this arglebargle is one > of many arglebargles that make up this larger arglebargle”. > > > > Object 1 has a lot of logistical overlap with a Sighting. There would > need to be some sort of deconfliction between what properties were > trying to be represented by Object 1 to make sure it wasn’t just a > duplicate of Sighting (which, by definition, is something that was > ‘seen’, just as Object 1 was described to be). This could also just be > an Observed Data object, if the it wasn’t actually “sighted”. > > > > Object 2 is something that would likely be looked at by a SOC analyst. > It isn’t really something that involves IR, but rather “is this thing my > sensor generated good or bad?” > > > > Object 3 is for your IR people or your CERT. > > > > Object 4 is likely distinct from the Report object as we have it now, as > it’s not likely to be in the same vein as a ‘published report’, but > rather, “Here are the series of questions that US CERT makes me answer > every time we have an ‘incident’”. > > > > Object 5 is basically what MISP has been asking for. > > > > I believe Objects 1-3 roughly correlate to the first three objects from > the FireEye proposal of “Event”, “Alert”, and “Investigation”. Object 5 > is closer to their “Grouping” object. > > > > All that being said, many of these tasks are not currently done in STIX > (if not most of them). In the diagram, we have the TIP (in green) as > being a separate object that lives alongside the workflow, but isn’t > really *IN* the workflow. That being said, if we added objects 1, 2, 4, > and 5, I think it could allow for easier data flow into/out of a TIP. (I > don’t think the IR object will ever be used directly by the types of > tools that produce that data, but maybe I’m wrong.) > > > > Personally, I think the Event object as it currently stands is somewhat > of a combination of Object 2 and Object 3. If people agree that these > are really separate objects, I think we could scope out a few properties > and turn the current Event object into Object 2 or Object 3 fairly > easily (or easily split it into two objects). I think Object 1 is out of > scope for 2.1 (unless it’s already covered by sighting/Observed Data). I > think Object 4 is out of scope for 2.1. I think Object 5 will be covered > by the “collection vs. report” debate/object, for which we should soon > have a proposal. > > > > > > > > > > Thoughts are appreciated. > > > > *Sarah Kelley* > > *Senior Cyber Threat Analyst* > > *Multi-State Information Sharing and Analysis Center > (MS-ISAC) * > > *31 Tech Valley Drive* > > *East Greenbush, NY 12061* > > * * > > *sarah.kelley@cisecurity.org < mailto:sarah.kelley@cisecurity.org >* > > *518-266-3493* > > *24x7 Security Operations Center* > > *SOC@cisecurity.org < mailto:SOC@cisecurity.org > - 1-866-787-4722* > > * * > > ** < https://msisac.cisecurity.org/ > > > * *** < https://www.facebook.com/CenterforIntSec >* *** > < https://twitter.com/CISecurity >* *** > < https://www.youtube.com/user/TheCISecurity >* *** > < https://www.linkedin.com/company/the-center-for-internet-security > > > 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. > > . . . . . > > This email and any attachments thereto may contain private, > confidential, and/or privileged material for the sole use of the > intended recipient. Any review, copying, or distribution of this email > (or any attachments thereto) by others is strictly prohibited. If you > are not the intended recipient, please contact the sender immediately > and permanently delete the original and any copies of this email and any > attachments thereto.

We had the straw poll with hand raises. IIRC you were on the call and, as below, were against putting it in Report :)
 
I’ll get the proposed changes out shortly. I got the review from the MISP folks and some others, just need to work through some comments. It’s in the playground now.
 

From: <cti-stix@lists.oasis-open.org> on behalf of Sean Barnum <sean.barnum@FireEye.com>
Date: Monday, September 11, 2017 at 11:12 AM
To: John Wunder <jwunder@mitre.org>, Allan Thomson <athomson@lookingglasscyber.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Current thoughts on Event Object


 

Hmm. I missed the last working call due to conflicting meetings.
Before that I do not recall strong consensus for rolling Object 5 into the Report object.
We would object to this approach.
We would suggest that the use cases for an object to convey a general grouping of content with some shared context that is fully mutable and the use cases for an object to convey a “report” of some content
including any relevant conclusions that is immutable are significantly distinct and would best be served with distinct named objects.
After chatting with Andras and Alexandre on Friday to get a better understanding of what MISP is looking for in such an object, I believe that they would agree with the above suggestion but will obviously
let them speak for themselves.
 

Sean Barnum
Principal Architect
FireEye
M: 703.473.8262

E: sean.barnum@fireeye.com
 

From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Monday, September 11, 2017 at 10:56 AM
To: Allan Thomson <athomson@lookingglasscyber.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Current thoughts on Event Object


 

So last we talked, on the working call, we had pretty strong consensus that the path forward for Object 5 was to roll it in to the report object. I’ve been working with a few people to get that integrated
in and will have a proposal to do so within the next day or two. At that point I think we can either reinforce that consensus or decide on a separate object.
 

From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Monday, September 11, 2017 at 10:52 AM
To: Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Current thoughts on Event Object


 

Sarah – thanks for sending the summary of different use cases.
 

I agree Object 1 is close to a sighting. We may want to just make sure Object2/3 have ways to reference Object1/Sighting and that might be sufficient to address
the use case. Object 2 & 3 – I have a slight preference for making them the same object with suitable properties to identify when its one or the other. But could live with
them being separate. Object 4 – this is a very common use case today but I’m convinced that it needs to be a separate object. This could potentially be solved by either a Report
or Object 5. Object 5 – Agree that this should exist and is separate from a Report object.
 
Regards
 
Allan
 

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
Date: Monday, September 11, 2017 at 6:41 AM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Current thoughts on Event Object


 

CTI-TC,
 
I have made an attempt to summarize the discussion to date surrounding the Event object. I have tried to use the diagrams that we’ve been referencing that show several workflows and where I see the various
SDOs we have been discussing.
 
I think there are five separate things that we’ve been talking about with regards to “Event”:
 
Object 1) Some sort of front end device sensing something. You could call this an alert, an event, a log line, etc. 
Object 2) A somewhat more mature version of the thing above. It
may be one to one, but it may not be. There may be many of Object #1 that make up one Object #2. 
Object 3) A way to document an incident/investigation that is either ongoing or concluded. This may (or may not) have come from an evolution out of an Object 1 or 2. Likely, most IR tools will not use Object
3 directly, so it should probably be a sort of summary object that can allow the results of an IR investigation to be linked back to all the related data (like Objects 1 and 2, but also Actors, malware, etc)
Object 4) Some sort of automated method of reporting, for cases such as mandatory reporting (like to US CERT). 
Object 5) A way to group a bunch of related data together. 
 
I see these as five distinct SDOs. Objects 1 and 2 are very similar, and
could be represented by one SDO, but if that was the case, then the SDO would need to have a relationship type of “this arglebargle is one of many arglebargles that make up this larger arglebargle”.
 
Object 1 has a lot of logistical overlap with a Sighting. There would need to be some sort of deconfliction between what properties were trying to be represented by Object 1 to make sure it wasn’t just a duplicate
of Sighting (which, by definition, is something that was ‘seen’, just as Object 1 was described to be). This could also just be an Observed Data object, if the it wasn’t actually “sighted”.

 
Object 2 is something that would likely be looked at by a SOC analyst. It isn’t really something that involves IR, but rather “is this thing my sensor generated good or bad?”
 
Object 3 is for your IR people or your CERT. 
 
Object 4 is likely distinct from the Report object as we have it now, as it’s not likely to be in the same vein as a ‘published report’, but rather, “Here are the series of questions that US CERT makes me
answer every time we have an ‘incident’”. 
 
Object 5 is basically what MISP has been asking for. 
 
I believe Objects 1-3 roughly correlate to the first three objects from the FireEye proposal of “Event”, “Alert”, and “Investigation”. Object 5 is closer to their “Grouping” object. 
 
All that being said, many of these tasks are not currently done in STIX (if not most of them). In the diagram, we have the TIP (in green) as being a separate object that lives alongside the workflow, but isn’t
really IN the workflow. That being said, if we added objects 1, 2, 4, and 5, I think it could allow for easier data flow into/out of a TIP. (I don’t think the IR object will ever be used directly by the types of tools that produce that data, but maybe
I’m wrong.) 
 
Personally, I think the Event object as it currently stands is somewhat of a combination of Object 2 and Object 3. If people agree that these are really separate objects, I think we could scope out a few properties
and turn the current Event object into Object 2 or Object 3 fairly easily (or easily split it into two objects). I think Object 1 is out of scope for 2.1 (unless it’s already covered by sighting/Observed Data). I think Object 4 is out of scope for 2.1. I think
Object 5 will be covered by the “collection vs. report” debate/object, for which we should soon have a proposal.

 
 

 
 
Thoughts are appreciated.

 
Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-ISAC)                   
31 Tech Valley Drive
East Greenbush, NY 12061
 
sarah.kelley@cisecurity.org
518-266-3493
24x7 Security Operations Center
SOC@cisecurity.org  - 1-866-787-4722
 

      
             
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.


. . . . .
This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments
thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

Hmm. I thought you meant the working call on Friday.
I remember several “had raise” votes on the Tuesday call but don’t remember this being one of them.
Maybe I am finally overflowing my stack with too many things to think about. ;-)
 
 
 

Sean Barnum
Principal Architect
FireEye
M: 703.473.8262

E: sean.barnum@fireeye.com
 

From: "Wunder, John A." <jwunder@mitre.org>
Date: Monday, September 11, 2017 at 11:31 AM
To: Sean Barnum <sean.barnum@FireEye.com>, Allan Thomson <athomson@lookingglasscyber.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Current thoughts on Event Object


 

We had the straw poll with hand raises. IIRC you were on the call and, as below, were against putting it in Report :)
 
I’ll get the proposed changes out shortly. I got the review from the MISP folks and some others, just need to work through some comments. It’s in the playground now.
 

From: <cti-stix@lists.oasis-open.org> on behalf of Sean Barnum <sean.barnum@FireEye.com>
Date: Monday, September 11, 2017 at 11:12 AM
To: John Wunder <jwunder@mitre.org>, Allan Thomson <athomson@lookingglasscyber.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Current thoughts on Event Object


 

Hmm. I missed the last working call due to conflicting meetings.
Before that I do not recall strong consensus for rolling Object 5 into the Report object.
We would object to this approach.
We would suggest that the use cases for an object to convey a general grouping of content with some shared context that is fully mutable and the use cases for an object to convey a “report” of some content
including any relevant conclusions that is immutable are significantly distinct and would best be served with distinct named objects.
After chatting with Andras and Alexandre on Friday to get a better understanding of what MISP is looking for in such an object, I believe that they would agree with the above suggestion but will obviously
let them speak for themselves.
 

Sean Barnum
Principal Architect
FireEye
M: 703.473.8262

E: sean.barnum@fireeye.com
 

From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Monday, September 11, 2017 at 10:56 AM
To: Allan Thomson <athomson@lookingglasscyber.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Current thoughts on Event Object


 

So last we talked, on the working call, we had pretty strong consensus that the path forward for Object 5 was to roll it in to the report object. I’ve been working with a few people to get that integrated
in and will have a proposal to do so within the next day or two. At that point I think we can either reinforce that consensus or decide on a separate object.
 

From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Monday, September 11, 2017 at 10:52 AM
To: Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Current thoughts on Event Object


 

Sarah – thanks for sending the summary of different use cases.
 

I agree Object 1 is close to a sighting. We may want to just make sure Object2/3 have ways to reference Object1/Sighting and that might be sufficient to address
the use case. Object 2 & 3 – I have a slight preference for making them the same object with suitable properties to identify when its one or the other. But could live with
them being separate. Object 4 – this is a very common use case today but I’m convinced that it needs to be a separate object. This could potentially be solved by either a Report
or Object 5. Object 5 – Agree that this should exist and is separate from a Report object.
 
Regards
 
Allan
 

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
Date: Monday, September 11, 2017 at 6:41 AM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Current thoughts on Event Object


 

CTI-TC,
 
I have made an attempt to summarize the discussion to date surrounding the Event object. I have tried to use the diagrams that we’ve been referencing that show several workflows and where I see the various
SDOs we have been discussing.
 
I think there are five separate things that we’ve been talking about with regards to “Event”:
 
Object 1) Some sort of front end device sensing something. You could call this an alert, an event, a log line, etc. 
Object 2) A somewhat more mature version of the thing above. It
may be one to one, but it may not be. There may be many of Object #1 that make up one Object #2. 
Object 3) A way to document an incident/investigation that is either ongoing or concluded. This may (or may not) have come from an evolution out of an Object 1 or 2. Likely, most IR tools will not use Object
3 directly, so it should probably be a sort of summary object that can allow the results of an IR investigation to be linked back to all the related data (like Objects 1 and 2, but also Actors, malware, etc)
Object 4) Some sort of automated method of reporting, for cases such as mandatory reporting (like to US CERT). 
Object 5) A way to group a bunch of related data together. 
 
I see these as five distinct SDOs. Objects 1 and 2 are very similar, and
could be represented by one SDO, but if that was the case, then the SDO would need to have a relationship type of “this arglebargle is one of many arglebargles that make up this larger arglebargle”.
 
Object 1 has a lot of logistical overlap with a Sighting. There would need to be some sort of deconfliction between what properties were trying to be represented by Object 1 to make sure it wasn’t just a duplicate
of Sighting (which, by definition, is something that was ‘seen’, just as Object 1 was described to be). This could also just be an Observed Data object, if the it wasn’t actually “sighted”.

 
Object 2 is something that would likely be looked at by a SOC analyst. It isn’t really something that involves IR, but rather “is this thing my sensor generated good or bad?”
 
Object 3 is for your IR people or your CERT. 
 
Object 4 is likely distinct from the Report object as we have it now, as it’s not likely to be in the same vein as a ‘published report’, but rather, “Here are the series of questions that US CERT makes me
answer every time we have an ‘incident’”. 
 
Object 5 is basically what MISP has been asking for. 
 
I believe Objects 1-3 roughly correlate to the first three objects from the FireEye proposal of “Event”, “Alert”, and “Investigation”. Object 5 is closer to their “Grouping” object. 
 
All that being said, many of these tasks are not currently done in STIX (if not most of them). In the diagram, we have the TIP (in green) as being a separate object that lives alongside the workflow, but isn’t
really IN the workflow. That being said, if we added objects 1, 2, 4, and 5, I think it could allow for easier data flow into/out of a TIP. (I don’t think the IR object will ever be used directly by the types of tools that produce that data, but maybe
I’m wrong.) 
 
Personally, I think the Event object as it currently stands is somewhat of a combination of Object 2 and Object 3. If people agree that these are really separate objects, I think we could scope out a few properties
and turn the current Event object into Object 2 or Object 3 fairly easily (or easily split it into two objects). I think Object 1 is out of scope for 2.1 (unless it’s already covered by sighting/Observed Data). I think Object 4 is out of scope for 2.1. I think
Object 5 will be covered by the “collection vs. report” debate/object, for which we should soon have a proposal.

 
 

 
 
Thoughts are appreciated.

 
Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-ISAC)                   
31 Tech Valley Drive
East Greenbush, NY 12061
 
sarah.kelley@cisecurity.org
518-266-3493
24x7 Security Operations Center
SOC@cisecurity.org  - 1-866-787-4722
 

      
             
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.


. . . . .
This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments
thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.


This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited.
If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

I believe the call that John Wunder is referring to took place a few weeks ago (August 29 th ). Last Fridays’ call wound up getting cut short due to lack of attendance, and last Tuesday’s call was
about some of the smaller STIX related items to get them taken care of.
 

Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-ISAC)                   
31 Tech Valley Drive
East Greenbush, NY 12061
 
sarah.kelley@cisecurity.org
518-266-3493
24x7 Security Operations Center
SOC@cisecurity.org  - 1-866-787-4722
 


      
             
 

From: Sean Barnum <sean.barnum@FireEye.com>
Date: Monday, September 11, 2017 at 11:41 AM
To: "Wunder, John A." <jwunder@mitre.org>, Allan Thomson <athomson@lookingglasscyber.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Current thoughts on Event Object


 




Hmm. I thought you meant the working call on Friday.
I remember several “had raise” votes on the Tuesday call but don’t remember this being one of them.
Maybe I am finally overflowing my stack with too many things to think about. ;-)
 
 
 

Sean Barnum
Principal Architect
FireEye
M: 703.473.8262

E: sean.barnum@fireeye.com
 

From: "Wunder, John A." <jwunder@mitre.org>
Date: Monday, September 11, 2017 at 11:31 AM
To: Sean Barnum <sean.barnum@FireEye.com>, Allan Thomson <athomson@lookingglasscyber.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Current thoughts on Event Object


 

We had the straw poll with hand raises. IIRC you were on the call and, as below, were against putting it in Report :)
 
I’ll get the proposed changes out shortly. I got the review from the MISP folks and some others, just need to work through some comments. It’s in the playground now.
 

From: <cti-stix@lists.oasis-open.org> on behalf of Sean Barnum <sean.barnum@FireEye.com>
Date: Monday, September 11, 2017 at 11:12 AM
To: John Wunder <jwunder@mitre.org>, Allan Thomson <athomson@lookingglasscyber.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Current thoughts on Event Object


 

Hmm. I missed the last working call due to conflicting meetings.
Before that I do not recall strong consensus for rolling Object 5 into the Report object.
We would object to this approach.
We would suggest that the use cases for an object to convey a general grouping of content with some shared context that is fully mutable and the use cases for an object to convey a “report” of some content
including any relevant conclusions that is immutable are significantly distinct and would best be served with distinct named objects.
After chatting with Andras and Alexandre on Friday to get a better understanding of what MISP is looking for in such an object, I believe that they would agree with the above suggestion but will obviously
let them speak for themselves.
 

Sean Barnum
Principal Architect
FireEye
M: 703.473.8262

E: sean.barnum@fireeye.com
 

From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Monday, September 11, 2017 at 10:56 AM
To: Allan Thomson <athomson@lookingglasscyber.com>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Current thoughts on Event Object


 

So last we talked, on the working call, we had pretty strong consensus that the path forward for Object 5 was to roll it in to the report object. I’ve been working with a few people to get that integrated
in and will have a proposal to do so within the next day or two. At that point I think we can either reinforce that consensus or decide on a separate object.
 

From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Monday, September 11, 2017 at 10:52 AM
To: Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Current thoughts on Event Object


 

Sarah – thanks for sending the summary of different use cases.
 

I agree Object 1 is close to a sighting. We may want to just make sure Object2/3 have ways to reference Object1/Sighting and that might be sufficient to address
the use case. Object 2 & 3 – I have a slight preference for making them the same object with suitable properties to identify when its one or the other. But could live with
them being separate. Object 4 – this is a very common use case today but I’m convinced that it needs to be a separate object. This could potentially be solved by either a Report
or Object 5. Object 5 – Agree that this should exist and is separate from a Report object.
 
Regards
 
Allan
 

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
Date: Monday, September 11, 2017 at 6:41 AM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Current thoughts on Event Object


 

CTI-TC,
 
I have made an attempt to summarize the discussion to date surrounding the Event object. I have tried to use the diagrams that we’ve been referencing that show several workflows and where I see the various
SDOs we have been discussing.
 
I think there are five separate things that we’ve been talking about with regards to “Event”:
 
Object 1) Some sort of front end device sensing something. You could call this an alert, an event, a log line, etc. 
Object 2) A somewhat more mature version of the thing above. It
may be one to one, but it may not be. There may be many of Object #1 that make up one Object #2. 
Object 3) A way to document an incident/investigation that is either ongoing or concluded. This may (or may not) have come from an evolution out of an Object 1 or 2. Likely, most IR tools will not use Object
3 directly, so it should probably be a sort of summary object that can allow the results of an IR investigation to be linked back to all the related data (like Objects 1 and 2, but also Actors, malware, etc)
Object 4) Some sort of automated method of reporting, for cases such as mandatory reporting (like to US CERT). 
Object 5) A way to group a bunch of related data together. 
 
I see these as five distinct SDOs. Objects 1 and 2 are very similar, and
could be represented by one SDO, but if that was the case, then the SDO would need to have a relationship type of “this arglebargle is one of many arglebargles that make up this larger arglebargle”.
 
Object 1 has a lot of logistical overlap with a Sighting. There would need to be some sort of deconfliction between what properties were trying to be represented by Object 1 to make sure it wasn’t just a duplicate
of Sighting (which, by definition, is something that was ‘seen’, just as Object 1 was described to be). This could also just be an Observed Data object, if the it wasn’t actually “sighted”.

 
Object 2 is something that would likely be looked at by a SOC analyst. It isn’t really something that involves IR, but rather “is this thing my sensor generated good or bad?”
 
Object 3 is for your IR people or your CERT. 
 
Object 4 is likely distinct from the Report object as we have it now, as it’s not likely to be in the same vein as a ‘published report’, but rather, “Here are the series of questions that US CERT makes me
answer every time we have an ‘incident’”. 
 
Object 5 is basically what MISP has been asking for. 
 
I believe Objects 1-3 roughly correlate to the first three objects from the FireEye proposal of “Event”, “Alert”, and “Investigation”. Object 5 is closer to their “Grouping” object. 
 
All that being said, many of these tasks are not currently done in STIX (if not most of them). In the diagram, we have the TIP (in green) as being a separate object that lives alongside the workflow, but isn’t
really IN the workflow. That being said, if we added objects 1, 2, 4, and 5, I think it could allow for easier data flow into/out of a TIP. (I don’t think the IR object will ever be used directly by the types of tools that produce that data, but maybe
I’m wrong.) 
 
Personally, I think the Event object as it currently stands is somewhat of a combination of Object 2 and Object 3. If people agree that these are really separate objects, I think we could scope out a few properties
and turn the current Event object into Object 2 or Object 3 fairly easily (or easily split it into two objects). I think Object 1 is out of scope for 2.1 (unless it’s already covered by sighting/Observed Data). I think Object 4 is out of scope for 2.1. I think
Object 5 will be covered by the “collection vs. report” debate/object, for which we should soon have a proposal.

 
 

 
 
Thoughts are appreciated.

 
Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-ISAC)                   
31 Tech Valley Drive
East Greenbush, NY 12061
 
sarah.kelley@cisecurity.org
518-266-3493
24x7 Security Operations Center
SOC@cisecurity.org  - 1-866-787-4722
 

      
             
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.


. . . . .
This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments
thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments
thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

.....



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 really don't like conflating concepts into a single object with a flag to show they are different, just because they have the same or similar fields.  So if object 2 and 3 are different concepts then they should be different objects. I agree with Jason's earlier take on this. Cheers Terry MacDonald Cosive On 12/09/2017 02:52, "Allan Thomson" < athomson@lookingglasscyber.com > wrote: Sarah – thanks for sending the summary of different use cases.   I agree Object 1 is close to a sighting. We may want to just make sure Object2/3 have ways to reference Object1/Sighting and that might be sufficient to address the use case. Object 2 & 3 – I have a slight preference for making them the same object with suitable properties to identify when its one or the other. But could live with them being separate. Object 4 – this is a very common use case today but I’m convinced that it needs to be a separate object. This could potentially be solved by either a Report or Object 5. Object 5 – Agree that this should exist and is separate from a Report object.   Regards   Allan   From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of Sarah Kelley < Sarah.Kelley@cisecurity.org > Date: Monday, September 11, 2017 at 6:41 AM To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Current thoughts on Event Object   CTI-TC,   I have made an attempt to summarize the discussion to date surrounding the Event object. I have tried to use the diagrams that we’ve been referencing that show several workflows and where I see the various SDOs we have been discussing.   I think there are five separate things that we’ve been talking about with regards to “Event”:   Object 1) Some sort of front end device sensing something. You could call this an alert, an event, a log line, etc.  Object 2) A somewhat more mature version of the thing above. It may be one to one, but it may not be. There may be many of Object #1 that make up one Object #2.  Object 3) A way to document an incident/investigation that is either ongoing or concluded. This may (or may not) have come from an evolution out of an Object 1 or 2. Likely, most IR tools will not use Object 3 directly, so it should probably be a sort of summary object that can allow the results of an IR investigation to be linked back to all the related data (like Objects 1 and 2, but also Actors, malware, etc) Object 4) Some sort of automated method of reporting, for cases such as mandatory reporting (like to US CERT).  Object 5) A way to group a bunch of related data together.    I see these as five distinct SDOs. Objects 1 and 2 are very similar, and could be represented by one SDO, but if that was the case, then the SDO would need to have a relationship type of “this arglebargle is one of many arglebargles that make up this larger arglebargle”.   Object 1 has a lot of logistical overlap with a Sighting. There would need to be some sort of deconfliction between what properties were trying to be represented by Object 1 to make sure it wasn’t just a duplicate of Sighting (which, by definition, is something that was ‘seen’, just as Object 1 was described to be). This could also just be an Observed Data object, if the it wasn’t actually “sighted”.   Object 2 is something that would likely be looked at by a SOC analyst. It isn’t really something that involves IR, but rather “is this thing my sensor generated good or bad?”   Object 3 is for your IR people or your CERT.    Object 4 is likely distinct from the Report object as we have it now, as it’s not likely to be in the same vein as a ‘published report’, but rather, “Here are the series of questions that US CERT makes me answer every time we have an ‘incident’”.    Object 5 is basically what MISP has been asking for.    I believe Objects 1-3 roughly correlate to the first three objects from the FireEye proposal of “Event”, “Alert”, and “Investigation”. Object 5 is closer to their “Grouping” object.    All that being said, many of these tasks are not currently done in STIX (if not most of them). In the diagram, we have the TIP (in green) as being a separate object that lives alongside the workflow, but isn’t really IN the workflow. That being said, if we added objects 1, 2, 4, and 5, I think it could allow for easier data flow into/out of a TIP. (I don’t think the IR object will ever be used directly by the types of tools that produce that data, but maybe I’m wrong.)    Personally, I think the Event object as it currently stands is somewhat of a combination of Object 2 and Object 3. If people agree that these are really separate objects, I think we could scope out a few properties and turn the current Event object into Object 2 or Object 3 fairly easily (or easily split it into two objects). I think Object 1 is out of scope for 2.1 (unless it’s already covered by sighting/Observed Data). I think Object 4 is out of scope for 2.1. I think Object 5 will be covered by the “collection vs. report” debate/object, for which we should soon have a proposal.         Thoughts are appreciated.   Sarah Kelley Senior Cyber Threat Analyst Multi-State Information Sharing and Analysis Center (MS-ISAC)                    31 Tech Valley Drive East Greenbush, NY 12061   sarah.kelley@cisecurity.org 518-266-3493 24x7 Security Operations Center SOC@cisecurity.org  - 1-866-787-4722                        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. . . . . .

So I’d been thinking about how we could distinguish these things. If you look at our design guidelines, I’m not sure there’s a solid answer. That said, there’s a few things I think we could prep that would help the discussion:
 

Write up definitions for the two objects, and run it past people blind to see what they think and whether they can distinguish them. Put together real-world examples and see if, given those descriptions, people can cleanly bucket them most of the time. (secondary) See how the fields align…if the fields are different, it’s a sign that they should be separate objects. If they’re the same, then it could go either way.
 
John
 

From: <cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
Date: Monday, September 11, 2017 at 3:57 PM
To: Allan Thomson <athomson@lookingglasscyber.com>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, Sarah Kelley <Sarah.Kelley@cisecurity.org>
Subject: Re: [cti-stix] Current thoughts on Event Object


 



I really don't like conflating concepts into a single object with a flag to show they are different, just because they have the same or similar fields. 


 


So if object 2 and 3 are different concepts then they should be different objects.


 


I agree with Jason's earlier take on this.


 


Cheers


Terry MacDonald


Cosive

 

 

On 12/09/2017 02:52, "Allan Thomson" < athomson@lookingglasscyber.com > wrote:



Sarah – thanks for sending the summary of different use cases.
 


I agree Object 1 is close to a sighting. We may want to just make sure Object2/3 have ways to reference Object1/Sighting and that might be sufficient to address the use case.
Object 2 & 3 – I have a slight preference for making them the same object with suitable properties to identify when its one or the other. But could live with them being separate.
Object 4 – this is a very common use case today but I’m convinced that it needs to be a separate object. This could potentially be solved by either a Report or Object 5.
Object 5 – Agree that this should exist and is separate from a Report object.
 
Regards
 
Allan
 

From:
" cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of Sarah Kelley
< Sarah.Kelley@cisecurity.org >
Date: Monday, September 11, 2017 at 6:41 AM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >


Subject: [cti-stix] Current thoughts on Event Object



 

CTI-TC,

 
I have made an attempt to summarize the discussion to date surrounding the Event object. I have tried to use the diagrams that we’ve been referencing that show several workflows
and where I see the various SDOs we have been discussing.
 
I think there are five separate things that we’ve been talking about with regards to “Event”:
 
Object 1) Some sort of front end device sensing something. You could call this an alert, an event, a log line, etc. 
Object 2) A somewhat more mature version of the thing above. It
may be one to one, but it may not be. There may be many of Object #1 that make up one Object #2. 
Object 3) A way to document an incident/investigation that is either ongoing or concluded. This may (or may not) have come from an evolution out of an Object 1 or 2. Likely, most
IR tools will not use Object 3 directly, so it should probably be a sort of summary object that can allow the results of an IR investigation to be linked back to all the related data (like Objects 1 and 2, but also Actors, malware, etc)
Object 4) Some sort of automated method of reporting, for cases such as mandatory reporting (like to US CERT). 
Object 5) A way to group a bunch of related data together. 
 
I see these as five distinct SDOs. Objects 1 and 2 are very similar, and
could be represented by one SDO, but if that was the case, then the SDO would need to have a relationship type of “this arglebargle is one of many arglebargles that make up this larger arglebargle”.
 
Object 1 has a lot of logistical overlap with a Sighting. There would need to be some sort of deconfliction between what properties were trying to be represented by Object 1 to
make sure it wasn’t just a duplicate of Sighting (which, by definition, is something that was ‘seen’, just as Object 1 was described to be). This could also just be an Observed Data object, if the it wasn’t actually “sighted”.

 
Object 2 is something that would likely be looked at by a SOC analyst. It isn’t really something that involves IR, but rather “is this thing my sensor generated good or bad?”
 
Object 3 is for your IR people or your CERT. 
 
Object 4 is likely distinct from the Report object as we have it now, as it’s not likely to be in the same vein as a ‘published report’, but rather, “Here are the series of questions
that US CERT makes me answer every time we have an ‘incident’”. 
 
Object 5 is basically what MISP has been asking for. 
 
I believe Objects 1-3 roughly correlate to the first three objects from the FireEye proposal of “Event”, “Alert”, and “Investigation”. Object 5 is closer to their “Grouping” object. 
 
All that being said, many of these tasks are not currently done in STIX (if not most of them). In the diagram, we have the TIP (in green) as being a separate object that lives alongside
the workflow, but isn’t really IN the workflow. That being said, if we added objects 1, 2, 4, and 5, I think it could allow for easier data flow into/out of a TIP. (I don’t think the IR object will ever be used directly by the types of tools that produce
that data, but maybe I’m wrong.) 
 
Personally, I think the Event object as it currently stands is somewhat of a combination of Object 2 and Object 3. If people agree that these are really separate objects, I think
we could scope out a few properties and turn the current Event object into Object 2 or Object 3 fairly easily (or easily split it into two objects). I think Object 1 is out of scope for 2.1 (unless it’s already covered by sighting/Observed Data). I think Object
4 is out of scope for 2.1. I think Object 5 will be covered by the “collection vs. report” debate/object, for which we should soon have a proposal.

 
 

 
 
Thoughts are appreciated.

 
Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-ISAC)                   
31 Tech
Valley Drive
East Greenbush,
NY 12061
 
sarah.kelley@cisecurity.org
518-266-3493
24x7 Security Operations Center

SOC@cisecurity.org  - 1-866-787-4722

 

      
             
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.


. . . . .