Great suggestions Jose. I've added IP and Application Layer protocol elements to the Network_Object_Attributes (we've since renamed the two different ones to Network_Object_Attributes and Network_Action_Attributes - hopefully this is a good bit less confusing now). Standardizing on the IANA names (
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml) also makes good sense.
Thanks for the schema link - I think it makes good sense for capturing honeyclient data. One question - can you explain the 'consequence' element under exploits? Is that akin to our effects in MAEC?
As far as exploits, I would say that the exploitation of a vulnerability is a behavior accomplished through some actions, so I concur that we already have the capability to characterize them to some degree. I think we could associate the CVE of the vulnerability exploited at the behavioral level, as an attribute of the behavior's effect.
Shellcode is interesting because although it is used in a singular fashion, it has its own unique attributes and can perform different types of actions. Perhaps it would make sense to create a new object class for it? In terms of its execution, I think that it could be represented in MAEC as a behavior that is dependent on a successful exploit behavior.
Funny that you mention wepawet - I was attempting to characterize some of their analyses using MAEC recently. Unfortunately, there's not too much there that's easily deconstructable into actions and behaviors, so I wasn't able to capture very much beyond the general analysis data.
I also agree that characterizing obfuscation is challenging, both for exploits/web-based malware and binaries. This is something that we plan on tackling at some point, but perhaps initially we should just have a binary indicator for the presence (or lack thereof) of obfuscation?
Regards,
Ivan
Ivan Kirillov
MAEC Working Group
The MITRE Corporation
-----Original Message-----
From:
[hidden email] [mailto:
[hidden email]] On Behalf Of jose nazario
Sent: Thursday, May 20, 2010 3:05 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: schema thoughts - IP network attributes and exploit artifacts
looking over the schema and thinking about my experiences with ICSG
and also with expressing malicious website behaviors in a schema. two
things come to mind.
the first is that the "Network_Attributes" elements (yes, there are
two different ones, similar but not the same ...) don't have anything
about the IP protocol nor the application protocol. i suggest adding
these sub-elements. i also suggest that they be standardizes on the
IANA names (for convenience and lack of ambiguity).
the second is expressing exploits and their effects. i think that
increasingly exploits are an artifact that should not be ignored in
this space, and with minimal effort it can be explicitly supported
(rather than shoehorning it in). in the malicious website world i've
been working on a honeyclient. here's the alert schema i've been
developing:
http://code.google.com/p/phoneyc/source/browse/phoneyc/trunk/doc/xml/
output/example.xsd
it's loosely based on the data captured by wepawet (i have never seen
an XML schema for wepawet):
http://wepawet.cs.ucsb.edu/view.php?
hash=41a0ef86e5b3f342ac336bab0ae9c432&t=1234806209&type=js
one of the foreign keys here is the CVE-ID of the vulnerability being
exploited. much of the rest of the material is already well supported
in MAEC, including API calls, arguments, and effects. expressing
obfuscation is a challenge and i don't see any good solutions there
that are clear, unambiguous, and accurate.
anyhow, just some ideas.
_____________________________
jose nazario, ph.d.
[hidden email]
sr. manager of security research, arbor networks
http://asert.arbor.net/
Locked
