CTI STIX Subcommittee

Have a preference for #2 followed by #3.
 
The reason for preference #2 is that malware will be referenced by other TLOs (potentially multiple instances) and therefore having just a flag does not resolve the issue of association
of the malware to TTPs, Intrusion Sets, Campaigns….etc.
 
allan
 

From:
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, June 9, 2016 at 3:08 PM
To: "Wunder, John" <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Re: Malware, Malicious Tool, and Tool


 




 
Based on your list from your email I would go with #2 or #3...  The reason for this, I spelled out in detail on the Slack channel.  But it comes down to, the industry
knows and understands what Malware is...  If we produce a spec that does not have a container for Malware, it will be a big mistake.  We will effectively need to re-train the entire internet on the fact that we are re-defining the way they use the term Malware.
 And I doubt that will have a positive outcome.  

 


Bret


 






From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on
behalf of Wunder, John A. <jwunder@mitre.org>
Sent: Thursday, June 9, 2016 8:10 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Malware, Malicious Tool, and Tool


 




All,
 
I took a shot at producing some material describing various approaches we could use to represent malware, malicious tools (or, malicious usage of tools), and tools.
 
It’s a tough call with a bunch of tradeoffs, I don’t really see a “right” answer, but my preference is still Option 1. My reasoning:
 
-          
IMO TLOs should be able to stand on their own…critical information should not be captured via relationships because people might not know them or might not want to share them. The fact that
a particular TLO represents malicious usage of a tool seems very important to me.
-          
I’m not sure that the fields used to represent data about malicious usage of tools is the same as the fields used to represent data about benign usage of tools (as a target, info source,
or other use cases). So, having those as separate TLOs seems important to me. You care about different data for a tool depending on how it’s being used.
 
To be honest I’m not 100% sold on “Weapon” as the TLO name (vs. Malicious Tool, Malicious Code, or something else) but I’m fairly comfortable with having one TLO for
stuff used maliciously and a different TLO for stuff not used maliciously (defining that based on our use cases for it).
 
John

Just to clarify, having the flag shouldn’t be a substitute for relationships to campaigns and other things. It’s just a way of indicating that the tool is malicious without having to have
that relationship (given that many sharing organizations don’t share the higher level items, only indicators and malware/tools). So with the flag you could have a flag saying the tool is malicious and also a relationship saying it’s used by the campaign…it’s
just that with the flag the tool stands on its own as the malicious usage of that tool.
 

From:
<cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, June 9, 2016 at 6:45 PM
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



Have a preference for #2 followed by #3.
 
The reason for preference #2 is that malware will be referenced by other TLOs (potentially multiple instances) and therefore having just a flag does not resolve the issue of association
of the malware to TTPs, Intrusion Sets, Campaigns….etc.
 
allan
 

From:
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, June 9, 2016 at 3:08 PM
To: "Wunder, John" <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Re: Malware, Malicious Tool, and Tool


 




 
Based on your list from your email I would go with #2 or #3...  The reason for this, I spelled out in detail on the Slack channel.  But it comes down to, the industry
knows and understands what Malware is...  If we produce a spec that does not have a container for Malware, it will be a big mistake.  We will effectively need to re-train the entire internet on the fact that we are re-defining the way they use the term Malware.
 And I doubt that will have a positive outcome.  

 


Bret


 






From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on
behalf of Wunder, John A. <jwunder@mitre.org>
Sent: Thursday, June 9, 2016 8:10 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Malware, Malicious Tool, and Tool


 




All,
 
I took a shot at producing some material describing various approaches we could use to represent malware, malicious tools (or, malicious usage of tools), and tools.
 
It’s a tough call with a bunch of tradeoffs, I don’t really see a “right” answer, but my preference is still Option 1. My reasoning:
 
-          
IMO TLOs should be able to stand on their own…critical information should not be captured via relationships because people might not know them or might not want to share them. The fact that
a particular TLO represents malicious usage of a tool seems very important to me.
-          
I’m not sure that the fields used to represent data about malicious usage of tools is the same as the fields used to represent data about benign usage of tools (as a target, info source,
or other use cases). So, having those as separate TLOs seems important to me. You care about different data for a tool depending on how it’s being used.
 
To be honest I’m not 100% sold on “Weapon” as the TLO name (vs. Malicious Tool, Malicious Code, or something else) but I’m fairly comfortable with having one TLO for
stuff used maliciously and a different TLO for stuff not used maliciously (defining that based on our use cases for it).
 
John

OK – then I don’t get the value of the Boolean flag provides that is not already captured by having 2 object classes (malware and tool) and the ability to define relationships between those
objects and others.
 
So #2 is still my preference.
 
allan
 

From:
"Wunder, John" <jwunder@mitre.org>
Date: Thursday, June 9, 2016 at 3:53 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



Just to clarify, having the flag shouldn’t be a substitute for relationships to campaigns and other things. It’s just a way of indicating that the tool is malicious without having to have
that relationship (given that many sharing organizations don’t share the higher level items, only indicators and malware/tools). So with the flag you could have a flag saying the tool is malicious and also a relationship saying it’s used by the campaign…it’s
just that with the flag the tool stands on its own as the malicious usage of that tool.
 

From:
<cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, June 9, 2016 at 6:45 PM
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



Have a preference for #2 followed by #3.
 
The reason for preference #2 is that malware will be referenced by other TLOs (potentially multiple instances) and therefore having just a flag does not resolve the issue of association
of the malware to TTPs, Intrusion Sets, Campaigns….etc.
 
allan
 

From:
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, June 9, 2016 at 3:08 PM
To: "Wunder, John" <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Re: Malware, Malicious Tool, and Tool


 




 
Based on your list from your email I would go with #2 or #3...  The reason for this, I spelled out in detail on the Slack channel.  But it comes down to, the industry
knows and understands what Malware is...  If we produce a spec that does not have a container for Malware, it will be a big mistake.  We will effectively need to re-train the entire internet on the fact that we are re-defining the way they use the term Malware.
 And I doubt that will have a positive outcome.  

 


Bret


 






From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on
behalf of Wunder, John A. <jwunder@mitre.org>
Sent: Thursday, June 9, 2016 8:10 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Malware, Malicious Tool, and Tool


 




All,
 
I took a shot at producing some material describing various approaches we could use to represent malware, malicious tools (or, malicious usage of tools), and tools.
 
It’s a tough call with a bunch of tradeoffs, I don’t really see a “right” answer, but my preference is still Option 1. My reasoning:
 
-          
IMO TLOs should be able to stand on their own…critical information should not be captured via relationships because people might not know them or might not want to share them. The fact that
a particular TLO represents malicious usage of a tool seems very important to me.
-          
I’m not sure that the fields used to represent data about malicious usage of tools is the same as the fields used to represent data about benign usage of tools (as a target, info source,
or other use cases). So, having those as separate TLOs seems important to me. You care about different data for a tool depending on how it’s being used.
 
To be honest I’m not 100% sold on “Weapon” as the TLO name (vs. Malicious Tool, Malicious Code, or something else) but I’m fairly comfortable with having one TLO for
stuff used maliciously and a different TLO for stuff not used maliciously (defining that based on our use cases for it).
 
John

So the use case is this: you’ve seen usage of a tool (not malware) to attack people and have some indicators for how to detect it. You don’t know who’s doing it, how they’re targeting,
or anything else. Basically you have some indicators for a tool that you know to be malicious and that’s it.
 
How would you represent that in #2 without assuming that anything with an indicator pointing to it is bad (which is something I thought we didn’t want to do)?
 
John
 

From:
<cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, June 9, 2016 at 7:01 PM
To: "Wunder, John A." <jwunder@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



OK – then I don’t get the value of the Boolean flag provides that is not already captured by having 2 object classes (malware and tool) and the ability to define relationships between those
objects and others.
 
So #2 is still my preference.
 
allan
 

From:
"Wunder, John" <jwunder@mitre.org>
Date: Thursday, June 9, 2016 at 3:53 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



Just to clarify, having the flag shouldn’t be a substitute for relationships to campaigns and other things. It’s just a way of indicating that the tool is malicious without having to have
that relationship (given that many sharing organizations don’t share the higher level items, only indicators and malware/tools). So with the flag you could have a flag saying the tool is malicious and also a relationship saying it’s used by the campaign…it’s
just that with the flag the tool stands on its own as the malicious usage of that tool.
 

From:
<cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, June 9, 2016 at 6:45 PM
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



Have a preference for #2 followed by #3.
 
The reason for preference #2 is that malware will be referenced by other TLOs (potentially multiple instances) and therefore having just a flag does not resolve the issue of association
of the malware to TTPs, Intrusion Sets, Campaigns….etc.
 
allan
 

From:
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, June 9, 2016 at 3:08 PM
To: "Wunder, John" <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Re: Malware, Malicious Tool, and Tool


 




 
Based on your list from your email I would go with #2 or #3...  The reason for this, I spelled out in detail on the Slack channel.  But it comes down to, the industry
knows and understands what Malware is...  If we produce a spec that does not have a container for Malware, it will be a big mistake.  We will effectively need to re-train the entire internet on the fact that we are re-defining the way they use the term Malware.
 And I doubt that will have a positive outcome.  

 


Bret


 






From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on
behalf of Wunder, John A. <jwunder@mitre.org>
Sent: Thursday, June 9, 2016 8:10 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Malware, Malicious Tool, and Tool


 




All,
 
I took a shot at producing some material describing various approaches we could use to represent malware, malicious tools (or, malicious usage of tools), and tools.
 
It’s a tough call with a bunch of tradeoffs, I don’t really see a “right” answer, but my preference is still Option 1. My reasoning:
 
-          
IMO TLOs should be able to stand on their own…critical information should not be captured via relationships because people might not know them or might not want to share them. The fact that
a particular TLO represents malicious usage of a tool seems very important to me.
-          
I’m not sure that the fields used to represent data about malicious usage of tools is the same as the fields used to represent data about benign usage of tools (as a target, info source,
or other use cases). So, having those as separate TLOs seems important to me. You care about different data for a tool depending on how it’s being used.
 
To be honest I’m not 100% sold on “Weapon” as the TLO name (vs. Malicious Tool, Malicious Code, or something else) but I’m fairly comfortable with having one TLO for
stuff used maliciously and a different TLO for stuff not used maliciously (defining that based on our use cases for it).
 
John

If you know that its malicious then why would you not create a malware instance and not a tool?
 
This is one of the reasons why having 2 classes of objects (malware & tool) for ‘software’ that have implicit knowledge associated with those classes is a problem in my mind.
 
If we had a ‘software’ class that represents all software (regardless of other knowledge) and that has attributes that identifies characteristics of the software including an attribute
that it was malicious then it would be better/simpler.
 
<soapbox>
This is why in object-oriented modelling you avoid derivation and rather have a class to represent the base type (i.e. software) and represent behavioral aspects separately as attributes
or optional objects that characterize the behavior instead of using inheritance.
</soapbox>
 
allan
 

From:
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org>
Date: Thursday, June 9, 2016 at 4:09 PM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



So the use case is this: you’ve seen usage of a tool (not malware) to attack people and have some indicators for how to detect it. You don’t know who’s doing it, how they’re targeting,
or anything else. Basically you have some indicators for a tool that you know to be malicious and that’s it.
 
How would you represent that in #2 without assuming that anything with an indicator pointing to it is bad (which is something I thought we didn’t want to do)?
 
John
 

From:
<cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, June 9, 2016 at 7:01 PM
To: "Wunder, John A." <jwunder@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



OK – then I don’t get the value of the Boolean flag provides that is not already captured by having 2 object classes (malware and tool) and the ability to define relationships between those
objects and others.
 
So #2 is still my preference.
 
allan
 

From:
"Wunder, John" <jwunder@mitre.org>
Date: Thursday, June 9, 2016 at 3:53 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



Just to clarify, having the flag shouldn’t be a substitute for relationships to campaigns and other things. It’s just a way of indicating that the tool is malicious without having to have
that relationship (given that many sharing organizations don’t share the higher level items, only indicators and malware/tools). So with the flag you could have a flag saying the tool is malicious and also a relationship saying it’s used by the campaign…it’s
just that with the flag the tool stands on its own as the malicious usage of that tool.
 

From:
<cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, June 9, 2016 at 6:45 PM
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



Have a preference for #2 followed by #3.
 
The reason for preference #2 is that malware will be referenced by other TLOs (potentially multiple instances) and therefore having just a flag does not resolve the issue of association
of the malware to TTPs, Intrusion Sets, Campaigns….etc.
 
allan
 

From:
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, June 9, 2016 at 3:08 PM
To: "Wunder, John" <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Re: Malware, Malicious Tool, and Tool


 




 
Based on your list from your email I would go with #2 or #3...  The reason for this, I spelled out in detail on the Slack channel.  But it comes down to, the industry
knows and understands what Malware is...  If we produce a spec that does not have a container for Malware, it will be a big mistake.  We will effectively need to re-train the entire internet on the fact that we are re-defining the way they use the term Malware.
 And I doubt that will have a positive outcome.  

 


Bret


 






From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on
behalf of Wunder, John A. <jwunder@mitre.org>
Sent: Thursday, June 9, 2016 8:10 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Malware, Malicious Tool, and Tool


 




All,
 
I took a shot at producing some material describing various approaches we could use to represent malware, malicious tools (or, malicious usage of tools), and tools.
 
It’s a tough call with a bunch of tradeoffs, I don’t really see a “right” answer, but my preference is still Option 1. My reasoning:
 
-          
IMO TLOs should be able to stand on their own…critical information should not be captured via relationships because people might not know them or might not want to share them. The fact that
a particular TLO represents malicious usage of a tool seems very important to me.
-          
I’m not sure that the fields used to represent data about malicious usage of tools is the same as the fields used to represent data about benign usage of tools (as a target, info source,
or other use cases). So, having those as separate TLOs seems important to me. You care about different data for a tool depending on how it’s being used.
 
To be honest I’m not 100% sold on “Weapon” as the TLO name (vs. Malicious Tool, Malicious Code, or something else) but I’m fairly comfortable with having one TLO for
stuff used maliciously and a different TLO for stuff not used maliciously (defining that based on our use cases for it).
 
John

So you would call something like LOIC (used to perform DoS) malware?
 

From:
<cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, June 9, 2016 at 7:15 PM
To: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



If you know that its malicious then why would you not create a malware instance and not a tool?
 
This is one of the reasons why having 2 classes of objects (malware & tool) for ‘software’ that have implicit knowledge associated with those classes is a problem in my mind.
 
If we had a ‘software’ class that represents all software (regardless of other knowledge) and that has attributes that identifies characteristics of the software including an attribute
that it was malicious then it would be better/simpler.
 
<soapbox>
This is why in object-oriented modelling you avoid derivation and rather have a class to represent the base type (i.e. software) and represent behavioral aspects separately as attributes
or optional objects that characterize the behavior instead of using inheritance.
</soapbox>
 
allan
 

From:
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org>
Date: Thursday, June 9, 2016 at 4:09 PM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



So the use case is this: you’ve seen usage of a tool (not malware) to attack people and have some indicators for how to detect it. You don’t know who’s doing it, how they’re targeting,
or anything else. Basically you have some indicators for a tool that you know to be malicious and that’s it.
 
How would you represent that in #2 without assuming that anything with an indicator pointing to it is bad (which is something I thought we didn’t want to do)?
 
John
 

From:
<cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, June 9, 2016 at 7:01 PM
To: "Wunder, John A." <jwunder@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



OK – then I don’t get the value of the Boolean flag provides that is not already captured by having 2 object classes (malware and tool) and the ability to define relationships between those
objects and others.
 
So #2 is still my preference.
 
allan
 

From:
"Wunder, John" <jwunder@mitre.org>
Date: Thursday, June 9, 2016 at 3:53 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



Just to clarify, having the flag shouldn’t be a substitute for relationships to campaigns and other things. It’s just a way of indicating that the tool is malicious without having to have
that relationship (given that many sharing organizations don’t share the higher level items, only indicators and malware/tools). So with the flag you could have a flag saying the tool is malicious and also a relationship saying it’s used by the campaign…it’s
just that with the flag the tool stands on its own as the malicious usage of that tool.
 

From:
<cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, June 9, 2016 at 6:45 PM
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



Have a preference for #2 followed by #3.
 
The reason for preference #2 is that malware will be referenced by other TLOs (potentially multiple instances) and therefore having just a flag does not resolve the issue of association
of the malware to TTPs, Intrusion Sets, Campaigns….etc.
 
allan
 

From:
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, June 9, 2016 at 3:08 PM
To: "Wunder, John" <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Re: Malware, Malicious Tool, and Tool


 




 
Based on your list from your email I would go with #2 or #3...  The reason for this, I spelled out in detail on the Slack channel.  But it comes down to, the industry
knows and understands what Malware is...  If we produce a spec that does not have a container for Malware, it will be a big mistake.  We will effectively need to re-train the entire internet on the fact that we are re-defining the way they use the term Malware.
 And I doubt that will have a positive outcome.  

 


Bret


 






From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on
behalf of Wunder, John A. <jwunder@mitre.org>
Sent: Thursday, June 9, 2016 8:10 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Malware, Malicious Tool, and Tool


 




All,
 
I took a shot at producing some material describing various approaches we could use to represent malware, malicious tools (or, malicious usage of tools), and tools.
 
It’s a tough call with a bunch of tradeoffs, I don’t really see a “right” answer, but my preference is still Option 1. My reasoning:
 
-          
IMO TLOs should be able to stand on their own…critical information should not be captured via relationships because people might not know them or might not want to share them. The fact that
a particular TLO represents malicious usage of a tool seems very important to me.
-          
I’m not sure that the fields used to represent data about malicious usage of tools is the same as the fields used to represent data about benign usage of tools (as a target, info source,
or other use cases). So, having those as separate TLOs seems important to me. You care about different data for a tool depending on how it’s being used.
 
To be honest I’m not 100% sold on “Weapon” as the TLO name (vs. Malicious Tool, Malicious Code, or something else) but I’m fairly comfortable with having one TLO for
stuff used maliciously and a different TLO for stuff not used maliciously (defining that based on our use cases for it).
 
John

Maybe I’m misunderstanding something. I thought there were two distinctions we wanted to make:
 
1.       
Whether or not something is being used maliciously. Some things are always used maliciously, others not so much.
2.       
Whether or not something is “malware”, by which I mean things that are installed without the user’s intent (Trojan, ransomware, etc.), and “tools”, by which I mean things like
LOIC that are generally installed intentionally by the user to attack other people.
 
If we don’t need to make that latter distinction and can call all of those things malware I’m very happy to go with #2.
 
John
 

From:
<cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Thursday, June 9, 2016 at 7:20 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



So you would call something like LOIC (used to perform DoS) malware?
 

From:
<cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, June 9, 2016 at 7:15 PM
To: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



If you know that its malicious then why would you not create a malware instance and not a tool?
 
This is one of the reasons why having 2 classes of objects (malware & tool) for ‘software’ that have implicit knowledge associated with those classes is a problem in my mind.
 
If we had a ‘software’ class that represents all software (regardless of other knowledge) and that has attributes that identifies characteristics of the software including an attribute
that it was malicious then it would be better/simpler.
 
<soapbox>
This is why in object-oriented modelling you avoid derivation and rather have a class to represent the base type (i.e. software) and represent behavioral aspects separately as attributes
or optional objects that characterize the behavior instead of using inheritance.
</soapbox>
 
allan
 

From:
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org>
Date: Thursday, June 9, 2016 at 4:09 PM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



So the use case is this: you’ve seen usage of a tool (not malware) to attack people and have some indicators for how to detect it. You don’t know who’s doing it, how they’re targeting,
or anything else. Basically you have some indicators for a tool that you know to be malicious and that’s it.
 
How would you represent that in #2 without assuming that anything with an indicator pointing to it is bad (which is something I thought we didn’t want to do)?
 
John
 

From:
<cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, June 9, 2016 at 7:01 PM
To: "Wunder, John A." <jwunder@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



OK – then I don’t get the value of the Boolean flag provides that is not already captured by having 2 object classes (malware and tool) and the ability to define relationships between those
objects and others.
 
So #2 is still my preference.
 
allan
 

From:
"Wunder, John" <jwunder@mitre.org>
Date: Thursday, June 9, 2016 at 3:53 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



Just to clarify, having the flag shouldn’t be a substitute for relationships to campaigns and other things. It’s just a way of indicating that the tool is malicious without having to have
that relationship (given that many sharing organizations don’t share the higher level items, only indicators and malware/tools). So with the flag you could have a flag saying the tool is malicious and also a relationship saying it’s used by the campaign…it’s
just that with the flag the tool stands on its own as the malicious usage of that tool.
 

From:
<cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, June 9, 2016 at 6:45 PM
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



Have a preference for #2 followed by #3.
 
The reason for preference #2 is that malware will be referenced by other TLOs (potentially multiple instances) and therefore having just a flag does not resolve the issue of association
of the malware to TTPs, Intrusion Sets, Campaigns….etc.
 
allan
 

From:
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, June 9, 2016 at 3:08 PM
To: "Wunder, John" <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Re: Malware, Malicious Tool, and Tool


 




 
Based on your list from your email I would go with #2 or #3...  The reason for this, I spelled out in detail on the Slack channel.  But it comes down to, the industry
knows and understands what Malware is...  If we produce a spec that does not have a container for Malware, it will be a big mistake.  We will effectively need to re-train the entire internet on the fact that we are re-defining the way they use the term Malware.
 And I doubt that will have a positive outcome.  

 


Bret


 






From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on
behalf of Wunder, John A. <jwunder@mitre.org>
Sent: Thursday, June 9, 2016 8:10 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Malware, Malicious Tool, and Tool


 




All,
 
I took a shot at producing some material describing various approaches we could use to represent malware, malicious tools (or, malicious usage of tools), and tools.
 
It’s a tough call with a bunch of tradeoffs, I don’t really see a “right” answer, but my preference is still Option 1. My reasoning:
 
-          
IMO TLOs should be able to stand on their own…critical information should not be captured via relationships because people might not know them or might not want to share them. The fact that
a particular TLO represents malicious usage of a tool seems very important to me.
-          
I’m not sure that the fields used to represent data about malicious usage of tools is the same as the fields used to represent data about benign usage of tools (as a target, info source,
or other use cases). So, having those as separate TLOs seems important to me. You care about different data for a tool depending on how it’s being used.
 
To be honest I’m not 100% sold on “Weapon” as the TLO name (vs. Malicious Tool, Malicious Code, or something else) but I’m fairly comfortable with having one TLO for
stuff used maliciously and a different TLO for stuff not used maliciously (defining that based on our use cases for it).
 
John

I also think there is a mindset that some want to document non malicious tools in STIX, which I am not sure you would do outside of use tool X during an automated COA or tool Y was used during an investigation.   I think where we are getting wrapped around the axle is with tools that have legitimate uses in the network but that an attacker may also use.  Gale NMAP as the poster child.  It is NOT malware. No one in the security world or network world would say it is malware.  It is a networking tool.  But it may be used by an attacker.   So you. An either put a flag on a tool object saying it is being used maliciously. (Explicit declaration).  Or you can link the tool object to an indicator and thus implicitly declare it is malicious. But this does not replace the need for a malware object Bret  Sent from my Commodore 64 On Jun 10, 2016, at 12:16 AM, Allan Thomson < athomson@lookingglasscyber.com > wrote: If you know that its malicious then why would you not create a malware instance and not a tool?   This is one of the reasons why having 2 classes of objects (malware & tool) for ‘software’ that have implicit knowledge associated with those classes is a problem in my mind.   If we had a ‘software’ class that represents all software (regardless of other knowledge) and that has attributes that identifies characteristics of the software including an attribute that it was malicious then it would be better/simpler.   <soapbox> This is why in object-oriented modelling you avoid derivation and rather have a class to represent the base type (i.e. software) and represent behavioral aspects separately as attributes or optional objects that characterize the behavior instead of using inheritance. </soapbox>   allan   From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of "Wunder, John" < jwunder@mitre.org > Date: Thursday, June 9, 2016 at 4:09 PM To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool   So the use case is this: you’ve seen usage of a tool (not malware) to attack people and have some indicators for how to detect it. You don’t know who’s doing it, how they’re targeting, or anything else. Basically you have some indicators for a tool that you know to be malicious and that’s it.   How would you represent that in #2 without assuming that anything with an indicator pointing to it is bad (which is something I thought we didn’t want to do)?   John   From: < cti-stix@lists.oasis-open.org > on behalf of Allan Thomson < athomson@lookingglasscyber.com > Date: Thursday, June 9, 2016 at 7:01 PM To: "Wunder, John A." < jwunder@mitre.org >, "Jordan, Bret" < bret.jordan@bluecoat.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool   OK – then I don’t get the value of the Boolean flag provides that is not already captured by having 2 object classes (malware and tool) and the ability to define relationships between those objects and others.   So #2 is still my preference.   allan   From: "Wunder, John" < jwunder@mitre.org > Date: Thursday, June 9, 2016 at 3:53 PM To: Allan Thomson < athomson@lookingglasscyber.com >, "Jordan, Bret" < bret.jordan@bluecoat.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool   Just to clarify, having the flag shouldn’t be a substitute for relationships to campaigns and other things. It’s just a way of indicating that the tool is malicious without having to have that relationship (given that many sharing organizations don’t share the higher level items, only indicators and malware/tools). So with the flag you could have a flag saying the tool is malicious and also a relationship saying it’s used by the campaign…it’s just that with the flag the tool stands on its own as the malicious usage of that tool.   From: < cti-stix@lists.oasis-open.org > on behalf of Allan Thomson < athomson@lookingglasscyber.com > Date: Thursday, June 9, 2016 at 6:45 PM To: "Jordan, Bret" < bret.jordan@bluecoat.com >, "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool   Have a preference for #2 followed by #3.   The reason for preference #2 is that malware will be referenced by other TLOs (potentially multiple instances) and therefore having just a flag does not resolve the issue of association of the malware to TTPs, Intrusion Sets, Campaigns….etc.   allan   From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of "Jordan, Bret" < bret.jordan@bluecoat.com > Date: Thursday, June 9, 2016 at 3:08 PM To: "Wunder, John" < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Re: Malware, Malicious Tool, and Tool     Based on your list from your email I would go with #2 or #3...  The reason for this, I spelled out in detail on the Slack channel.  But it comes down to, the industry knows and understands what Malware is...  If we produce a spec that does not have a container for Malware, it will be a big mistake.  We will effectively need to re-train the entire internet on the fact that we are re-defining the way they use the term Malware.  And I doubt that will have a positive outcome.     Bret   From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of Wunder, John A. < jwunder@mitre.org > Sent: Thursday, June 9, 2016 8:10 AM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] Malware, Malicious Tool, and Tool   All,   I took a shot at producing some material describing various approaches we could use to represent malware, malicious tools (or, malicious usage of tools), and tools.   It’s a tough call with a bunch of tradeoffs, I don’t really see a “right” answer, but my preference is still Option 1. My reasoning:   -           IMO TLOs should be able to stand on their own…critical information should not be captured via relationships because people might not know them or might not want to share them. The fact that a particular TLO represents malicious usage of a tool seems very important to me. -           I’m not sure that the fields used to represent data about malicious usage of tools is the same as the fields used to represent data about benign usage of tools (as a target, info source, or other use cases). So, having those as separate TLOs seems important to me. You care about different data for a tool depending on how it’s being used.   To be honest I’m not 100% sold on “Weapon” as the TLO name (vs. Malicious Tool, Malicious Code, or something else) but I’m fairly comfortable with having one TLO for stuff used maliciously and a different TLO for stuff not used maliciously (defining that based on our use cases for it).   John

In your TI product you may have a tool documented, say NMAP.   You may link against that tool in lots of ways..  And you may also want to link against it in a campaign and say that the tool, in this case, was used maliciously.   Or think of a script for Windows PowerShell.  It may be a tool that was built to clean up malware or something, but an attacker found a way of using that to attack something in your network.  You will not want to create two instances of that Tool.  You will want only one... And you will want to say how it was being used...  Tool === Actual Thing..   Relationship === assertion on how Thing was used.  I am completely against adding behavioral usage declarations on a Thing...  For they are always subjective.   Bret   From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org> Sent: Thursday, June 9, 2016 5:09 PM To: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool   So the use case is this: you’ve seen usage of a tool (not malware) to attack people and have some indicators for how to detect it. You don’t know who’s doing it, how they’re targeting, or anything else. Basically you have some indicators for a tool that you know to be malicious and that’s it.   How would you represent that in #2 without assuming that anything with an indicator pointing to it is bad (which is something I thought we didn’t want to do)?   John   From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com> Date: Thursday, June 9, 2016 at 7:01 PM To: "Wunder, John A." <jwunder@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool   OK – then I don’t get the value of the Boolean flag provides that is not already captured by having 2 object classes (malware and tool) and the ability to define relationships between those objects and others.   So #2 is still my preference.   allan   From: "Wunder, John" <jwunder@mitre.org> Date: Thursday, June 9, 2016 at 3:53 PM To: Allan Thomson <athomson@lookingglasscyber.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool   Just to clarify, having the flag shouldn’t be a substitute for relationships to campaigns and other things. It’s just a way of indicating that the tool is malicious without having to have that relationship (given that many sharing organizations don’t share the higher level items, only indicators and malware/tools). So with the flag you could have a flag saying the tool is malicious and also a relationship saying it’s used by the campaign…it’s just that with the flag the tool stands on its own as the malicious usage of that tool.   From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com> Date: Thursday, June 9, 2016 at 6:45 PM To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool   Have a preference for #2 followed by #3.   The reason for preference #2 is that malware will be referenced by other TLOs (potentially multiple instances) and therefore having just a flag does not resolve the issue of association of the malware to TTPs, Intrusion Sets, Campaigns….etc.   allan   From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com> Date: Thursday, June 9, 2016 at 3:08 PM To: "Wunder, John" <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: [cti-stix] Re: Malware, Malicious Tool, and Tool     Based on your list from your email I would go with #2 or #3...  The reason for this, I spelled out in detail on the Slack channel.  But it comes down to, the industry knows and understands what Malware is...  If we produce a spec that does not have a container for Malware, it will be a big mistake.  We will effectively need to re-train the entire internet on the fact that we are re-defining the way they use the term Malware.  And I doubt that will have a positive outcome.     Bret   From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org> Sent: Thursday, June 9, 2016 8:10 AM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] Malware, Malicious Tool, and Tool   All,   I took a shot at producing some material describing various approaches we could use to represent malware, malicious tools (or, malicious usage of tools), and tools.   It’s a tough call with a bunch of tradeoffs, I don’t really see a “right” answer, but my preference is still Option 1. My reasoning:   -           IMO TLOs should be able to stand on their own…critical information should not be captured via relationships because people might not know them or might not want to share them. The fact that a particular TLO represents malicious usage of a tool seems very important to me. -           I’m not sure that the fields used to represent data about malicious usage of tools is the same as the fields used to represent data about benign usage of tools (as a target, info source, or other use cases). So, having those as separate TLOs seems important to me. You care about different data for a tool depending on how it’s being used.   To be honest I’m not 100% sold on “Weapon” as the TLO name (vs. Malicious Tool, Malicious Code, or something else) but I’m fairly comfortable with having one TLO for stuff used maliciously and a different TLO for stuff not used maliciously (defining that based on our use cases for it).   John

Still not sure I buy this but as long as we’re OK representing all types of malicious tools as malware I’m OK with #2.
 

From:
"Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Friday, June 10, 2016 at 7:09 AM
To: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 




In your TI product you may have a tool documented, say NMAP.   You may link against that tool in lots of ways..  And you may also want to link against it in a campaign and say that the
tool, in this case, was used maliciously.  
 
Or think of a script for Windows PowerShell.  It may be a tool that was built to clean up malware or something, but an attacker found a way of using that to attack something in your network.
 You will not want to create two instances of that Tool.  You will want only one... And you will want to say how it was being used...  Tool === Actual Thing..   Relationship === assertion on how Thing was used. 
 
I am completely against adding behavioral usage declarations on a Thing...  For they are always subjective.  
 
Bret
 
 






From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on
behalf of Wunder, John A. <jwunder@mitre.org>
Sent: Thursday, June 9, 2016 5:09 PM
To: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 




So the use case is this: you’ve seen usage of a tool (not malware) to attack people and have some indicators for how to detect it. You don’t know who’s doing it, how
they’re targeting, or anything else. Basically you have some indicators for a tool that you know to be malicious and that’s it.
 
How would you represent that in #2 without assuming that anything with an indicator pointing to it is bad (which is something I thought we didn’t want to do)?
 
John
 

From:
<cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, June 9, 2016 at 7:01 PM
To: "Wunder, John A." <jwunder@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



OK – then I don’t get the value of the Boolean flag provides that is not already captured by having 2 object classes (malware and tool) and the ability to define relationships
between those objects and others.
 
So #2 is still my preference.
 
allan
 

From:
"Wunder, John" <jwunder@mitre.org>
Date: Thursday, June 9, 2016 at 3:53 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



Just to clarify, having the flag shouldn’t be a substitute for relationships to campaigns and other things. It’s just a way of indicating that the tool is malicious without
having to have that relationship (given that many sharing organizations don’t share the higher level items, only indicators and malware/tools). So with the flag you could have a flag saying the tool is malicious and also a relationship saying it’s used by
the campaign…it’s just that with the flag the tool stands on its own as the malicious usage of that tool.
 

From:
<cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, June 9, 2016 at 6:45 PM
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



Have a preference for #2 followed by #3.
 
The reason for preference #2 is that malware will be referenced by other TLOs (potentially multiple instances) and therefore having just a flag does not resolve the issue
of association of the malware to TTPs, Intrusion Sets, Campaigns….etc.
 
allan
 

From:
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, June 9, 2016 at 3:08 PM
To: "Wunder, John" <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Re: Malware, Malicious Tool, and Tool


 




 
Based on your list from your email I would go with #2 or #3...  The reason for this, I spelled out in detail on the Slack channel.  But it comes down to, the industry knows and understands
what Malware is...  If we produce a spec that does not have a container for Malware, it will be a big mistake.  We will effectively need to re-train the entire internet on the fact that we are re-defining the way they use the term Malware.  And I doubt that
will have a positive outcome.  

 


Bret


 






From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder,
John A. <jwunder@mitre.org>
Sent: Thursday, June 9, 2016 8:10 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Malware, Malicious Tool, and Tool


 




All,
 
I took a shot at producing some material describing various approaches we could use to represent malware, malicious tools (or, malicious usage of tools), and tools.
 
It’s a tough call with a bunch of tradeoffs, I don’t really see a “right” answer, but my preference is still Option 1. My reasoning:
 
-          
IMO TLOs should be able to stand on their own…critical information should not be captured via relationships because people might not know them or might not want to share them. The fact that
a particular TLO represents malicious usage of a tool seems very important to me.
-          
I’m not sure that the fields used to represent data about malicious usage of tools is the same as the fields used to represent data about benign usage of tools (as a target, info source,
or other use cases). So, having those as separate TLOs seems important to me. You care about different data for a tool depending on how it’s being used.
 
To be honest I’m not 100% sold on “Weapon” as the TLO name (vs. Malicious Tool, Malicious Code, or something else) but I’m fairly comfortable with having one TLO for
stuff used maliciously and a different TLO for stuff not used maliciously (defining that based on our use cases for it).
 
John

I would like some analysts to chime into this conversation as opposed to all of us product people. My gut says that an analyst is not going to want to classify NMAP or VNC as "malware". - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Wunder, John A." ---06/10/2016 09:13:26 AM---Still not sure I buy this but as long as we’re OK representing all types of malicious tools as malwa From: "Wunder, John A." <jwunder@mitre.org> To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 06/10/2016 09:13 AM Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool Sent by: <cti-stix@lists.oasis-open.org> Still not sure I buy this but as long as we’re OK representing all types of malicious tools as malware I’m OK with #2. From: "Jordan, Bret" <bret.jordan@bluecoat.com> Date: Friday, June 10, 2016 at 7:09 AM To: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool In your TI product you may have a tool documented, say NMAP. You may link against that tool in lots of ways.. And you may also want to link against it in a campaign and say that the tool, in this case, was used maliciously. Or think of a script for Windows PowerShell. It may be a tool that was built to clean up malware or something, but an attacker found a way of using that to attack something in your network. You will not want to create two instances of that Tool. You will want only one... And you will want to say how it was being used... Tool === Actual Thing.. Relationship === assertion on how Thing was used. I am completely against adding behavioral usage declarations on a Thing... For they are always subjective. Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org> Sent: Thursday, June 9, 2016 5:09 PM To: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool So the use case is this: you’ve seen usage of a tool (not malware) to attack people and have some indicators for how to detect it. You don’t know who’s doing it, how they’re targeting, or anything else. Basically you have some indicators for a tool that you know to be malicious and that’s it. How would you represent that in #2 without assuming that anything with an indicator pointing to it is bad (which is something I thought we didn’t want to do)? John From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com> Date: Thursday, June 9, 2016 at 7:01 PM To: "Wunder, John A." <jwunder@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool OK – then I don’t get the value of the Boolean flag provides that is not already captured by having 2 object classes (malware and tool) and the ability to define relationships between those objects and others. So #2 is still my preference. allan From: "Wunder, John" <jwunder@mitre.org> Date: Thursday, June 9, 2016 at 3:53 PM To: Allan Thomson <athomson@lookingglasscyber.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool Just to clarify, having the flag shouldn’t be a substitute for relationships to campaigns and other things. It’s just a way of indicating that the tool is malicious without having to have that relationship (given that many sharing organizations don’t share the higher level items, only indicators and malware/tools). So with the flag you could have a flag saying the tool is malicious and also a relationship saying it’s used by the campaign…it’s just that with the flag the tool stands on its own as the malicious usage of that tool. From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com> Date: Thursday, June 9, 2016 at 6:45 PM To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool Have a preference for #2 followed by #3. The reason for preference #2 is that malware will be referenced by other TLOs (potentially multiple instances) and therefore having just a flag does not resolve the issue of association of the malware to TTPs, Intrusion Sets, Campaigns….etc. allan From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com> Date: Thursday, June 9, 2016 at 3:08 PM To: "Wunder, John" <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: [cti-stix] Re: Malware, Malicious Tool, and Tool Based on your list from your email I would go with #2 or #3... The reason for this, I spelled out in detail on the Slack channel. But it comes down to, the industry knows and understands what Malware is... If we produce a spec that does not have a container for Malware, it will be a big mistake. We will effectively need to re-train the entire internet on the fact that we are re-defining the way they use the term Malware. And I doubt that will have a positive outcome. Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org> Sent: Thursday, June 9, 2016 8:10 AM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] Malware, Malicious Tool, and Tool All, I took a shot at producing some material describing various approaches we could use to represent malware, malicious tools (or, malicious usage of tools), and tools. It’s a tough call with a bunch of tradeoffs, I don’t really see a “right” answer, but my preference is still Option 1. My reasoning: - IMO TLOs should be able to stand on their own…critical information should not be captured via relationships because people might not know them or might not want to share them. The fact that a particular TLO represents malicious usage of a tool seems very important to me. - I’m not sure that the fields used to represent data about malicious usage of tools is the same as the fields used to represent data about benign usage of tools (as a target, info source, or other use cases). So, having those as separate TLOs seems important to me. You care about different data for a tool depending on how it’s being used. To be honest I’m not 100% sold on “Weapon” as the TLO name (vs. Malicious Tool, Malicious Code, or something else) but I’m fairly comfortable with having one TLO for stuff used maliciously and a different TLO for stuff not used maliciously (defining that based on our use cases for it). John

Jason: You are right.  As an Analyst, I would prefer to go with the earlier suggestion that we separate out 'Malware' from 'Malicious_Tool' - Or even the other suggestion made by Terry earlier this week that we call the Object 'Tool' and have a boolean for 'Malicious' Yes/No. That is a very intuitive way to proceed on this.  Jane On 6/10/2016 8:06 AM, Jason Keirstead wrote: I would like some analysts to chime into this conversation as opposed to all of us product people. My gut says that an analyst is not going to want to classify NMAP or VNC as malware . - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Wunder, John A. ---06/10/2016 09:13:26 AM---Still not sure I buy this but as long as we’re OK representing all types of malicious tools as malwa From: Wunder, John A. <jwunder@mitre.org> To: Jordan, Bret <bret.jordan@bluecoat.com> , cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> Date: 06/10/2016 09:13 AM Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool Sent by: <cti-stix@lists.oasis-open.org> Still not sure I buy this but as long as we’re OK representing all types of malicious tools as malware I’m OK with #2. From: Jordan, Bret <bret.jordan@bluecoat.com> Date: Friday, June 10, 2016 at 7:09 AM To: Wunder, John A. <jwunder@mitre.org> , cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool In your TI product you may have a tool documented, say NMAP. You may link against that tool in lots of ways.. And you may also want to link against it in a campaign and say that the tool, in this case, was used maliciously. Or think of a script for Windows PowerShell. It may be a tool that was built to clean up malware or something, but an attacker found a way of using that to attack something in your network. You will not want to create two instances of that Tool. You will want only one... And you will want to say how it was being used... Tool === Actual Thing.. Relationship === assertion on how Thing was used. I am completely against adding behavioral usage declarations on a Thing... For they are always subjective. Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org> Sent: Thursday, June 9, 2016 5:09 PM To: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool So the use case is this: you’ve seen usage of a tool (not malware) to attack people and have some indicators for how to detect it. You don’t know who’s doing it, how they’re targeting, or anything else. Basically you have some indicators for a tool that you know to be malicious and that’s it. How would you represent that in #2 without assuming that anything with an indicator pointing to it is bad (which is something I thought we didn’t want to do)? John From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com> Date: Thursday, June 9, 2016 at 7:01 PM To: Wunder, John A. <jwunder@mitre.org> , Jordan, Bret <bret.jordan@bluecoat.com> , cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool OK – then I don’t get the value of the Boolean flag provides that is not already captured by having 2 object classes (malware and tool) and the ability to define relationships between those objects and others. So #2 is still my preference. allan From: Wunder, John <jwunder@mitre.org> Date: Thursday, June 9, 2016 at 3:53 PM To: Allan Thomson <athomson@lookingglasscyber.com> , Jordan, Bret <bret.jordan@bluecoat.com> , cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool Just to clarify, having the flag shouldn’t be a substitute for relationships to campaigns and other things. It’s just a way of indicating that the tool is malicious without having to have that relationship (given that many sharing organizations don’t share the higher level items, only indicators and malware/tools). So with the flag you could have a flag saying the tool is malicious and also a relationship saying it’s used by the campaign…it’s just that with the flag the tool stands on its own as the malicious usage of that tool. From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com> Date: Thursday, June 9, 2016 at 6:45 PM To: Jordan, Bret <bret.jordan@bluecoat.com> , Wunder, John A. <jwunder@mitre.org> , cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool Have a preference for #2 followed by #3. The reason for preference #2 is that malware will be referenced by other TLOs (potentially multiple instances) and therefore having just a flag does not resolve the issue of association of the malware to TTPs, Intrusion Sets, Campaigns….etc. allan From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Jordan, Bret <bret.jordan@bluecoat.com> Date: Thursday, June 9, 2016 at 3:08 PM To: Wunder, John <jwunder@mitre.org> , cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> Subject: [cti-stix] Re: Malware, Malicious Tool, and Tool Based on your list from your email I would go with #2 or #3... The reason for this, I spelled out in detail on the Slack channel. But it comes down to, the industry knows and understands what Malware is... If we produce a spec that does not have a container for Malware, it will be a big mistake. We will effectively need to re-train the entire internet on the fact that we are re-defining the way they use the term Malware. And I doubt that will have a positive outcome. Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org> Sent: Thursday, June 9, 2016 8:10 AM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] Malware, Malicious Tool, and Tool All, I took a shot at producing some material describing various approaches we could use to represent malware, malicious tools (or, malicious usage of tools), and tools. It’s a tough call with a bunch of tradeoffs, I don’t really see a “right” answer, but my preference is still Option 1. My reasoning: - IMO TLOs should be able to stand on their own…critical information should not be captured via relationships because people might not know them or might not want to share them. The fact that a particular TLO represents malicious usage of a tool seems very important to me. - I’m not sure that the fields used to represent data about malicious usage of tools is the same as the fields used to represent data about benign usage of tools (as a target, info source, or other use cases). So, having those as separate TLOs seems important to me. You care about different data for a tool depending on how it’s being used. To be honest I’m not 100% sold on “Weapon” as the TLO name (vs. Malicious Tool, Malicious Code, or something else) but I’m fairly comfortable with having one TLO for stuff used maliciously and a different TLO for stuff not used maliciously (defining that based on our use cases for it). John -- Jane Ginn, MSIA, MRP CTI-TC Co-Secretary Cyber Threat Intelligence Network, Inc. jg@ctin.us

Hi Jason – Agree with the suggestion on getting analyst input regardless of this specific issue.
 
Regarding statement on VNC as malware. Was anyone suggesting that? I agree its not malware but can be used in the act of performing something malicious. Hence why it would be good to have
a tool/software that can be associated with other aspects of the threat landscape including TTP, Campaign….etc.
 
allan
 

From:
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Friday, June 10, 2016 at 8:06 AM
To: "Wunder, John" <jwunder@mitre.org>
Cc: "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


 



I would like some analysts to chime into this conversation as opposed to all of us product people.

My gut says that an analyst is not going to want to classify NMAP or VNC as "malware".

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


"Wunder, John A." ---06/10/2016 09:13:26 AM---Still not sure I
buy this but as long as we’re OK representing all types of malicious tools as malwa

From: "Wunder, John A." <jwunder@mitre.org>
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 06/10/2016 09:13 AM
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool
Sent by: <cti-stix@lists.oasis-open.org>






Still not sure I buy this but as long as we’re OK representing all types of malicious tools as malware I’m OK with #2.

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Friday, June 10, 2016 at 7:09 AM
To: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool

In your TI product you may have a tool documented, say NMAP. You may link against that tool in lots of ways.. And you may also want to link against it in a campaign and say that the tool, in this case, was
used maliciously.

Or think of a script for Windows PowerShell. It may be a tool that was built to clean up malware or something, but an attacker found a way of using that to attack something in your network. You will not want
to create two instances of that Tool. You will want only one... And you will want to say how it was being used... Tool === Actual Thing.. Relationship === assertion on how Thing was used.


I am completely against adding behavioral usage declarations on a Thing... For they are always subjective.


Bret



From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org>
Sent: Thursday, June 9, 2016 5:09 PM
To: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


So the use case is this: you’ve seen usage of a tool (not malware) to attack people and have some indicators for how to detect it. You don’t know who’s doing it, how they’re targeting, or anything else. Basically you have some
indicators for a tool that you know to be malicious and that’s it.

How would you represent that in #2 without assuming that anything with an indicator pointing to it is bad (which is something I thought we didn’t want to do)?

John

From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, June 9, 2016 at 7:01 PM
To: "Wunder, John A." <jwunder@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool

OK – then I don’t get the value of the Boolean flag provides that is not already captured by having 2 object classes (malware and tool) and the ability to define relationships between those objects and others.

So #2 is still my preference.

allan

From: "Wunder, John" <jwunder@mitre.org>
Date: Thursday, June 9, 2016 at 3:53 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool

Just to clarify, having the flag shouldn’t be a substitute for relationships to campaigns and other things. It’s just a way of indicating that the tool is malicious without having to have that relationship (given that many
sharing organizations don’t share the higher level items, only indicators and malware/tools). So with the flag you could have a flag saying the tool is malicious and also a relationship saying it’s used by the campaign…it’s just that with the flag the tool
stands on its own as the malicious usage of that tool.

From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, June 9, 2016 at 6:45 PM
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool

Have a preference for #2 followed by #3.

The reason for preference #2 is that malware will be referenced by other TLOs (potentially multiple instances) and therefore having just a flag does not resolve the issue of association of the malware to TTPs, Intrusion Sets,
Campaigns….etc.

allan

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Thursday, June 9, 2016 at 3:08 PM
To: "Wunder, John" <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Re: Malware, Malicious Tool, and Tool


Based on your list from your email I would go with #2 or #3... The reason for this, I spelled out in detail on the Slack channel. But it comes down to, the industry knows and understands what Malware is...
If we produce a spec that does not have a container for Malware, it will be a big mistake. We will effectively need to re-train the entire internet on the fact that we are re-defining the way they use the term Malware. And I doubt that will have a positive
outcome.

Bret



From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org>
Sent: Thursday, June 9, 2016 8:10 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Malware, Malicious Tool, and Tool


All,

I took a shot at producing some material describing various approaches we could use to represent malware, malicious tools (or, malicious usage of tools), and tools.

It’s a tough call with a bunch of tradeoffs, I don’t really see a “right” answer, but my preference is still Option 1. My reasoning:
-
IMO TLOs should be able to stand on their own…critical information should not be captured via relationships because people might not know them or might not want to share them. The fact that a particular TLO represents
malicious usage of a tool seems very important to me.
-
I’m not sure that the fields used to represent data about malicious usage of tools is the same as the fields used to represent data about benign usage of tools (as a target, info source, or other use cases). So, having
those as separate TLOs seems important to me. You care about different data for a tool depending on how it’s being used.

To be honest I’m not 100% sold on “Weapon” as the TLO name (vs. Malicious Tool, Malicious Code, or something else) but I’m fairly comfortable with having one TLO for stuff used maliciously and a different TLO for stuff not
used maliciously (defining that based on our use cases for it).

John

It was mainly a reply to John's earlier email (quoted below to save looking it up). I am just saying, my gut says that analysts care very much about this distinction... but maybe I am wrong. --
Maybe I’m misunderstanding something. I thought there were two distinctions we wanted to make:   1.       Whether or not something is being used maliciously. Some things are always used maliciously, others not so much. 2.       Whether or not something is “malware”, by which I mean things that are installed without the user’s intent (Trojan, ransomware, etc.), and “tools”, by which I mean things like LOIC that are generally installed intentionally by the user to attack other people.   If we don’t need to make that latter distinction and can call all of those things malware I’m very happy to go with #2.   John - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Allan Thomson ---06/10/2016 03:18:37 PM---Hi Jason – Agree with the suggestion on getting analyst input regardless of this specific issue. Reg From: Allan Thomson <athomson@lookingglasscyber.com> To: Jason Keirstead/CanEast/IBM@IBMCA, "Wunder, John A." <jwunder@mitre.org> Cc: "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 06/10/2016 03:18 PM Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool Hi Jason – Agree with the suggestion on getting analyst input regardless of this specific issue. Regarding statement on VNC as malware. Was anyone suggesting that? I agree its not malware but can be used in the act of performing something malicious. Hence why it would be good to have a tool/software that can be associated with other aspects of the threat landscape including TTP, Campaign….etc. allan From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com> Date: Friday, June 10, 2016 at 8:06 AM To: "Wunder, John" <jwunder@mitre.org> Cc: "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool I would like some analysts to chime into this conversation as opposed to all of us product people. My gut says that an analyst is not going to want to classify NMAP or VNC as "malware". - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Wunder, John A." ---06/10/2016 09:13:26 AM---Still not sure I buy this but as long as we’re OK representing all types of malicious tools as malwa From: "Wunder, John A." <jwunder@mitre.org> To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 06/10/2016 09:13 AM Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool Sent by: <cti-stix@lists.oasis-open.org> Still not sure I buy this but as long as we’re OK representing all types of malicious tools as malware I’m OK with #2. From: "Jordan, Bret" <bret.jordan@bluecoat.com> Date: Friday, June 10, 2016 at 7:09 AM To: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool In your TI product you may have a tool documented, say NMAP. You may link against that tool in lots of ways.. And you may also want to link against it in a campaign and say that the tool, in this case, was used maliciously. Or think of a script for Windows PowerShell. It may be a tool that was built to clean up malware or something, but an attacker found a way of using that to attack something in your network. You will not want to create two instances of that Tool. You will want only one... And you will want to say how it was being used... Tool === Actual Thing.. Relationship === assertion on how Thing was used. I am completely against adding behavioral usage declarations on a Thing... For they are always subjective. Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org> Sent: Thursday, June 9, 2016 5:09 PM To: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool So the use case is this: you’ve seen usage of a tool (not malware) to attack people and have some indicators for how to detect it. You don’t know who’s doing it, how they’re targeting, or anything else. Basically you have some indicators for a tool that you know to be malicious and that’s it. How would you represent that in #2 without assuming that anything with an indicator pointing to it is bad (which is something I thought we didn’t want to do)? John From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com> Date: Thursday, June 9, 2016 at 7:01 PM To: "Wunder, John A." <jwunder@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool OK – then I don’t get the value of the Boolean flag provides that is not already captured by having 2 object classes (malware and tool) and the ability to define relationships between those objects and others. So #2 is still my preference. allan From: "Wunder, John" <jwunder@mitre.org> Date: Thursday, June 9, 2016 at 3:53 PM To: Allan Thomson <athomson@lookingglasscyber.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool Just to clarify, having the flag shouldn’t be a substitute for relationships to campaigns and other things. It’s just a way of indicating that the tool is malicious without having to have that relationship (given that many sharing organizations don’t share the higher level items, only indicators and malware/tools). So with the flag you could have a flag saying the tool is malicious and also a relationship saying it’s used by the campaign…it’s just that with the flag the tool stands on its own as the malicious usage of that tool. From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com> Date: Thursday, June 9, 2016 at 6:45 PM To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool Have a preference for #2 followed by #3. The reason for preference #2 is that malware will be referenced by other TLOs (potentially multiple instances) and therefore having just a flag does not resolve the issue of association of the malware to TTPs, Intrusion Sets, Campaigns….etc. allan From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com> Date: Thursday, June 9, 2016 at 3:08 PM To: "Wunder, John" <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: [cti-stix] Re: Malware, Malicious Tool, and Tool Based on your list from your email I would go with #2 or #3... The reason for this, I spelled out in detail on the Slack channel. But it comes down to, the industry knows and understands what Malware is... If we produce a spec that does not have a container for Malware, it will be a big mistake. We will effectively need to re-train the entire internet on the fact that we are re-defining the way they use the term Malware. And I doubt that will have a positive outcome. Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org> Sent: Thursday, June 9, 2016 8:10 AM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] Malware, Malicious Tool, and Tool All, I took a shot at producing some material describing various approaches we could use to represent malware, malicious tools (or, malicious usage of tools), and tools. It’s a tough call with a bunch of tradeoffs, I don’t really see a “right” answer, but my preference is still Option 1. My reasoning: - IMO TLOs should be able to stand on their own…critical information should not be captured via relationships because people might not know them or might not want to share them. The fact that a particular TLO represents malicious usage of a tool seems very important to me. - I’m not sure that the fields used to represent data about malicious usage of tools is the same as the fields used to represent data about benign usage of tools (as a target, info source, or other use cases). So, having those as separate TLOs seems important to me. You care about different data for a tool depending on how it’s being used. To be honest I’m not 100% sold on “Weapon” as the TLO name (vs. Malicious Tool, Malicious Code, or something else) but I’m fairly comfortable with having one TLO for stuff used maliciously and a different TLO for stuff not used maliciously (defining that based on our use cases for it). John

I put this in the Slack channel, but I will put it here as well.  I have asked for feedback from our threat team and reverse engineers and others... And what I have heard back is: ## Begin a)        Keep malware. For God’s sake, no weapon or somesuch. b)        Malicious-tool is another name for things that have traditionally been called Hacktool, Tool, Application, Grayware, or even PUP c)         What is a “Tool”? In my mind, that’s any program? d)        Is Adware/PUP included in this?     Generally, I’d advocate keeping known terms and “standards”, such as they are. I remember back in the early 2000’s when some AV companies were pushing the word “vandals” for backdoor trojans. (shudder). ## End From: Jason Keirstead <Jason.Keirstead@ca.ibm.com> Sent: Friday, June 10, 2016 1:02 PM To: Allan Thomson Cc: Jordan, Bret; cti-stix@lists.oasis-open.org; Wunder, John A. Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool   It was mainly a reply to John's earlier email (quoted below to save looking it up). I am just saying, my gut says that analysts care very much about this distinction... but maybe I am wrong. -- Maybe I’m misunderstanding something. I thought there were two distinctions we wanted to make:   1.       Whether or not something is being used maliciously. Some things are always used maliciously, others not so much. 2.       Whether or not something is “malware”, by which I mean things that are installed without the user’s intent (Trojan, ransomware, etc.), and “tools”, by which I mean things like LOIC that are generally installed intentionally by the user to attack other people.   If we don’t need to make that latter distinction and can call all of those things malware I’m very happy to go with #2.   John - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Allan Thomson ---06/10/2016 03:18:37 PM---Hi Jason – Agree with the suggestion on getting analyst input regardless of this specific issue. Reg From: Allan Thomson <athomson@lookingglasscyber.com> To: Jason Keirstead/CanEast/IBM@IBMCA, "Wunder, John A." <jwunder@mitre.org> Cc: "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 06/10/2016 03:18 PM Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool Hi Jason – Agree with the suggestion on getting analyst input regardless of this specific issue. Regarding statement on VNC as malware. Was anyone suggesting that? I agree its not malware but can be used in the act of performing something malicious. Hence why it would be good to have a tool/software that can be associated with other aspects of the threat landscape including TTP, Campaign….etc. allan From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com> Date: Friday, June 10, 2016 at 8:06 AM To: "Wunder, John" <jwunder@mitre.org> Cc: "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool I would like some analysts to chime into this conversation as opposed to all of us product people. My gut says that an analyst is not going to want to classify NMAP or VNC as "malware". - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Wunder, John A." ---06/10/2016 09:13:26 AM---Still not sure I buy this but as long as we’re OK representing all types of malicious tools as malwa From: "Wunder, John A." <jwunder@mitre.org> To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 06/10/2016 09:13 AM Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool Sent by: <cti-stix@lists.oasis-open.org> Still not sure I buy this but as long as we’re OK representing all types of malicious tools as malware I’m OK with #2. From: "Jordan, Bret" <bret.jordan@bluecoat.com> Date: Friday, June 10, 2016 at 7:09 AM To: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool In your TI product you may have a tool documented, say NMAP. You may link against that tool in lots of ways.. And you may also want to link against it in a campaign and say that the tool, in this case, was used maliciously. Or think of a script for Windows PowerShell. It may be a tool that was built to clean up malware or something, but an attacker found a way of using that to attack something in your network. You will not want to create two instances of that Tool. You will want only one... And you will want to say how it was being used... Tool === Actual Thing.. Relationship === assertion on how Thing was used. I am completely against adding behavioral usage declarations on a Thing... For they are always subjective. Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org> Sent: Thursday, June 9, 2016 5:09 PM To: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool So the use case is this: you’ve seen usage of a tool (not malware) to attack people and have some indicators for how to detect it. You don’t know who’s doing it, how they’re targeting, or anything else. Basically you have some indicators for a tool that you know to be malicious and that’s it. How would you represent that in #2 without assuming that anything with an indicator pointing to it is bad (which is something I thought we didn’t want to do)? John From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com> Date: Thursday, June 9, 2016 at 7:01 PM To: "Wunder, John A." <jwunder@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool OK – then I don’t get the value of the Boolean flag provides that is not already captured by having 2 object classes (malware and tool) and the ability to define relationships between those objects and others. So #2 is still my preference. allan From: "Wunder, John" <jwunder@mitre.org> Date: Thursday, June 9, 2016 at 3:53 PM To: Allan Thomson <athomson@lookingglasscyber.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool Just to clarify, having the flag shouldn’t be a substitute for relationships to campaigns and other things. It’s just a way of indicating that the tool is malicious without having to have that relationship (given that many sharing organizations don’t share the higher level items, only indicators and malware/tools). So with the flag you could have a flag saying the tool is malicious and also a relationship saying it’s used by the campaign…it’s just that with the flag the tool stands on its own as the malicious usage of that tool. From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com> Date: Thursday, June 9, 2016 at 6:45 PM To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool Have a preference for #2 followed by #3. The reason for preference #2 is that malware will be referenced by other TLOs (potentially multiple instances) and therefore having just a flag does not resolve the issue of association of the malware to TTPs, Intrusion Sets, Campaigns….etc. allan From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com> Date: Thursday, June 9, 2016 at 3:08 PM To: "Wunder, John" <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: [cti-stix] Re: Malware, Malicious Tool, and Tool Based on your list from your email I would go with #2 or #3... The reason for this, I spelled out in detail on the Slack channel. But it comes down to, the industry knows and understands what Malware is... If we produce a spec that does not have a container for Malware, it will be a big mistake. We will effectively need to re-train the entire internet on the fact that we are re-defining the way they use the term Malware. And I doubt that will have a positive outcome. Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org> Sent: Thursday, June 9, 2016 8:10 AM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] Malware, Malicious Tool, and Tool All, I took a shot at producing some material describing various approaches we could use to represent malware, malicious tools (or, malicious usage of tools), and tools. It’s a tough call with a bunch of tradeoffs, I don’t really see a “right” answer, but my preference is still Option 1. My reasoning: - IMO TLOs should be able to stand on their own…critical information should not be captured via relationships because people might not know them or might not want to share them. The fact that a particular TLO represents malicious usage of a tool seems very important to me. - I’m not sure that the fields used to represent data about malicious usage of tools is the same as the fields used to represent data about benign usage of tools (as a target, info source, or other use cases). So, having those as separate TLOs seems important to me. You care about different data for a tool depending on how it’s being used. To be honest I’m not 100% sold on “Weapon” as the TLO name (vs. Malicious Tool, Malicious Code, or something else) but I’m fairly comfortable with having one TLO for stuff used maliciously and a different TLO for stuff not used maliciously (defining that based on our use cases for it). John