[MAEC] Proposal: Allow AV Classifications to be captured for any CybOX Object

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[MAEC] Proposal: Allow AV Classifications to be captured for any CybOX Object

Paul Patrick
Proposal: Allow AV Classifications to be captured for any CybOX Object

After reading this proposal, I wanted to suggest that we should perhaps consider replacing Classification_Name (which is a xs:string) with the new MalwareNameType.

Requested Feedback

1.      Is it important to capture AV classifications of CybOX Objects (and not just malware instances)?

      [Paul] Yes, as it would then make it possible to apply it directly objects that may or may not be malware instances but were part of an overall analysis performed.  This also allows for support for non-file based targets.  For example,  Wepawet could be considered AV for web-based, jsunpack for Javascript. 

2.      Would it be preferable to define AV Classifications as top level objects in a MAEC Package?

      [Paul] Beyond the convenience of minimizing nesting, I don’t know if there are significant advantages to making it a top level object given the relationship between the AV classification and the associated object.  But clearly if made top level objects, we’d need them to be able to reference by id.

3.      Is there any issue with AVClassificationType duplicating the Name and Vendor fields in the cyboxCommon:ToolInformationType?

      [Paul] I don’t think there would be any concern, but I wonder if we might consider defining the AV classification as a derived type from cyboxCommon:ToolInformationType.  The cyboxCommon:ConfigurationSettingType could be used to support engine version, definition version, and other aspects about the AV tool.

4.      Is the scan_date field sufficient for capturing changes in scans over time?

      [Paul] I think would be sufficient

5.      Would it work well for an Analysis to reference an AV classification by its id field?

      [Paul] The ability to reference an AV classification by ID would allow a common one to be shared by multiple entities but I don’t think it’s critical.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [MAEC] Proposal: Allow AV Classifications to be captured for any CybOX Object

Kirillov, Ivan A.
Thanks for the feedback, Paul. Replies inline below.

Regards,
Ivan

From: Paul Patrick
Reply-To: Paul Patrick
Date: Monday, August 31, 2015 at 2:16 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: [MAEC] Proposal: Allow AV Classifications to be captured for any CybOX Object

Proposal: Allow AV Classifications to be captured for any CybOX Object

After reading this proposal, I wanted to suggest that weshould perhaps consider replacing Classification_Name (which is a xs:string) with the new MalwareNameType.

[Ivan] That would make sense – my only issue in doing so is that AV classification results, as reported by AV tools, are often rather arbitrary (e.g., “Trojan.Generic”) so it may be difficult to accurately break them up and/or use them in the Malware_Instance_Name/Malware_Family_Name fields. My inclination is that Classification_Name should hold the raw AV classification output, which can then be extracted into the Malware_Name or Malware_Aliases field on the Malware Subject.

Requested Feedback

1.     Is it important to capture AV classifications of CybOX Objects (and not just malware instances)?

      [Paul] Yes, as it would then make it possible to apply it directly objects that may or may not be malware instances but were part of an overall analysis performed. This also allows for support for non-file based targets. For example,  Wepawet could be considered AV for web-based,jsunpack for Javascript.

[Ivan] Good point! This is definitely another reason to allow for the capture of more arbitrary classifications on CybOX Objects.

2.     Would it be preferable to define AV Classifications as top level objects in a MAEC Package?

      [Paul] Beyondtheconvenience of minimizing nesting, I don’t know if there are significant advantages to making it a top level object given the relationship between the AV classification and the associated object. But clearly if made top level objects, we’d need them to be able toreference by id.

3.     Is there any issue withAVClassificationType duplicating the Name and Vendor fields in thecyboxCommon:ToolInformationType?

      [Paul]I don’t think there would be any concern, but I wonder if we might consider defining the AV classification as a derived type from cyboxCommon:ToolInformationType.  The cyboxCommon:ConfigurationSettingType could be used to supportengine version, definition version, and other aspects about the AV tool.

[Ivan] Actually, AVClassificationType is indeed derived from ToolInformationType in this proposal :) We had just forgotten to remove this question, which applied to a previous version of the proposal where this derivation was not present. As far as cyboxCommon:ConfigurationSettingType, my issue with its use is that it really just functions as a set of key/value pairs, so we wouldn’t be able to have the explicit fields for engine version/definition version/etc. and would instead have to recommend a set of “default” keys for this purpose.

4.     Is the scan_date field sufficient for capturing changes in scans over time?

      [Paul] I think would be sufficient

5.     Would it work well for an Analysis to reference an AV classification by its id field?

      [Paul]The ability to reference an AV classification by ID would allow a common one to be shared by multiple entities but I don’t thinkit’s critical.

[Ivan] That would certainly be a valid use case for the referencing of AV Classifications (they would already have an ID from the extension of the ToolInformationType) but I think the more typical usage would be Analysis -> AV Classification, to specify that the AV Classification was one of the findings of the Analysis.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [MAEC] Proposal: Allow AV Classifications to be captured for any CybOX Object

Paul Patrick
Proposal: Allow AV Classifications to be captured for any CybOX Object

 

 

From: Kirillov, Ivan A. [mailto:[hidden email]]
Sent: Tuesday, September 01, 2015 6:36 AM
To: Paul B. Patrick <[hidden email]>; maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] Proposal: Allow AV Classifications to be captured for any CybOX Object

 

Thanks for the feedback, Paul. Replies inline below.

 

Regards,

Ivan

 

From: Paul Patrick
Reply-To: Paul Patrick
Date: Monday, August 31, 2015 at 2:16 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: [MAEC] Proposal: Allow AV Classifications to be captured for any CybOX Object

 

After reading this proposal, I wanted to suggest that weshould perhaps consider replacing Classification_Name (which is a xs:string) with the new MalwareNameType.

[Ivan] That would make sense – my only issue in doing so is that AV classification results, as reported by AV tools, are often rather arbitrary (e.g., “Trojan.Generic”) so it may be difficult to accurately break them up and/or use them in the Malware_Instance_Name/Malware_Family_Name fields. My inclination is that Classification_Name should hold the raw AV classification output, which can then be extracted into the Malware_Name or Malware_Aliases field on the Malware Subject.

 

[Paul] Agree

Requested Feedback

1.     Is it important to capture AV classifications of CybOX Objects (and not just malware instances)?

[Paul] Yes, as it would then make it possible to apply it directly objects that may or may not be malware instances but were part of an overall analysis performed. This also allows for support for non-file based targets. For example,  Wepawet could be considered AV for web-based,jsunpack for Javascript.

[Ivan] Good point! This is definitely another reason to allow for the capture of more arbitrary classifications on CybOX Objects.

2.     Would it be preferable to define AV Classifications as top level objects in a MAEC Package?

[Paul] Beyondtheconvenience of minimizing nesting, I don’t know if there are significant advantages to making it a top level object given the relationship between the AV classification and the associated object. But clearly if made top level objects, we’d need them to be able toreference by id.

3.     Is there any issue withAVClassificationType duplicating the Name and Vendor fields in thecyboxCommon:ToolInformationType?

[Paul]I don’t think there would be any concern, but I wonder if we might consider defining the AV classification as a derived type from cyboxCommon:ToolInformationType.  The cyboxCommon:ConfigurationSettingType could be used to supportengine version, definition version, and other aspects about the AV tool.

[Ivan] Actually, AVClassificationType is indeed derived from ToolInformationType in this proposal :) We had just forgotten to remove this question, which applied to a previous version of the proposal where this derivation was not present. As far as cyboxCommon:ConfigurationSettingType, my issue with its use is that it really just functions as a set of key/value pairs, so we wouldn’t be able to have the explicit fields for engine version/definition version/etc. and would instead have to recommend a set of “default” keys for this purpose.

 

[Paul] Can’t believe I missed that it already is derived.  Agree with your points on why not to use ConfigurationSettingType.

4.     Is the scan_date field sufficient for capturing changes in scans over time?

[Paul] I think would be sufficient

5.     Would it work well for an Analysis to reference an AV classification by its id field?

[Paul]The ability to reference an AV classification by ID would allow a common one to be shared by multiple entities but I don’t thinkit’s critical.

[Ivan] That would certainly be a valid use case for the referencing of AV Classifications (they would already have an ID from the extension of the ToolInformationType) but I think the more typical usage would be Analysis -> AV Classification, to specify that the AV Classification was one of the findings of the Analysis.

 

[Paul] Agree as that was the typical use case I envisioned as well.

 

Loading...