OASIS Cyber Threat Intelligence (CTI) TC

Ivan – regarding 1.
 
What if I have multiple observables for the same malware from different analysis (i.e. static + dynamic results).
 
Would consolidating them into a single place really make it easier? You would still want to indicate that you have a list of observables and indicate where those were ‘observed’ from either static or dynamic
or other.
 
So I’m not sure consolidating it makes it easier but so long as the same things are possible with the consolidated design then I don’t have a strong preference either way.
 

Allan Thomson
CTO ( +1-408-331-6646)

LookingGlass Cyber Solutions
 

From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Kirillov, Ivan" <ikirillov@mitre.org>
Date: Wednesday, June 13, 2018 at 12:57 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Cc: "Kumar, Subodh" <subodh.kumar@jpmorgan.com>
Subject: [cti] Finalizing the STIX 2.1 Malware Object


 

All,
 
As we’re wrapping up work on STIX 2.1 CSD01, we need to finalize what we have for the updated Malware SDO. Accordingly, I have two topics I’d like to bring up in this regard:
 

Thanks to the work done by Subodh Kumar and his team, I’ve been wondering if there’s a better way to capture the Observable Objects associated with the
Malware SDO. Right now, there are three places where you may encounter a Cyber Observable Object: samples (a dict of observable objects), static_analysis_results/results (certain keys have a corresponding dict of observable objects), dynamic_analysis_results/results
(each key has a corresponding dict of observable objects).  
 
Instead of having these observable object dictionaries all over the place, I believe it would make more sense to have a single property at the top level of the object (let’s call it
“observable_objects”), where any Cyber Observable Objects associated with the SDO (samples, analysis results, etc.) could be captured, via references. There are a number of advantages to this: a simpler data model (less embedded observable object dicts everywhere),
the ability to re-use objects (e.g., if static and dynamic analysis find the same objects, you can create one object and just reference it accordingly), and a more compact serialization. See the attached JSON example for what this looks like in practice –
this is a modified version of the “Malware Instance with Analysis Data” example currently in the 2.1 spec.
 

Currently, the “av-results-type”, used to capture AV classification results, has only optional properties and the text specifies that at least one must
be included. This allows you to construct some odd, but spec-valid instances, such as an AV classification with only the engine version. In order to make this type more useful, I’d suggest that we make “product” (the name of the tool performing the scan) and
“scanned” (the date/time the scan occurred) required, so that way you’ll at least have this minimum set of useful data for each instance. In addition, we should probably add some text stating that the “result” property (the actual AV classification result,
e.g., “Trojan.Zeus”) must be included if the tool reports some classification during the scan.
 
Let me know what you think – if we can get these final things wrapped up, we’re that much closer to getting STIX 2.1 out the door.
 
Regards,
Ivan

Hi Allan,
 
This approach doesn’t fundamentally change how we capture static/dynamic analysis data, but rather where and how the Cyber Observable Objects that correspond to that data are stored. If you have multiple observables
from different analyses, you’ll just reference their corresponding objects that are stored in the “observable_objects” dictionary (which may or may not be the same objects across different analyses).


As far as being easier, it’s kind of a wash – it may simplify the generation of content because any Cyber Observable Objects would have to be stored in this top-level dictionary. Conversely, parsing the SDO because you’ll have to dereference the objects as
you come across their usage. However, I do think that the simplification to the data model and the ability to re-use objects are worthwhile changes.
 
Regards,
Ivan
 

From: Allan Thomson <athomson@lookingglasscyber.com>
Date: Wednesday, June 13, 2018 at 2:22 PM
To: Ivan Kirillov <ikirillov@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Cc: "Kumar, Subodh" <subodh.kumar@jpmorgan.com>
Subject: Re: [cti] Finalizing the STIX 2.1 Malware Object


 

Ivan – regarding 1.
 
What if I have multiple observables for the same malware from different analysis (i.e. static + dynamic results).
 
Would consolidating them into a single place really make it easier? You would still want to indicate that you have a list of observables and indicate where those
were ‘observed’ from either static or dynamic or other.
 
So I’m not sure consolidating it makes it easier but so long as the same things are possible with the consolidated design then I don’t have a strong preference
either way.
 

Allan Thomson
CTO ( +1-408-331-6646)

LookingGlass Cyber Solutions
 

From:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Kirillov, Ivan" <ikirillov@mitre.org>
Date: Wednesday, June 13, 2018 at 12:57 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Cc: "Kumar, Subodh" <subodh.kumar@jpmorgan.com>
Subject: [cti] Finalizing the STIX 2.1 Malware Object


 

All,
 
As we’re wrapping up work on STIX 2.1 CSD01, we need to finalize what we have for the updated Malware SDO. Accordingly, I have two topics I’d like to bring up in
this regard:
 

Thanks to the work done by Subodh Kumar and his team, I’ve been wondering if there’s a better way to capture the Observable Objects
associated with the Malware SDO. Right now, there are three places where you may encounter a Cyber Observable Object: samples (a dict of observable objects), static_analysis_results/results (certain keys have a corresponding dict of observable objects), dynamic_analysis_results/results
(each key has a corresponding dict of observable objects).  
 
Instead of having these observable object dictionaries all over the place, I believe it would make more sense to have a single property
at the top level of the object (let’s call it “observable_objects”), where any Cyber Observable Objects associated with the SDO (samples, analysis results, etc.) could be captured, via references. There are a number of advantages to this: a simpler data model
(less embedded observable object dicts everywhere), the ability to re-use objects (e.g., if static and dynamic analysis find the same objects, you can create one object and just reference it accordingly), and a more compact serialization. See the attached
JSON example for what this looks like in practice – this is a modified version of the “Malware Instance with Analysis Data” example currently in the 2.1 spec.
 

Currently, the “av-results-type”, used to capture AV classification results, has only optional properties and the text specifies
that at least one must be included. This allows you to construct some odd, but spec-valid instances, such as an AV classification with only the engine version. In order to make this type more useful, I’d suggest that we make “product” (the name of the tool
performing the scan) and “scanned” (the date/time the scan occurred) required, so that way you’ll at least have this minimum set of useful data for each instance. In addition, we should probably add some text stating that the “result” property (the actual
AV classification result, e.g., “Trojan.Zeus”) must be included if the tool reports some classification during the scan.
 
Let me know what you think – if we can get these final things wrapped up, we’re that much closer to getting STIX 2.1 out the door.
 
Regards,
Ivan

Sorry, that should read “ Conversely, parsing the SDO
may become more difficult because…”
 
Regards,
Ivan
 

From: Ivan Kirillov <ikirillov@mitre.org>
Date: Wednesday, June 13, 2018 at 2:44 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Cc: "Kumar, Subodh" <subodh.kumar@jpmorgan.com>
Subject: Re: [cti] Finalizing the STIX 2.1 Malware Object


 

Hi Allan,
 
This approach doesn’t fundamentally change how we capture static/dynamic analysis data, but rather where and how the Cyber Observable Objects that correspond to that data are stored. If you have multiple observables
from different analyses, you’ll just reference their corresponding objects that are stored in the “observable_objects” dictionary (which may or may not be the same objects across different analyses).


As far as being easier, it’s kind of a wash – it may simplify the generation of content because any Cyber Observable Objects would have to be stored in this top-level dictionary. Conversely, parsing the SDO because you’ll have to dereference the objects as
you come across their usage. However, I do think that the simplification to the data model and the ability to re-use objects are worthwhile changes.
 
Regards,
Ivan
 

From: Allan Thomson <athomson@lookingglasscyber.com>
Date: Wednesday, June 13, 2018 at 2:22 PM
To: Ivan Kirillov <ikirillov@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Cc: "Kumar, Subodh" <subodh.kumar@jpmorgan.com>
Subject: Re: [cti] Finalizing the STIX 2.1 Malware Object


 

Ivan – regarding 1.
 
What if I have multiple observables for the same malware from different analysis (i.e. static + dynamic results).
 
Would consolidating them into a single place really make it easier? You would still want to indicate that you have a list of observables and indicate where those
were ‘observed’ from either static or dynamic or other.
 
So I’m not sure consolidating it makes it easier but so long as the same things are possible with the consolidated design then I don’t have a strong preference
either way.
 

Allan Thomson
CTO ( +1-408-331-6646)

LookingGlass Cyber Solutions
 

From:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Kirillov, Ivan" <ikirillov@mitre.org>
Date: Wednesday, June 13, 2018 at 12:57 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Cc: "Kumar, Subodh" <subodh.kumar@jpmorgan.com>
Subject: [cti] Finalizing the STIX 2.1 Malware Object


 

All,
 
As we’re wrapping up work on STIX 2.1 CSD01, we need to finalize what we have for the updated Malware SDO. Accordingly, I have two topics I’d like to bring up in
this regard:
 

Thanks to the work done by Subodh Kumar and his team, I’ve been wondering if there’s a better way to capture the Observable Objects
associated with the Malware SDO. Right now, there are three places where you may encounter a Cyber Observable Object: samples (a dict of observable objects), static_analysis_results/results (certain keys have a corresponding dict of observable objects), dynamic_analysis_results/results
(each key has a corresponding dict of observable objects).  
 
Instead of having these observable object dictionaries all over the place, I believe it would make more sense to have a single property
at the top level of the object (let’s call it “observable_objects”), where any Cyber Observable Objects associated with the SDO (samples, analysis results, etc.) could be captured, via references. There are a number of advantages to this: a simpler data model
(less embedded observable object dicts everywhere), the ability to re-use objects (e.g., if static and dynamic analysis find the same objects, you can create one object and just reference it accordingly), and a more compact serialization. See the attached
JSON example for what this looks like in practice – this is a modified version of the “Malware Instance with Analysis Data” example currently in the 2.1 spec.
 

Currently, the “av-results-type”, used to capture AV classification results, has only optional properties and the text specifies
that at least one must be included. This allows you to construct some odd, but spec-valid instances, such as an AV classification with only the engine version. In order to make this type more useful, I’d suggest that we make “product” (the name of the tool
performing the scan) and “scanned” (the date/time the scan occurred) required, so that way you’ll at least have this minimum set of useful data for each instance. In addition, we should probably add some text stating that the “result” property (the actual
AV classification result, e.g., “Trojan.Zeus”) must be included if the tool reports some classification during the scan.
 
Let me know what you think – if we can get these final things wrapped up, we’re that much closer to getting STIX 2.1 out the door.
 
Regards,
Ivan

Are there any other thoughts on these topics? It would be great to close them out so we can finish up CSD01 of STIX 2.1.
 
Regards,
Ivan
 

From: <cti@lists.oasis-open.org> on behalf of Ivan Kirillov <ikirillov@mitre.org>
Date: Wednesday, June 13, 2018 at 2:47 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Cc: "Kumar, Subodh" <subodh.kumar@jpmorgan.com>
Subject: Re: [cti] Finalizing the STIX 2.1 Malware Object


 

Sorry, that should read “Conversely, parsing the SDO
may become more difficult because…”
 
Regards,
Ivan
 

From: Ivan Kirillov <ikirillov@mitre.org>
Date: Wednesday, June 13, 2018 at 2:44 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Cc: "Kumar, Subodh" <subodh.kumar@jpmorgan.com>
Subject: Re: [cti] Finalizing the STIX 2.1 Malware Object


 

Hi Allan,
 
This approach doesn’t fundamentally change how we capture static/dynamic analysis data, but rather where and how the Cyber Observable Objects that correspond to that data are stored. If you have multiple observables
from different analyses, you’ll just reference their corresponding objects that are stored in the “observable_objects” dictionary (which may or may not be the same objects across different analyses).


As far as being easier, it’s kind of a wash – it may simplify the generation of content because any Cyber Observable Objects would have to be stored in this top-level dictionary. Conversely, parsing the SDO because you’ll have to dereference the objects as
you come across their usage. However, I do think that the simplification to the data model and the ability to re-use objects are worthwhile changes.
 
Regards,
Ivan
 

From: Allan Thomson <athomson@lookingglasscyber.com>
Date: Wednesday, June 13, 2018 at 2:22 PM
To: Ivan Kirillov <ikirillov@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Cc: "Kumar, Subodh" <subodh.kumar@jpmorgan.com>
Subject: Re: [cti] Finalizing the STIX 2.1 Malware Object


 

Ivan – regarding 1.
 
What if I have multiple observables for the same malware from different analysis (i.e. static + dynamic results).
 
Would consolidating them into a single place really make it easier? You would still want to indicate that you have a list of observables and indicate where those were ‘observed’ from either static or dynamic
or other.
 
So I’m not sure consolidating it makes it easier but so long as the same things are possible with the consolidated design then I don’t have a strong preference either way.
 

Allan Thomson
CTO ( +1-408-331-6646)

LookingGlass Cyber Solutions
 

From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Kirillov, Ivan" <ikirillov@mitre.org>
Date: Wednesday, June 13, 2018 at 12:57 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Cc: "Kumar, Subodh" <subodh.kumar@jpmorgan.com>
Subject: [cti] Finalizing the STIX 2.1 Malware Object


 

All,
 
As we’re wrapping up work on STIX 2.1 CSD01, we need to finalize what we have for the updated Malware SDO. Accordingly, I have two topics I’d like to bring up in this regard:
 

Thanks to the work done by Subodh Kumar and his team, I’ve been wondering if there’s a better way to capture the Observable Objects associated with the Malware SDO. Right now,
there are three places where you may encounter a Cyber Observable Object: samples (a dict of observable objects), static_analysis_results/results (certain keys have a corresponding dict of observable objects), dynamic_analysis_results/results (each key has
a corresponding dict of observable objects).  
 
Instead of having these observable object dictionaries all over the place, I believe it would make more sense to have a single property at the top level of the object (let’s call it
“observable_objects”), where any Cyber Observable Objects associated with the SDO (samples, analysis results, etc.) could be captured, via references. There are a number of advantages to this: a simpler data model (less embedded observable object dicts everywhere),
the ability to re-use objects (e.g., if static and dynamic analysis find the same objects, you can create one object and just reference it accordingly), and a more compact serialization. See the attached JSON example for what this looks like in practice –
this is a modified version of the “Malware Instance with Analysis Data” example currently in the 2.1 spec.
 

Currently, the “av-results-type”, used to capture AV classification results, has only optional properties and the text specifies that at least one must be included. This allows
you to construct some odd, but spec-valid instances, such as an AV classification with only the engine version. In order to make this type more useful, I’d suggest that we make “product” (the name of the tool performing the scan) and “scanned” (the date/time
the scan occurred) required, so that way you’ll at least have this minimum set of useful data for each instance. In addition, we should probably add some text stating that the “result” property (the actual AV classification result, e.g., “Trojan.Zeus”) must
be included if the tool reports some classification during the scan.
 
Let me know what you think – if we can get these final things wrapped up, we’re that much closer to getting STIX 2.1 out the door.
 
Regards,
Ivan

I will try and review this change this week. Bret From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Kirillov, Ivan A. <ikirillov@mitre.org> Sent: Monday, June 18, 2018 10:26:15 AM To: cti@lists.oasis-open.org Subject: [EXT] Re: [cti] Finalizing the STIX 2.1 Malware Object   Are there any other thoughts on these topics? It would be great to close them out so we can finish up CSD01 of STIX 2.1.   Regards, Ivan   From: <cti@lists.oasis-open.org> on behalf of Ivan Kirillov <ikirillov@mitre.org> Date: Wednesday, June 13, 2018 at 2:47 PM To: Allan Thomson <athomson@lookingglasscyber.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Cc: "Kumar, Subodh" <subodh.kumar@jpmorgan.com> Subject: Re: [cti] Finalizing the STIX 2.1 Malware Object   Sorry, that should read “Conversely, parsing the SDO may become more difficult because…”   Regards, Ivan   From: Ivan Kirillov <ikirillov@mitre.org> Date: Wednesday, June 13, 2018 at 2:44 PM To: Allan Thomson <athomson@lookingglasscyber.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Cc: "Kumar, Subodh" <subodh.kumar@jpmorgan.com> Subject: Re: [cti] Finalizing the STIX 2.1 Malware Object   Hi Allan,   This approach doesn’t fundamentally change how we capture static/dynamic analysis data, but rather where and how the Cyber Observable Objects that correspond to that data are stored. If you have multiple observables from different analyses, you’ll just reference their corresponding objects that are stored in the “observable_objects” dictionary (which may or may not be the same objects across different analyses). As far as being easier, it’s kind of a wash – it may simplify the generation of content because any Cyber Observable Objects would have to be stored in this top-level dictionary. Conversely, parsing the SDO because you’ll have to dereference the objects as you come across their usage. However, I do think that the simplification to the data model and the ability to re-use objects are worthwhile changes.   Regards, Ivan   From: Allan Thomson <athomson@lookingglasscyber.com> Date: Wednesday, June 13, 2018 at 2:22 PM To: Ivan Kirillov <ikirillov@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Cc: "Kumar, Subodh" <subodh.kumar@jpmorgan.com> Subject: Re: [cti] Finalizing the STIX 2.1 Malware Object   Ivan – regarding 1.   What if I have multiple observables for the same malware from different analysis (i.e. static + dynamic results).   Would consolidating them into a single place really make it easier? You would still want to indicate that you have a list of observables and indicate where those were ‘observed’ from either static or dynamic or other.   So I’m not sure consolidating it makes it easier but so long as the same things are possible with the consolidated design then I don’t have a strong preference either way.   Allan Thomson CTO ( +1-408-331-6646) LookingGlass Cyber Solutions   From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Kirillov, Ivan" <ikirillov@mitre.org> Date: Wednesday, June 13, 2018 at 12:57 PM To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Cc: "Kumar, Subodh" <subodh.kumar@jpmorgan.com> Subject: [cti] Finalizing the STIX 2.1 Malware Object   All,   As we’re wrapping up work on STIX 2.1 CSD01, we need to finalize what we have for the updated Malware SDO. Accordingly, I have two topics I’d like to bring up in this regard:   Thanks to the work done by Subodh Kumar and his team, I’ve been wondering if there’s a better way to capture the Observable Objects associated with the Malware SDO. Right now, there are three places where you may encounter a Cyber Observable Object: samples (a dict of observable objects), static_analysis_results/results (certain keys have a corresponding dict of observable objects), dynamic_analysis_results/results (each key has a corresponding dict of observable objects).     Instead of having these observable object dictionaries all over the place, I believe it would make more sense to have a single property at the top level of the object (let’s call it “observable_objects”), where any Cyber Observable Objects associated with the SDO (samples, analysis results, etc.) could be captured, via references. There are a number of advantages to this: a simpler data model (less embedded observable object dicts everywhere), the ability to re-use objects (e.g., if static and dynamic analysis find the same objects, you can create one object and just reference it accordingly), and a more compact serialization. See the attached JSON example for what this looks like in practice – this is a modified version of the “Malware Instance with Analysis Data” example currently in the 2.1 spec.   Currently, the “av-results-type”, used to capture AV classification results, has only optional properties and the text specifies that at least one must be included. This allows you to construct some odd, but spec-valid instances, such as an AV classification with only the engine version. In order to make this type more useful, I’d suggest that we make “product” (the name of the tool performing the scan) and “scanned” (the date/time the scan occurred) required, so that way you’ll at least have this minimum set of useful data for each instance. In addition, we should probably add some text stating that the “result” property (the actual AV classification result, e.g., “Trojan.Zeus”) must be included if the tool reports some classification during the scan.   Let me know what you think – if we can get these final things wrapped up, we’re that much closer to getting STIX 2.1 out the door.   Regards, Ivan