OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti-stix] Re: Malware, Malicious Tool, and Tool


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]