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: STIX 2.1 Malware


PE Info
Hashes
Section Hashes
IMP Hashes
AV Hits
Dropped files
Packers used
Unique Strings
Bunch of other stuff
And everything listed here:
https://github.com/Defense-Cyber-Crime-Center/DC3-MWCP/blob/master/mwcp/resources/fields.json


-----Original Message-----
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Bret Jordan (CS)
Sent: Wednesday, September 21, 2016 4:30 PM
To: Katz, Gary CTR DC3\DCCI; cti-stix@lists.oasis-open.org
Subject: [Non-DoD Source] [cti-stix] Re: STIX 2.1 Malware

But we would like to be able to tell you everything we know about a piece of Malware, wether that comes from our sandboxing solutions, our internal automated tools, our manual analysis, etc.  We would like to be able send that out in STIX.  


I could see having a property on the STIX Malware object that was called "detailed_analysis" or just "analysis" and have its type be a STIX malware analysis type that had all of the extra "stuff" in it.  I am currently just calling this "analysis" in the 2.1 Concepts document. 


This functionality is just so vitally important.  Being able to discuss malware in a structured way, discuss the C2 servers it is talking to (Infrastructure) and the data-exfiltration servers it is talking to (Infrastructure) and the methods it is using for data exfiltration in a structured way is vital.  


What would be some of the fields and properties we would need to capture in an analysis section?  


Bret
________________________________

From: Katz, Gary CTR DC3\DCCI <Gary.Katz.ctr@dc3.mil>
Sent: Wednesday, September 21, 2016 2:18:56 PM
To: Bret Jordan (CS); cti-stix@lists.oasis-open.org
Subject: RE: STIX 2.1 Malware 
 
Bret,
 
   One way that we might be able to break this out is that STIX is used for capturing artifacts about the malware that are relevant for network defense and cyber analytics while MAEC is more fine-grained and used for capturing how the malware analysis was performed.
 
Thoughts?
   -Gary
 
 
 
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Bret Jordan (CS)
Sent: Wednesday, September 21, 2016 3:58 PM
To: cti-stix@lists.oasis-open.org
Subject: [Non-DoD Source] [cti-stix] STIX 2.1 Malware
 
As I have been working on the Malware object for STIX 2.1, it is becoming clear that it would be nice if the STIX Malware object had some basic analysis data and some more advanced malware analysis data in it.  This would make this object infinitely more valuable.  
 
I think there are two options for this.....
 
1) We just start doing all of this natively in STIX.  We start with basic malware meta data, similar to what I have and then just add more and more analysis stuff as we go along.  You can see what I have been working on here: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.s5l7katgbp09
 
2) We do some of the basic malware meta data in STIX natively, like what I have so far.  But the detailed analysis we look for some external language to provide that and then link to it or embedded it or something. When this has come up in the past, many have voiced concerns about using things like MAEC.  My concern is that using a third party language always comes at a significant cost and with significant complexity.  Things tend to revision on their own and you have to build a matrix of support which makes it hard on product owners. 
 
So since my initial desire to just use MAEC was shot down by the community, I would like to propose that we just start doing more and more malware analysis documentation and modeling natively in STIX.  What do you all think of this?
 
Bret
 


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