OASIS Cyber Threat Intelligence (CTI) TC

I would say that, philosophically, we should do whichever option lets us finish STIX 2.1 as soon as possible while ensuring that it s usable and complete (note that I didn t say perfect ). We re waiting on 2.1 in order to do internationalization,
confidence, malware, and a whole pile of other things. These are critical capabilities that we can t share in a standardized way right now, and that s preventing people from using STIX 2. If we spend another year trying to get observed data perfect I think
we risk losing support and getting the perception that we won t finish things.
 
To that end, IMO the best options are #1 or #2 because they had the most support on the working calls (personally I prefer #5 but I think #1 and #2 are workable). So my suggestion would be that we do #1 or #2 and the people that prefer
it should address the comments from JMG and others (see working call notes from today) to ensure we don t lose the important aspects of observed-data when used to capture operational data observed by sensors. If we can get that done by the end of the review
period for WD02 let s include it in CSD01, otherwise let s defer to CSD02.
 
John


From: <cti@lists.oasis-open.org> on behalf of "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
Date: Tuesday, August 14, 2018 at 5:04 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Possible Changes to Observed Data


 


All,
 
There has been several discussions over the past few months about relaxing and making slight changes to Observed Data to make it useable for other use cases (Malware, Infrastructure, Incident, Intrusion Sets, etc). 
We have talked about it a few times on working calls and over slack and we now need to make a decision about what to do. As such we are bringing this issue to the email list for review and comment by the full TC.
 
Historically, the Observed Data object came to be after the great Arglebargle debate from the DC3 F2F meeting. The question at that time was, "should Cyber Observables (CybOX) be first order citizens or should they
be in a wrapper". At that time, most people felt like it should be in a wrapper, even though this would mean a graph inside of a graph. So the TC created the Observed Data Object to address one specific use case, that is relating cyber observables to another
STIX object, specifically an indicator, via the Sighting Relationship object. This would allow you to say, I saw this indicator, and what I saw is located in this Observed Data object. So all of the descriptions, normative text, and properties were designed
to address this one specific use case.
 
Fast forward 24 months, some TC members are now asking for a way to capture cyber observables that are not just "observations" (in the definition that was defined for Observed Data). They are looking for a more
generic container or solution so cyber observables can be documented, captured, and shared.  This data may come from an analyst that reads some report, this may come from a sandbox, this may come from a URL lookup service like URLVoid, etc, but the key point
is that it is not an "observation" it is just cyber observable data.
 
I have heard a few different options that we as a TC could take, if you have other ideas, please let us know. This is really a critical decision that the TC needs to address. The options I have heard are:
 
1) Relax Observed Data and some of the properties to make it useable by more use cases
 
2) Same as 1, but rename Observed Data to be something more appropriate
 
3) Created a different cyber observable container (this would mean we could have more than one, and that might cause confusion)
 
4) Revisit the ArgleBargle decision and look to make cyber observables first order citizens (this would get rid of the graph inside a graph design that some people have since complained about) 
 
5) Due nothing and try and create some other cyber observable property on objects that need cyber observables that are not "observations". This could represent multiple ways of doing the same thing, something we
have tried hard to avoid. 
 
 
## Personal Opinion ##
From my personal perspective, it would be nice if we could address this in this first CSD, since it may represent breaking changes. This does not mean we have to get it 100% correct for CSD01, as we can tweak it
and refine it more in CSD02 and CSD03.  But it would be nice to at least get the major changes done for CSD01. 
## END ##
 
Please comment here on the email list and help us understand what you as a TC member would like to have happen here. 
 
 
Bret
 
 
 
 
 

I support #1 -> #2 in that order.
 
Although I don t really see a need for #2 and therefore am primarily supportive on #1.
 
I agree with John s perspective on getting 2.1 done but that needs to include the new malware definition that I believe was leveraging this new relaxed observed data object.

 
That is why I think #1 is also the best course of action.
 
Regards
 
allan
 

From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org>
Date: Tuesday, August 14, 2018 at 2:38 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Possible Changes to Observed Data


 

I would say that, philosophically, we should do whichever option lets us finish STIX 2.1 as soon as possible while ensuring that it s usable and complete (note that I didn t say perfect ). We re waiting on 2.1 in order to do internationalization,
confidence, malware, and a whole pile of other things. These are critical capabilities that we can t share in a standardized way right now, and that s preventing people from using STIX 2. If we spend another year trying to get observed data perfect I think
we risk losing support and getting the perception that we won t finish things.
 
To that end, IMO the best options are #1 or #2 because they had the most support on the working calls (personally I prefer #5 but I think #1 and #2 are workable). So my suggestion would be that we do #1 or #2 and the people that prefer
it should address the comments from JMG and others (see working call notes from today) to ensure we don t lose the important aspects of observed-data when used to capture operational data observed by sensors. If we can get that done by the end of the review
period for WD02 let s include it in CSD01, otherwise let s defer to CSD02.
 
John

From: <cti@lists.oasis-open.org> on behalf of "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
Date: Tuesday, August 14, 2018 at 5:04 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Possible Changes to Observed Data


 


All,
 
There has been several discussions over the past few months about relaxing and making slight changes to Observed Data to make it useable for other use cases (Malware, Infrastructure, Incident, Intrusion Sets, etc). 
We have talked about it a few times on working calls and over slack and we now need to make a decision about what to do. As such we are bringing this issue to the email list for review and comment by the full TC.
 
Historically, the Observed Data object came to be after the great Arglebargle debate from the DC3 F2F meeting. The question at that time was, "should Cyber Observables (CybOX) be first order citizens or should they
be in a wrapper". At that time, most people felt like it should be in a wrapper, even though this would mean a graph inside of a graph. So the TC created the Observed Data Object to address one specific use case, that is relating cyber observables to another
STIX object, specifically an indicator, via the Sighting Relationship object. This would allow you to say, I saw this indicator, and what I saw is located in this Observed Data object. So all of the descriptions, normative text, and properties were designed
to address this one specific use case.
 
Fast forward 24 months, some TC members are now asking for a way to capture cyber observables that are not just "observations" (in the definition that was defined for Observed Data). They are looking for a more
generic container or solution so cyber observables can be documented, captured, and shared.  This data may come from an analyst that reads some report, this may come from a sandbox, this may come from a URL lookup service like URLVoid, etc, but the key point
is that it is not an "observation" it is just cyber observable data.
 
I have heard a few different options that we as a TC could take, if you have other ideas, please let us know. This is really a critical decision that the TC needs to address. The options I have heard are:
 
1) Relax Observed Data and some of the properties to make it useable by more use cases
 
2) Same as 1, but rename Observed Data to be something more appropriate
 
3) Created a different cyber observable container (this would mean we could have more than one, and that might cause confusion)
 
4) Revisit the ArgleBargle decision and look to make cyber observables first order citizens (this would get rid of the graph inside a graph design that some people have since complained about) 
 
5) Due nothing and try and create some other cyber observable property on objects that need cyber observables that are not "observations". This could represent multiple ways of doing the same thing, something we
have tried hard to avoid. 
 
 
## Personal Opinion ##
From my personal perspective, it would be nice if we could address this in this first CSD, since it may represent breaking changes. This does not mean we have to get it 100% correct for CSD01, as we can tweak it
and refine it more in CSD02 and CSD03.  But it would be nice to at least get the major changes done for CSD01. 
## END ##
 
Please comment here on the email list and help us understand what you as a TC member would like to have happen here. 
 
 
Bret
 
 
 
 
 

I support #1. I do not support #2, simply because
of the extremely large & cascading ramifications this has for software
implementors, for something so minor as the name of a JSON field not meant
to be primarily consumed by humans. - Jason Keirstead Lead Architect - IBM.Security www.ibm.com/security "Things may come to those who wait, but only the things left by those
who hustle." - Unknown From:      
  Allan Thomson <athomson@lookingglasscyber.com> To:      
  "Wunder, John
A." <jwunder@mitre.org>, "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org> Date:      
  08/14/2018 06:42 PM Subject:    
    Re: [cti] Possible
Changes to Observed Data Sent by:    
    <cti@lists.oasis-open.org> I support #1 -> #2 in that order.   Although I don t really see a need for
#2 and therefore am primarily supportive on #1.   I agree with John s perspective on getting
2.1 done but that needs to include the new malware definition that I believe
was leveraging this new relaxed observed data object.   That is why I think #1 is also the best
course of action.   Regards   allan   From: "cti@lists.oasis-open.org"
<cti@lists.oasis-open.org> on behalf of "Wunder, John"
<jwunder@mitre.org> Date: Tuesday, August 14, 2018 at 2:38 PM To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: Re: [cti] Possible Changes to Observed Data   I would say that, philosophically, we should
do whichever option lets us finish STIX 2.1 as soon as possible while ensuring
that it s usable and complete (note that I didn t say perfect ). We re
waiting on 2.1 in order to do internationalization, confidence, malware,
and a whole pile of other things. These are critical capabilities that
we can t share in a standardized way right now, and that s preventing
people from using STIX 2. If we spend another year trying to get observed
data perfect I think we risk losing support and getting the perception
that we won t finish things.   To that end, IMO the best options are #1
or #2 because they had the most support on the working calls (personally
I prefer #5 but I think #1 and #2 are workable). So my suggestion would
be that we do #1 or #2 and the people that prefer it should address the
comments from JMG and others (see working call notes from today) to ensure
we don t lose the important aspects of observed-data when used to capture
operational data observed by sensors. If we can get that done by the end
of the review period for WD02 let s include it in CSD01, otherwise let s
defer to CSD02.   John From: <cti@lists.oasis-open.org>
on behalf of "Bret Jordan (CS)" <Bret_Jordan@symantec.com> Date: Tuesday, August 14, 2018 at 5:04 PM To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: [cti] Possible Changes to Observed Data   All,   There has been several discussions over the past few months
about relaxing and making slight changes to Observed Data to make it useable
for other use cases (Malware, Infrastructure, Incident, Intrusion Sets,
etc).  We have talked about it a few times on working calls and over
slack and we now need to make a decision about what to do. As such we are
bringing this issue to the email list for review and comment by the full
TC.   Historically, the Observed Data object came to be after
the great Arglebargle debate from the DC3 F2F meeting. The question at
that time was, "should Cyber Observables (CybOX) be first order citizens
or should they be in a wrapper". At that time, most people felt like
it should be in a wrapper, even though this would mean a graph inside of
a graph. So the TC created the Observed Data Object to address one specific
use case, that is relating cyber observables to another STIX object, specifically
an indicator, via the Sighting Relationship object. This would allow you
to say, I saw this indicator, and what I saw is located in this Observed
Data object. So all of the descriptions, normative text, and properties
were designed to address this one specific use case.   Fast forward 24 months, some TC members are now asking
for a way to capture cyber observables that are not just "observations"
(in the definition that was defined for Observed Data). They are looking
for a more generic container or solution so cyber observables can be documented,
captured, and shared.  This data may come from an analyst that reads
some report, this may come from a sandbox, this may come from a URL lookup
service like URLVoid, etc, but the key point is that it is not an "observation"
it is just cyber observable data.   I have heard a few different options that we as a TC could
take, if you have other ideas, please let us know. This is really a critical
decision that the TC needs to address. The options I have heard are:   1) Relax Observed Data and some of the properties to make
it useable by more use cases   2) Same as 1, but rename Observed Data to be something
more appropriate   3) Created a different cyber observable container (this
would mean we could have more than one, and that might cause confusion)   4) Revisit the ArgleBargle decision and look to make cyber
observables first order citizens (this would get rid of the graph inside
a graph design that some people have since complained about)   5) Due nothing and try and create some other cyber observable
property on objects that need cyber observables that are not "observations".
This could represent multiple ways of doing the same thing, something we
have tried hard to avoid.     ## Personal Opinion ## From my personal perspective, it would be nice if we could
address this in this first CSD, since it may represent breaking changes.
This does not mean we have to get it 100% correct for CSD01, as we can
tweak it and refine it more in CSD02 and CSD03.  But it would be nice
to at least get the major changes done for CSD01. ## END ##   Please comment here on the email list and help us understand
what you as a TC member would like to have happen here.     Bret          

I support #1 and #4.

#1 minimizes the impact while gives the flexibility for broader use. We may have to watch to avoid implementation complexity. Too much flexibility can introduce
confusion.
#4 is needed in long run. I truly believe that observables are first class citizens. They are independent of any other attribute and can later contribute towards
automation via events.
 
Subodh Kumar    Executive
Director  Technology
Cybersecurity & Technology Controls
 J.P. Morgan Chase & Co. 
575 Washington Boulevard, Jersey City, NJ, 07310 T: +1
201 595 7299   subodh.kumar@jpmorgan.com
 
From: cti@lists.oasis-open.org [mailto: cti@lists.oasis-open.org ]
On Behalf Of Jason Keirstead
Sent: Wednesday, August 15, 2018 8:02 AM
To: Allan Thomson < athomson@lookingglasscyber.com >
Cc: cti@lists.oasis-open.org ; Wunder, John A. < jwunder@mitre.org >
Subject: Re: [cti] Possible Changes to Observed Data
 
I support #1.

I do not support #2, simply because of the extremely large & cascading ramifications this has for software implementors, for something so minor as the name of a JSON field not meant to be primarily
consumed by humans.

-
Jason Keirstead
Lead Architect - IBM.Security
www.ibm.com/security

"Things may come to those who wait, but only the things left by those who hustle." - Unknown





From:         Allan Thomson < athomson@lookingglasscyber.com >
To:         "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >
Date:         08/14/2018 06:42 PM
Subject:         Re: [cti] Possible Changes to Observed Data
Sent by:         < cti@lists.oasis-open.org >






I support #1 -> #2 in that order.
 
Although I don t really see a need for #2 and therefore am primarily supportive on #1.
 
I agree with John s perspective on getting 2.1 done but that needs to include the new malware definition that I believe was leveraging this new relaxed observed data object.

 
That is why I think #1 is also the best course of action.
 
Regards
 
allan
 
From: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
on behalf of "Wunder, John" < jwunder@mitre.org >
Date: Tuesday, August 14, 2018 at 2:38 PM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Possible Changes to Observed Data
 
I would say that, philosophically, we should do whichever option lets us finish STIX 2.1 as soon as possible while ensuring that it s usable and complete (note that I didn t say perfect ). We re
waiting on 2.1 in order to do internationalization, confidence, malware, and a whole pile of other things. These are critical capabilities that we can t share in a standardized way right now, and that s preventing people from using STIX 2. If we spend another
year trying to get observed data perfect I think we risk losing support and getting the perception that we won t finish things.
 
To that end, IMO the best options are #1 or #2 because they had the most support on the working calls (personally I prefer #5 but I think #1 and #2 are workable). So my suggestion would be that
we do #1 or #2 and the people that prefer it should address the comments from JMG and others (see working call notes from today) to ensure we don t lose the important aspects of observed-data when used to capture operational data observed by sensors. If we
can get that done by the end of the review period for WD02 let s include it in CSD01, otherwise let s defer to CSD02.
 
John
From: < cti@lists.oasis-open.org > on behalf of "Bret Jordan (CS)" < Bret_Jordan@symantec.com >
Date: Tuesday, August 14, 2018 at 5:04 PM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: [cti] Possible Changes to Observed Data
 
All,
 
There has been several discussions over the past few months about relaxing and making slight changes to Observed Data to make it useable for other use cases (Malware, Infrastructure, Incident, Intrusion Sets, etc).  We have talked about it a few times on
working calls and over slack and we now need to make a decision about what to do. As such we are bringing this issue to the email list for review and comment by the full TC.
 
Historically, the Observed Data object came to be after the great Arglebargle debate from the DC3 F2F meeting. The question at that time was, "should Cyber Observables (CybOX) be first order citizens or should they be in a wrapper". At that time, most people
felt like it should be in a wrapper, even though this would mean a graph inside of a graph. So the TC created the Observed Data Object to address one specific use case, that is relating cyber observables to another STIX object, specifically an indicator, via
the Sighting Relationship object. This would allow you to say, I saw this indicator, and what I saw is located in this Observed Data object. So all of the descriptions, normative text, and properties were designed to address this one specific use case.
 
Fast forward 24 months, some TC members are now asking for a way to capture cyber observables that are not just "observations" (in the definition that was defined for Observed Data). They are looking for a more generic container or solution so cyber observables
can be documented, captured, and shared.  This data may come from an analyst that reads some report, this may come from a sandbox, this may come from a URL lookup service like URLVoid, etc, but the key point is that it is not an "observation" it is just cyber
observable data.
 
I have heard a few different options that we as a TC could take, if you have other ideas, please let us know. This is really a critical decision that the TC needs to address. The options I have heard are:
 
1) Relax Observed Data and some of the properties to make it useable by more use cases
 
2) Same as 1, but rename Observed Data to be something more appropriate
 
3) Created a different cyber observable container (this would mean we could have more than one, and that might cause confusion)
 
4) Revisit the ArgleBargle decision and look to make cyber observables first order citizens (this would get rid of the graph inside a graph design that some people have since complained about)

 
5) Due nothing and try and create some other cyber observable property on objects that need cyber observables that are not "observations". This could represent multiple ways of doing the same thing, something we have tried hard to avoid.

 
 
## Personal Opinion ##
From my personal perspective, it would be nice if we could address this in this first CSD, since it may represent breaking changes. This does not mean we have to get it 100% correct for CSD01, as we can tweak it and refine it more in CSD02 and CSD03.  But
it would be nice to at least get the major changes done for CSD01.
## END ##
 
Please comment here on the email list and help us understand what you as a TC member would like to have happen here.

 
 
Bret
 
 
 
 
 
 

This message is confidential and subject to terms at: http:// www.jpmorgan.com/emaildisclaimer including on confidentiality, legal privilege, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.

Having been the one who pushed to release 2.1 in the Spring as is, I guess I have to also agree with #1.   However, I feel #3 is ultimately (2.2?) the right answer. Remember in STIX 1.x when we conflated observed data and patterns because they kinda looked the same?   From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com> Date: Wednesday, August 15, 2018 at 8:02 AM To: Allan Thomson <athomson@lookingglasscyber.com> Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, John Wunder <jwunder@mitre.org> Subject: Re: [cti] Possible Changes to Observed Data   I support #1. I do not support #2, simply because of the extremely large & cascading ramifications this has for software implementors, for something so minor as the name of a JSON field not meant to be primarily consumed by humans. - Jason Keirstead Lead Architect - IBM.Security www.ibm.com/security "Things may come to those who wait, but only the things left by those who hustle." - Unknown From:         Allan Thomson <athomson@lookingglasscyber.com> To:         "Wunder, John A." <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Date:         08/14/2018 06:42 PM Subject:         Re: [cti] Possible Changes to Observed Data Sent by:         <cti@lists.oasis-open.org> I support #1 -> #2 in that order.   Although I don t really see a need for #2 and therefore am primarily supportive on #1.   I agree with John s perspective on getting 2.1 done but that needs to include the new malware definition that I believe was leveraging this new relaxed observed data object.   That is why I think #1 is also the best course of action.   Regards   allan   From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org> Date: Tuesday, August 14, 2018 at 2:38 PM To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: Re: [cti] Possible Changes to Observed Data   I would say that, philosophically, we should do whichever option lets us finish STIX 2.1 as soon as possible while ensuring that it s usable and complete (note that I didn t say perfect ). We re waiting on 2.1 in order to do internationalization, confidence, malware, and a whole pile of other things. These are critical capabilities that we can t share in a standardized way right now, and that s preventing people from using STIX 2. If we spend another year trying to get observed data perfect I think we risk losing support and getting the perception that we won t finish things.   To that end, IMO the best options are #1 or #2 because they had the most support on the working calls (personally I prefer #5 but I think #1 and #2 are workable). So my suggestion would be that we do #1 or #2 and the people that prefer it should address the comments from JMG and others (see working call notes from today) to ensure we don t lose the important aspects of observed-data when used to capture operational data observed by sensors. If we can get that done by the end of the review period for WD02 let s include it in CSD01, otherwise let s defer to CSD02.   John From: <cti@lists.oasis-open.org> on behalf of "Bret Jordan (CS)" <Bret_Jordan@symantec.com> Date: Tuesday, August 14, 2018 at 5:04 PM To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: [cti] Possible Changes to Observed Data   All,   There has been several discussions over the past few months about relaxing and making slight changes to Observed Data to make it useable for other use cases (Malware, Infrastructure, Incident, Intrusion Sets, etc).  We have talked about it a few times on working calls and over slack and we now need to make a decision about what to do. As such we are bringing this issue to the email list for review and comment by the full TC.   Historically, the Observed Data object came to be after the great Arglebargle debate from the DC3 F2F meeting. The question at that time was, "should Cyber Observables (CybOX) be first order citizens or should they be in a wrapper". At that time, most people felt like it should be in a wrapper, even though this would mean a graph inside of a graph. So the TC created the Observed Data Object to address one specific use case, that is relating cyber observables to another STIX object, specifically an indicator, via the Sighting Relationship object. This would allow you to say, I saw this indicator, and what I saw is located in this Observed Data object. So all of the descriptions, normative text, and properties were designed to address this one specific use case.   Fast forward 24 months, some TC members are now asking for a way to capture cyber observables that are not just "observations" (in the definition that was defined for Observed Data). They are looking for a more generic container or solution so cyber observables can be documented, captured, and shared.  This data may come from an analyst that reads some report, this may come from a sandbox, this may come from a URL lookup service like URLVoid, etc, but the key point is that it is not an "observation" it is just cyber observable data.   I have heard a few different options that we as a TC could take, if you have other ideas, please let us know. This is really a critical decision that the TC needs to address. The options I have heard are:   1) Relax Observed Data and some of the properties to make it useable by more use cases   2) Same as 1, but rename Observed Data to be something more appropriate   3) Created a different cyber observable container (this would mean we could have more than one, and that might cause confusion)   4) Revisit the ArgleBargle decision and look to make cyber observables first order citizens (this would get rid of the graph inside a graph design that some people have since complained about)   5) Due nothing and try and create some other cyber observable property on objects that need cyber observables that are not "observations". This could represent multiple ways of doing the same thing, something we have tried hard to avoid.     ## Personal Opinion ## From my personal perspective, it would be nice if we could address this in this first CSD, since it may represent breaking changes. This does not mean we have to get it 100% correct for CSD01, as we can tweak it and refine it more in CSD02 and CSD03.  But it would be nice to at least get the major changes done for CSD01. ## END ##   Please comment here on the email list and help us understand what you as a TC member would like to have happen here.     Bret             Attachment: smime.p7s Description: S/MIME cryptographic signature

I m OK with #1 as long as we understand the implications of doing this and that we re changing the definition of Observed Data that we ve long held. E.g., are we comfortable with the fact that users can now create Observed Data instances without specifying the time window during which the data was observed and how many times it as observed during that window?   We also still haven t changed the definition of the objects property which stipulates that any Observables captured must be part of the same graph (i.e., related to each other). This is particularly problematic for use cases such as the capture of malware sandbox analysis data where you may end up with a large collection of unrelated Observables.   Regards, Ivan   From: <cti@lists.oasis-open.org> on behalf of Rich Piazza <rpiazza@mitre.org> Date: Wednesday, August 15, 2018 at 6:19 AM To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Allan Thomson <athomson@lookingglasscyber.com> Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, John Wunder <jwunder@mitre.org> Subject: Re: [cti] Possible Changes to Observed Data   Having been the one who pushed to release 2.1 in the Spring as is, I guess I have to also agree with #1.   However, I feel #3 is ultimately (2.2?) the right answer.  Remember in STIX 1.x when we conflated observed data and patterns because they kinda looked the same?   From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com> Date: Wednesday, August 15, 2018 at 8:02 AM To: Allan Thomson <athomson@lookingglasscyber.com> Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, John Wunder <jwunder@mitre.org> Subject: Re: [cti] Possible Changes to Observed Data   I support #1. I do not support #2, simply because of the extremely large & cascading ramifications this has for software implementors, for something so minor as the name of a JSON field not meant to be primarily consumed by humans. - Jason Keirstead Lead Architect - IBM.Security www.ibm.com/security "Things may come to those who wait, but only the things left by those who hustle." - Unknown From:         Allan Thomson <athomson@lookingglasscyber.com> To:         "Wunder, John A." <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Date:         08/14/2018 06:42 PM Subject:         Re: [cti] Possible Changes to Observed Data Sent by:         <cti@lists.oasis-open.org> I support #1 -> #2 in that order.   Although I don t really see a need for #2 and therefore am primarily supportive on #1.   I agree with John s perspective on getting 2.1 done but that needs to include the new malware definition that I believe was leveraging this new relaxed observed data object.   That is why I think #1 is also the best course of action.   Regards   allan   From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org> Date: Tuesday, August 14, 2018 at 2:38 PM To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: Re: [cti] Possible Changes to Observed Data   I would say that, philosophically, we should do whichever option lets us finish STIX 2.1 as soon as possible while ensuring that it s usable and complete (note that I didn t say perfect ). We re waiting on 2.1 in order to do internationalization, confidence, malware, and a whole pile of other things. These are critical capabilities that we can t share in a standardized way right now, and that s preventing people from using STIX 2. If we spend another year trying to get observed data perfect I think we risk losing support and getting the perception that we won t finish things.   To that end, IMO the best options are #1 or #2 because they had the most support on the working calls (personally I prefer #5 but I think #1 and #2 are workable). So my suggestion would be that we do #1 or #2 and the people that prefer it should address the comments from JMG and others (see working call notes from today) to ensure we don t lose the important aspects of observed-data when used to capture operational data observed by sensors. If we can get that done by the end of the review period for WD02 let s include it in CSD01, otherwise let s defer to CSD02.   John From: <cti@lists.oasis-open.org> on behalf of "Bret Jordan (CS)" <Bret_Jordan@symantec.com> Date: Tuesday, August 14, 2018 at 5:04 PM To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: [cti] Possible Changes to Observed Data   All,   There has been several discussions over the past few months about relaxing and making slight changes to Observed Data to make it useable for other use cases (Malware, Infrastructure, Incident, Intrusion Sets, etc).  We have talked about it a few times on working calls and over slack and we now need to make a decision about what to do. As such we are bringing this issue to the email list for review and comment by the full TC.   Historically, the Observed Data object came to be after the great Arglebargle debate from the DC3 F2F meeting. The question at that time was, "should Cyber Observables (CybOX) be first order citizens or should they be in a wrapper". At that time, most people felt like it should be in a wrapper, even though this would mean a graph inside of a graph. So the TC created the Observed Data Object to address one specific use case, that is relating cyber observables to another STIX object, specifically an indicator, via the Sighting Relationship object. This would allow you to say, I saw this indicator, and what I saw is located in this Observed Data object. So all of the descriptions, normative text, and properties were designed to address this one specific use case.   Fast forward 24 months, some TC members are now asking for a way to capture cyber observables that are not just "observations" (in the definition that was defined for Observed Data). They are looking for a more generic container or solution so cyber observables can be documented, captured, and shared.  This data may come from an analyst that reads some report, this may come from a sandbox, this may come from a URL lookup service like URLVoid, etc, but the key point is that it is not an "observation" it is just cyber observable data.   I have heard a few different options that we as a TC could take, if you have other ideas, please let us know. This is really a critical decision that the TC needs to address. The options I have heard are:   1) Relax Observed Data and some of the properties to make it useable by more use cases   2) Same as 1, but rename Observed Data to be something more appropriate   3) Created a different cyber observable container (this would mean we could have more than one, and that might cause confusion)   4) Revisit the ArgleBargle decision and look to make cyber observables first order citizens (this would get rid of the graph inside a graph design that some people have since complained about)   5) Due nothing and try and create some other cyber observable property on objects that need cyber observables that are not "observations". This could represent multiple ways of doing the same thing, something we have tried hard to avoid.     ## Personal Opinion ## From my personal perspective, it would be nice if we could address this in this first CSD, since it may represent breaking changes. This does not mean we have to get it 100% correct for CSD01, as we can tweak it and refine it more in CSD02 and CSD03.  But it would be nice to at least get the major changes done for CSD01. ## END ##   Please comment here on the email list and help us understand what you as a TC member would like to have happen here.     Bret             Attachment: smime.p7s Description: S/MIME cryptographic signature

Ivan I believe that the primary use cases where systems do capture the time window and number of instances, they * will * provide that information. There is a good intelligence use of that information being provided and more mature
use of that data will naturally select providers that have it to share.
 
But there are also certain use cases where it s not known and those use cases should not be precluded by the schema itself.
 
Regarding the objects property definition. I m not exactly sure how we were going to test that all observables are related to each other anyway. That is a complicated analysis if you have systems reporting both network and host based observations
in the same observed data object. I doubt most systems would be testing for the connected-ness of the data to begin with.

 
From my perspective I suggest we let the market/products dictate how complete their data sets are rather than excluding use cases solely based on a spec.
Allan
 

From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Kirillov, Ivan" <ikirillov@mitre.org>
Date: Wednesday, August 15, 2018 at 6:29 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Possible Changes to Observed Data


 

I m OK with #1 as long as we understand the implications of doing this and that we re changing the definition of Observed Data that we ve long held. E.g., are we comfortable with the fact that users can now create Observed Data instances
without specifying the time window during which the data was observed and how many times it as observed during that window?
 
We also still haven t changed the definition of the objects property which stipulates that any Observables captured must be part of the same graph (i.e., related to each other). This is particularly problematic for use cases such as the
capture of malware sandbox analysis data where you may end up with a large collection of unrelated Observables.
 
Regards,
Ivan
 

From: <cti@lists.oasis-open.org> on behalf of Rich Piazza <rpiazza@mitre.org>
Date: Wednesday, August 15, 2018 at 6:19 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Allan Thomson <athomson@lookingglasscyber.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, John Wunder <jwunder@mitre.org>
Subject: Re: [cti] Possible Changes to Observed Data


 

Having been the one who pushed to release 2.1 in the Spring as is, I guess I have to also agree with #1.
 
However, I feel #3 is ultimately (2.2?) the right answer.  Remember in STIX 1.x when we conflated observed data and patterns because they kinda looked the same?
 

From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, August 15, 2018 at 8:02 AM
To: Allan Thomson <athomson@lookingglasscyber.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, John Wunder <jwunder@mitre.org>
Subject: Re: [cti] Possible Changes to Observed Data


 

I support #1.

I do not support #2, simply because of the extremely large & cascading ramifications this has for software implementors, for something so minor as the name of a JSON field not meant to be primarily
consumed by humans.

-
Jason Keirstead
Lead Architect - IBM.Security
www.ibm.com/security

"Things may come to those who wait, but only the things left by those who hustle." - Unknown





From:         Allan Thomson <athomson@lookingglasscyber.com>
To:         "Wunder, John A." <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date:         08/14/2018 06:42 PM
Subject:         Re: [cti] Possible Changes to Observed Data
Sent by:         <cti@lists.oasis-open.org>






I support #1 -> #2 in that order.
 
Although I don t really see a need for #2 and therefore am primarily supportive on #1.
 
I agree with John s perspective on getting 2.1 done but that needs to include the new malware definition that I believe was leveraging this new relaxed observed data object.

 
That is why I think #1 is also the best course of action.
 
Regards
 
allan
 
From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org>
Date: Tuesday, August 14, 2018 at 2:38 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Possible Changes to Observed Data
 
I would say that, philosophically, we should do whichever option lets us finish STIX 2.1 as soon as possible while ensuring that it s usable and complete (note that I didn t say perfect ). We re waiting on 2.1 in order to do
internationalization, confidence, malware, and a whole pile of other things. These are critical capabilities that we can t share in a standardized way right now, and that s preventing people from using STIX 2. If we spend another year trying to get observed
data perfect I think we risk losing support and getting the perception that we won t finish things.
 
To that end, IMO the best options are #1 or #2 because they had the most support on the working calls (personally I prefer #5 but I think #1 and #2 are workable). So my suggestion would be that we do #1 or #2 and the people that
prefer it should address the comments from JMG and others (see working call notes from today) to ensure we don t lose the important aspects of observed-data when used to capture operational data observed by sensors. If we can get that done by the end of the
review period for WD02 let s include it in CSD01, otherwise let s defer to CSD02.
 
John
From: <cti@lists.oasis-open.org> on behalf of "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
Date: Tuesday, August 14, 2018 at 5:04 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Possible Changes to Observed Data
 
All,
 
There has been several discussions over the past few months about relaxing and making slight changes to Observed Data to make it useable for other use cases (Malware, Infrastructure, Incident, Intrusion Sets, etc).  We have
talked about it a few times on working calls and over slack and we now need to make a decision about what to do. As such we are bringing this issue to the email list for review and comment by the full TC.
 
Historically, the Observed Data object came to be after the great Arglebargle debate from the DC3 F2F meeting. The question at that time was, "should Cyber Observables (CybOX) be first order citizens or should they be in a
wrapper". At that time, most people felt like it should be in a wrapper, even though this would mean a graph inside of a graph. So the TC created the Observed Data Object to address one specific use case, that is relating cyber observables to another STIX
object, specifically an indicator, via the Sighting Relationship object. This would allow you to say, I saw this indicator, and what I saw is located in this Observed Data object. So all of the descriptions, normative text, and properties were designed to
address this one specific use case.
 
Fast forward 24 months, some TC members are now asking for a way to capture cyber observables that are not just "observations" (in the definition that was defined for Observed Data). They are looking for a more generic container
or solution so cyber observables can be documented, captured, and shared.  This data may come from an analyst that reads some report, this may come from a sandbox, this may come from a URL lookup service like URLVoid, etc, but the key point is that it is not
an "observation" it is just cyber observable data.
 
I have heard a few different options that we as a TC could take, if you have other ideas, please let us know. This is really a critical decision that the TC needs to address. The options I have heard are:
 
1) Relax Observed Data and some of the properties to make it useable by more use cases
 
2) Same as 1, but rename Observed Data to be something more appropriate
 
3) Created a different cyber observable container (this would mean we could have more than one, and that might cause confusion)
 
4) Revisit the ArgleBargle decision and look to make cyber observables first order citizens (this would get rid of the graph inside a graph design that some people have since complained about)

 
5) Due nothing and try and create some other cyber observable property on objects that need cyber observables that are not "observations". This could represent multiple ways of doing the same thing, something we have tried
hard to avoid.
 
 
## Personal Opinion ##
From my personal perspective, it would be nice if we could address this in this first CSD, since it may represent breaking changes. This does not mean we have to get it 100% correct for CSD01, as we can tweak it and refine
it more in CSD02 and CSD03.  But it would be nice to at least get the major changes done for CSD01.

## END ##
 
Please comment here on the email list and help us understand what you as a TC member would like to have happen here.

 
 
Bret
 
 
 
 
 
 

Allan I don t disagree that we should be flexible enough to meet the various use cases needed by the market. However, I think the issues we re running into here are based on our attempt to rearchitect Observed Data around an entirely
different set of use cases than originally envisioned, which is why I want to make sure that whatever we end up with is coherent from both a specification perspective and for implementers/end users as well.
 
Regards,
Ivan
 

From: <cti@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Wednesday, August 15, 2018 at 7:40 AM
To: Ivan Kirillov <ikirillov@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Possible Changes to Observed Data


 

Ivan I believe that the primary use cases where systems do capture the time window and number of instances, they * will * provide that information. There is a good intelligence use of that information being provided and more mature
use of that data will naturally select providers that have it to share.
 
But there are also certain use cases where it s not known and those use cases should not be precluded by the schema itself.
 
Regarding the objects property definition. I m not exactly sure how we were going to test that all observables are related to each other anyway. That is a complicated analysis if you have systems reporting both network and host based observations
in the same observed data object. I doubt most systems would be testing for the connected-ness of the data to begin with.

 
From my perspective I suggest we let the market/products dictate how complete their data sets are rather than excluding use cases solely based on a spec.
Allan
 

From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Kirillov, Ivan" <ikirillov@mitre.org>
Date: Wednesday, August 15, 2018 at 6:29 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Possible Changes to Observed Data


 

I m OK with #1 as long as we understand the implications of doing this and that we re changing the definition of Observed Data that we ve long held. E.g., are we comfortable with the fact that users can now create Observed Data instances
without specifying the time window during which the data was observed and how many times it as observed during that window?
 
We also still haven t changed the definition of the objects property which stipulates that any Observables captured must be part of the same graph (i.e., related to each other). This is particularly problematic for use cases such as the
capture of malware sandbox analysis data where you may end up with a large collection of unrelated Observables.
 
Regards,
Ivan
 

From: <cti@lists.oasis-open.org> on behalf of Rich Piazza <rpiazza@mitre.org>
Date: Wednesday, August 15, 2018 at 6:19 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Allan Thomson <athomson@lookingglasscyber.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, John Wunder <jwunder@mitre.org>
Subject: Re: [cti] Possible Changes to Observed Data


 

Having been the one who pushed to release 2.1 in the Spring as is, I guess I have to also agree with #1.
 
However, I feel #3 is ultimately (2.2?) the right answer.  Remember in STIX 1.x when we conflated observed data and patterns because they kinda looked the same?
 

From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, August 15, 2018 at 8:02 AM
To: Allan Thomson <athomson@lookingglasscyber.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, John Wunder <jwunder@mitre.org>
Subject: Re: [cti] Possible Changes to Observed Data


 

I support #1.

I do not support #2, simply because of the extremely large & cascading ramifications this has for software implementors, for something so minor as the name of a JSON field not meant to be primarily
consumed by humans.

-
Jason Keirstead
Lead Architect - IBM.Security
www.ibm.com/security

"Things may come to those who wait, but only the things left by those who hustle." - Unknown





From:         Allan Thomson <athomson@lookingglasscyber.com>
To:         "Wunder, John A." <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date:         08/14/2018 06:42 PM
Subject:         Re: [cti] Possible Changes to Observed Data
Sent by:         <cti@lists.oasis-open.org>






I support #1 -> #2 in that order.
 
Although I don t really see a need for #2 and therefore am primarily supportive on #1.
 
I agree with John s perspective on getting 2.1 done but that needs to include the new malware definition that I believe was leveraging this new relaxed observed data object.

 
That is why I think #1 is also the best course of action.
 
Regards
 
allan
 
From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org>
Date: Tuesday, August 14, 2018 at 2:38 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Possible Changes to Observed Data
 
I would say that, philosophically, we should do whichever option lets us finish STIX 2.1 as soon as possible while ensuring that it s usable and complete (note that I didn t say perfect ). We re waiting on 2.1 in order to do
internationalization, confidence, malware, and a whole pile of other things. These are critical capabilities that we can t share in a standardized way right now, and that s preventing people from using STIX 2. If we spend another year trying to get observed
data perfect I think we risk losing support and getting the perception that we won t finish things.
 
To that end, IMO the best options are #1 or #2 because they had the most support on the working calls (personally I prefer #5 but I think #1 and #2 are workable). So my suggestion would be that we do #1 or #2 and the people that
prefer it should address the comments from JMG and others (see working call notes from today) to ensure we don t lose the important aspects of observed-data when used to capture operational data observed by sensors. If we can get that done by the end of the
review period for WD02 let s include it in CSD01, otherwise let s defer to CSD02.
 
John
From: <cti@lists.oasis-open.org> on behalf of "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
Date: Tuesday, August 14, 2018 at 5:04 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Possible Changes to Observed Data
 
All,
 
There has been several discussions over the past few months about relaxing and making slight changes to Observed Data to make it useable for other use cases (Malware, Infrastructure, Incident, Intrusion Sets, etc).  We have
talked about it a few times on working calls and over slack and we now need to make a decision about what to do. As such we are bringing this issue to the email list for review and comment by the full TC.
 
Historically, the Observed Data object came to be after the great Arglebargle debate from the DC3 F2F meeting. The question at that time was, "should Cyber Observables (CybOX) be first order citizens or should they be in a
wrapper". At that time, most people felt like it should be in a wrapper, even though this would mean a graph inside of a graph. So the TC created the Observed Data Object to address one specific use case, that is relating cyber observables to another STIX
object, specifically an indicator, via the Sighting Relationship object. This would allow you to say, I saw this indicator, and what I saw is located in this Observed Data object. So all of the descriptions, normative text, and properties were designed to
address this one specific use case.
 
Fast forward 24 months, some TC members are now asking for a way to capture cyber observables that are not just "observations" (in the definition that was defined for Observed Data). They are looking for a more generic container
or solution so cyber observables can be documented, captured, and shared.  This data may come from an analyst that reads some report, this may come from a sandbox, this may come from a URL lookup service like URLVoid, etc, but the key point is that it is not
an "observation" it is just cyber observable data.
 
I have heard a few different options that we as a TC could take, if you have other ideas, please let us know. This is really a critical decision that the TC needs to address. The options I have heard are:
 
1) Relax Observed Data and some of the properties to make it useable by more use cases
 
2) Same as 1, but rename Observed Data to be something more appropriate
 
3) Created a different cyber observable container (this would mean we could have more than one, and that might cause confusion)
 
4) Revisit the ArgleBargle decision and look to make cyber observables first order citizens (this would get rid of the graph inside a graph design that some people have since complained about)

 
5) Due nothing and try and create some other cyber observable property on objects that need cyber observables that are not "observations". This could represent multiple ways of doing the same thing, something we have tried
hard to avoid.
 
 
## Personal Opinion ##
From my personal perspective, it would be nice if we could address this in this first CSD, since it may represent breaking changes. This does not mean we have to get it 100% correct for CSD01, as we can tweak it and refine
it more in CSD02 and CSD03.  But it would be nice to at least get the major changes done for CSD01.

## END ##
 
Please comment here on the email list and help us understand what you as a TC member would like to have happen here.

 
 
Bret
 
 
 
 
 
 

My views are:


#1 this is the easiest and quickest, but least eloquent 


#2 this would remove some of the baggage we have with the term Observed Data and its connotations that Ivan brings up. If we do this we should fix property names too. 


#3 I am not a fan of this right now, as I think #4 would be the better choice and I would worry that we would end up with multiple containers for cyber observables. I could get behind this if we made it a super generic wrapper.


#4 I am really starting to think this might be the best choice. But we would need to look at this after CSD01 given how much time it would take 


#5 I personally do not like this option at all.


Bret 






Sent from my Commodore 64 


PGP
Fingerprint:  63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050


On Aug 15, 2018, at 8:00 AM, Kirillov, Ivan A. < ikirillov@mitre.org > wrote:







Allan I don t disagree that we should be flexible enough to meet the various use cases needed by the market. However, I think the issues we re running into here are based on our attempt to rearchitect Observed Data around an entirely
different set of use cases than originally envisioned, which is why I want to make sure that whatever we end up with is coherent from both a specification perspective and for implementers/end users as well.
 
Regards,
Ivan
 

From: < cti@lists.oasis-open.org > on behalf of Allan Thomson < athomson@lookingglasscyber.com >
Date: Wednesday, August 15, 2018 at 7:40 AM
To: Ivan Kirillov < ikirillov@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Possible Changes to Observed Data


 

Ivan I believe that the primary use cases where systems do capture the time window and number of instances, they * will * provide that information. There is a good intelligence use of that information being provided and more mature
use of that data will naturally select providers that have it to share.
 
But there are also certain use cases where it s not known and those use cases should not be precluded by the schema itself.
 
Regarding the objects property definition. I m not exactly sure how we were going to test that all observables are related to each other anyway. That is a complicated analysis if you have systems reporting both network and host based observations
in the same observed data object. I doubt most systems would be testing for the connected-ness of the data to begin with.

 
From my perspective I suggest we let the market/products dictate how complete their data sets are rather than excluding use cases solely based on a spec.
Allan
 

From: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
on behalf of "Kirillov, Ivan" < ikirillov@mitre.org >
Date: Wednesday, August 15, 2018 at 6:29 AM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Possible Changes to Observed Data


 

I m OK with #1 as long as we understand the implications of doing this and that we re changing the definition of Observed Data that we ve long held. E.g., are we comfortable with the fact that users can now create Observed Data instances
without specifying the time window during which the data was observed and how many times it as observed during that window?
 
We also still haven t changed the definition of the objects property which stipulates that any Observables captured must be part of the same graph (i.e., related to each other). This is particularly problematic for use cases such as the
capture of malware sandbox analysis data where you may end up with a large collection of unrelated Observables.
 
Regards,
Ivan
 

From: < cti@lists.oasis-open.org > on behalf of Rich Piazza < rpiazza@mitre.org >
Date: Wednesday, August 15, 2018 at 6:19 AM
To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Allan Thomson < athomson@lookingglasscyber.com >
Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, John Wunder < jwunder@mitre.org >
Subject: Re: [cti] Possible Changes to Observed Data


 

Having been the one who pushed to release 2.1 in the Spring as is, I guess I have to also agree with #1.
 
However, I feel #3 is ultimately (2.2?) the right answer.  Remember in STIX 1.x when we conflated observed data and patterns because they kinda looked the same?
 

From: < cti@lists.oasis-open.org > on behalf of Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Date: Wednesday, August 15, 2018 at 8:02 AM
To: Allan Thomson < athomson@lookingglasscyber.com >
Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, John Wunder < jwunder@mitre.org >
Subject: Re: [cti] Possible Changes to Observed Data


 

I support #1.

I do not support #2, simply because of the extremely large & cascading ramifications this has for software implementors, for something so minor as the name of a JSON field not meant to be primarily
consumed by humans.

-
Jason Keirstead
Lead Architect - IBM.Security
www.ibm.com/security

"Things may come to those who wait, but only the things left by those who hustle." - Unknown





From:         Allan Thomson < athomson@lookingglasscyber.com >
To:         "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >
Date:         08/14/2018 06:42 PM
Subject:         Re: [cti] Possible Changes to Observed Data
Sent by:         < cti@lists.oasis-open.org >






I support #1 -> #2 in that order.
 
Although I don t really see a need for #2 and therefore am primarily supportive on #1.
 
I agree with John s perspective on getting 2.1 done but that needs to include the new malware definition that I believe was leveraging this new relaxed observed data object.

 
That is why I think #1 is also the best course of action.
 
Regards
 
allan
 
From: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > on behalf of "Wunder, John" < jwunder@mitre.org >
Date: Tuesday, August 14, 2018 at 2:38 PM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: Re: [cti] Possible Changes to Observed Data
 
I would say that, philosophically, we should do whichever option lets us finish STIX 2.1 as soon as possible while ensuring that it s usable and complete (note that I didn t say perfect ). We re waiting on 2.1 in order to do
internationalization, confidence, malware, and a whole pile of other things. These are critical capabilities that we can t share in a standardized way right now, and that s preventing people from using STIX 2. If we spend another year trying to get observed
data perfect I think we risk losing support and getting the perception that we won t finish things.
 
To that end, IMO the best options are #1 or #2 because they had the most support on the working calls (personally I prefer #5 but I think #1 and #2 are workable). So my suggestion would be that we do #1 or #2 and the people that
prefer it should address the comments from JMG and others (see working call notes from today) to ensure we don t lose the important aspects of observed-data when used to capture operational data observed by sensors. If we can get that done by the end of the
review period for WD02 let s include it in CSD01, otherwise let s defer to CSD02.
 
John
From: < cti@lists.oasis-open.org > on behalf of "Bret Jordan (CS)" < Bret_Jordan@symantec.com >
Date: Tuesday, August 14, 2018 at 5:04 PM
To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: [cti] Possible Changes to Observed Data
 
All,
 
There has been several discussions over the past few months about relaxing and making slight changes to Observed Data to make it useable for other use cases (Malware, Infrastructure, Incident, Intrusion Sets, etc).  We have
talked about it a few times on working calls and over slack and we now need to make a decision about what to do. As such we are bringing this issue to the email list for review and comment by the full TC.
 
Historically, the Observed Data object came to be after the great Arglebargle debate from the DC3 F2F meeting. The question at that time was, "should Cyber Observables (CybOX) be first order citizens or should they be in a
wrapper". At that time, most people felt like it should be in a wrapper, even though this would mean a graph inside of a graph. So the TC created the Observed Data Object to address one specific use case, that is relating cyber observables to another STIX
object, specifically an indicator, via the Sighting Relationship object. This would allow you to say, I saw this indicator, and what I saw is located in this Observed Data object. So all of the descriptions, normative text, and properties were designed to
address this one specific use case.
 
Fast forward 24 months, some TC members are now asking for a way to capture cyber observables that are not just "observations" (in the definition that was defined for Observed Data). They are looking for a more generic container
or solution so cyber observables can be documented, captured, and shared.  This data may come from an analyst that reads some report, this may come from a sandbox, this may come from a URL lookup service like URLVoid, etc, but the key point is that it is not
an "observation" it is just cyber observable data.
 
I have heard a few different options that we as a TC could take, if you have other ideas, please let us know. This is really a critical decision that the TC needs to address. The options I have heard are:
 
1) Relax Observed Data and some of the properties to make it useable by more use cases
 
2) Same as 1, but rename Observed Data to be something more appropriate
 
3) Created a different cyber observable container (this would mean we could have more than one, and that might cause confusion)
 
4) Revisit the ArgleBargle decision and look to make cyber observables first order citizens (this would get rid of the graph inside a graph design that some people have since complained about)

 
5) Due nothing and try and create some other cyber observable property on objects that need cyber observables that are not "observations". This could represent multiple ways of doing the same thing, something we have tried
hard to avoid.
 
 
## Personal Opinion ##
From my personal perspective, it would be nice if we could address this in this first CSD, since it may represent breaking changes. This does not mean we have to get it 100% correct for CSD01, as we can tweak it and refine
it more in CSD02 and CSD03.  But it would be nice to at least get the major changes done for CSD01.

## END ##
 
Please comment here on the email list and help us understand what you as a TC member would like to have happen here.

 
 
Bret
 
 
 
 
 
 

Kirillov, Ivan A. wrote this message on Wed, Aug 15, 2018 at 13:29 +0000: > I m OK with #1 as long as we understand the implications of doing this and that we re changing the definition of Observed Data that we ve long held. E.g., are we comfortable with the fact that users can now create Observed Data instances without specifying the time window during which the data was observed and how many times it as observed during that window? The changes made had no requirement that first/last_observed be present when number_observed is present. > We also still haven t changed the definition of the objects property which stipulates that any Observables captured must be part of the same graph (i.e., related to each other). This is particularly problematic for use cases such as the capture of malware sandbox analysis data where you may end up with a large collection of unrelated Observables. Only if we use the observed data object, the related definition is only in observed-data, not in observable-objects. Current malware uses observable-objects directly, and so no related requirement. > From: <cti@lists.oasis-open.org> on behalf of Rich Piazza <rpiazza@mitre.org> > Date: Wednesday, August 15, 2018 at 6:19 AM > To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Allan Thomson <athomson@lookingglasscyber.com> > Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, John Wunder <jwunder@mitre.org> > Subject: Re: [cti] Possible Changes to Observed Data > > > > Having been the one who pushed to release 2.1 in the Spring as is, I guess I have to also agree with #1. > > > > However, I feel #3 is ultimately (2.2?) the right answer. Remember in STIX 1.x when we conflated observed data and patterns because they kinda looked the same? > > > > From: <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com> > Date: Wednesday, August 15, 2018 at 8:02 AM > To: Allan Thomson <athomson@lookingglasscyber.com> > Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, John Wunder <jwunder@mitre.org> > Subject: Re: [cti] Possible Changes to Observed Data > > > > I support #1. > > I do not support #2, simply because of the extremely large & cascading ramifications this has for software implementors, for something so minor as the name of a JSON field not meant to be primarily consumed by humans. > > - > Jason Keirstead > Lead Architect - IBM.Security > www.ibm.com/security > > "Things may come to those who wait, but only the things left by those who hustle." - Unknown > > > > > From: Allan Thomson <athomson@lookingglasscyber.com> > To: "Wunder, John A." <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> > Date: 08/14/2018 06:42 PM > Subject: Re: [cti] Possible Changes to Observed Data > Sent by: <cti@lists.oasis-open.org> > > > > > I support #1 -> #2 in that order. > > Although I don t really see a need for #2 and therefore am primarily supportive on #1. > > I agree with John s perspective on getting 2.1 done but that needs to include the new malware definition that I believe was leveraging this new relaxed observed data object. > > That is why I think #1 is also the best course of action. > > Regards > > allan > > From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org> > Date: Tuesday, August 14, 2018 at 2:38 PM > To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> > Subject: Re: [cti] Possible Changes to Observed Data > > I would say that, philosophically, we should do whichever option lets us finish STIX 2.1 as soon as possible while ensuring that it s usable and complete (note that I didn t say perfect ). We re waiting on 2.1 in order to do internationalization, confidence, malware, and a whole pile of other things. These are critical capabilities that we can t share in a standardized way right now, and that s preventing people from using STIX 2. If we spend another year trying to get observed data perfect I think we risk losing support and getting the perception that we won t finish things. > > To that end, IMO the best options are #1 or #2 because they had the most support on the working calls (personally I prefer #5 but I think #1 and #2 are workable). So my suggestion would be that we do #1 or #2 and the people that prefer it should address the comments from JMG and others (see working call notes from today) to ensure we don t lose the important aspects of observed-data when used to capture operational data observed by sensors. If we can get that done by the end of the review period for WD02 let s include it in CSD01, otherwise let s defer to CSD02. > > John > From: <cti@lists.oasis-open.org> on behalf of "Bret Jordan (CS)" <Bret_Jordan@symantec.com> > Date: Tuesday, August 14, 2018 at 5:04 PM > To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> > Subject: [cti] Possible Changes to Observed Data > > > All, > > > > There has been several discussions over the past few months about relaxing and making slight changes to Observed Data to make it useable for other use cases (Malware, Infrastructure, Incident, Intrusion Sets, etc). We have talked about it a few times on working calls and over slack and we now need to make a decision about what to do. As such we are bringing this issue to the email list for review and comment by the full TC. > > > > Historically, the Observed Data object came to be after the great Arglebargle debate from the DC3 F2F meeting. The question at that time was, "should Cyber Observables (CybOX) be first order citizens or should they be in a wrapper". At that time, most people felt like it should be in a wrapper, even though this would mean a graph inside of a graph. So the TC created the Observed Data Object to address one specific use case, that is relating cyber observables to another STIX object, specifically an indicator, via the Sighting Relationship object. This would allow you to say, I saw this indicator, and what I saw is located in this Observed Data object. So all of the descriptions, normative text, and properties were designed to address this one specific use case. > > > > Fast forward 24 months, some TC members are now asking for a way to capture cyber observables that are not just "observations" (in the definition that was defined for Observed Data). They are looking for a more generic container or solution so cyber observables can be documented, captured, and shared. This data may come from an analyst that reads some report, this may come from a sandbox, this may come from a URL lookup service like URLVoid, etc, but the key point is that it is not an "observation" it is just cyber observable data. > > > > I have heard a few different options that we as a TC could take, if you have other ideas, please let us know. This is really a critical decision that the TC needs to address. The options I have heard are: > > > > 1) Relax Observed Data and some of the properties to make it useable by more use cases > > > > 2) Same as 1, but rename Observed Data to be something more appropriate > > > > 3) Created a different cyber observable container (this would mean we could have more than one, and that might cause confusion) > > > > 4) Revisit the ArgleBargle decision and look to make cyber observables first order citizens (this would get rid of the graph inside a graph design that some people have since complained about) > > > > 5) Due nothing and try and create some other cyber observable property on objects that need cyber observables that are not "observations". This could represent multiple ways of doing the same thing, something we have tried hard to avoid. > > > > > > ## Personal Opinion ## > > From my personal perspective, it would be nice if we could address this in this first CSD, since it may represent breaking changes. This does not mean we have to get it 100% correct for CSD01, as we can tweak it and refine it more in CSD02 and CSD03. But it would be nice to at least get the major changes done for CSD01. > > ## END ## > > > > Please comment here on the email list and help us understand what you as a TC member would like to have happen here. > -- John-Mark

John-Mark,


I think the idea is that Malware and other things like it will use embedded relationships to observed data or something like observed data.


Bret 

Sent from my Commodore 64 


PGP
Fingerprint:  63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050


On Aug 15, 2018, at 10:55 AM, John-Mark Gurney < jmg@newcontext.com > wrote:



Kirillov, Ivan A. wrote this message on Wed, Aug 15, 2018 at 13:29 +0000:
I m OK with #1 as long as we understand the implications of doing this and that we re changing the definition of Observed Data that we ve long held. E.g., are we comfortable with the fact that users can now create Observed Data
instances without specifying the time window during which the data was observed and how many times it as observed during that window?


The changes made had no requirement that first/last_observed be present
when number_observed is present.

We also still haven t changed the definition of the objects property which stipulates that any Observables captured must be part of the same graph (i.e., related to each other). This is particularly problematic for use cases such
as the capture of malware sandbox analysis data where you may end up with a large collection of unrelated Observables.


Only if we use the observed data object, the related definition is only
in observed-data, not in observable-objects.

Current malware uses observable-objects directly, and so no related
requirement.

From: < cti@lists.oasis-open.org > on behalf of Rich Piazza < rpiazza@mitre.org >

Date: Wednesday, August 15, 2018 at 6:19 AM

To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Allan Thomson < athomson@lookingglasscyber.com >

Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, John Wunder < jwunder@mitre.org >

Subject: Re: [cti] Possible Changes to Observed Data







Having been the one who pushed to release 2.1 in the Spring as is, I guess I have to also agree with #1.







However, I feel #3 is ultimately (2.2?) the right answer.  Remember in STIX 1.x when we conflated observed data and patterns because they kinda looked the same?







From: < cti@lists.oasis-open.org > on behalf of Jason Keirstead < Jason.Keirstead@ca.ibm.com >

Date: Wednesday, August 15, 2018 at 8:02 AM

To: Allan Thomson < athomson@lookingglasscyber.com >

Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, John Wunder < jwunder@mitre.org >

Subject: Re: [cti] Possible Changes to Observed Data







I support #1.



I do not support #2, simply because of the extremely large & cascading ramifications this has for software implementors, for something so minor as the name of a JSON field not meant to be primarily consumed by humans.



-

Jason Keirstead

Lead Architect - IBM.Security

www.ibm.com/security



"Things may come to those who wait, but only the things left by those who hustle." - Unknown










From:        Allan Thomson < athomson@lookingglasscyber.com >

To:        "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >

Date:        08/14/2018 06:42 PM

Subject:        Re: [cti] Possible Changes to Observed Data

Sent by:        < cti@lists.oasis-open.org >









I support #1 -> #2 in that order.



Although I don t really see a need for #2 and therefore am primarily supportive on #1.



I agree with John s perspective on getting 2.1 done but that needs to include the new malware definition that I believe was leveraging this new relaxed observed data object.




That is why I think #1 is also the best course of action.



Regards



allan



From: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > on behalf of "Wunder, John" < jwunder@mitre.org >

Date: Tuesday, August 14, 2018 at 2:38 PM

To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >

Subject: Re: [cti] Possible Changes to Observed Data



I would say that, philosophically, we should do whichever option lets us finish STIX 2.1 as soon as possible while ensuring that it s usable and complete (note that I didn t say perfect ). We re waiting on 2.1 in order to do internationalization,
confidence, malware, and a whole pile of other things. These are critical capabilities that we can t share in a standardized way right now, and that s preventing people from using STIX 2. If we spend another year trying to get observed data perfect I think
we risk losing support and getting the perception that we won t finish things.



To that end, IMO the best options are #1 or #2 because they had the most support on the working calls (personally I prefer #5 but I think #1 and #2 are workable). So my suggestion would be that we do #1 or #2 and the people that
prefer it should address the comments from JMG and others (see working call notes from today) to ensure we don t lose the important aspects of observed-data when used to capture operational data observed by sensors. If we can get that done by the end of the
review period for WD02 let s include it in CSD01, otherwise let s defer to CSD02.



John

From: < cti@lists.oasis-open.org > on behalf of "Bret Jordan (CS)" < Bret_Jordan@symantec.com >

Date: Tuesday, August 14, 2018 at 5:04 PM

To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >

Subject: [cti] Possible Changes to Observed Data





All,







There has been several discussions over the past few months about relaxing and making slight changes to Observed Data to make it useable for other use cases (Malware, Infrastructure, Incident, Intrusion Sets, etc).  We have talked
about it a few times on working calls and over slack and we now need to make a decision about what to do. As such we are bringing this issue to the email list for review and comment by the full TC.







Historically, the Observed Data object came to be after the great Arglebargle debate from the DC3 F2F meeting. The question at that time was, "should Cyber Observables (CybOX) be first order citizens or should they be in a wrapper".
At that time, most people felt like it should be in a wrapper, even though this would mean a graph inside of a graph. So the TC created the Observed Data Object to address one specific use case, that is relating cyber observables to another STIX object, specifically
an indicator, via the Sighting Relationship object. This would allow you to say, I saw this indicator, and what I saw is located in this Observed Data object. So all of the descriptions, normative text, and properties were designed to address this one specific
use case.







Fast forward 24 months, some TC members are now asking for a way to capture cyber observables that are not just "observations" (in the definition that was defined for Observed Data). They are looking for a more generic container
or solution so cyber observables can be documented, captured, and shared.  This data may come from an analyst that reads some report, this may come from a sandbox, this may come from a URL lookup service like URLVoid, etc, but the key point is that it is not
an "observation" it is just cyber observable data.







I have heard a few different options that we as a TC could take, if you have other ideas, please let us know. This is really a critical decision that the TC needs to address. The options I have heard are:







1) Relax Observed Data and some of the properties to make it useable by more use cases







2) Same as 1, but rename Observed Data to be something more appropriate







3) Created a different cyber observable container (this would mean we could have more than one, and that might cause confusion)







4) Revisit the ArgleBargle decision and look to make cyber observables first order citizens (this would get rid of the graph inside a graph design that some people have since complained about)








5) Due nothing and try and create some other cyber observable property on objects that need cyber observables that are not "observations". This could represent multiple ways of doing the same thing, something we have tried hard
to avoid.











## Personal Opinion ##



From my personal perspective, it would be nice if we could address this in this first CSD, since it may represent breaking changes. This does not mean we have to get it 100% correct for CSD01, as we can tweak it and refine it more
in CSD02 and CSD03.  But it would be nice to at least get the major changes done for CSD01.




## END ##







Please comment here on the email list and help us understand what you as a TC member would like to have happen here.






--
John-Mark

---------------------------------------------------------------------
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://clicktime.symantec.com/a/1/WjL0BNNLSSfy48DNxI0gjOfA4xqAbzvwVTe-wFkRu1U=?d=GQOtyPk8refrgLooup2jjGxGm9jyOBV-FzaYgj5azJQZyFNQLM73p0UuCAVhP9dvEYnvjM-zcivptBS_-vfTDVUActM95HivtxYXWlLlZ61YaEkgtTwQL1TzYR-Gc0zziWHIwTf7R9MMUGHYTTByV81suBTYj4FFeOBiyqHPEPFkfPNBbRbkSMZTqG7906OBMndRvVio79DM6CJwD5D0R723OoUQGbJq55dcnjBj9mqx6HTwkUJJSqgyB7LVCoe9OljG2MNZ0EzZsorDEfdIFUnc62X06uvuzG6xgCYOeHLuOyk3st3_iS3n4wbnWfv8WonjdbmEWWXxOkXI7iFPSvQX3Q367ZoVAg5cYKvsBASMOme3GqRpTlFLM6pOuszgSHIZ_wUvkRWl17XC0e-fzqWEgpuQ4zqsenEJrGVLUu-HIE9ydd-wwjd_3A%3D%3D&u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php

Since the whole reason we re contemplating changing how observed data works is so that it fits for new use cases like malware and infrastructure, I d like to suggest that we should hold off on making a decision on how to change observed
data until we know that it will actually work with these new proposed objects. Since we pushed malware from CSD01, and infrastructure was never in it, I think we should hold off on making any changes to the observed data object until we can work through these
objects at the same time. Otherwise we could wind up making changes now that ultimately will need to be changed again if they don t work for malware/infrastructure, etc.

 

Sarah Kelley
Lead Cybersecurity Engineer, T8B2
Defensive Operations
The MITRE Corporation
703-983-6242
skelley@mitre.org


 


From: cti@lists.oasis-open.org <cti@lists.oasis-open.org>
On Behalf Of Bret Jordan
Sent: Wednesday, August 15, 2018 3:31 PM
To: John-Mark Gurney <jmg@newcontext.com>
Cc: Kirillov, Ivan A. <ikirillov@mitre.org>; cti@lists.oasis-open.org
Subject: [cti] Re: [EXT] Re: [cti] Possible Changes to Observed Data


 
John-Mark,

 


I think the idea is that Malware and other things like it will use embedded relationships to observed data or something like observed data.


 


Bret 

Sent from my Commodore 64 

 


PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050




On Aug 15, 2018, at 10:55 AM, John-Mark Gurney < jmg@newcontext.com > wrote:



Kirillov, Ivan A. wrote this message on Wed, Aug 15, 2018 at 13:29 +0000:



I m OK with #1 as long as we understand the implications of doing this and that we re changing the definition of Observed Data that we ve long held. E.g., are we comfortable with the fact that users can now create Observed Data instances
without specifying the time window during which the data was observed and how many times it as observed during that window?


The changes made had no requirement that first/last_observed be present
when number_observed is present.




We also still haven t changed the definition of the objects property which stipulates that any Observables captured must be part of the same graph (i.e., related to each other). This is particularly problematic for use cases such as the
capture of malware sandbox analysis data where you may end up with a large collection of unrelated Observables.


Only if we use the observed data object, the related definition is only
in observed-data, not in observable-objects.

Current malware uses observable-objects directly, and so no related
requirement.




From: < cti@lists.oasis-open.org > on behalf of Rich Piazza < rpiazza@mitre.org >


Date: Wednesday, August 15, 2018 at 6:19 AM


To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Allan Thomson < athomson@lookingglasscyber.com >


Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, John Wunder < jwunder@mitre.org >


Subject: Re: [cti] Possible Changes to Observed Data


 


 


 


Having been the one who pushed to release 2.1 in the Spring as is, I guess I have to also agree with #1.


 


 


 


However, I feel #3 is ultimately (2.2?) the right answer.  Remember in STIX 1.x when we conflated observed data and patterns because they kinda looked the same?


 


 


 


From: < cti@lists.oasis-open.org > on behalf of Jason Keirstead < Jason.Keirstead@ca.ibm.com >


Date: Wednesday, August 15, 2018 at 8:02 AM


To: Allan Thomson < athomson@lookingglasscyber.com >


Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >, John Wunder < jwunder@mitre.org >


Subject: Re: [cti] Possible Changes to Observed Data


 


 


 


I support #1.


 


I do not support #2, simply because of the extremely large & cascading ramifications this has for software implementors, for something so minor as the name of a JSON field not meant to be primarily consumed by humans.


 


-


Jason Keirstead


Lead Architect - IBM.Security


www.ibm.com/security


 


"Things may come to those who wait, but only the things left by those who hustle." - Unknown



 


 


 


 


From:        Allan Thomson < athomson@lookingglasscyber.com >


To:        "Wunder, John A." < jwunder@mitre.org >, " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >


Date:        08/14/2018 06:42 PM


Subject:        Re: [cti] Possible Changes to Observed Data


Sent by:        < cti@lists.oasis-open.org >


 


 


 


 


I support #1 -> #2 in that order.


 


Although I don t really see a need for #2 and therefore am primarily supportive on #1.


 


I agree with John s perspective on getting 2.1 done but that needs to include the new malware definition that I believe was leveraging this new relaxed observed data object.



 


That is why I think #1 is also the best course of action.


 


Regards


 


allan


 


From: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org > on behalf of "Wunder, John" < jwunder@mitre.org >


Date: Tuesday, August 14, 2018 at 2:38 PM


To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >


Subject: Re: [cti] Possible Changes to Observed Data


 


I would say that, philosophically, we should do whichever option lets us finish STIX 2.1 as soon as possible while ensuring that it s usable and complete (note that I didn t say perfect ). We re waiting on 2.1 in order to do internationalization,
confidence, malware, and a whole pile of other things. These are critical capabilities that we can t share in a standardized way right now, and that s preventing people from using STIX 2. If we spend another year trying to get observed data perfect I think
we risk losing support and getting the perception that we won t finish things.


 


To that end, IMO the best options are #1 or #2 because they had the most support on the working calls (personally I prefer #5 but I think #1 and #2 are workable). So my suggestion would be that we do #1 or #2 and the people that prefer
it should address the comments from JMG and others (see working call notes from today) to ensure we don t lose the important aspects of observed-data when used to capture operational data observed by sensors. If we can get that done by the end of the review
period for WD02 let s include it in CSD01, otherwise let s defer to CSD02.


 


John


From: < cti@lists.oasis-open.org > on behalf of "Bret Jordan (CS)" < Bret_Jordan@symantec.com >


Date: Tuesday, August 14, 2018 at 5:04 PM


To: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >


Subject: [cti] Possible Changes to Observed Data


 


 


All,


 


 


 


There has been several discussions over the past few months about relaxing and making slight changes to Observed Data to make it useable for other use cases (Malware, Infrastructure, Incident, Intrusion Sets, etc).  We have talked about
it a few times on working calls and over slack and we now need to make a decision about what to do. As such we are bringing this issue to the email list for review and comment by the full TC.


 


 


 


Historically, the Observed Data object came to be after the great Arglebargle debate from the DC3 F2F meeting. The question at that time was, "should Cyber Observables (CybOX) be first order citizens or should they be in a wrapper". At
that time, most people felt like it should be in a wrapper, even though this would mean a graph inside of a graph. So the TC created the Observed Data Object to address one specific use case, that is relating cyber observables to another STIX object, specifically
an indicator, via the Sighting Relationship object. This would allow you to say, I saw this indicator, and what I saw is located in this Observed Data object. So all of the descriptions, normative text, and properties were designed to address this one specific
use case.


 


 


 


Fast forward 24 months, some TC members are now asking for a way to capture cyber observables that are not just "observations" (in the definition that was defined for Observed Data). They are looking for a more generic container or solution
so cyber observables can be documented, captured, and shared.  This data may come from an analyst that reads some report, this may come from a sandbox, this may come from a URL lookup service like URLVoid, etc, but the key point is that it is not an "observation"
it is just cyber observable data.


 


 


 


I have heard a few different options that we as a TC could take, if you have other ideas, please let us know. This is really a critical decision that the TC needs to address. The options I have heard are:


 


 


 


1) Relax Observed Data and some of the properties to make it useable by more use cases


 


 


 


2) Same as 1, but rename Observed Data to be something more appropriate


 


 


 


3) Created a different cyber observable container (this would mean we could have more than one, and that might cause confusion)


 


 


 


4) Revisit the ArgleBargle decision and look to make cyber observables first order citizens (this would get rid of the graph inside a graph design that some people have since complained about)



 


 


 


5) Due nothing and try and create some other cyber observable property on objects that need cyber observables that are not "observations". This could represent multiple ways of doing the same thing, something we have tried hard to avoid.



 


 


 


 


 


## Personal Opinion ##


 


From my personal perspective, it would be nice if we could address this in this first CSD, since it may represent breaking changes. This does not mean we have to get it 100% correct for CSD01, as we can tweak it and refine it more in CSD02
and CSD03.  But it would be nice to at least get the major changes done for CSD01.



 


## END ##


 


 


 


Please comment here on the email list and help us understand what you as a TC member would like to have happen here.



 



--
John-Mark

---------------------------------------------------------------------
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://clicktime.symantec.com/a/1/WjL0BNNLSSfy48DNxI0gjOfA4xqAbzvwVTe-wFkRu1U=?d=GQOtyPk8refrgLooup2jjGxGm9jyOBV-FzaYgj5azJQZyFNQLM73p0UuCAVhP9dvEYnvjM-zcivptBS_-vfTDVUActM95HivtxYXWlLlZ61YaEkgtTwQL1TzYR-Gc0zziWHIwTf7R9MMUGHYTTByV81suBTYj4FFeOBiyqHPEPFkfPNBbRbkSMZTqG7906OBMndRvVio79DM6CJwD5D0R723OoUQGbJq55dcnjBj9mqx6HTwkUJJSqgyB7LVCoe9OljG2MNZ0EzZsorDEfdIFUnc62X06uvuzG6xgCYOeHLuOyk3st3_iS3n4wbnWfv8WonjdbmEWWXxOkXI7iFPSvQX3Q367ZoVAg5cYKvsBASMOme3GqRpTlFLM6pOuszgSHIZ_wUvkRWl17XC0e-fzqWEgpuQ4zqsenEJrGVLUu-HIE9ydd-wwjd_3A%3D%3D&u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php

On 16.08.2018 12:07:33, Kelley, Sarah E. wrote: > Since the whole reason we re contemplating changing how observed > data works is so that it fits for new use cases like malware and > infrastructure, I d like to suggest that we should hold off on > making a decision on how to change observed data until we know that > it will actually work with these new proposed objects. Since we > pushed malware from CSD01, and infrastructure was never in it, I > think we should hold off on making any changes to the observed data > object until we can work through these objects at the same > time. Otherwise we could wind up making changes now that ultimately > will need to be changed again if they don t work for > malware/infrastructure, etc. > That would be my preference, Sarah. We should back out the changes to Observed Data and issue draft-03. As an editor, I understand the pressure to resolve comments and get drafts out for review promptly. However Bret's suggested changes to Observed Data were accepted into draft-02 without being adequately discussed. (Neither Ivan Kirillov nor myself were consulted; as the Cyber Observable co-chairs, at the very least this should have happened.) In fact, we *should* have discussed this on a TC working call. As you rightly point out, the TC needs to validate that these changes to Observed Data are adequate to address the needs of Malware and Infrastructure. There are still a fair number of folks out on summer vacation. I recommend that we dedicate the entire working calls 11 & 18 September to discussing this with a larger audience. (The week of 03 September being US Labor Day holiday period, we'll likely have lower participation on the 04 September working call.) As Ivan and I are the Cyber Observable co-chairs and as we led the work on Malware, we will happily lead this discussion. If the TC elects to go this route, Ivan and I will work with together the TC membership to assemble a set of questions which will allow us to validate that the changes we make to Observed Data are fit-to-purpose for Malware and Infrastructure, and that they do not negatively impact STIX Patterning. -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "You know you have achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away." --Antoine de Saint-ExupÃry Attachment: signature.asc Description: PGP signature

To Sarah's point, I would like to provide an overview of how Cyber Observables could be updated to support the new use cases. These updates were based upon a discussion with Ivan and Jeff prior to being turned into a power point. The power point was developed with the idea that someone would be speaking to the slides, so I apologize if anything is obtuse. By making a couple of changes to the Cyber Observable object, we should be able to accommodate new use cases. Obviously, as we continue to refine Infrastructure Malware, and Incident we will need to confirm that these changes do support their use cases but it looks like this would be a solution to meet Option 1. Comments or questions welcome. -Gary
Original Message----- From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Trey Darley Sent: Thursday, August 16, 2018 8:43 AM To: Kelley, Sarah E. <skelley@mitre.org> Cc: cti@lists.oasis-open.org Subject: [Non-DoD Source] Re: [cti] RE: [EXT] Re: [cti] Possible Changes to Observed Data On 16.08.2018 12:07:33, Kelley, Sarah E. wrote: > Since the whole reason we re contemplating changing how observed data > works is so that it fits for new use cases like malware and > infrastructure, I d like to suggest that we should hold off on making > a decision on how to change observed data until we know that it will > actually work with these new proposed objects. Since we pushed malware > from CSD01, and infrastructure was never in it, I think we should hold > off on making any changes to the observed data object until we can > work through these objects at the same time. Otherwise we could wind > up making changes now that ultimately will need to be changed again if > they don t work for malware/infrastructure, etc. > That would be my preference, Sarah. We should back out the changes to Observed Data and issue draft-03. As an editor, I understand the pressure to resolve comments and get drafts out for review promptly. However Bret's suggested changes to Observed Data were accepted into draft-02 without being adequately discussed. (Neither Ivan Kirillov nor myself were consulted; as the Cyber Observable co-chairs, at the very least this should have happened.) In fact, we *should* have discussed this on a TC working call. As you rightly point out, the TC needs to validate that these changes to Observed Data are adequate to address the needs of Malware and Infrastructure. There are still a fair number of folks out on summer vacation. I recommend that we dedicate the entire working calls 11 & 18 September to discussing this with a larger audience. (The week of 03 September being US Labor Day holiday period, we'll likely have lower participation on the 04 September working call.) As Ivan and I are the Cyber Observable co-chairs and as we led the work on Malware, we will happily lead this discussion. If the TC elects to go this route, Ivan and I will work with together the TC membership to assemble a set of questions which will allow us to validate that the changes we make to Observed Data are fit-to-purpose for Malware and Infrastructure, and that they do not negatively impact STIX Patterning. -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "You know you have achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away." --Antoine de Saint-ExupÃry Attachment: Observed Data Presentation.pptx Description: application/vnd.openxmlformats-officedocument.presentationml.presentation Attachment: smime.p7s Description: S/MIME cryptographic signature

On 21.08.2018 18:47:05, Katz, Gary CTR DC3/TSD wrote: > To Sarah's point, I would like to provide an overview of how Cyber > Observables could be updated to support the new use cases. These > updates were based upon a discussion with Ivan and Jeff prior to > being turned into a power point. The power point was developed with > the idea that someone would be speaking to the slides, so I > apologize if anything is obtuse. By making a couple of changes to > the Cyber Observable object, we should be able to accommodate new > use cases. Obviously, as we continue to refine Infrastructure > Malware, and Incident we will need to confirm that these changes do > support their use cases but it looks like this would be a solution > to meet Option 1. > Hi, Gary - Would you and Jeff be willing to present this on next week's TC working call? -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "He who defends with love will be secure." --Lao Tzu Attachment: signature.asc Description: PGP signature

Not entirely sure of next week's schedule for me, but always love to signup Jeff for things so, yes!
Original Message----- From: Trey Darley <trey@newcontext.com> Sent: Tuesday, August 21, 2018 2:55 PM To: Katz, Gary CTR DC3/TSD <Gary.Katz.ctr@dc3.mil> Cc: Kelley, Sarah E. <skelley@mitre.org>; cti@lists.oasis-open.org Subject: Re: [Non-DoD Source] Re: [cti] RE: [EXT] Re: [cti] Possible Changes to Observed Data On 21.08.2018 18:47:05, Katz, Gary CTR DC3/TSD wrote: > To Sarah's point, I would like to provide an overview of how Cyber > Observables could be updated to support the new use cases. These > updates were based upon a discussion with Ivan and Jeff prior to being > turned into a power point. The power point was developed with the idea > that someone would be speaking to the slides, so I apologize if > anything is obtuse. By making a couple of changes to the Cyber > Observable object, we should be able to accommodate new use cases. > Obviously, as we continue to refine Infrastructure Malware, and > Incident we will need to confirm that these changes do support their > use cases but it looks like this would be a solution to meet Option 1. > Hi, Gary - Would you and Jeff be willing to present this on next week's TC working call? -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "He who defends with love will be secure." --Lao Tzu Attachment: smime.p7s Description: S/MIME cryptographic signature

Gary: The proposal you outline on your PowerPoint makes a lot of sense. As we move forward with the Infrastructure object, and see overlapping malicious infrastructure (or even Tool objects) this will be a way to surface those relationships. As I understand your proposal, this will allow us to pivot on the Observed Data object, which will be very useful during a hunting expedition. For the Malware object I can see us using it to characterize multiple uses of the same malware. If we take the recent Mueller Indictment of the 12 GRU operatives as an example, we saw that the threat actors used the X-Agent Malware on the DCCC (Victim 1), and then again on the DNC (Victim 2). And, we saw that the X-Tunnel Malware was used to exfiltrate documents from each of the separate victims. As an analyst, I want to be able to see the multiple uses of X-Agent on the different victims. One way to see that overlap would be to use the parent_nodes property that you suggest for the Observed Data object. It would allow me to "see" the connection (on a Graph) representation, without being overwhelmed by all of the related nodes. For example, if 76 'hosts' within Victim 1 were infected with X-Agent, I don't want to be swamped with all of the infected hosts when I'm searching for connections to other related Campaigns on Victim 2. I may only want to see Patient Zero or a specific Cyber Observable such as a binary or executable file. This would help me filter out the noise and use deductive logic to draw a relationship between the two separate Campaigns. Jane On 8/21/2018 11:47 AM, Katz, Gary CTR DC3/TSD wrote: > To Sarah's point, I would like to provide an overview of how Cyber Observables could be updated to support the new use cases. These updates were based upon a discussion with Ivan and Jeff prior to being turned into a power point. The power point was developed with the idea that someone would be speaking to the slides, so I apologize if anything is obtuse. By making a couple of changes to the Cyber Observable object, we should be able to accommodate new use cases. Obviously, as we continue to refine Infrastructure Malware, and Incident we will need to confirm that these changes do support their use cases but it looks like this would be a solution to meet Option 1. > > Comments or questions welcome. > -Gary > >
Original Message----- > From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Trey Darley > Sent: Thursday, August 16, 2018 8:43 AM > To: Kelley, Sarah E. <skelley@mitre.org> > Cc: cti@lists.oasis-open.org > Subject: [Non-DoD Source] Re: [cti] RE: [EXT] Re: [cti] Possible Changes to Observed Data > > On 16.08.2018 12:07:33, Kelley, Sarah E. wrote: >> Since the whole reason we re contemplating changing how observed data >> works is so that it fits for new use cases like malware and >> infrastructure, I d like to suggest that we should hold off on making >> a decision on how to change observed data until we know that it will >> actually work with these new proposed objects. Since we pushed malware >> from CSD01, and infrastructure was never in it, I think we should hold >> off on making any changes to the observed data object until we can >> work through these objects at the same time. Otherwise we could wind >> up making changes now that ultimately will need to be changed again if >> they don t work for malware/infrastructure, etc. >> > That would be my preference, Sarah. We should back out the changes to Observed Data and issue draft-03. > > As an editor, I understand the pressure to resolve comments and get drafts out for review promptly. However Bret's suggested changes to Observed Data were accepted into draft-02 without being adequately discussed. (Neither Ivan Kirillov nor myself were consulted; as the Cyber Observable co-chairs, at the very least this should have > happened.) > > In fact, we *should* have discussed this on a TC working call. As you rightly point out, the TC needs to validate that these changes to Observed Data are adequate to address the needs of Malware and Infrastructure. > > There are still a fair number of folks out on summer vacation. I recommend that we dedicate the entire working calls 11 & 18 September to discussing this with a larger audience. (The week of 03 September being US Labor Day holiday period, we'll likely have lower participation on the 04 September working call.) > > As Ivan and I are the Cyber Observable co-chairs and as we led the work on Malware, we will happily lead this discussion. If the TC elects to go this route, Ivan and I will work with together the TC membership to assemble a set of questions which will allow us to validate that the changes we make to Observed Data are fit-to-purpose for Malware and Infrastructure, and that they do not negatively impact STIX Patterning. > > -- > Cheers, > Trey > ++--------------------------------------------------------------------------++ > Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 > ++--------------------------------------------------------------------------++ > -- > "You know you have achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away." > --Antoine de Saint-ExupÃry -- R. Jane Ginn, MSIA, MRP Secretary, Cyber Threat Intelligence Technical Committee (CTI TC) OASIS jg@ctin.us +1(928)399-0509