MAEC Draft Specification Now Available

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

MAEC Draft Specification Now Available

Kirillov, Ivan A.
All,

We're happy to announce that the draft specification for the MAEC Language (v4.0.1) is now available:

http://maec.mitre.org/language/version4.0.1/MAEC_Language_Specification_11-15-2013.docx (Word)
http://maec.mitre.org/language/version4.0.1/MAEC_Language_Specification_11-15-2013.pdf (PDF)

While providing an in-depth look at the data model behind MAEC, this document also includes a discussion of some use cases where MAEC may be relevant, FAQs about MAEC and its usage, and other pertinent topics. Here's the top-level table of contents for those interested:

1 Introduction
        1.1 The MAEC Language
        1.2 Usage of Other Languages and Formats
        1.3 Document Conventions
        1.4 Document Overview
2 Overview of the MAEC Data Models
        2.1 Overview of the MAEC Bundle Data Model
        2.2 Overview of the MAEC Package Data Model
        2.3 Overview of the MAEC Container Data Model
3 High Level Use Cases for the MAEC Language
        3.1 Malware Analysis
        3.2 Cyber Threat Analysis
        3.3 Intrusion Detection
        3.4 Incident Management
4 Requirements for the MAEC Language
        4.1 Basic Requirements
        4.2 Detailed Requirements
5 Data Models for the MAEC Language
        5.1 Data Model Conventions
        5.2 MAEC Bundle Data Model
        5.3 MAEC Package Data Model
        5.4 MAEC Container Data Model
6 MAEC Default Vocabularies
7 XML Implementation
        7.1 Validation Requirements
Appendix A - MAEC Language Versioning Policy
Appendix B - MAEC Language Deprecation Policy
Appendix C - FAQs
Appendix D - Terminology
Appendix E - References

We welcome your feedback and any suggestions on how to improve this document, especially given its draft status. For those wishing to submit changes or questions directly, please feel free to edit the Word document version (.docx), which has track-changes enabled.

Regards,
Ivan Kirillov
MITRE
JA
Reply | Threaded
Open this post in threaded view
|

Re: MAEC Draft Specification Now Available

JA
BRAVO is my first feedback!

From a quick review, some notes:
Typo on page 35 "Defintion_Version" should be "Definition_Version"
(check the "B" of BehaviorPurposeType page 38)

and some more interesting:
CVE's cardinality (multiplicity) in VulnerabilityExploitType: should
maybe be 0..n

dateTime for timestamp, start_date: is it a timestamp with time zone?

method's multiplicity of AnalysisType: will it be always 0..1? (or
0..n possible)
same for Tools

a CPE could be interesting for HypervisorHostSystemType

is it possible to clarify Edge and Edge/Nodes?

using IANA for LayerXProtocolEnum?


Then, for some (non-exhaustive as clearly stated ;)) enumerations:
create, emulate in DeviceDriverActionNameEnum

hide in DirectoryActionNameEnum

emulate, list, monitor in DiskActionNameEnum

hide in FileActionNameEnum

shatter in GUIActionNameEnum
https://en.wikipedia.org/wiki/Shatter_attack

split in HTTPActionNameEnum

inject in LibraryActionNameEnum

Just my 2c
Best regards
/JA

2013/11/18 Kirillov, Ivan A. <[hidden email]>:

> All,
>
> We're happy to announce that the draft specification for the MAEC Language (v4.0.1) is now available:
>
> http://maec.mitre.org/language/version4.0.1/MAEC_Language_Specification_11-15-2013.docx (Word)
> http://maec.mitre.org/language/version4.0.1/MAEC_Language_Specification_11-15-2013.pdf (PDF)
>
> While providing an in-depth look at the data model behind MAEC, this document also includes a discussion of some use cases where MAEC may be relevant, FAQs about MAEC and its usage, and other pertinent topics. Here's the top-level table of contents for those interested:
>
> 1       Introduction
>         1.1     The MAEC Language
>         1.2     Usage of Other Languages and Formats
>         1.3     Document Conventions
>         1.4     Document Overview
> 2       Overview of the MAEC Data Models
>         2.1     Overview of the MAEC Bundle Data Model
>         2.2     Overview of the MAEC Package Data Model
>         2.3     Overview of the MAEC Container Data Model
> 3       High Level Use Cases for the MAEC Language
>         3.1     Malware Analysis
>         3.2     Cyber Threat Analysis
>         3.3     Intrusion Detection
>         3.4     Incident Management
> 4       Requirements for the MAEC Language
>         4.1     Basic Requirements
>         4.2     Detailed Requirements
> 5       Data Models for the MAEC Language
>         5.1     Data Model Conventions
>         5.2     MAEC Bundle Data Model
>         5.3     MAEC Package Data Model
>         5.4     MAEC Container Data Model
> 6       MAEC Default Vocabularies
> 7       XML Implementation
>         7.1     Validation Requirements
> Appendix A - MAEC Language Versioning Policy
> Appendix B - MAEC Language Deprecation Policy
> Appendix C - FAQs
> Appendix D - Terminology
> Appendix E - References
>
> We welcome your feedback and any suggestions on how to improve this document, especially given its draft status. For those wishing to submit changes or questions directly, please feel free to edit the Word document version (.docx), which has track-changes enabled.
>
> Regards,
> Ivan Kirillov
> MITRE
Reply | Threaded
Open this post in threaded view
|

RE: MAEC Draft Specification Now Available

Kirillov, Ivan A.
Jerome - thanks very much for the comments and feedback! We'll make note of the typo and will fix it in the next draft.  

As far as your other points:

>CVE's cardinality (multiplicity) in VulnerabilityExploitType: should
>maybe be 0..n

A VulnerabilityExploitType is intended to characterize a single vulnerability, so having the 0..1 CVE here (as it is now) makes sense, I think. However, I think it's possible for a Behavior to exploit more than one vulnerability, so we should consider changing the cardinality of the Vulnerability_Exploit in the Vulnerability_Exploit_Type to 0..N.

>dateTime for timestamp, start_date: is it a timestamp with time zone?

I'm assuming you meant the start_datetime in the AnalysisType? If so, then yes, it refers to a timestamp with a timezone, e.g. 2002-05-30T09:30:10+06:00, as it is based off the xs:dateTime type from the XML Schema specification.  

>method's multiplicity of AnalysisType: will it be always 0..1? (or
>0..n possible)
>same for Tools

Good question. I think we've restricted the @method to a fairly small, broad list of terms ("static", "dynamic", and "combinatorial"), which should serve to characterize the types of analysis methods used on malware; "combinatorial" is intended to be a catch-all method for referring to analyses that used static and dynamic techniques. Do you think this is adequate, or would you suggest a more granular list of terms for this attribute (in which case having the 0..n multiplicity would probably make good sense)?

As far as the Tools - not sure what you mean. The Tools field uses the ToolListType, which allows for the specification of 1..N tools used in the analysis.

>a CPE could be interesting for HypervisorHostSystemType

Agreed! However, the PlatformSpecificationType from CybOX Common (http://cybox.mitre.org/language/version2.0.1/xsddocs/cybox_common.html), which is used in this Type, allows you to specify a CPE or other platform identifier.

> is it possible to clarify Edge and Edge/Nodes?

Sure. "Node" refers to a single vertex (e.g. "A") in an undirected graph, and "edge" refers to a line between two vertices in the graph. Thus, an "Edge_Node_Pair" simply refers to two nodes connected by an edge (e.g. "A"->"B"). We realize that this is a fairly clumsy way of referring to graph structures, so we'll likely significantly refactor this for MAEC 5.0.

> using IANA for LayerXProtocolEnum?

Yup, I think using some of the IANA tables for this would make good sense. We've thought about doing so in the past, but need to figure out some logistical issues in doing so (e.g. how to incorporate the table in XML, etc.).

>Then, for some (non-exhaustive as clearly stated ;)) enumerations:
> ...

Great suggestions. I'll make sure we add these to their respective enumerations for the next release of MAEC, v4.1.

Regards,
Ivan

-----Original Message-----
From: Jerome Athias [mailto:[hidden email]]
Sent: Monday, November 18, 2013 2:35 PM
To: Kirillov, Ivan A.
Cc: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: MAEC Draft Specification Now Available

BRAVO is my first feedback!

From a quick review, some notes:
Typo on page 35 "Defintion_Version" should be "Definition_Version"
(check the "B" of BehaviorPurposeType page 38)

and some more interesting:
CVE's cardinality (multiplicity) in VulnerabilityExploitType: should
maybe be 0..n

dateTime for timestamp, start_date: is it a timestamp with time zone?

method's multiplicity of AnalysisType: will it be always 0..1? (or
0..n possible)
same for Tools

a CPE could be interesting for HypervisorHostSystemType

is it possible to clarify Edge and Edge/Nodes?

using IANA for LayerXProtocolEnum?


Then, for some (non-exhaustive as clearly stated ;)) enumerations:
create, emulate in DeviceDriverActionNameEnum

hide in DirectoryActionNameEnum

emulate, list, monitor in DiskActionNameEnum

hide in FileActionNameEnum

shatter in GUIActionNameEnum
https://en.wikipedia.org/wiki/Shatter_attack

split in HTTPActionNameEnum

inject in LibraryActionNameEnum

Just my 2c
Best regards
/JA

2013/11/18 Kirillov, Ivan A. <[hidden email]>:

> All,
>
> We're happy to announce that the draft specification for the MAEC Language (v4.0.1) is now available:
>
> http://maec.mitre.org/language/version4.0.1/MAEC_Language_Specification_11-15-2013.docx (Word)
> http://maec.mitre.org/language/version4.0.1/MAEC_Language_Specification_11-15-2013.pdf (PDF)
>
> While providing an in-depth look at the data model behind MAEC, this document also includes a discussion of some use cases where MAEC may be relevant, FAQs about MAEC and its usage, and other pertinent topics. Here's the top-level table of contents for those interested:
>
> 1       Introduction
>         1.1     The MAEC Language
>         1.2     Usage of Other Languages and Formats
>         1.3     Document Conventions
>         1.4     Document Overview
> 2       Overview of the MAEC Data Models
>         2.1     Overview of the MAEC Bundle Data Model
>         2.2     Overview of the MAEC Package Data Model
>         2.3     Overview of the MAEC Container Data Model
> 3       High Level Use Cases for the MAEC Language
>         3.1     Malware Analysis
>         3.2     Cyber Threat Analysis
>         3.3     Intrusion Detection
>         3.4     Incident Management
> 4       Requirements for the MAEC Language
>         4.1     Basic Requirements
>         4.2     Detailed Requirements
> 5       Data Models for the MAEC Language
>         5.1     Data Model Conventions
>         5.2     MAEC Bundle Data Model
>         5.3     MAEC Package Data Model
>         5.4     MAEC Container Data Model
> 6       MAEC Default Vocabularies
> 7       XML Implementation
>         7.1     Validation Requirements
> Appendix A - MAEC Language Versioning Policy
> Appendix B - MAEC Language Deprecation Policy
> Appendix C - FAQs
> Appendix D - Terminology
> Appendix E - References
>
> We welcome your feedback and any suggestions on how to improve this document, especially given its draft status. For those wishing to submit changes or questions directly, please feel free to edit the Word document version (.docx), which has track-changes enabled.
>
> Regards,
> Ivan Kirillov
> MITRE
JA
Reply | Threaded
Open this post in threaded view
|

Re: MAEC Draft Specification Now Available

JA
Excellent, thanks for your fast answer.
My feedbacks inline

2013/11/19 Kirillov, Ivan A. <[hidden email]>:

>>CVE's cardinality (multiplicity) in VulnerabilityExploitType: should
>>maybe be 0..n
>
> A VulnerabilityExploitType is intended to characterize a single vulnerability, so having the 0..1 CVE here (as it is now) makes sense, I think. However, I think it's possible for a Behavior to exploit more than one vulnerability, so we should consider changing the cardinality of the Vulnerability_Exploit in the Vulnerability_Exploit_Type to 0..N.
>

Fair enough, it makes sense

>>dateTime for timestamp, start_date: is it a timestamp with time zone?
>
> I'm assuming you meant the start_datetime in the AnalysisType? If so, then yes, it refers to a timestamp with a timezone, e.g. 2002-05-30T09:30:10+06:00, as it is based off the xs:dateTime type from the XML Schema specification.
>

Perfect, just wanted to double-check

>>method's multiplicity of AnalysisType: will it be always 0..1? (or
>>0..n possible)
>>same for Tools
>
> Good question. I think we've restricted the @method to a fairly small, broad list of terms ("static", "dynamic", and "combinatorial"), which should serve to characterize the types of analysis methods used on malware; "combinatorial" is intended to be a catch-all method for referring to analyses that used static and dynamic techniques. Do you think this is adequate, or would you suggest a more granular list of terms for this attribute (in which case having the 0..n multiplicity would probably make good sense)?
>

combinatorial makes sense

> As far as the Tools - not sure what you mean. The Tools field uses the ToolListType, which allows for the specification of 1..N tools used in the analysis.
>

no problem (I've read too fast ;))

>>a CPE could be interesting for HypervisorHostSystemType
>
> Agreed! However, the PlatformSpecificationType from CybOX Common (http://cybox.mitre.org/language/version2.0.1/xsddocs/cybox_common.html), which is used in this Type, allows you to specify a CPE or other platform identifier.
>

ok, seems good

>> is it possible to clarify Edge and Edge/Nodes?
>
> Sure. "Node" refers to a single vertex (e.g. "A") in an undirected graph, and "edge" refers to a line between two vertices in the graph. Thus, an "Edge_Node_Pair" simply refers to two nodes connected by an edge (e.g. "A"->"B"). We realize that this is a fairly clumsy way of referring to graph structures, so we'll likely significantly refactor this for MAEC 5.0.
>

ok, thanks (btw, any idea already about a (python) library for graphs? ;p)

>> using IANA for LayerXProtocolEnum?
>
> Yup, I think using some of the IANA tables for this would make good sense. We've thought about doing so in the past, but need to figure out some logistical issues in doing so (e.g. how to incorporate the table in XML, etc.).
>

ok, I did some stuff around this, will try to share asap

>>Then, for some (non-exhaustive as clearly stated ;)) enumerations:
>> ...
>
> Great suggestions. I'll make sure we add these to their respective enumerations for the next release of MAEC, v4.1.
>
> Regards,
> Ivan
>

Thanks for keeping this in mind.
I have also some ideas for IRC actions (like the commands used; xdcc...)
PS: also I think we can use (or submit update proposals for) part of
the CAPEC vocabularies (i.e.: Methods_of_Attack, Injection_Vector)

Thanks again!

Jerome


> -----Original Message-----
> From: Jerome Athias [mailto:[hidden email]]
> Sent: Monday, November 18, 2013 2:35 PM
> To: Kirillov, Ivan A.
> Cc: maec-discussion-list Malware Attribute Enumeration Discussion
> Subject: Re: MAEC Draft Specification Now Available
>
> BRAVO is my first feedback!
>
> From a quick review, some notes:
> Typo on page 35 "Defintion_Version" should be "Definition_Version"
> (check the "B" of BehaviorPurposeType page 38)
>
> and some more interesting:
> CVE's cardinality (multiplicity) in VulnerabilityExploitType: should
> maybe be 0..n
>
> dateTime for timestamp, start_date: is it a timestamp with time zone?
>
> method's multiplicity of AnalysisType: will it be always 0..1? (or
> 0..n possible)
> same for Tools
>
> a CPE could be interesting for HypervisorHostSystemType
>
> is it possible to clarify Edge and Edge/Nodes?
>
> using IANA for LayerXProtocolEnum?
>
>
> Then, for some (non-exhaustive as clearly stated ;)) enumerations:
> create, emulate in DeviceDriverActionNameEnum
>
> hide in DirectoryActionNameEnum
>
> emulate, list, monitor in DiskActionNameEnum
>
> hide in FileActionNameEnum
>
> shatter in GUIActionNameEnum
> https://en.wikipedia.org/wiki/Shatter_attack
>
> split in HTTPActionNameEnum
>
> inject in LibraryActionNameEnum
>
> Just my 2c
> Best regards
> /JA
>
> 2013/11/18 Kirillov, Ivan A. <[hidden email]>:
>> All,
>>
>> We're happy to announce that the draft specification for the MAEC Language (v4.0.1) is now available:
>>
>> http://maec.mitre.org/language/version4.0.1/MAEC_Language_Specification_11-15-2013.docx (Word)
>> http://maec.mitre.org/language/version4.0.1/MAEC_Language_Specification_11-15-2013.pdf (PDF)
>>
>> While providing an in-depth look at the data model behind MAEC, this document also includes a discussion of some use cases where MAEC may be relevant, FAQs about MAEC and its usage, and other pertinent topics. Here's the top-level table of contents for those interested:
>>
>> 1       Introduction
>>         1.1     The MAEC Language
>>         1.2     Usage of Other Languages and Formats
>>         1.3     Document Conventions
>>         1.4     Document Overview
>> 2       Overview of the MAEC Data Models
>>         2.1     Overview of the MAEC Bundle Data Model
>>         2.2     Overview of the MAEC Package Data Model
>>         2.3     Overview of the MAEC Container Data Model
>> 3       High Level Use Cases for the MAEC Language
>>         3.1     Malware Analysis
>>         3.2     Cyber Threat Analysis
>>         3.3     Intrusion Detection
>>         3.4     Incident Management
>> 4       Requirements for the MAEC Language
>>         4.1     Basic Requirements
>>         4.2     Detailed Requirements
>> 5       Data Models for the MAEC Language
>>         5.1     Data Model Conventions
>>         5.2     MAEC Bundle Data Model
>>         5.3     MAEC Package Data Model
>>         5.4     MAEC Container Data Model
>> 6       MAEC Default Vocabularies
>> 7       XML Implementation
>>         7.1     Validation Requirements
>> Appendix A - MAEC Language Versioning Policy
>> Appendix B - MAEC Language Deprecation Policy
>> Appendix C - FAQs
>> Appendix D - Terminology
>> Appendix E - References
>>
>> We welcome your feedback and any suggestions on how to improve this document, especially given its draft status. For those wishing to submit changes or questions directly, please feel free to edit the Word document version (.docx), which has track-changes enabled.
>>
>> Regards,
>> Ivan Kirillov
>> MITRE
Reply | Threaded
Open this post in threaded view
|

Re: MAEC Draft Specification Now Available

Terry MacDonald
In reply to this post by Kirillov, Ivan A.
Wow! I just have to say that's pretty amazing work. Well done to all who contributed.

I finally had some time to read this ginormous doc, and I do have one question thats popped out...

'5.2.4.2 ProcessTreeNodeType' - Is the order that the spawned processes and injected processes were created by the malware reflected in the same order in the Process Tree? If so I couldnt find this specifically mentioned in the document. Does ProcessTreeNodeType need an ordinal_position field to represent order? 

Great work.

Cheers

Terry MacDonald



Terry MacDonald


On 19 November 2013 02:46, Kirillov, Ivan A. <[hidden email]> wrote:
All,

We're happy to announce that the draft specification for the MAEC Language (v4.0.1) is now available:

http://maec.mitre.org/language/version4.0.1/MAEC_Language_Specification_11-15-2013.docx (Word)
http://maec.mitre.org/language/version4.0.1/MAEC_Language_Specification_11-15-2013.pdf (PDF)

While providing an in-depth look at the data model behind MAEC, this document also includes a discussion of some use cases where MAEC may be relevant, FAQs about MAEC and its usage, and other pertinent topics. Here's the top-level table of contents for those interested:

1       Introduction
        1.1     The MAEC Language
        1.2     Usage of Other Languages and Formats
        1.3     Document Conventions
        1.4     Document Overview
2       Overview of the MAEC Data Models
        2.1     Overview of the MAEC Bundle Data Model
        2.2     Overview of the MAEC Package Data Model
        2.3     Overview of the MAEC Container Data Model
3       High Level Use Cases for the MAEC Language
        3.1     Malware Analysis
        3.2     Cyber Threat Analysis
        3.3     Intrusion Detection
        3.4     Incident Management
4       Requirements for the MAEC Language
        4.1     Basic Requirements
        4.2     Detailed Requirements
5       Data Models for the MAEC Language
        5.1     Data Model Conventions
        5.2     MAEC Bundle Data Model
        5.3     MAEC Package Data Model
        5.4     MAEC Container Data Model
6       MAEC Default Vocabularies
7       XML Implementation
        7.1     Validation Requirements
Appendix A - MAEC Language Versioning Policy
Appendix B - MAEC Language Deprecation Policy
Appendix C - FAQs
Appendix D - Terminology
Appendix E - References

We welcome your feedback and any suggestions on how to improve this document, especially given its draft status. For those wishing to submit changes or questions directly, please feel free to edit the Word document version (.docx), which has track-changes enabled.

Regards,
Ivan Kirillov
MITRE

Reply | Threaded
Open this post in threaded view
|

RE: MAEC Draft Specification Now Available

Kirillov, Ivan A.

Thanks for the kind words Terry!

 

As far as your question – the order that the processes are spawned and created should be the same order that is captured in the Process Tree. However, it will probably be useful and consistent to make this explicit by adding an ordinal_position field, as we’ve done in other places. I’ll make sure we add this for MAEC v4.1.

 

Regards,

Ivan Kirillov

MITRE

 

From: Terry MacDonald [mailto:[hidden email]]
Sent: Thursday, November 21, 2013 5:13 AM
To: Kirillov, Ivan A.
Cc: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: MAEC Draft Specification Now Available

 

Wow! I just have to say that's pretty amazing work. Well done to all who contributed.

 

I finally had some time to read this ginormous doc, and I do have one question thats popped out...

 

'5.2.4.2 ProcessTreeNodeType' - Is the order that the spawned processes and injected processes were created by the malware reflected in the same order in the Process Tree? If so I couldnt find this specifically mentioned in the document. Does ProcessTreeNodeType need an ordinal_position field to represent order? 

 

Great work.

 

Cheers

 

Terry MacDonald

 

 


Terry MacDonald

 

On 19 November 2013 02:46, Kirillov, Ivan A. <[hidden email]> wrote:

All,

We're happy to announce that the draft specification for the MAEC Language (v4.0.1) is now available:

http://maec.mitre.org/language/version4.0.1/MAEC_Language_Specification_11-15-2013.docx (Word)
http://maec.mitre.org/language/version4.0.1/MAEC_Language_Specification_11-15-2013.pdf (PDF)

While providing an in-depth look at the data model behind MAEC, this document also includes a discussion of some use cases where MAEC may be relevant, FAQs about MAEC and its usage, and other pertinent topics. Here's the top-level table of contents for those interested:

1       Introduction
        1.1     The MAEC Language
        1.2     Usage of Other Languages and Formats
        1.3     Document Conventions
        1.4     Document Overview
2       Overview of the MAEC Data Models
        2.1     Overview of the MAEC Bundle Data Model
        2.2     Overview of the MAEC Package Data Model
        2.3     Overview of the MAEC Container Data Model
3       High Level Use Cases for the MAEC Language
        3.1     Malware Analysis
        3.2     Cyber Threat Analysis
        3.3     Intrusion Detection
        3.4     Incident Management
4       Requirements for the MAEC Language
        4.1     Basic Requirements
        4.2     Detailed Requirements
5       Data Models for the MAEC Language
        5.1     Data Model Conventions
        5.2     MAEC Bundle Data Model
        5.3     MAEC Package Data Model
        5.4     MAEC Container Data Model
6       MAEC Default Vocabularies
7       XML Implementation
        7.1     Validation Requirements
Appendix A - MAEC Language Versioning Policy
Appendix B - MAEC Language Deprecation Policy
Appendix C - FAQs
Appendix D - Terminology
Appendix E - References

We welcome your feedback and any suggestions on how to improve this document, especially given its draft status. For those wishing to submit changes or questions directly, please feel free to edit the Word document version (.docx), which has track-changes enabled.

Regards,
Ivan Kirillov
MITRE