MAEC & Signature Management

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

MAEC & Signature Management

Kirillov, Ivan A.

One of the things we’re looking into adding to MAEC 2.0 is the ability to characterize and manage malware signatures, whether they be of the IDS or host-based (e.g. Yara, AV) variety. We’re also planning on developing a slice, or view, of MAEC that is intended to represent the common set of attributes typically exchanged as indicators of malware infection; more on this topic a bit later.

 

Adding this capability to MAEC will permit extra context to be built around signatures, thus allowing better understanding of their nature and enabling better use/re-use. This can be in terms of correlation with the MAEC Actions or Behaviors that the signature is related to. For instance, one could link an IDS signature to a specific bot C2 beaconing behavior, and capture this relationship in a single MAEC bundle. Accordingly, we’re thinking of adding an element to the ObjectType to allow for the specification of the signature(s) that triggered on or were used to detect particular objects associated with malware.

 

In terms of modeling signatures, it seems like there are two approaches we could take. One is to build a more general signature class that can encompass any IDS or other signature, but perhaps without the accompanying semantics that detail exactly what the signature represents. The other option would be to model different specific types of signatures, such as Snort, ClamAV, etc. Perhaps a third option would be to develop a detailed set of semantics for signatures, something which is done to some extent in the Common Intrusion Detection Signatures Standard (http://tools.ietf.org/html/draft-wierzbicki-cidss-04), although this standard does not seem to be widely utilized from what we can tell.

 

I think right now we’re shooting for the former (a more generalized signature type), at least as an initial pass. This would allow for the definition of the signature itself, a textual description of what the signature represents, the type of signature (e.g. byte pattern), and the syntax used (e.g. Snort). Are there any other attributes or requirements that we should be covering? Also, any thoughts on signature management and MAEC in general?

 

Regards,

 

Ivan Kirillov

MAEC Working Group
The
MITRE Corporation

 

Reply | Threaded
Open this post in threaded view
|

Plz remove my name from distro- RE: MAEC & Signature Management

Mark Harwood

Thanks very much.

Mark Harwood

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kirillov, Ivan A.
Sent: Friday, June 03, 2011 2:27 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: MAEC & Signature Management

 

One of the things we’re looking into adding to MAEC 2.0 is the ability to characterize and manage malware signatures, whether they be of the IDS or host-based (e.g. Yara, AV) variety. We’re also planning on developing a slice, or view, of MAEC that is intended to represent the common set of attributes typically exchanged as indicators of malware infection; more on this topic a bit later.

 

Adding this capability to MAEC will permit extra context to be built around signatures, thus allowing better understanding of their nature and enabling better use/re-use. This can be in terms of correlation with the MAEC Actions or Behaviors that the signature is related to. For instance, one could link an IDS signature to a specific bot C2 beaconing behavior, and capture this relationship in a single MAEC bundle. Accordingly, we’re thinking of adding an element to the ObjectType to allow for the specification of the signature(s) that triggered on or were used to detect particular objects associated with malware.

 

In terms of modeling signatures, it seems like there are two approaches we could take. One is to build a more general signature class that can encompass any IDS or other signature, but perhaps without the accompanying semantics that detail exactly what the signature represents. The other option would be to model different specific types of signatures, such as Snort, ClamAV, etc. Perhaps a third option would be to develop a detailed set of semantics for signatures, something which is done to some extent in the Common Intrusion Detection Signatures Standard (http://tools.ietf.org/html/draft-wierzbicki-cidss-04), although this standard does not seem to be widely utilized from what we can tell.

 

I think right now we’re shooting for the former (a more generalized signature type), at least as an initial pass. This would allow for the definition of the signature itself, a textual description of what the signature represents, the type of signature (e.g. byte pattern), and the syntax used (e.g. Snort). Are there any other attributes or requirements that we should be covering? Also, any thoughts on signature management and MAEC in general?

 

Regards,

 

Ivan Kirillov

MAEC Working Group
The
MITRE Corporation

 

Reply | Threaded
Open this post in threaded view
|

Re: MAEC & Signature Management

jose nazario
In reply to this post by Kirillov, Ivan A.
<base href="x-msg://303/">
the IEEE ICSG method uses what they call a classification object. it's flexible enough to enable CVE IDs, tags and strings like we use internally, and traditional AV sigs. you can record, much like you get in say VTotal, product versions, DAT versions, detection timestamps, etc ... or if you're a vendor you can specify when you shipped detection.

a useful approach, i have found, and flexible. 

<xs:complexType name="classificationObject">
<xs:sequence>
<xs:element name="classificationName" type="xs:string"/>
<xs:element name="companyName" type="xs:string"/>
<xs:element minOccurs="0" name="category" type="xs:string">
</xs:element>
<xs:element minOccurs="0" name="classificationDetails">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="definitionVersion" type="xs:string"/>
<xs:element minOccurs="0" name="detectionAddedTimeStamp" type="xs:dateTime"/>
<xs:element minOccurs="0" name="detectionShippedTimeStamp" type="xs:dateTime"/>
<xs:element minOccurs="0" name="product" type="xs:string"/>
<xs:element minOccurs="0" name="productVersion" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="type" type="ClassificationTypeEnum" use="required"/>
</xs:complexType>


On Jun 3, 2011, at 2:26 PM, Kirillov, Ivan A. wrote:

One of the things we’re looking into adding to MAEC 2.0 is the ability to characterize and manage malware signatures, whether they be of the IDS or host-based (e.g. Yara, AV) variety. We’re also planning on developing a slice, or view, of MAEC that is intended to represent the common set of attributes typically exchanged as indicators of malware infection; more on this topic a bit later.
 
Adding this capability to MAEC will permit extra context to be built around signatures, thus allowing better understanding of their nature and enabling better use/re-use. This can be in terms of correlation with the MAEC Actions or Behaviors that the signature is related to. For instance, one could link an IDS signature to a specific bot C2 beaconing behavior, and capture this relationship in a single MAEC bundle. Accordingly, we’re thinking of adding an element to the ObjectType to allow for the specification of the signature(s) that triggered on or were used to detect particular objects associated with malware.
 
In terms of modeling signatures, it seems like there are two approaches we could take. One is to build a more general signature class that can encompass any IDS or other signature, but perhaps without the accompanying semantics that detail exactly what the signature represents. The other option would be to model different specific types of signatures, such as Snort, ClamAV, etc. Perhaps a third option would be to develop a detailed set of semantics for signatures, something which is done to some extent in the Common Intrusion Detection Signatures Standard (http://tools.ietf.org/html/draft-wierzbicki-cidss-04), although this standard does not seem to be widely utilized from what we can tell.
 
I think right now we’re shooting for the former (a more generalized signature type), at least as an initial pass. This would allow for the definition of the signature itself, a textual description of what the signature represents, the type of signature (e.g. byte pattern), and the syntax used (e.g. Snort). Are there any other attributes or requirements that we should be covering? Also, any thoughts on signature management and MAEC in general?
 
Regards,
 
Ivan Kirillov

MAEC Working Group
The 
MITRE Corporation

 

_____________________________
jose nazario, ph.d. [hidden email]
sr. manager of security research, arbor networks

Reply | Threaded
Open this post in threaded view
|

RE: MAEC & Signature Management

Kirillov, Ivan A.
<base href="x-msg://303/">

Yes, the classificationObject from the IEEE ICSG v1.1 schema is useful for referring to attributes associated with malware detection performed by traditional AV systems. We actually import it and employ it in MAEC for this very purpose J

 

However, in this context we’re referring more to custom signatures that may be deployed in an enterprise, such as those of the Yara variety (http://code.google.com/p/yara-project/). As far as I know, there aren’t any standard mechanisms for sharing or capturing signatures such as these.

 

Regards,

 

Ivan Kirillov

MAEC Working Group
The
MITRE Corporation

 

From: Jose Nazario [mailto:[hidden email]]
Sent: Friday, June 03, 2011 2:39 PM
To: Kirillov, Ivan A.
Cc: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: MAEC & Signature Management

 

the IEEE ICSG method uses what they call a classification object. it's flexible enough to enable CVE IDs, tags and strings like we use internally, and traditional AV sigs. you can record, much like you get in say VTotal, product versions, DAT versions, detection timestamps, etc ... or if you're a vendor you can specify when you shipped detection.

 

a useful approach, i have found, and flexible. 

 

<xs:complexType name="classificationObject">

  <xs:sequence>

    <xs:element name="classificationName" type="xs:string"/>

    <xs:element name="companyName" type="xs:string"/>

    <xs:element minOccurs="0" name="category" type="xs:string">
    </xs:element>

    <xs:element minOccurs="0" name="classificationDetails">

      <xs:complexType>

        <xs:sequence>

          <xs:element minOccurs="0" name="definitionVersion" type="xs:string"/>

          <xs:element minOccurs="0" name="detectionAddedTimeStamp" type="xs:dateTime"/>

          <xs:element minOccurs="0" name="detectionShippedTimeStamp" type="xs:dateTime"/>

          <xs:element minOccurs="0" name="product" type="xs:string"/>

          <xs:element minOccurs="0" name="productVersion" type="xs:string"/>

        </xs:sequence>

      </xs:complexType>

    </xs:element>

  </xs:sequence>

  <xs:attribute name="id" type="xs:string" use="required"/>

  <xs:attribute name="type" type="ClassificationTypeEnum" use="required"/>

</xs:complexType>

 

 

On Jun 3, 2011, at 2:26 PM, Kirillov, Ivan A. wrote:



One of the things we’re looking into adding to MAEC 2.0 is the ability to characterize and manage malware signatures, whether they be of the IDS or host-based (e.g. Yara, AV) variety. We’re also planning on developing a slice, or view, of MAEC that is intended to represent the common set of attributes typically exchanged as indicators of malware infection; more on this topic a bit later.

 

Adding this capability to MAEC will permit extra context to be built around signatures, thus allowing better understanding of their nature and enabling better use/re-use. This can be in terms of correlation with the MAEC Actions or Behaviors that the signature is related to. For instance, one could link an IDS signature to a specific bot C2 beaconing behavior, and capture this relationship in a single MAEC bundle. Accordingly, we’re thinking of adding an element to the ObjectType to allow for the specification of the signature(s) that triggered on or were used to detect particular objects associated with malware.

 

In terms of modeling signatures, it seems like there are two approaches we could take. One is to build a more general signature class that can encompass any IDS or other signature, but perhaps without the accompanying semantics that detail exactly what the signature represents. The other option would be to model different specific types of signatures, such as Snort, ClamAV, etc. Perhaps a third option would be to develop a detailed set of semantics for signatures, something which is done to some extent in the Common Intrusion Detection Signatures Standard (http://tools.ietf.org/html/draft-wierzbicki-cidss-04), although this standard does not seem to be widely utilized from what we can tell.

 

I think right now we’re shooting for the former (a more generalized signature type), at least as an initial pass. This would allow for the definition of the signature itself, a textual description of what the signature represents, the type of signature (e.g. byte pattern), and the syntax used (e.g. Snort). Are there any other attributes or requirements that we should be covering? Also, any thoughts on signature management and MAEC in general?

 

Regards,

 

Ivan Kirillov

MAEC Working Group
The 
MITRE Corporation

 

 

_____________________________

jose nazario, ph.d. [hidden email]

sr. manager of security research, arbor networks

 

Reply | Threaded
Open this post in threaded view
|

Re: MAEC & Signature Management

jose nazario
<base href="x-msg://303/">
Ahh, ok ... could you import the <pattern /> element tree from CIDSS to accomplish this task?

On Jun 3, 2011, at 2:50 PM, Kirillov, Ivan A. wrote:

Yes, the classificationObject from the IEEE ICSG v1.1 schema is useful for referring to attributes associated with malware detection performed by traditional AV systems. We actually import it and employ it in MAEC for this very purpose J
 
However, in this context we’re referring more to custom signatures that may be deployed in an enterprise, such as those of the Yara variety (http://code.google.com/p/yara-project/). As far as I know, there aren’t any standard mechanisms for sharing or capturing signatures such as these.
 
Regards,
 
Ivan Kirillov

MAEC Working Group
The 
MITRE Corporation

 
From: Jose Nazario [mailto:[hidden email]] 
Sent: Friday, June 03, 2011 2:39 PM
To: Kirillov, Ivan A.
Cc: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: MAEC & Signature Management
 
the IEEE ICSG method uses what they call a classification object. it's flexible enough to enable CVE IDs, tags and strings like we use internally, and traditional AV sigs. you can record, much like you get in say VTotal, product versions, DAT versions, detection timestamps, etc ... or if you're a vendor you can specify when you shipped detection.
 
a useful approach, i have found, and flexible. 
 
<xs:complexType name="classificationObject">
  <xs:sequence>
    <xs:element name="classificationName"type="xs:string"/>
    <xs:element name="companyName" type="xs:string"/>
    <xs:element minOccurs="0" name="category"type="xs:string">
    </xs:element>
    <xs:element minOccurs="0"name="classificationDetails">
      <xs:complexType>
        <xs:sequence>
          <xs:element minOccurs="0"name="definitionVersion" type="xs:string"/>
          <xs:element minOccurs="0"name="detectionAddedTimeStamp" type="xs:dateTime"/>
          <xs:element minOccurs="0"name="detectionShippedTimeStamp" type="xs:dateTime"/>
          <xs:element minOccurs="0" name="product"type="xs:string"/>
          <xs:element minOccurs="0"name="productVersion" type="xs:string"/>
        </xs:sequence>
      </xs:complexType>
    </xs:element>
  </xs:sequence>
  <xs:attribute name="id" type="xs:string"use="required"/>
  <xs:attribute name="type"type="ClassificationTypeEnum" use="required"/>
</xs:complexType>
 
 
On Jun 3, 2011, at 2:26 PM, Kirillov, Ivan A. wrote:


One of the things we’re looking into adding to MAEC 2.0 is the ability to characterize and manage malware signatures, whether they be of the IDS or host-based (e.g. Yara, AV) variety. We’re also planning on developing a slice, or view, of MAEC that is intended to represent the common set of attributes typically exchanged as indicators of malware infection; more on this topic a bit later.
 
Adding this capability to MAEC will permit extra context to be built around signatures, thus allowing better understanding of their nature and enabling better use/re-use. This can be in terms of correlation with the MAEC Actions or Behaviors that the signature is related to. For instance, one could link an IDS signature to a specific bot C2 beaconing behavior, and capture this relationship in a single MAEC bundle. Accordingly, we’re thinking of adding an element to the ObjectType to allow for the specification of the signature(s) that triggered on or were used to detect particular objects associated with malware.
 
In terms of modeling signatures, it seems like there are two approaches we could take. One is to build a more general signature class that can encompass any IDS or other signature, but perhaps without the accompanying semantics that detail exactly what the signature represents. The other option would be to model different specific types of signatures, such as Snort, ClamAV, etc. Perhaps a third option would be to develop a detailed set of semantics for signatures, something which is done to some extent in the Common Intrusion Detection Signatures Standard (http://tools.ietf.org/html/draft-wierzbicki-cidss-04), although this standard does not seem to be widely utilized from what we can tell.
 
I think right now we’re shooting for the former (a more generalized signature type), at least as an initial pass. This would allow for the definition of the signature itself, a textual description of what the signature represents, the type of signature (e.g. byte pattern), and the syntax used (e.g. Snort). Are there any other attributes or requirements that we should be covering? Also, any thoughts on signature management and MAEC in general?
 
Regards,
 
Ivan Kirillov

MAEC Working Group
The 
MITRE Corporation

 
 
_____________________________
jose nazario, ph.d. [hidden email]
sr. manager of security research, arbor networks
 

_____________________________
jose nazario, ph.d. [hidden email]
sr. manager of security research, arbor networks

Reply | Threaded
Open this post in threaded view
|

RE: MAEC & Signature Management

Kirillov, Ivan A.
<base href="x-msg://303/">

Good suggestion. I think this would be a good balance between capturing the detailed semantic information about the pattern, without requiring all of the associated metadata (protocol, session info, etc.) inherent to CIDSS. I’m not completely sure if the CIDSS <pattern/> element is applicable to more general (host-based/non-IDS) signatures as well, but it looks like it may be a good fit.

 

Regards,

 

Ivan Kirillov

MAEC Working Group
The
MITRE Corporation

From: Jose Nazario [mailto:[hidden email]]
Sent: Friday, June 03, 2011 2:53 PM
To: Kirillov, Ivan A.
Cc: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: MAEC & Signature Management

 

Ahh, ok ... could you import the <pattern /> element tree from CIDSS to accomplish this task?

 

On Jun 3, 2011, at 2:50 PM, Kirillov, Ivan A. wrote:



Yes, the classificationObject from the IEEE ICSG v1.1 schema is useful for referring to attributes associated with malware detection performed by traditional AV systems. We actually import it and employ it in MAEC for this very purpose J

 

However, in this context we’re referring more to custom signatures that may be deployed in an enterprise, such as those of the Yara variety (http://code.google.com/p/yara-project/). As far as I know, there aren’t any standard mechanisms for sharing or capturing signatures such as these.

 

Regards,

 

Ivan Kirillov

MAEC Working Group
The 
MITRE Corporation

 

From: Jose Nazario [mailto:[hidden email]] 
Sent: Friday, June 03, 2011 2:39 PM
To: Kirillov, Ivan A.
Cc: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: MAEC & Signature Management

 

the IEEE ICSG method uses what they call a classification object. it's flexible enough to enable CVE IDs, tags and strings like we use internally, and traditional AV sigs. you can record, much like you get in say VTotal, product versions, DAT versions, detection timestamps, etc ... or if you're a vendor you can specify when you shipped detection.

 

a useful approach, i have found, and flexible. 

 

<xs:complexType name="classificationObject">

  <xs:sequence>

    <xs:element name="classificationName"type="xs:string"/>

    <xs:element name="companyName" type="xs:string"/>

    <xs:element minOccurs="0" name="category"type="xs:string">
    </xs:element>

    <xs:element minOccurs="0"name="classificationDetails">

      <xs:complexType>

        <xs:sequence>

          <xs:element minOccurs="0"name="definitionVersion" type="xs:string"/>

          <xs:element minOccurs="0"name="detectionAddedTimeStamp" type="xs:dateTime"/>

          <xs:element minOccurs="0"name="detectionShippedTimeStamp" type="xs:dateTime"/>

          <xs:element minOccurs="0" name="product"type="xs:string"/>

          <xs:element minOccurs="0"name="productVersion" type="xs:string"/>

        </xs:sequence>

      </xs:complexType>

    </xs:element>

  </xs:sequence>

  <xs:attribute name="id" type="xs:string"use="required"/>

  <xs:attribute name="type"type="ClassificationTypeEnum" use="required"/>

</xs:complexType>

 

 

On Jun 3, 2011, at 2:26 PM, Kirillov, Ivan A. wrote:




One of the things we’re looking into adding to MAEC 2.0 is the ability to characterize and manage malware signatures, whether they be of the IDS or host-based (e.g. Yara, AV) variety. We’re also planning on developing a slice, or view, of MAEC that is intended to represent the common set of attributes typically exchanged as indicators of malware infection; more on this topic a bit later.

 

Adding this capability to MAEC will permit extra context to be built around signatures, thus allowing better understanding of their nature and enabling better use/re-use. This can be in terms of correlation with the MAEC Actions or Behaviors that the signature is related to. For instance, one could link an IDS signature to a specific bot C2 beaconing behavior, and capture this relationship in a single MAEC bundle. Accordingly, we’re thinking of adding an element to the ObjectType to allow for the specification of the signature(s) that triggered on or were used to detect particular objects associated with malware.

 

In terms of modeling signatures, it seems like there are two approaches we could take. One is to build a more general signature class that can encompass any IDS or other signature, but perhaps without the accompanying semantics that detail exactly what the signature represents. The other option would be to model different specific types of signatures, such as Snort, ClamAV, etc. Perhaps a third option would be to develop a detailed set of semantics for signatures, something which is done to some extent in the Common Intrusion Detection Signatures Standard (http://tools.ietf.org/html/draft-wierzbicki-cidss-04), although this standard does not seem to be widely utilized from what we can tell.

 

I think right now we’re shooting for the former (a more generalized signature type), at least as an initial pass. This would allow for the definition of the signature itself, a textual description of what the signature represents, the type of signature (e.g. byte pattern), and the syntax used (e.g. Snort). Are there any other attributes or requirements that we should be covering? Also, any thoughts on signature management and MAEC in general?

 

Regards,

 

Ivan Kirillov

MAEC Working Group
The 
MITRE Corporation

 

 

_____________________________

jose nazario, ph.d. [hidden email]

sr. manager of security research, arbor networks

 

 

_____________________________

jose nazario, ph.d. [hidden email]

sr. manager of security research, arbor networks