[MAEC] March 29 Working Call Agenda

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

[MAEC] March 29 Working Call Agenda

Kirillov, Ivan A.

All,

 

For tomorrow’s working call, I’d like to discuss the remaining open items in the MAEC 5.0 specification:

 

·         API call parameter values – should we capture the constant names (e.g., GENERIC_WRITE) or actual byte values?

o    https://docs.google.com/document/d/1cnjjZAPHITFjo_8xGVBo1mX9Qvo7pN-YJ4pRZwdsuL0/edit#heading=h.bgw48ww0jje1

·         Distance measures – are there additional properties we should be capturing, or should we add a catch-all property (dictionary)?

o    https://docs.google.com/document/d/1cnjjZAPHITFjo_8xGVBo1mX9Qvo7pN-YJ4pRZwdsuL0/edit#heading=h.e9yw7k904di4

·         Actions – should we capture a list of timestamps for when the (same) Action occurred, or should we limit the granularity of Actions to a singleton?

o    https://docs.google.com/document/d/1cnjjZAPHITFjo_8xGVBo1mX9Qvo7pN-YJ4pRZwdsuL0/edit#heading=h.yn04yetlim3i

·         Malware Instances – should we specify any restrictions on the Objects or properties of Objects referenced in the instance_object_refs property?

o    https://docs.google.com/document/d/1cnjjZAPHITFjo_8xGVBo1mX9Qvo7pN-YJ4pRZwdsuL0/edit#heading=h.5ob769orcztq

·         Packages – should we have properties for classes of MAEC top-level entities (e.g., Actions, Behaviors, etc.) or just a single list that encompasses all MAEC entities (similar to the STIX Bundle)?

o    https://docs.google.com/document/d/1cnjjZAPHITFjo_8xGVBo1mX9Qvo7pN-YJ4pRZwdsuL0/edit#heading=h.efuhzu24o2t3

 

Regards,

Ivan

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

Re: [MAEC] March 29 Working Call Agenda

Kirillov, Ivan A.

Here are some notes on yesterday’s discussions of these topics. If anyone has any further thoughts, please let us know.

 

  • API call parameter values – should we capture the constant names (e.g., GENERIC_WRITE) or actual byte values?
    • The consensus was that we should support both (constant names and byte values) in the same property, but with a preference towards constant names if available. The logic was that constant names are easier to interpret and correlate against.
  • Distance measures – are there additional properties we should be capturing, or should we add a catch-all property (dictionary)?
    • The consensus was that while no other properties were readily identified, adding a catch-all “metadata” property (as done elsewhere in MAEC) is reasonable.
  • Actions – should we capture a list of timestamps for when the (same) Action occurred, or should we limit the granularity of Actions to a singleton?
    • The consensus was that Actions should be “atomic” for the sake of simplicity in creation and interpretation (including with relationships – what does it mean to relate two actions that happened multiple times?), and therefore we should rename the “timestamps” property to “timestamp” and accordingly make it a singleton. It was also brought up that sandboxes are more intelligent about how they filter their output, so the problem that “timestamps” was attempting to solve is less relevant.
  • Malware Instances – should we specify any restrictions on the Objects or properties of Objects referenced in the instance_object_refs property?
    • The consensus was that we shouldn’t specify any restrictions on Object properties, since there could be various use cases for including header fields and other properties as part of an instance_object. However, there was also consensus that the Cyber Observable File Object should be recommended as the “default” Object for representation of an instance object.
  • Packages – should we have properties for classes of MAEC top-level entities (e.g., Actions, Behaviors, etc.) or just a single list that encompasses all MAEC entities (similar to the STIX Bundle)?
    • The consensus was that we should go with the single-list approach, both for being more compatible with the approach taken in STIX but also being more future-proof, since we won’t have to add a new field to the Package for capturing any future top-level MAEC entities that we may add.

 

Regards,

Ivan

 

From: Ivan Kirillov <[hidden email]>
Reply-To: Ivan Kirillov <[hidden email]>
Date: Tuesday, March 28, 2017 at 8:07 AM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: [MAEC] March 29 Working Call Agenda

 

All,

 

For tomorrow’s working call, I’d like to discuss the remaining open items in the MAEC 5.0 specification:

 

·         API call parameter values – should we capture the constant names (e.g., GENERIC_WRITE) or actual byte values?

o   https://docs.google.com/document/d/1cnjjZAPHITFjo_8xGVBo1mX9Qvo7pN-YJ4pRZwdsuL0/edit#heading=h.bgw48ww0jje1

·         Distance measures – are there additional properties we should be capturing, or should we add a catch-all property (dictionary)?

o   https://docs.google.com/document/d/1cnjjZAPHITFjo_8xGVBo1mX9Qvo7pN-YJ4pRZwdsuL0/edit#heading=h.e9yw7k904di4

·         Actions – should we capture a list of timestamps for when the (same) Action occurred, or should we limit the granularity of Actions to a singleton?

o   https://docs.google.com/document/d/1cnjjZAPHITFjo_8xGVBo1mX9Qvo7pN-YJ4pRZwdsuL0/edit#heading=h.yn04yetlim3i

·         Malware Instances – should we specify any restrictions on the Objects or properties of Objects referenced in the instance_object_refs property?

o   https://docs.google.com/document/d/1cnjjZAPHITFjo_8xGVBo1mX9Qvo7pN-YJ4pRZwdsuL0/edit#heading=h.5ob769orcztq

·         Packages – should we have properties for classes of MAEC top-level entities (e.g., Actions, Behaviors, etc.) or just a single list that encompasses all MAEC entities (similar to the STIX Bundle)?

o   https://docs.google.com/document/d/1cnjjZAPHITFjo_8xGVBo1mX9Qvo7pN-YJ4pRZwdsuL0/edit#heading=h.efuhzu24o2t3

 

Regards,

Ivan

Loading...