Re: [MAEC] MAEC v5.0 Proposals - Round 2

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

Re: [MAEC] MAEC v5.0 Proposals - Round 2

Kirillov, Ivan A.
Just sending out a friendly reminder that we’re still looking for any feedback on these proposals.  Also, given the timing of BlackHat/Defcon last week, and it also being vacation season, I think we’ll extend the comment period for this round of proposals another week to August 20th.

Regards,
Ivan

From: Ivan Kirillov
Reply-To: Ivan Kirillov
Date: Thursday, July 30, 2015 at 1:49 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: [MAEC] MAEC v5.0 Proposals - Round 2

The second round of proposals for MAEC v5.0 is now ready for feedback and comments. This round incorporates some of the larger, backwards compatibility breaking changes that we’ve been considering, largely targeted towards simplification and ease-of-use.  



We look forward to your feedback! Feel free to reply directly to this thread, so that we can keep the comments contained in one place.

Comments for this round will close in two weeks, on August 13th.

Regards,
Ivan Kirillov
MITRE
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [MAEC] MAEC v5.0 Proposals - Round 2

Paul Patrick

Here’s my initial thoughts on the proposals on the table

  • Proposal: Deprecate MAEC Bundle (as a concept and output format)
    Overall, I think this proposal is a good idea.  I think it makes things a lot cleaner.  Renaming Bundle to Core makes good sense.

  • Proposal: Deprecate MAEC Container
    I believe this clouds the issue of what a Package is intended to represent as it raise a question with regards to the semantics intended for the maecPackage:Grouping_Relationships element.  With a Package possibly containing multiple packages, each with potentially more Malware_Subjects, the scope of the maecPackage:Grouping_Relationships element is now ambiguous – does it apply only to those Malware_Subject in this package or across all packages?  The other question is are we proposing to make maecPackage:Package be an envelope, similar to what STIX did with Package in 1.2 or are the ‘other’ packages related to the maecPackage:Package which references them?  I would RECOMMEND that we not deprecate MAEC Container as with it, Container and Package have much clearer semantics.

  • Proposal: Deprecate MAEC Candidate Indicators in Favor of STIX Indicators
    I think this proposal makes a lot of sense as it unifies that there is one definition of indicator but also makes a strong case for keeping Malware Actions as a derived subtype of cybox:Action so that the normal extension mechanisms can be used.  I think the use of a type of collection to specify potential/candidate indicators is a good way to go.

  • Proposal: Refactor Malware Actions
    The biggest benefit I see to this is that there are additional fields on CybOX Action that I no longer have to think about since they don’t exist in the new maecCore:Action.  That being said, I think the biggest issue here is in CybOX and perhaps a refactoring of cybox:Action is what we should be pushing  to have done.  I think the majority of the fields you’ve suggested in the new malware Action is what should be in a cybox:ActionBase type with the full complement being in cybox:Action.  This way maecCore:Action could extend from cybox:ActionBase adding @count and implementation, while remaining lean.  This way building upon a CybOX foundation remains.
    As for making name an attribute versus a field, I think there is power in the consistency of using ControlledVocabularies as an extension mechanism across the specification family (STIX, MAEC, CybOX) and throughout MAEC.  I don’t know that I see a great win by changing this.

  • Proposal: Make Collections Top Level Entities
    If the Deprecation of MAEC Bundle is approved, doesn’t much of the use of Collection actually occur since all the actions will be grouped together, objects grouped together, etc.?  Also should this proposal go forward, I think the @maec_entity_type needs to be required with ‘various’ being the default value.  The idea of using collections to help categorize things via @type the type attribute makes sense although I might have swapped the means with @maec_entity_type since the latter adds context.  I like the idea of being able to use ‘qualified collections’ to imply grouping as provided through CollectionTypeEnum since there MAEC doesn’t use cybox:Event to capture that.

  • Proposal: Make Tools Top Level Entities
  • Proposal: Make CybOX Objects Top Level Entities
    I think moving both the Tools and CybOX Object as top-level entities does help, so I’d be in support of this.

  • Proposal: Make Relationships Top Level Entities
    While I like a number of aspects of this, the idea of @scope=”pairwise” does make more of a burden of interpretation for relationship type since only single direct value is specified.  I think the explicit relationships, while requiring more lines, actually provides more control and having them explicitly defined on the source making parsing easier.

 

My .02 cents

 

 

Paul Patrick

 

 

 

From: Kirillov, Ivan A. [mailto:[hidden email]]
Sent: Monday, August 10, 2015 6:05 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 2

 

Just sending out a friendly reminder that we’re still looking for any feedback on these proposals.  Also, given the timing of BlackHat/Defcon last week, and it also being vacation season, I think we’ll extend the comment period for this round of proposals another week to August 20th.

 

Regards,

Ivan

 

From: Ivan Kirillov
Reply-To: Ivan Kirillov
Date: Thursday, July 30, 2015 at 1:49 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: [MAEC] MAEC v5.0 Proposals - Round 2

 

The second round of proposals for MAEC v5.0 is now ready for feedback and comments. This round incorporates some of the larger, backwards compatibility breaking changes that we’ve been considering, largely targeted towards simplification and ease-of-use.  

 

 

 

We look forward to your feedback! Feel free to reply directly to this thread, so that we can keep the comments contained in one place.

 

Comments for this round will close in two weeks, on August 13th.

 

Regards,

Ivan Kirillov

MITRE

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

Re: [MAEC] MAEC v5.0 Proposals - Round 2

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

Regards,
Ivan

From: Paul Patrick
Date: Monday, August 10, 2015 at 4:54 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Cc: Ivan Kirillov
Subject: RE: [MAEC] MAEC v5.0 Proposals - Round 2

Here’s my initial thoughts on the proposals on the table

  • Proposal: Deprecate MAEC Bundle (as a concept and output format)
    Overall, I think this proposal is a good idea.  I think it makes things a lot cleaner.  Renaming Bundle to Core makes good sense.

  • Proposal: Deprecate MAEC Container
    I believe this clouds the issue of what a Package is intended to represent as it raise a question with regards to the semantics intended for the maecPackage:Grouping_Relationships element.  With a Package possibly containing multiple packages, each with potentially more Malware_Subjects, the scope of the maecPackage:Grouping_Relationships element is now ambiguous – does it apply only to those Malware_Subject in this package or across all packages?  The other question is are we proposing to make maecPackage:Package be an envelope, similar to what STIX did with Package in 1.2 or are the ‘other’ packages related to the maecPackage:Package which references them?  I would RECOMMEND that we not deprecate MAEC Container as with it, Container and Package have much clearer semantics.

    [Ivan] Good point – I agree that having multiple Packages in a single document would make the semantics of Grouping_Relationships (or many-to-many top-level relationships) more ambiguous, though in theory they should be constrained to the Package that they are defined in. What we’re proposing here is the deprecation of the MAEC Container, with the possibility of still retaining its functionality if deemed necessary (via MAEC_Packages), which I think is similar to the STIX Package implementation from v1.2. The primary goal here is to reduce the number of MAEC output formats from three as before (Bundle, Package, Container) to a single one. Accordingly, I concur with your assessment that having separate Container and Package constructs leads to clearer semantics, but besides having multiple Packages in a single place, is there much of a use case for having a Container? Our previous rationale for adding it was to meet some potential future use cases around multiple Package management, but from what I’ve seen we haven’t come across any of these since the Container was actually introduced.

  • Proposal: Deprecate MAEC Candidate Indicators in Favor of STIX Indicators
    I think this proposal makes a lot of sense as it unifies that there is one definition of indicator but also makes a strong case for keeping Malware Actions as a derived subtype of cybox:Action so that the normal extension mechanisms can be used.  I think the use of a type of collection to specify potential/candidate indicators is a good way to go.

  • Proposal: Refactor Malware Actions
    The biggest benefit I see to this is that there are additional fields on CybOX Action that I no longer have to think about since they don’t exist in the new maecCore:Action.  That being said, I think the biggest issue here is in CybOX and perhaps a refactoring of cybox:Action is what we should be pushing  to have done.  I think the majority of the fields you’ve suggested in the new malware Action is what should be in a cybox:ActionBase type with the full complement being in cybox:Action.  This way maecCore:Action could extend from cybox:ActionBase adding @count and implementation, while remaining lean.  This way building upon a CybOX foundation remains.
    As for making name an attribute versus a field, I think there is power in the consistency of using ControlledVocabularies as an extension mechanism across the specification family (STIX, MAEC, CybOX) and throughout MAEC.  I don’t know that I see a great win by changing this.

[Ivan] Right – the primary benefit of this proposal is a leaner, simpler ActionType. Accordingly, I agree that the CybOX ActionType needs refactoring, and I like the idea of having a lean cybox:ActionBase type that can be extended as necessary. While it would be nice to build upon such a foundation, this would mean waiting until CybOX v3.0 is released, which is unlikely to happen for some time. Also, my inclination is that the semantics of malware actions are domain specific enough to warrant having more control over their structure and composition, which also allows us to make changes down the road as needed without having to first modify any inherited types in CybOX. As far as the action name and controlled vocabularies, this is something we went back and forth over, and I think the core issue was that while they are a powerful extension mechanism they can also be difficult to use, though much of this is owing to our separation of action names into numerous vocabularies. Perhaps a middle ground would be to continue supporting controlled vocabularies (via a Name element of type ControlledVocabularyStringType), and instead coalesce all separate action name vocabularies into a single ActionNameVocabulary?

  • Proposal: Make Collections Top Level Entities
    If the Deprecation of MAEC Bundle is approved, doesn’t much of the use of Collection actually occur since all the actions will be grouped together, objects grouped together, etc.?  Also should this proposal go forward, I think the @maec_entity_type needs to be required with ‘various’ being the default value.  The idea of using collections to help categorize things via @type the type attribute makes sense although I might have swapped the means with @maec_entity_type since the latter adds context.  I like the idea of being able to use ‘qualified collections’ to imply grouping as provided through CollectionTypeEnum since there MAEC doesn’t use cybox:Event to capture that.

[Ivan] With the current set of proposals, Actions would still be captured at the Malware Subject level, which may not strictly necessitate grouping. However, I could certainly see it being used for creating groupings from sandbox output (e.g., all file system actions in one group), and in fact this is what most of the MAEC sandbox translators do today. I could see Collections being used more commonly for Objects, though I think for the most part they will be referenced individually (e.g. from the Instance_Object field). I think making @maec_entity_type required with a default of ‘various’ makes good sense, as this will help consumers identify what is contained in a collection when parsing MAEC data, so I will make this change. As far as @type vs. @maec_entity_type, are you suggesting that the definitions/vocabularies of each be swapped?


[Ivan] We went back and forth on this one as well, and felt that being able to define the scope of a relationship would be useful for global relationships (instead of having to define explicit relationships in such cases), though I can certainly see this making relationships more difficult to parse. Perhaps instead we should consider having two types of relationships, one for strictly pairwise relationships, and one for global? Of course, this semantically isn’t much different from the current implementation – it just move things up another layer. I think we need to think through this one a bit more :-)

 

My .02 cents

 

 

Paul Patrick

 

 

 

From: Kirillov, Ivan A. [[hidden email]]
Sent: Monday, August 10, 2015 6:05 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 2

 

Just sending out a friendly reminder that we’re still looking for any feedback on these proposals.  Also, given the timing of BlackHat/Defcon last week, and it also being vacation season, I think we’ll extend the comment period for this round of proposals another week to August 20th.

 

Regards,

Ivan

 

From: Ivan Kirillov
Reply-To: Ivan Kirillov
Date: Thursday, July 30, 2015 at 1:49 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: [MAEC] MAEC v5.0 Proposals - Round 2

 

The second round of proposals for MAEC v5.0 is now ready for feedback and comments. This round incorporates some of the larger, backwards compatibility breaking changes that we’ve been considering, largely targeted towards simplification and ease-of-use.  

 

 

 

We look forward to your feedback! Feel free to reply directly to this thread, so that we can keep the comments contained in one place.

 

Comments for this round will close in two weeks, on August 13th.

 

Regards,

Ivan Kirillov

MITRE

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

Re: [MAEC] MAEC v5.0 Proposals - Round 2

Paul Patrick

 

 

From: Kirillov, Ivan A. [mailto:[hidden email]]
Sent: Tuesday, August 11, 2015 7:01 AM
To: Paul B. Patrick <[hidden email]>; maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 2

 

Thanks for the feedback, Paul! Replies inline below.

 

Regards,

Ivan

 

From: Paul Patrick
Date: Monday, August 10, 2015 at 4:54 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Cc: Ivan Kirillov
Subject: RE: [MAEC] MAEC v5.0 Proposals - Round 2

 

Here’s my initial thoughts on the proposals on the table


[Paul] Is the intention that maecPackage:Analysis remains as a member of maecPackage:Analyses so that more than one analysis can be contained within a maecPackage:Malware_Subject?  The both the 4.1 and 5.0 samples show the use of maecPackage:Analysis directly on maecPackage:Malware_Subject  instead of contained as a member of maecPackage:Analyses (of type AnalysisListType).

  • Proposal: Deprecate MAEC Container
    I believe this clouds the issue of what a Package is intended to represent as it raise a question with regards to the semantics intended for the maecPackage:Grouping_Relationships element.  With a Package possibly containing multiple packages, each with potentially more Malware_Subjects, the scope of the maecPackage:Grouping_Relationships element is now
    ambiguous – does it apply only to those Malware_Subject in this package or across all packages?  The other question is are we proposing to make maecPackage:Package be an envelope, similar to what STIX did with Package in 1.2 or are the ‘other’ packages related to the maecPackage:Package which references them?  I would RECOMMEND that we not deprecate MAEC Container as with it, Container and Package have much clearer semantics.

 

    [Ivan] Good point – I agree that having multiple Packages in a single document would make the semantics of Grouping_Relationships (or many-to-many top-level relationships) more ambiguous, though in theory they should be constrained to the Package that they are defined in. What we’re proposing here is the deprecation of the MAEC Container, with the possibility of still retaining its functionality if deemed necessary (via MAEC_Packages), which I think is similar to the STIX Package implementation from v1.2. The primary goal here is to reduce the number of MAEC output formats from three as before (Bundle, Package, Container) to a single one. Accordingly, I concur with your assessment that having separate Container and Package constructs leads to clearer semantics, but besides having multiple Packages in a single place, is there much of a use case for having a Container? Our previous rationale for adding it was to meet some potential future use cases around multiple Package management, but from what I’ve seen we haven’t come across any of these since the Container was actually introduced.

 

[Paul] My original thinking for the value in a MAEC Container was the easy by which MAEC results generated from independent tools could be brought together instead of trying to weave the results from different tools into a single MAEC Package.  When we built the automated malware analysis environment, inter-weaving the results from separate tools was one of the more difficult tasks.  Clearly, having a Related_Packages element on MAEC Package could be used to address this.  As for handling Grouping_Relationship, that should probably be thought through as part of the Relationships proposal.

  • Proposal: Deprecate MAEC Candidate Indicators in Favor of STIX Indicators
    I think this proposal makes a lot of sense as it unifies that there is one definition of indicator but also makes a strong case for keeping Malware Actions as a derived subtype of cybox:Action so that the normal extension mechanisms can be used.  I think the use of a type of collection to specify potential/candidate indicators is a good way to go.


  • Proposal: Refactor Malware Actions
    The biggest benefit I see to this is that there are additional fields on CybOX Action that I no longer have to think about since they don’t exist in the new maecCore:Action.  That being said, I think the biggest issue here is in CybOX and perhaps a refactoring of cybox:Action is what we should be pushing  to have done.  I think the majority of the fields you’ve suggested in the new malware Action is what should be in a cybox:ActionBase type with the full complement being in cybox:Action.  This way maecCore:Action could extend from cybox:ActionBase adding @count and implementation, while remaining lean.  This way building upon a CybOX foundation remains.
    As for making name an attribute versus a field, I think there is power in the consistency of using ControlledVocabularies as an extension mechanism across the specification family (STIX, MAEC, CybOX) and throughout MAEC.  I don’t know that I see a great win by changing this.

 

[Ivan] Right – the primary benefit of this proposal is a leaner, simpler ActionType. Accordingly, I agree that the CybOX ActionType needs refactoring, and I like the idea of having a lean cybox:ActionBase type that can be extended as necessary. While it would be nice to build upon such a foundation, this would mean waiting until CybOX v3.0 is released, which is unlikely to happen for some time. Also, my inclination is that the semantics of malware actions are domain specific enough to warrant having more control over their structure and composition, which also allows us to make changes down the road as needed without having to first modify any inherited types in CybOX. As far as the action name and controlled vocabularies, this is something we went back and forth over, and I think the core issue was that while they are a powerful extension mechanism they can also be difficult to use, though much of this is owing to our separation of action names into numerous vocabularies. Perhaps a middle ground would be to continue supporting controlled vocabularies (via a Name element of type ControlledVocabularyStringType), and instead coalesce all separate action name vocabularies into a single ActionNameVocabulary?

 

[Paul] I think a single, unified vocabulary would definitely be better and a good balance between simplicity and flexibility.  In addition it doesn’t require a new release of MAEC just to extend the vocabulary making for easier evolution.

  • Proposal: Make Collections Top Level Entities
    If the Deprecation of MAEC Bundle is approved, doesn’t much of the use of Collection actually occur since all the actions will be grouped together, objects grouped together, etc.?  Also should this proposal go forward, I think the @maec_entity_type needs to be required with ‘various’ being the default value.  The idea of using collections to help categorize things via @type the type attribute makes sense although I might have swapped the means with @maec_entity_type since the latter adds context.  I like the idea of being able to use ‘qualified collections’ to imply grouping as provided through CollectionTypeEnum since there MAEC doesn’t use cybox:Event to capture that.

 

[Ivan] With the current set of proposals, Actions would still be captured at the Malware Subject level, which may not strictly necessitate grouping. However, I could certainly see it being used for creating groupings from sandbox output (e.g., all file system actions in one group), and in fact this is what most of the MAEC sandbox translators do today. I could see Collections being used more commonly for Objects, though I think for the most part they will be referenced individually (e.g. from the Instance_Object field). I think making @maec_entity_type required with a default of ‘various’ makes good sense, as this will help consumers identify what is contained in a collection when parsing MAEC data, so I will make this change. As far as @type vs. @maec_entity_type, are you suggesting that the definitions/vocabularies of each be swapped?

 

[Paul] I agree with your assessment of the use of Collections both for Action, but definitely more commonly for Objects. As for swapping the definitions, I could go either way.  I argued with myself a bit on this as well. 



 

[Ivan] We went back and forth on this one as well, and felt that being able to define the scope of a relationship would be useful for global relationships (instead of having to define explicit relationships in such cases), though I can certainly see this making relationships more difficult to parse. Perhaps instead we should consider having two types of relationships, one for strictly pairwise relationships, and one for global? Of course, this semantically isn’t much different from the current implementation – it just move things up another layer. I think we need to think through this one a bit more :-)

 

[Paul] Since a relationship specifies a single source and a single destination they are specific to a pair of entities.  Since the proposed Relationship element is generic it definitely reduces the number of specific-Relationships.  If the direction is go with a generic Relationship, then I think the @source_id and @destination_Id can’t have a cardinality of 0-1 but must instead be required with a cardinality of 1 else there is no relationship.

 

 

 

My .02 cents

 

 

Paul Patrick

 

 

 

From: Kirillov, Ivan A. [[hidden email]]
Sent: Monday, August 10, 2015 6:05 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 2

 

Just sending out a friendly reminder that we’re still looking for any feedback on these proposals.  Also, given the timing of BlackHat/Defcon last week, and it also being vacation season, I think we’ll extend the comment period for this round of proposals another week to August 20th.

 

Regards,

Ivan

 

From: Ivan Kirillov
Reply-To: Ivan Kirillov
Date: Thursday, July 30, 2015 at 1:49 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: [MAEC] MAEC v5.0 Proposals - Round 2

 

The second round of proposals for MAEC v5.0 is now ready for feedback and comments. This round incorporates some of the larger, backwards compatibility breaking changes that we’ve been considering, largely targeted towards simplification and ease-of-use.  

 

 

 

We look forward to your feedback! Feel free to reply directly to this thread, so that we can keep the comments contained in one place.

 

Comments for this round will close in two weeks, on August 13th.

 

Regards,

Ivan Kirillov

MITRE

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

Re: [MAEC] MAEC v5.0 Proposals - Round 2

Kirillov, Ivan A.
Further replies below.

Regards,
Ivan

From: Paul Patrick
Date: Tuesday, August 11, 2015 at 2:13 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Cc: Ivan Kirillov
Subject: RE: [MAEC] MAEC v5.0 Proposals - Round 2

 

 

From: Kirillov, Ivan A. [[hidden email]]
Sent: Tuesday, August 11, 2015 7:01 AM
To: Paul B. Patrick <[hidden email]>; maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 2

 

Thanks for the feedback, Paul! Replies inline below.

 

Regards,

Ivan

 

From: Paul Patrick
Date: Monday, August 10, 2015 at 4:54 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Cc: Ivan Kirillov
Subject: RE: [MAEC] MAEC v5.0 Proposals - Round 2

 

Here’s my initial thoughts on the proposals on the table


[Paul] Is the intention that maecPackage:Analysis remains as a member of maecPackage:Analyses so that more than one analysis can be contained within a maecPackage:Malware_Subject?  The both the 4.1 and 5.0 samples show the use of maecPackage:Analysis directly on maecPackage:Malware_Subject  instead of contained as a member of maecPackage:Analyses (of type AnalysisListType).

  • Proposal: Deprecate MAEC Container
    I believe this clouds the issue of what a Package is intended to represent as it raise a question with regards to the semantics intended for the maecPackage:Grouping_Relationships element.  With a Package possibly containing multiple packages, each with potentially more Malware_Subjects, the scope of the maecPackage:Grouping_Relationships element is now
    ambiguous – does it apply only to those Malware_Subject in this package or across all packages?  The other question is are we proposing to make maecPackage:Package be an envelope, similar to what STIX did with Package in 1.2 or are the ‘other’ packages related to the maecPackage:Package which references them?  I would RECOMMEND that we not deprecate MAEC Container as with it, Container and Package have much clearer semantics.

 

    [Ivan] Good point – I agree that having multiple Packages in a single document would make the semantics of Grouping_Relationships (or many-to-many top-level relationships) more ambiguous, though in theory they should be constrained to the Package that they are defined in. What we’re proposing here is the deprecation of the MAEC Container, with the possibility of still retaining its functionality if deemed necessary (via MAEC_Packages), which I think is similar to the STIX Package implementation from v1.2. The primary goal here is to reduce the number of MAEC output formats from three as before (Bundle, Package, Container) to a single one. Accordingly, I concur with your assessment that having separate Container and Package constructs leads to clearer semantics, but besides having multiple Packages in a single place, is there much of a use case for having a Container? Our previous rationale for adding it was to meet some potential future use cases around multiple Package management, but from what I’ve seen we haven’t come across any of these since the Container was actually introduced.

 

[Paul] My original thinking for the value in a MAEC Container was the easy by which MAEC results generated from independent tools could be brought together instead of trying to weave the results from different tools into a single MAEC Package.  When we built the automated malware analysis environment, inter-weaving the results from separate tools was one of the more difficult tasks.  Clearly, having a Related_Packages element on MAEC Package could be used to address this.  As for handling Grouping_Relationship, that should probably be thought through as part of the Relationships proposal.


[Ivan] That’s a good point, though I wonder if having a Container for weaving multiple tool outputs together is duplicative when this could also be accomplished through STIX (specifically multiple related TTPs w/ embedded MAEC)? That way, MAEC can focus more on the characterization of malware instances and the relationships between them, and STIX can serve as a way of managing multiple tool outputs and similar abstractions. This would also help us focus on supporting only one output format.

  • Proposal: Deprecate MAEC Candidate Indicators in Favor of STIX Indicators
    I think this proposal makes a lot of sense as it unifies that there is one definition of indicator but also makes a strong case for keeping Malware Actions as a derived subtype of cybox:Action so that the normal extension mechanisms can be used.  I think the use of a type of collection to specify potential/candidate indicators is a good way to go.


  • Proposal: Refactor Malware Actions
    The biggest benefit I see to this is that there are additional fields on CybOX Action that I no longer have to think about since they don’t exist in the new maecCore:Action.  That being said, I think the biggest issue here is in CybOX and perhaps a refactoring of cybox:Action is what we should be pushing  to have done.  I think the majority of the fields you’ve suggested in the new malware Action is what should be in a cybox:ActionBase type with the full complement being in cybox:Action.  This way maecCore:Action could extend from cybox:ActionBase adding @count and implementation, while remaining lean.  This way building upon a CybOX foundation remains.
    As for making name an attribute versus a field, I think there is power in the consistency of using ControlledVocabularies as an extension mechanism across the specification family (STIX, MAEC, CybOX) and throughout MAEC.  I don’t know that I see a great win by changing this.

 

[Ivan] Right – the primary benefit of this proposal is a leaner, simpler ActionType. Accordingly, I agree that the CybOX ActionType needs refactoring, and I like the idea of having a lean cybox:ActionBase type that can be extended as necessary. While it would be nice to build upon such a foundation, this would mean waiting until CybOX v3.0 is released, which is unlikely to happen for some time. Also, my inclination is that the semantics of malware actions are domain specific enough to warrant having more control over their structure and composition, which also allows us to make changes down the road as needed without having to first modify any inherited types in CybOX. As far as the action name and controlled vocabularies, this is something we went back and forth over, and I think the core issue was that while they are a powerful extension mechanism they can also be difficult to use, though much of this is owing to our separation of action names into numerous vocabularies. Perhaps a middle ground would be to continue supporting controlled vocabularies (via a Name element of type ControlledVocabularyStringType), and instead coalesce all separate action name vocabularies into a single ActionNameVocabulary?

 

[Paul] I think a single, unified vocabulary would definitely be better and a good balance between simplicity and flexibility.  In addition it doesn’t require a new release of MAEC just to extend the vocabulary making for easier evolution.


[Ivan] Sounds good – I’ll go ahead and make this change in the proposal. I agree that this also makes it easier to update the action enumeration, since it decouples it from the MAEC Core schema.

  • Proposal: Make Collections Top Level Entities
    If the Deprecation of MAEC Bundle is approved, doesn’t much of the use of Collection actually occur since all the actions will be grouped together, objects grouped together, etc.?  Also should this proposal go forward, I think the @maec_entity_type needs to be required with ‘various’ being the default value.  The idea of using collections to help categorize things via @type the type attribute makes sense although I might have swapped the means with @maec_entity_type since the latter adds context.  I like the idea of being able to use ‘qualified collections’ to imply grouping as provided through CollectionTypeEnum since there MAEC doesn’t use cybox:Event to capture that.

 

[Ivan] With the current set of proposals, Actions would still be captured at the Malware Subject level, which may not strictly necessitate grouping. However, I could certainly see it being used for creating groupings from sandbox output (e.g., all file system actions in one group), and in fact this is what most of the MAEC sandbox translators do today. I could see Collections being used more commonly for Objects, though I think for the most part they will be referenced individually (e.g. from the Instance_Object field). I think making @maec_entity_type required with a default of ‘various’ makes good sense, as this will help consumers identify what is contained in a collection when parsing MAEC data, so I will make this change. As far as @type vs. @maec_entity_type, are you suggesting that the definitions/vocabularies of each be swapped?

 

[Paul] I agree with your assessment of the use of Collections both for Action, but definitely more commonly for Objects. As for swapping the definitions, I could go either way.  I argued with myself a bit on this as well. 

 

[Ivan] We went back and forth on this one as well, and felt that being able to define the scope of a relationship would be useful for global relationships (instead of having to define explicit relationships in such cases), though I can certainly see this making relationships more difficult to parse. Perhaps instead we should consider having two types of relationships, one for strictly pairwise relationships, and one for global? Of course, this semantically isn’t much different from the current implementation – it just move things up another layer. I think we need to think through this one a bit more :-)

 

[Paul] Since a relationship specifies a single source and a single destination they are specific to a pair of entities.  Since the proposed Relationship element is generic it definitely reduces the number of specific-Relationships.  If the direction is go with a generic Relationship, then I think the @source_id and @destination_Id can’t have a cardinality of 0-1 but must instead be required with a cardinality of 1 else there is no relationship.

 

[Ivan] Good point. I agree that having a single source and destination on a relationship is implicit to it being applicable only to a pair of entities, and that the cardinality of these fields should really be 1. I chatted about this with one of my MAEC team colleagues, Desiree Beck, and we came to the realization that perhaps Collections could be used to capture grouping relationships, as they inherently represent a many-to-many relationship. That way, individual relationships will be pairwise, and Collections will serve to capture many-to-many relationships. This could also including grouping relationships, so that we can move over the GroupingRelationshipInformationType to the Collection and add a corresponding element for it (though perhaps it should be called something else here). What do you think?

 

 

My .02 cents

 

 

Paul Patrick

 

 

 

From: Kirillov, Ivan A. [[hidden email]]
Sent: Monday, August 10, 2015 6:05 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 2

 

Just sending out a friendly reminder that we’re still looking for any feedback on these proposals.  Also, given the timing of BlackHat/Defcon last week, and it also being vacation season, I think we’ll extend the comment period for this round of proposals another week to August 20th.

 

Regards,

Ivan

 

From: Ivan Kirillov
Reply-To: Ivan Kirillov
Date: Thursday, July 30, 2015 at 1:49 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: [MAEC] MAEC v5.0 Proposals - Round 2

 

The second round of proposals for MAEC v5.0 is now ready for feedback and comments. This round incorporates some of the larger, backwards compatibility breaking changes that we’ve been considering, largely targeted towards simplification and ease-of-use.  

 

 

 

We look forward to your feedback! Feel free to reply directly to this thread, so that we can keep the comments contained in one place.

 

Comments for this round will close in two weeks, on August 13th.

 

Regards,

Ivan Kirillov

MITRE

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

Re: [MAEC] MAEC v5.0 Proposals - Round 2

Paul Patrick

Replies below

 

 

From: Kirillov, Ivan A. [mailto:[hidden email]]
Sent: Wednesday, August 12, 2015 1:26 PM
To: Paul B. Patrick <[hidden email]>; maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 2

 

Further replies below.

 

Regards,

Ivan

 

From: Paul Patrick
Date: Tuesday, August 11, 2015 at 2:13 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Cc: Ivan Kirillov
Subject: RE: [MAEC] MAEC v5.0 Proposals - Round 2

 

 

 

From: Kirillov, Ivan A. [[hidden email]]
Sent: Tuesday, August 11, 2015 7:01 AM
To: Paul B. Patrick <[hidden email]>; maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 2

 

Thanks for the feedback, Paul! Replies inline below.

 

Regards,

Ivan

 

From: Paul Patrick
Date: Monday, August 10, 2015 at 4:54 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Cc: Ivan Kirillov
Subject: RE: [MAEC] MAEC v5.0 Proposals - Round 2

 

Here’s my initial thoughts on the proposals on the table



[Paul] Is the intention that maecPackage:Analysis remains as a member of maecPackage:Analyses so that more than one analysis can be contained within a maecPackage:Malware_Subject?  The both the 4.1 and 5.0 samples show the use of maecPackage:Analysis directly on maecPackage:Malware_Subject  instead of contained as a member of maecPackage:Analyses (of type AnalysisListType).

  • Proposal: Deprecate MAEC Container
    I believe this clouds the issue of what a Package is intended to represent as it raise a question with regards to the semantics intended for the maecPackage:Grouping_Relationships element.  With a Package possibly containing multiple packages, each with potentially more Malware_Subjects, the scope of the maecPackage:Grouping_Relationships element is nowambiguous – does it apply only to those Malware_Subject in this package or across all packages?  The other question is are we proposing to make maecPackage:Package be an envelope, similar to what STIX did with Package in 1.2 or are the ‘other’ packages related to the maecPackage:Package which references them?  I would RECOMMEND that we not deprecate MAEC Container as with it, Container and Package have much clearer semantics.

 

    [Ivan] Good point – I agree that having multiple Packages in a single document would make the semantics of Grouping_Relationships (or many-to-many top-level relationships) more ambiguous, though in theory they should be constrained to the Package that they are defined in. What we’re proposing here is the deprecation of the MAEC Container, with the possibility of still retaining its functionality if deemed necessary (via MAEC_Packages), which I think is similar to the STIX Package implementation from v1.2. The primary goal here is to reduce the number of MAEC output formats from three as before (Bundle, Package, Container) to a single one. Accordingly, I concur with your assessment that having separate Container and Package constructs leads to clearer semantics, but besides having multiple Packages in a single place, is there much of a use case for having a Container? Our previous rationale for adding it was to meet some potential future use cases around multiple Package management, but from what I’ve seen we haven’t come across any of these since the Container was actually introduced.

 

[Paul] My original thinking for the value in a MAEC Container was the easy by which MAEC results generated from independent tools could be brought together instead of trying to weave the results from different tools into a single MAEC Package.  When we built the automated malware analysis environment, inter-weaving the results from separate tools was one of the more difficult tasks.  Clearly, having a Related_Packages element on MAEC Package could be used to address this.  As for handling Grouping_Relationship, that should probably be thought through as part of the Relationships proposal.

 

[Ivan] That’s a good point, though I wonder if having a Container for weaving multiple tool outputs together is duplicative when this could also be accomplished through STIX (specifically multiple related TTPs w/ embedded MAEC)? That way, MAEC can focus more on the characterization of malware instances and the relationships between them, and STIX can serve as a way of managing multiple tool outputs and similar abstractions. This would also help us focus on supporting only one output format.

 

[Paul]  I think use STIX is a workable solution.  Was just thinking about folks like ThreatExpert or VirusTotal that might want to have a container holding each of the multiple tool outputs.  Be nice to hear from other folks doing automated malware analysis to get their thoughts.

  • Proposal: Deprecate MAEC Candidate Indicators in Favor of STIX Indicators
    I think this proposal makes a lot of sense as it unifies that there is one definition of indicator but also makes a strong case for keeping Malware Actions as a derived subtype of cybox:Action so that the normal extension mechanisms can be used.  I think the use of a type of collection to specify potential/candidate indicators is a good way to go.



  • Proposal: Refactor Malware Actions
    The biggest benefit I see to this is that there are additional fields on CybOX Action that I no longer have to think about since they don’t exist in the new maecCore:Action.  That being said, I think the biggest issue here is in CybOX and perhaps a refactoring of cybox:Action is what we should be pushing  to have done.  I think the majority of the fields you’ve suggested in the new malware Action is what should be in a cybox:ActionBase type with the full complement being in cybox:Action.  This way maecCore:Action could extend from cybox:ActionBase adding @count and implementation, while remaining lean.  This way building upon a CybOX foundation remains.
    As for making name an attribute versus a field, I think there is power in the consistency of using ControlledVocabularies as an extension mechanism across the specification family (STIX, MAEC, CybOX) and throughout MAEC.  I don’t know that I see a great win by changing this.

 

[Ivan] Right – the primary benefit of this proposal is a leaner, simpler ActionType. Accordingly, I agree that the CybOX ActionType needs refactoring, and I like the idea of having a lean cybox:ActionBase type that can be extended as necessary. While it would be nice to build upon such a foundation, this would mean waiting until CybOX v3.0 is released, which is unlikely to happen for some time. Also, my inclination is that the semantics of malware actions are domain specific enough to warrant having more control over their structure and composition, which also allows us to make changes down the road as needed without having to first modify any inherited types in CybOX. As far as the action name and controlled vocabularies, this is something we went back and forth over, and I think the core issue was that while they are a powerful extension mechanism they can also be difficult to use, though much of this is owing to our separation of action names into numerous vocabularies. Perhaps a middle ground would be to continue supporting controlled vocabularies (via a Name element of type ControlledVocabularyStringType), and instead coalesce all separate action name vocabularies into a single ActionNameVocabulary?

 

[Paul] I think a single, unified vocabulary would definitely be better and a good balance between simplicity and flexibility.  In addition it doesn’t require a new release of MAEC just to extend the vocabulary making for easier evolution.

 

[Ivan] Sounds good – I’ll go ahead and make this change in the proposal. I agree that this also makes it easier to update the action enumeration, since it decouples it from the MAEC Core schema.

  • Proposal: Make Collections Top Level Entities
    If the Deprecation of MAEC Bundle is approved, doesn’t much of the use of Collection actually occur since all the actions will be grouped together, objects grouped together, etc.?  Also should this proposal go forward, I think the @maec_entity_type needs to be required with ‘various’ being the default value.  The idea of using collections to help categorize things via @type the type attribute makes sense although I might have swapped the means with @maec_entity_type since the latter adds context.  I like the idea of being able to use ‘qualified collections’ to imply grouping as provided through CollectionTypeEnum since there MAEC doesn’t use cybox:Event to capture that.

 

[Ivan] With the current set of proposals, Actions would still be captured at the Malware Subject level, which may not strictly necessitate grouping. However, I could certainly see it being used for creating groupings from sandbox output (e.g., all file system actions in one group), and in fact this is what most of the MAEC sandbox translators do today. I could see Collections being used more commonly for Objects, though I think for the most part they will be referenced individually (e.g. from the Instance_Object field). I think making @maec_entity_type required with a default of ‘various’ makes good sense, as this will help consumers identify what is contained in a collection when parsing MAEC data, so I will make this change. As far as @type vs. @maec_entity_type, are you suggesting that the definitions/vocabularies of each be swapped?

 

[Paul] I agree with your assessment of the use of Collections both for Action, but definitely more commonly for Objects. As for swapping the definitions, I could go either way.  I argued with myself a bit on this as well. 

 

[Ivan] We went back and forth on this one as well, and felt that being able to define the scope of a relationship would be useful for global relationships (instead of having to define explicit relationships in such cases), though I can certainly see this making relationships more difficult to parse. Perhaps instead we should consider having two types of relationships, one for strictly pairwise relationships, and one for global? Of course, this semantically isn’t much different from the current implementation – it just move things up another layer. I think we need to think through this one a bit more :-)

 

[Paul] Since a relationship specifies a single source and a single destination they are specific to a pair of entities.  Since the proposed Relationship element is generic it definitely reduces the number of specific-Relationships.  If the direction is go with a generic Relationship, then I think the @source_id and @destination_Id can’t have a cardinality of 0-1 but must instead be required with a cardinality of 1 else there is no relationship.

 

[Ivan] Good point. I agree that having a single source and destination on a relationship is implicit to it being applicable only to a pair of entities, and that the cardinality of these fields should really be 1. I chatted about this with one of my MAEC team colleagues, Desiree Beck, and we came to the realization that perhaps Collections could be used to capture grouping relationships, as they inherently represent a many-to-many relationship. That way, individual relationships will be pairwise, and Collections will serve to capture many-to-many relationships. This could also including grouping relationships, so that we can move over the GroupingRelationshipInformationType to the Collection and add a corresponding element for it (though perhaps it should be called something else here). What do you think?

 

[Paul] I think what your proposing makes a lot sense and could definitely support it.

 

 

My .02 cents

 

 

Paul Patrick

 

 

 

From: Kirillov, Ivan A. [[hidden email]]
Sent: Monday, August 10, 2015 6:05 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 2

 

Just sending out a friendly reminder that we’re still looking for any feedback on these proposals.  Also, given the timing of BlackHat/Defcon last week, and it also being vacation season, I think we’ll extend the comment period for this round of proposals another week to August 20th.

 

Regards,

Ivan

 

From: Ivan Kirillov
Reply-To: Ivan Kirillov
Date: Thursday, July 30, 2015 at 1:49 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: [MAEC] MAEC v5.0 Proposals - Round 2

 

The second round of proposals for MAEC v5.0 is now ready for feedback and comments. This round incorporates some of the larger, backwards compatibility breaking changes that we’ve been considering, largely targeted towards simplification and ease-of-use.  

 

 

 

We look forward to your feedback! Feel free to reply directly to this thread, so that we can keep the comments contained in one place.

 

Comments for this round will close in two weeks, on August 13th.

 

Regards,

Ivan Kirillov

MITRE

Loading...