[MAEC] MAEC v5.0 Proposals - Round 1

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

[MAEC] MAEC v5.0 Proposals - Round 1

Kirillov, Ivan A.
The MAEC team has been busy putting together the proposals for changes in MAEC v5.0, and now that the majority are ready we’re looking to start sending them out for feedback. We plan on having two rounds of proposals, with two weeks of comments for each. For this first round (starting today), which focuses on some of the smaller changes, we have the following:

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.

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

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

Terry MacDonald
Hi Ivan,

I'll reply per proposal below:
  1. Does it make sense to add such a capability to MAEC?
    [terry] - Yes. I especially like the fact that it is adding the ability to describe aliases, as we all know malware can be called different names by different vendors.

  2. Do the defined types, their child properties, their datatypes, and their annotations makes sense? Should they be changed in any way?
    [terry] - My concern by lumping the various names that the malware is known as together into a pair of single fields is that we potentially lose sight of what the malware sample is called by the MAEC producer. I wonder if it is better to separate the aliases out into their own field. i.e. keep the Malware_Instance_Name and Malware_Family_Name (limited to 0-1), but also add Malware_Instance_Aliases and Malware_Family_Aliases (limited 0-N). In this way people can easily discern what the producer calls the malware, and they can also see what others call the malware sample. It allows for others to release details of similar malware under their own family names, and a relationship to still be discerned through the alias fields.

  3. Does it make sense to have a multiplicity of 0-N (unbounded) for malware instance and malware family names, or should it be bounded to 1?
    [terry] - I woulsd suggest bounded to 1 if you add the Malware_Instance_Aliases and Malware_Family_Aliases (unbounded).

  4. Does it make sense to assign a relative measure of confidence to malware instance and malware family names? Accordingly, do the values in the ConfidenceMeasureEnummake sense?
    [terry] - I would like to align the ConfidenceMeasureEnum values with the values in the STIX confidence (High, Medium, Low, None, Unknown). 

  1. Are the proposed descriptions changes accurate and necessary?
    [terry] - Looks good to me.

  2. Are the proposed additional values appropriate?
    [terry] - Also look good.
  1. Does it make sense to make this field name change in MAEC?
    [terry] - Yes it makes sense.

  2. Does the proposed name make sense? Are there preferable alternatives?
    [terry] - what about renaming it simply 'observables', or 'instance_observables'? This would align somewhat with STIX.
Proposal: Deprecate Use of QNames for Ids
  1. Should URIs be used instead of QNames in IDs?
    [terry] - I'm in two minds here. I really dislike QNames as they complicate the processing involved in generating and consuming the XML output of STIX, CYBOX and MAEC. But, I am equally concerned that MAEC will be deprecating the use of QNames in IDs, when there has been no public discussion about doing the same within STIX or CybOX. I would hate for producers and consumers of threat intelligence to be forced to support two different ways of generating IDs within a single library if it could be avoided.

    In other words - has this been discussed with the STIX/CybOX communities to see if they would be open to changing the IDs to use URIs? I think a LOT of people would, but ti would be great to check this out and confirm it before changing MAEC. It would be far better to have MAEC the first of the related protocols to migrate, rather than it be the only one doing this change.

  2. Are there any circumstances when using QNames is necessary or preferable?
    [terry] - When STIX uses MAEC, the deprecation of QNames will have an impact. This needs to be aligned and adjusted for in everyone's STIX implementations (if they support MAEC via the TTP construct).
Proposal: Rename ExploitType and Expand Fields
  1. Should ExploitType be renamed to VulnerabilityExploitType? Or, should it be named VulnerabilityType? (What is the purpose of the "Exploit" modifier?)
    [terry] - I have never understood where the ExploitTarget object name was derived from. I would have preferred VulnerableTarget or something similar for STIX, as it is focused on identifying vulnerable systems. The ExploitTarget and MAEC ExploitType are two sides of the same coin as I see it. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. 

  2. Should VulnerabilityExploitType align as closely as possible with the STIXVulnerabilityType or is it better to take a more flexible approach by defining a new MAEC VulnerabilityReferenceType?
    [terry] - They must align in my opinion. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. There is a lot of benefit to be had by ensuring that consumers can find linkages between vulnerable systems, and malware that exploits those vulnerabilities. For this to happen it is imperative that STIX and MAEC align their descriptions, such that one can make a connection.

    I would posit that as the STIX ExploitTarget is designed to describe vulnerable systems that the STIXVulnerabilityType should be considered the 'standard' for vulnerability description, and that as MAEC is designed to describe malware and the exploits they contain that the MAEC Exploit descriptions should be considered the 'standard' for exploit description, and that they should leverage each others work.

  3. Should the multiplicity of the Vulnerability_Reference field be 0..* or should aVulnerabilityReferenceListType be defined?
    [terry] - It depends on how flexible you want the VulnerabilityExploitType to be. It needs to cope with:
    1. A single binary using exploiting multiple vulnerabilities
    2. Multiple binaries exploiting the same single vulnerability
    3. Multiple binaries each exploiting a different single vulnerability
    4. A single binary exploiting a single vulnerability

      The placement of the title may preclude some of the scenarios described above.

  4. Although not captured in the STIX VulnerabilityType, should Impact (the effect and extent of the vulnerability) be captured as a field in the MAECVulnerabilityExploitType?
    [terry] - This is potentially where a CVSS base score could be useful as it describes how worried an organization should be, on a nice scale from 0-10. Thats one thing the STIX VulnerabilityType has right.

  5. Is the generic use of the ID field in the VulnerabilityReferenceType to capture identifiers (such as CVE and OSVDB identifiers) preferable to defining separate fields that are of restricted string types that correspond to the format of each identifier. For example, a CVE ID would be explicitly defined as a restriction of type String such that it adheres to the regular expression “CVE-\d\d\d\d+\d+”.
    [terry] - I like the fact that the proposal allows for multiple different identifiers.


Cheers
Terry MacDonald


On 15 July 2015 at 06:08, Kirillov, Ivan A. <[hidden email]> wrote:
The MAEC team has been busy putting together the proposals for changes in MAEC v5.0, and now that the majority are ready we’re looking to start sending them out for feedback. We plan on having two rounds of proposals, with two weeks of comments for each. For this first round (starting today), which focuses on some of the smaller changes, we have the following:

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.

Regards,
Ivan Kirillov
MITRE

Reply | Threaded
Open this post in threaded view
|

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

Jon Baker
Administrator

Terry,

 

WRT the removal of qnames in stix/cybox we have had that as an open issue for a few months. Obviously it is a bigger change than we could fit into the 1.2 minor release for STIX and it is not something that we have discussed with the community. Check out:

 

https://github.com/STIXProject/schemas/issues/301

 

and

 

https://github.com/CybOXProject/schemas/issues/354

 

Thanks,

 

Jon

 

============================================

Jonathan O. Baker

J83D - Cyber Security Partnerships, Sharing, and Automation

The MITRE Corporation

Email: [hidden email]

 

From: Terry MacDonald [mailto:[hidden email]]
Sent: Tuesday, July 14, 2015 9:24 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Hi Ivan,

 

I'll reply per proposal below:

  1. Does it make sense to add such a capability to MAEC?
    [terry] - Yes. I especially like the fact that it is adding the ability to describe aliases, as we all know malware can be called different names by different vendors.
  2. Do the defined types, their child properties, their datatypes, and their annotations makes sense? Should they be changed in any way?
    [terry] - My concern by lumping the various names that the malware is known as together into a pair of single fields is that we potentially lose sight of what the malware sample is called by the MAEC producer. I wonder if it is better to separate the aliases out into their own field. i.e. keep the Malware_Instance_Name and Malware_Family_Name (limited to 0-1), but also add Malware_Instance_Aliases and Malware_Family_Aliases (limited 0-N). In this way people can easily discern what the producer calls the malware, and they can also see what others call the malware sample. It allows for others to release details of similar malware under their own family names, and a relationship to still be discerned through the alias fields.
  3. Does it make sense to have a multiplicity of 0-N (unbounded) for malware instance and malware family names, or should it be bounded to 1?
    [terry] - I woulsd suggest bounded to 1 if you add the Malware_Instance_Aliases and Malware_Family_Aliases (unbounded).
  4. Does it make sense to assign a relative measure of confidence to malware instance and malware family names? Accordingly, do the values in the ConfidenceMeasureEnummake sense?
    [terry] - I would like to align the ConfidenceMeasureEnum values with the values in the STIX confidence (High, Medium, Low, None, Unknown). 

 

  1. Are the proposed descriptions changes accurate and necessary?
    [terry] - Looks good to me.
  2. Are the proposed additional values appropriate?
    [terry] - Also look good.
  1. Does it make sense to make this field name change in MAEC?
    [terry] - Yes it makes sense.
  2. Does the proposed name make sense? Are there preferable alternatives?
    [terry] - what about renaming it simply 'observables', or 'instance_observables'? This would align somewhat with STIX.

Proposal: Deprecate Use of QNames for Ids

  1. Should URIs be used instead of QNames in IDs?
    [terry] - I'm in two minds here. I really dislike QNames as they complicate the processing involved in generating and consuming the XML output of STIX, CYBOX and MAEC. But, I am equally concerned that MAEC will be deprecating the use of QNames in IDs, when there has been no public discussion about doing the same within STIX or CybOX. I would hate for producers and consumers of threat intelligence to be forced to support two different ways of generating IDs within a single library if it could be avoided.

    In other words - has this been discussed with the STIX/CybOX communities to see if they would be open to changing the IDs to use URIs? I think a LOT of people would, but ti would be great to check this out and confirm it before changing MAEC. It would be far better to have MAEC the first of the related protocols to migrate, rather than it be the only one doing this change.
  2. Are there any circumstances when using QNames is necessary or preferable?
    [terry] - When STIX uses MAEC, the deprecation of QNames will have an impact. This needs to be aligned and adjusted for in everyone's STIX implementations (if they support MAEC via the TTP construct).

Proposal: Rename ExploitType and Expand Fields

  1. Should ExploitType be renamed to VulnerabilityExploitType? Or, should it be named VulnerabilityType? (What is the purpose of the "Exploit" modifier?)
    [terry] - I have never understood where the ExploitTarget object name was derived from. I would have preferred VulnerableTarget or something similar for STIX, as it is focused on identifying vulnerable systems. The ExploitTarget and MAEC ExploitType are two sides of the same coin as I see it. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. 
  2. Should VulnerabilityExploitType align as closely as possible with the STIXVulnerabilityType or is it better to take a more flexible approach by defining a new MAEC VulnerabilityReferenceType?
    [terry] - They must align in my opinion. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. There is a lot of benefit to be had by ensuring that consumers can find linkages between vulnerable systems, and malware that exploits those vulnerabilities. For this to happen it is imperative that STIX and MAEC align their descriptions, such that one can make a connection.

    I would posit that as the STIX ExploitTarget is designed to describe vulnerable systems that the STIXVulnerabilityType should be considered the 'standard' for vulnerability description, and that as MAEC is designed to describe malware and the exploits they contain that the MAEC Exploit descriptions should be considered the 'standard' for exploit description, and that they should leverage each others work.
  3. Should the multiplicity of the Vulnerability_Reference field be 0..* or should aVulnerabilityReferenceListType be defined?
    [terry] - It depends on how flexible you want the VulnerabilityExploitType to be. It needs to cope with:
    1. A single binary using exploiting multiple vulnerabilities
    2. Multiple binaries exploiting the same single vulnerability
    3. Multiple binaries each exploiting a different single vulnerability
    4. A single binary exploiting a single vulnerability

      The placement of the title may preclude some of the scenarios described above.
  1. Although not captured in the STIX VulnerabilityType, should Impact (the effect and extent of the vulnerability) be captured as a field in the MAECVulnerabilityExploitType?
    [terry] - This is potentially where a CVSS base score could be useful as it describes how worried an organization should be, on a nice scale from 0-10. Thats one thing the STIX VulnerabilityType has right.
  2. Is the generic use of the ID field in the VulnerabilityReferenceType to capture identifiers (such as CVE and OSVDB identifiers) preferable to defining separate fields that are of restricted string types that correspond to the format of each identifier. For example, a CVE ID would be explicitly defined as a restriction of type String such that it adheres to the regular expression “CVE-\d\d\d\d+\d+”.
    [terry] - I like the fact that the proposal allows for multiple different identifiers.

 


Cheers
Terry MacDonald

 

 

On 15 July 2015 at 06:08, Kirillov, Ivan A. <[hidden email]> wrote:

The MAEC team has been busy putting together the proposals for changes in MAEC v5.0, and now that the majority are ready we’re looking to start sending them out for feedback. We plan on having two rounds of proposals, with two weeks of comments for each. For this first round (starting today), which focuses on some of the smaller changes, we have the following:

 

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.

 

Regards,

Ivan Kirillov

MITRE

 

Reply | Threaded
Open this post in threaded view
|

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

Kirillov, Ivan A.
In reply to this post by Terry MacDonald
Appreciate the great feedback, Terry. Replies inline below.

Regards,
Ivan

From: Terry MacDonald <[hidden email]>
Date: Tuesday, July 14, 2015 at 9:24 PM
To: Ivan Kirillov <[hidden email]>
Cc: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

Hi Ivan,

I'll reply per proposal below:
  1. Does it make sense to add such a capability to MAEC?
    [terry] - Yes. I especially like the fact that it is adding the ability to describe aliases, as we all know malware can be called different names by different vendors.

  2. Do the defined types, their child properties, their datatypes, and their annotations makes sense? Should they be changed in any way?
    [terry] - My concern by lumping the various names that the malware is known as together into a pair of single fields is that we potentially lose sight of what the malware sample is called by the MAEC producer. I wonder if it is better to separate the aliases out into their own field. i.e. keep the Malware_Instance_Name and Malware_Family_Name (limited to 0-1), but also add Malware_Instance_Aliases and Malware_Family_Aliases (limited 0-N). In this way people can easily discern what the producer calls the malware, and they can also see what others call the malware sample. It allows for others to release details of similar malware under their own family names, and a relationship to still be discerned through the alias fields.
     [Ivan] That’s a good point – with the current approach, it’s unclear where the malware instance/family names (as captured in a MAEC instance document) came from. Capturing aliases as a separate field may be a viable solution, but I’m     
wondering if it might be simpler and more direct to just capture the source using a separate field (probably an @source attribute) for each Malware_Instance_Name and Malware_Family_Name. That way, the producer of the MAEC document can 
specify whether the name came from their own organization (e.g., @source=“MITRE” for me) or somewhere else. It might also be useful to capture a reference URL that goes along with the source (if availble), e.g., for publicly available malware analysis reports where the name may be referenced. What do you think?
  1. Does it make sense to have a multiplicity of 0-N (unbounded) for malware instance and malware family names, or should it be bounded to 1?
    [terry] - I woulsd suggest bounded to 1 if you add the Malware_Instance_Aliases and Malware_Family_Aliases (unbounded).

  2. Does it make sense to assign a relative measure of confidence to malware instance and malware family names? Accordingly, do the values in the ConfidenceMeasureEnummake sense?
    [terry] - I would like to align the ConfidenceMeasureEnum values with the values in the STIX confidence (High, Medium, Low, None, Unknown).
     [Ivan] Agreed – I’ll update the proposal to align the values with the ConfidenceMeasureEnum. In the future, it would be nice to be able to use MAEC/STIX/CybOX vocabularies interchangeably. Currently this isn’t possible (at least with respect to STIX <-> MAEC/CybOX) because their vocabularies extend from different base types.

  1. Are the proposed descriptions changes accurate and necessary?
    [terry] - Looks good to me.

  2. Are the proposed additional values appropriate?
    [terry] - Also look good.
  1. Does it make sense to make this field name change in MAEC?
    [terry] - Yes it makes sense.

  2. Does the proposed name make sense? Are there preferable alternatives?
  1. [terry] - what about renaming it simply 'observables', or 'instance_observables'? This would align somewhat with STIX.
    [Ivan] That would be closer to STIX, but not completely accurate as the field only supports capturing a CybOX Object (cybox:ObjectType). Maybe “Instance_Object” then?

Proposal: Deprecate Use of QNames for Ids
  1. Should URIs be used instead of QNames in IDs?
    [terry] - I'm in two minds here. I really dislike QNames as they complicate the processing involved in generating and consuming the XML output of STIX, CYBOX and MAEC. But, I am equally concerned that MAEC will be deprecating the use of QNames in IDs, when there has been no public discussion about doing the same within STIX or CybOX. I would hate for producers and consumers of threat intelligence to be forced to support two different ways of generating IDs within a single library if it could be avoided.

    In other words - has this been discussed with the STIX/CybOX communities to see if they would be open to changing the IDs to use URIs? I think a LOT of people would, but ti would be great to check this out and confirm it before changing MAEC. It would be far better to have MAEC the first of the related protocols to migrate, rather than it be the only one doing this change.
    [Ivan] As Jon mentioned in his response, this has been an outstanding issue for a while in STIX and CybOX, but hasn’t been brought up for explicit discussion because it would not be a backwards compatible change. Accordingly, we chose to do this now in MAEC because we felt it would be a good time (being a major version) to incorporate any backwards-incompatible changes that would be useful. We should certainly check with the STIX/CybOX communities to see if this is something that they may be interested in doing down the road. Also, I definitely agree that having to support multiple ID formats would be painful for content producers (and consumers as well), especially when dealing with embedded MAEC in STIX TTPs. However, with regards to that last point, this won’t be a (potential) issue until STIX is updated to support the embedding of MAEC v5.0 (STIX 1.2.x will be limited to MAEC v4.1).

  1. Are there any circumstances when using QNames is necessary or preferable?
    [terry] - When STIX uses MAEC, the deprecation of QNames will have an impact. This needs to be aligned and adjusted for in everyone's STIX implementations (if they support MAEC via the TTP construct).
Proposal: Rename ExploitType and Expand Fields
  1. Should ExploitType be renamed to VulnerabilityExploitType? Or, should it be named VulnerabilityType? (What is the purpose of the "Exploit" modifier?)
    [terry] - I have never understood where the ExploitTarget object name was derived from. I would have preferred VulnerableTarget or something similar for STIX, as it is focused on identifying vulnerable systems. The ExploitTarget and MAEC ExploitType are two sides of the same coin as I see it. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. 

  2. Should VulnerabilityExploitType align as closely as possible with the STIXVulnerabilityType or is it better to take a more flexible approach by defining a new MAEC VulnerabilityReferenceType?
    [terry] - They must align in my opinion. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. There is a lot of benefit to be had by ensuring that consumers can find linkages between vulnerable systems, and malware that exploits those vulnerabilities. For this to happen it is imperative that STIX and MAEC align their descriptions, such that one can make a connection.

    I would posit that as the STIX ExploitTarget is designed to describe vulnerable systems that the STIXVulnerabilityType should be considered the 'standard' for vulnerability description, and that as MAEC is designed to describe malware and the exploits they contain that the MAEC Exploit descriptions should be considered the 'standard' for exploit description, and that they should leverage each others work.
   [Ivan] I definitely agree with your characterization of the purpose of MAEC’s VulnerabilityExploitType and the ExploitTarget from STIX. The main reason that we decided not to completely mirror the fields in the STIX VulnerabilityType is that, currently, the STIX VulnerabilityType is inflexible when it comes to vulnerability references, supporting only CVE and OSVDB. Therefore, there is some expectation that the STIX VulnerabilityType will be updated to accommodate other references (e.g., CWE for the underlying software flaw of the vulnerability). As such, given that STIX functions as the ‘standard’ for vulnerability description (which we 100% agree with), perhaps we should postpone this change and wait for the STIX VulnerabilityType to be updated?
  1. Should the multiplicity of the Vulnerability_Reference field be 0..* or should aVulnerabilityReferenceListType be defined?
    [terry] - It depends on how flexible you want the VulnerabilityExploitType to be. It needs to cope with:
    1. A single binary using exploiting multiple vulnerabilities
    2. Multiple binaries exploiting the same single vulnerability
    3. Multiple binaries each exploiting a different single vulnerability
    4. A single binary exploiting a single vulnerability

      The placement of the title may preclude some of the scenarios described above.
   [Ivan] Great point. Our thinking is that the VulnerabilityExploitType itself is intended for characterizing a single vulnerability, with multiple potential references. However, with regards to its actual use in MAEC, we currently have the exploitation of a vulnerability as part of the purpose” behind a Behavior (see http://maecproject.github.io/data-model/4.1/maecBundle/BehaviorPurposeType/), which would support #1 (with one Behavior per exploited vulnerability, #3 (with each binary as its own Malware Subject) #4, in your above list. In order to support #2, at least without duplicating content, we’d need to supporting the IDing/referencing of vulnerabilities (probably by adding an ID to the VulnerabilityExploitType, and a separate VulnerabilityReferenceType).
  1. Although not captured in the STIX VulnerabilityType, should Impact (the effect and extent of the vulnerability) be captured as a field in the MAECVulnerabilityExploitType?
    [terry] - This is potentially where a CVSS base score could be useful as it describes how worried an organization should be, on a nice scale from 0-10. Thats one thing the STIX VulnerabilityType has right.
    [Ivan] Agreed; not sure why we didn’t carry over the CVSS score field (at least base score) from the VulnerabilityType, as it provides a useful metric for (at least initially) making judgments about the potential impact of a vulnerability exploit.
  1. Is the generic use of the ID field in the VulnerabilityReferenceType to capture identifiers (such as CVE and OSVDB identifiers) preferable to defining separate fields that are of restricted string types that correspond to the format of each identifier. For example, a CVE ID would be explicitly defined as a restriction of type String such that it adheres to the regular expression “CVE-\d\d\d\d+\d+”.
    [terry] - I like the fact that the proposal allows for multiple different identifiers.


Cheers
Terry MacDonald


On 15 July 2015 at 06:08, Kirillov, Ivan A. <[hidden email]> wrote:
The MAEC team has been busy putting together the proposals for changes in MAEC v5.0, and now that the majority are ready we’re looking to start sending them out for feedback. We plan on having two rounds of proposals, with two weeks of comments for each. For this first round (starting today), which focuses on some of the smaller changes, we have the following:

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.

Regards,
Ivan Kirillov
MITRE

Reply | Threaded
Open this post in threaded view
|

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

Terry MacDonald-2
Hi Ivan,

Replies inline, with the unnecessary sections removed.
Cheers

Terry MacDonald | STIX, TAXII, CybOX Consultant




Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.
  1. Do the defined types, their child properties, their datatypes, and their annotations makes sense? Should they be changed in any way?
    [terry] - My concern by lumping the various names that the malware is known as together into a pair of single fields is that we potentially lose sight of what the malware sample is called by the MAEC producer. I wonder if it is better to separate the aliases out into their own field. i.e. keep the Malware_Instance_Name and Malware_Family_Name (limited to 0-1), but also add Malware_Instance_Aliases and Malware_Family_Aliases (limited 0-N). In this way people can easily discern what the producer calls the malware, and they can also see what others call the malware sample. It allows for others to release details of similar malware under their own family names, and a relationship to still be discerned through the alias fields.
     [Ivan] That’s a good point – with the current approach, it’s unclear where the malware instance/family names (as captured in a MAEC instance document) came from. Capturing aliases as a separate field may be a viable solution, but I’m     
wondering if it might be simpler and more direct to just capture the source using a separate field (probably an @source attribute) for each Malware_Instance_Name and Malware_Family_Name. That way, the producer of the MAEC document can 
specify whether the name came from their own organization (e.g., @source=“MITRE” for me) or somewhere else. It might also be useful to capture a reference URL that goes along with the source (if availble), e.g., for publicly available malware analysis reports where the name may be referenced. What do you think?

[Terry] - I'm not so sold on the capturing all family names in a single place. Realistically a producer is not going to know which names came from which other vendors, as some may be produced by 3rd parties, and they may only hear of them second hand. The producer is only going to know a subset of that information. I do think that recording the name of what the producer calls the malware instance is important, and recording the information source is important, but that the alias information is useful, but not important. Ultimately I think a list of alias names should be separate from the malware names, and that it doesn't need a source tag. I also think that what the producer calls the malware instance is important, and that the source of the name could be important for Incident Responders who would like more information on the data.

I personally think you should leverage the InformationSourceType available in STIX if you want to tack the source, as that is comprehensive, and a good way of providing whatever level of flexibility the producer wants. It also contains the References section, which could be useful for tracking URLs for more information, if that is something you would like to see tracked within MAEC. 
 
  1. Does it make sense to have a multiplicity of 0-N (unbounded) for malware instance and malware family names, or should it be bounded to 1?
    [terry] - I woulsd suggest bounded to 1 if you add the Malware_Instance_Aliases and Malware_Family_Aliases (unbounded).

  2. Does it make sense to assign a relative measure of confidence to malware instance and malware family names? Accordingly, do the values in the ConfidenceMeasureEnummake sense?
    [terry] - I would like to align the ConfidenceMeasureEnum values with the values in the STIX confidence (High, Medium, Low, None, Unknown).
     [Ivan] Agreed – I’ll update the proposal to align the values with the ConfidenceMeasureEnum. In the future, it would be nice to be able to use MAEC/STIX/CybOX vocabularies interchangeably. Currently this isn’t possible (at least with respect to STIX <-> MAEC/CybOX) because their vocabularies extend from different base types.

[Terry] - I would like to see a lot of things shared across MAEC.STIX/CybOX - Information source, reference URL structures as well as default vocabs. There is a reasonable scope for that. Maybe thats worth bringing up on the OASIS CTI Subcommittees.
 
  1. Does it make sense to make this field name change in MAEC?
    [terry] - Yes it makes sense.

  2. Does the proposed name make sense? Are there preferable alternatives?
  1. [terry] - what about renaming it simply 'observables', or 'instance_observables'? This would align somewhat with STIX.
    [Ivan] That would be closer to STIX, but not completely accurate as the field only supports capturing a CybOX Object (cybox:ObjectType). Maybe “Instance_Object” then?

[Terry] - Instance_Object could work.
 

Proposal: Deprecate Use of QNames for Ids
  1. Should URIs be used instead of QNames in IDs?
    [terry] - I'm in two minds here. I really dislike QNames as they complicate the processing involved in generating and consuming the XML output of STIX, CYBOX and MAEC. But, I am equally concerned that MAEC will be deprecating the use of QNames in IDs, when there has been no public discussion about doing the same within STIX or CybOX. I would hate for producers and consumers of threat intelligence to be forced to support two different ways of generating IDs within a single library if it could be avoided.

    In other words - has this been discussed with the STIX/CybOX communities to see if they would be open to changing the IDs to use URIs? I think a LOT of people would, but ti would be great to check this out and confirm it before changing MAEC. It would be far better to have MAEC the first of the related protocols to migrate, rather than it be the only one doing this change.
    [Ivan] As Jon mentioned in his response, this has been an outstanding issue for a while in STIX and CybOX, but hasn’t been brought up for explicit discussion because it would not be a backwards compatible change. Accordingly, we chose to do this now in MAEC because we felt it would be a good time (being a major version) to incorporate any backwards-incompatible changes that would be useful. We should certainly check with the STIX/CybOX communities to see if this is something that they may be interested in doing down the road. Also, I definitely agree that having to support multiple ID formats would be painful for content producers (and consumers as well), especially when dealing with embedded MAEC in STIX TTPs. However, with regards to that last point, this won’t be a (potential) issue until STIX is updated to support the embedding of MAEC v5.0 (STIX 1.2.x will be limited to MAEC v4.1).

[Terry] - OK, didn't know that. In that case, URIs are better :). 

With all the changes being discussed on the STIX/TAXII lists at present regtarding v2.0 or both TAXII and STIX, I wouldn't be surprised if we end up moving away from XML based documents to another structured data format. I'm really pushing for a 'review all the things' mentality for STIX/TAXII, as the opportunities for a major release don't come about very often. It will be interesting to see what impact that will have on MAEC in the future.

  1. Should VulnerabilityExploitType align as closely as possible with the STIXVulnerabilityType or is it better to take a more flexible approach by defining a new MAEC VulnerabilityReferenceType?
    [terry] - They must align in my opinion. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. There is a lot of benefit to be had by ensuring that consumers can find linkages between vulnerable systems, and malware that exploits those vulnerabilities. For this to happen it is imperative that STIX and MAEC align their descriptions, such that one can make a connection.

    I would posit that as the STIX ExploitTarget is designed to describe vulnerable systems that the STIXVulnerabilityType should be considered the 'standard' for vulnerability description, and that as MAEC is designed to describe malware and the exploits they contain that the MAEC Exploit descriptions should be considered the 'standard' for exploit description, and that they should leverage each others work.
   [Ivan] I definitely agree with your characterization of the purpose of MAEC’s VulnerabilityExploitType and the ExploitTarget from STIX. The main reason that we decided not to completely mirror the fields in the STIX VulnerabilityType is that, currently, the STIX VulnerabilityType is inflexible when it comes to vulnerability references, supporting only CVE and OSVDB. Therefore, there is some expectation that the STIX VulnerabilityType will be updated to accommodate other references (e.g., CWE for the underlying software flaw of the vulnerability). As such, given that STIX functions as the ‘standard’ for vulnerability description (which we 100% agree with), perhaps we should postpone this change and wait for the STIX VulnerabilityType to be updated?

[Terry] - It depends if there is urgent need for this at present. We can always make this change and feed back the need for alignment to the CTI STIX Sub-Committee. It all depends if the MAEC Community can wait.


Reply | Threaded
Open this post in threaded view
|

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

Paul Patrick

 

 

From: Terry MacDonald [mailto:[hidden email]]
Sent: Wednesday, July 15, 2015 4:36 PM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Hi Ivan,

 

Replies inline, with the unnecessary sections removed.

Cheers


Terry MacDonald | STIX, TAXII, CybOX Consultant

 

M: +61-407-203-026

 

 

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

  1. Do the defined types, their child properties, their datatypes, and their annotations makes sense? Should they be changed in any way?
    [terry] - My concern by lumping the various names that the malware is known as together into a pair of single fields is that we potentially lose sight of what the malware sample is called by the MAEC producer. I wonder if it is better to separate the aliases out into their own field. i.e. keep the Malware_Instance_Name and Malware_Family_Name (limited to 0-1), but also add Malware_Instance_Aliases and Malware_Family_Aliases (limited 0-N). In this way people can easily discern what the producer calls the malware, and they can also see what others call the malware sample. It allows for others to release details of similar malware under their own family names, and a relationship to still be discerned through the alias fields.

     [Ivan] That’s a good point – with the current approach, it’s unclear where the malware instance/family names (as captured in a MAEC instance document) came from. Capturing aliases as a separate field may be a viable solution, but I’m     

wondering if it might be simpler and more direct to just capture the source using a separate field (probably an @source attribute) for each Malware_Instance_Name and Malware_Family_Name. That way, the producer of the MAEC document can 

specify whether the name came from their own organization (e.g., @source=“MITRE” for me) or somewhere else. It might also be useful to capture a reference URL that goes along with the source (if availble), e.g., for publicly available malware analysis reports where the name may be referenced. What do you think?

 

[Terry] - I'm not so sold on the capturing all family names in a single place. Realistically a producer is not going to know which names came from which other vendors, as some may be produced by 3rd parties, and they may only hear of them second hand. The producer is only going to know a subset of that information. I do think that recording the name of what the producer calls the malware instance is important, and recording the information source is important, but that the alias information is useful, but not important. Ultimately I think a list of alias names should be separate from the malware names, and that it doesn't need a source tag. I also think that what the producer calls the malware instance is important, and that the source of the name could be important for Incident Responders who would like more information on the data.

 

[Paul] – I might suggest that rather than have 2 lists, that you might have a new MalwareAlias type that contains a single member for both name and family.  I would agree that the producer of the MAEC would likely have its own name and that is important.  But I would argue that the alias information is important.  Without alias, it becomes difficult that something reported by one producer can be correlated with another.  For example, image the same malware instance is submitted to multiple online sandboxes that produce results in MAEC format.  It likely that both sandboxes will assign their own unique name but may also be able to relate the instance to a given name and/or corresponding family.  Without the aliases, it’s very difficult to correlate across them.

 

I personally think you should leverage the InformationSourceType available in STIX if you want to tack the source, as that is comprehensive, and a good way of providing whatever level of flexibility the producer wants. It also contains the References section, which could be useful for tracking URLs for more information, if that is something you would like to see tracked within MAEC. 

 

[Paul] – I’m in agreement with Terry wrt leveraging some of the things in STIX (InformationSourceType, common vocabularies …) but I do have a concern of circular dependencies being created.  I think there is likely a number of things in STIX that should actually be in a common place and leveraged by STIX and MAEC.  A common base type of some of this that then could be extended by STIX and/or MAEC would definitely be a step in the right direction and I think the common base type that is based on a lot of what is in STIX would be a good start.

 

  1. Does it make sense to have a multiplicity of 0-N (unbounded) for malware instance and malware family names, or should it be bounded to 1?
    [terry] - I woulsd suggest bounded to 1 if you add the Malware_Instance_Aliases and Malware_Family_Aliases (unbounded).
  2. Does it make sense to assign a relative measure of confidence to malware instance and malware family names? Accordingly, do the values in the ConfidenceMeasureEnummake sense?
    [terry] - I would like to align the ConfidenceMeasureEnum values with the values in the STIX confidence (High, Medium, Low, None, Unknown).

     [Ivan] Agreed – I’ll update the proposal to align the values with the ConfidenceMeasureEnum. In the future, it would be nice to be able to use MAEC/STIX/CybOX vocabularies interchangeably. Currently this isn’t possible (at least with respect to STIX <-> MAEC/CybOX) because their vocabularies extend from different base types.

 

[Terry] - I would like to see a lot of things shared across MAEC.STIX/CybOX - Information source, reference URL structures as well as default vocabs. There is a reasonable scope for that. Maybe thats worth bringing up on the OASIS CTI Subcommittees.

 

[Paul] – I second Terry’s suggested.  I think there are already a couple of these types of instance that are emerging with likely more as we move forward.

 

  1. Does it make sense to make this field name change in MAEC?
    [terry] - Yes it makes sense.
  2. Does the proposed name make sense? Are there preferable alternatives?
  1. [terry] - what about renaming it simply 'observables', or 'instance_observables'? This would align somewhat with STIX.

    [Ivan] That would be closer to STIX, but not completely accurate as the field only supports capturing a CybOX Object (cybox:ObjectType). Maybe “Instance_Object” then?

 

[Terry] - Instance_Object could work.

[Paul] I could agree with that

 

 

Proposal: Deprecate Use of QNames for Ids

  1. Should URIs be used instead of QNames in IDs?
    [terry] - I'm in two minds here. I really dislike QNames as they complicate the processing involved in generating and consuming the XML output of STIX, CYBOX and MAEC. But, I am equally concerned that MAEC will be deprecating the use of QNames in IDs, when there has been no public discussion about doing the same within STIX or CybOX. I would hate for producers and consumers of threat intelligence to be forced to support two different ways of generating IDs within a single library if it could be avoided.

    In other words - has this been discussed with the STIX/CybOX communities to see if they would be open to changing the IDs to use URIs? I think a LOT of people would, but ti would be great to check this out and confirm it before changing MAEC. It would be far better to have MAEC the first of the related protocols to migrate, rather than it be the only one doing this change.

    [Ivan] As Jon mentioned in his response, this has been an outstanding issue for a while in STIX and CybOX, but hasn’t been brought up for explicit discussion because it would not be a backwards compatible change. Accordingly, we chose to do this now in MAEC because we felt it would be a good time (being a major version) to incorporate any backwards-incompatible changes that would be useful. We should certainly check with the STIX/CybOX communities to see if this is something that they may be interested in doing down the road. Also, I definitely agree that having to support multiple ID formats would be painful for content producers (and consumers as well), especially when dealing with embedded MAEC in STIX TTPs. However, with regards to that last point, this won’t be a (potential) issue until STIX is updated to support the embedding of MAEC v5.0 (STIX 1.2.x will be limited to MAEC v4.1).

 

[Terry] - OK, didn't know that. In that case, URIs are better :). 

 

With all the changes being discussed on the STIX/TAXII lists at present regtarding v2.0 or both TAXII and STIX, I wouldn't be surprised if we end up moving away from XML based documents to another structured data format. I'm really pushing for a 'review all the things' mentality for STIX/TAXII, as the opportunities for a major release don't come about very often. It will be interesting to see what impact that will have on MAEC in the future.

 

[Paul] – I think we are an interesting point in time since both STIX and MAEC depend upon CybOX which faces the same issue.  Unless the 3 aren’t updated consistently at roughly the same time, users are going to be faced with understanding different formats.  URIs (be they URLs or URNs) will definitely be better. 

 

  1. Should VulnerabilityExploitType align as closely as possible with the STIXVulnerabilityType or is it better to take a more flexible approach by defining a new MAEC VulnerabilityReferenceType?
    [terry] - They must align in my opinion. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. There is a lot of benefit to be had by ensuring that consumers can find linkages between vulnerable systems, and malware that exploits those vulnerabilities. For this to happen it is imperative that STIX and MAEC align their descriptions, such that one can make a connection.

    I would posit that as the STIX ExploitTarget is designed to describe vulnerable systems that the STIXVulnerabilityType should be considered the 'standard' for vulnerability description, and that as MAEC is designed to describe malware and the exploits they contain that the MAEC Exploit descriptions should be considered the 'standard' for exploit description, and that they should leverage each others work.

   [Ivan] I definitely agree with your characterization of the purpose of MAEC’s VulnerabilityExploitType and the ExploitTarget from STIX. The main reason that we decided not to completely mirror the fields in the STIX VulnerabilityType is that, currently, the STIX VulnerabilityType is inflexible when it comes to vulnerability references, supporting only CVE and OSVDB. Therefore, there is some expectation that the STIX VulnerabilityType will be updated to accommodate other references (e.g., CWE for the underlying software flaw of the vulnerability). As such, given that STIX functions as the ‘standard’ for vulnerability description (which we 100% agree with), perhaps we should postpone this change and wait for the STIX VulnerabilityType to be updated?

 

[Terry] - It depends if there is urgent need for this at present. We can always make this change and feed back the need for alignment to the CTI STIX Sub-Committee. It all depends if the MAEC Community can wait.

 

[Paul] – I agree with Ivan in that the STIX VulnerabilityType is too restrictive.  If any one looks at the XML schema for CVE or CWE, you’ll see indications that the authors were considering a single VulnerabilityType that could be used to expresses vulnerabilities, weaknesses, and configuration issues.  I would suggest if we look to defining a new VulnerabilityType that it take into consideration that work as well as the unique requirements of STIX and MAEC.  Perhaps this is another instance of where there is a common type that isn’t defined by STIX or MAEC but rather is leveraged/extended by them.  I would also suggest that a closer look be taken as to whether a new vulnerability type should be extended with something like CVE/OSVDB/CWE/CCE (all of which are expressed in XML schemas ONLY) or just reference these external entities.  Part of my thinking is I don’t suspect most producers will likely populate all the fields defined by the extension, but would rather just provide a reference to them, and second these types of extensions result in duplication of data.

 

 

 

Reply | Threaded
Open this post in threaded view
|

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

Kirillov, Ivan A.
Paul, Terry, great discussion. Replies inline below.

Regards,
Ivan

From: Paul Patrick <[hidden email]>
Reply-To: Paul Patrick <[hidden email]>
Date: Thursday, July 16, 2015 at 5:29 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

 

From: Terry MacDonald [[hidden email]]
Sent: Wednesday, July 15, 2015 4:36 PM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Hi Ivan,

 

Replies inline, with the unnecessary sections removed.

Cheers


Terry MacDonald | STIX, TAXII, CybOX Consultant

 

M: +61-407-203-026

 

 

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

  1. Do the defined types, their child properties, their datatypes, and their annotations makes sense? Should they be changed in any way?
    [terry] - My concern by lumping the various names that the malware is known as together into a pair of single fields is that we potentially lose sight of what the malware sample is called by the MAEC producer. I wonder if it is better to separate the aliases out into their own field. i.e. keep the Malware_Instance_Name and Malware_Family_Name (limited to 0-1), but also add Malware_Instance_Aliases and Malware_Family_Aliases (limited 0-N). In this way people can easily discern what the producer calls the malware, and they can also see what others call the malware sample. It allows for others to release details of similar malware under their own family names, and a relationship to still be discerned through the alias fields.

     [Ivan] That’s a good point – with the current approach, it’s unclear where the malware instance/family names (as captured in a MAEC instance document) came from. Capturing aliases as a separate field may be a viable solution, but I’m     

wondering if it might be simpler and more direct to just capture the source using a separate field (probably an @source attribute) for each Malware_Instance_Name and Malware_Family_Name. That way, the producer of the MAEC document can 

specify whether the name came from their own organization (e.g., @source=“MITRE” for me) or somewhere else. It might also be useful to capture a reference URL that goes along with the source (if availble), e.g., for publicly available malware analysis reports where the name may be referenced. What do you think?

 

[Terry] - I'm not so sold on the capturing all family names in a single place. Realistically a producer is not going to know which names came from which other vendors, as some may be produced by 3rd parties, and they may only hear of them second hand. The producer is only going to know a subset of that information. I do think that recording the name of what the producer calls the malware instance is important, and recording the information source is important, but that the alias information is useful, but not important. Ultimately I think a list of alias names should be separate from the malware names, and that it doesn't need a source tag. I also think that what the producer calls the malware instance is important, and that the source of the name could be important for Incident Responders who would like more information on the data.

 

[Paul] – I might suggest that rather than have 2 lists, that you might have a new MalwareAlias type that contains a single member for both name and family.  I would agree that the producer of the MAEC would likely have its own name and that is important.  But I would argue that the alias information is important.  Without alias, it becomes difficult that something reported by one producer can be correlated with another.  For example, image the same malware instance is submitted to multiple online sandboxes that produce results in MAEC format.  It likely that both sandboxes will assign their own unique name but may also be able to relate the instance to a given name and/or corresponding family.  Without the aliases, it’s very difficult to correlate across them.


[Ivan] Good point by Terry in that producers are unlikely to always know which names came from which vendors, so having the ability to identify a name as an alias would still be necessary. Paul, I think your point about having the ability to correlate multiple malware instance/family names is also well taken. It sounds like what Paul is suggesting is keeping the Malware_Instance_Name and Malware_Family_Name and then having an additional field (maybe something like Malware_Alias?) that can capture both instance and family aliases via a new MalwareAlias type. This seems sound to me, though it would probably also be useful to capture the source of the alias, if known; Im still on the side of having a simple @source field to keep things basic and lightweight, and also because we currently can’t use the STIX InformationSourceType – see comments below. What do you guys think?

 

I personally think you should leverage the InformationSourceType available in STIX if you want to tack the source, as that is comprehensive, and a good way of providing whatever level of flexibility the producer wants. It also contains the References section, which could be useful for tracking URLs for more information, if that is something you would like to see tracked within MAEC. 

 

[Paul] – I’m in agreement with Terry wrt leveraging some of the things in STIX (InformationSourceType, common vocabularies …) but I do have a concern of circular dependencies being created.  I think there is likely a number of things in STIX that should actually be in a common place and leveraged by STIX and MAEC.  A common base type of some of this that then could be extended by STIX and/or MAEC would definitely be a step in the right direction and I think the common base type that is based on a lot of what is in STIX would be a good start.


[Ivan] Yes, the primary reason that we don’t already import any STIX constructs is because of circular dependencies. Also, from a semantic perspective, it would be quite odd for MAEC to import STIX, given that STIX really sits at a much higher level of abstraction. I completely agree with Paul that we really need a common base “layer” where we can define common concepts like InformationSourceType, ConfidenceMeasureEnum, etc. I personally plan on bringing this up as part of the STIX/CybOX discussion in the OASIS CTI. For now though, we’ll have to make due with either duplicating types or creating divergent implementations. 

 

  1. Does it make sense to have a multiplicity of 0-N (unbounded) for malware instance and malware family names, or should it be bounded to 1?
    [terry] - I woulsd suggest bounded to 1 if you add the Malware_Instance_Aliases and Malware_Family_Aliases (unbounded).
  2. Does it make sense to assign a relative measure of confidence to malware instance and malware family names? Accordingly, do the values in the ConfidenceMeasureEnummake sense?
    [terry] - I would like to align the ConfidenceMeasureEnum values with the values in the STIX confidence (High, Medium, Low, None, Unknown).

     [Ivan] Agreed – I’ll update the proposal to align the values with the ConfidenceMeasureEnum. In the future, it would be nice to be able to use MAEC/STIX/CybOX vocabularies interchangeably. Currently this isn’t possible (at least with respect to STIX <-> MAEC/CybOX) because their vocabularies extend from different base types.

 

[Terry] - I would like to see a lot of things shared across MAEC.STIX/CybOX - Information source, reference URL structures as well as default vocabs. There is a reasonable scope for that. Maybe thats worth bringing up on the OASIS CTI Subcommittees.

 

[Paul] – I second Terry’s suggested.  I think there are already a couple of these types of instance that are emerging with likely more as we move forward.

 

  1. Does it make sense to make this field name change in MAEC?
    [terry] - Yes it makes sense.
  2. Does the proposed name make sense? Are there preferable alternatives?
  1. [terry] - what about renaming it simply 'observables', or 'instance_observables'? This would align somewhat with STIX.

    [Ivan] That would be closer to STIX, but not completely accurate as the field only supports capturing a CybOX Object (cybox:ObjectType). Maybe “Instance_Object” then?

 

[Terry] - Instance_Object could work.

[Paul] I could agree with that

[Ivan] Sounds good. Let’s go with “Instance_Object” then :)

 

Proposal: Deprecate Use of QNames for Ids

  1. Should URIs be used instead of QNames in IDs?
    [terry] - I'm in two minds here. I really dislike QNames as they complicate the processing involved in generating and consuming the XML output of STIX, CYBOX and MAEC. But, I am equally concerned that MAEC will be deprecating the use of QNames in IDs, when there has been no public discussion about doing the same within STIX or CybOX. I would hate for producers and consumers of threat intelligence to be forced to support two different ways of generating IDs within a single library if it could be avoided.

    In other words - has this been discussed with the STIX/CybOX communities to see if they would be open to changing the IDs to use URIs? I think a LOT of people would, but ti would be great to check this out and confirm it before changing MAEC. It would be far better to have MAEC the first of the related protocols to migrate, rather than it be the only one doing this change.

    [Ivan] As Jon mentioned in his response, this has been an outstanding issue for a while in STIX and CybOX, but hasn’t been brought up for explicit discussion because it would not be a backwards compatible change. Accordingly, we chose to do this now in MAEC because we felt it would be a good time (being a major version) to incorporate any backwards-incompatible changes that would be useful. We should certainly check with the STIX/CybOX communities to see if this is something that they may be interested in doing down the road. Also, I definitely agree that having to support multiple ID formats would be painful for content producers (and consumers as well), especially when dealing with embedded MAEC in STIX TTPs. However, with regards to that last point, this won’t be a (potential) issue until STIX is updated to support the embedding of MAEC v5.0 (STIX 1.2.x will be limited to MAEC v4.1).

 

[Terry] - OK, didn't know that. In that case, URIs are better :). 

 

With all the changes being discussed on the STIX/TAXII lists at present regtarding v2.0 or both TAXII and STIX, I wouldn't be surprised if we end up moving away from XML based documents to another structured data format. I'm really pushing for a 'review all the things' mentality for STIX/TAXII, as the opportunities for a major release don't come about very often. It will be interesting to see what impact that will have on MAEC in the future.

 

[Paul] – I think we are an interesting point in time since both STIX and MAEC depend upon CybOX which faces the same issue.  Unless the 3 aren’t updated consistently at roughly the same time, users are going to be faced with understanding different formats.  URIs (be they URLs or URNs) will definitely be better. 


[Ivan] Yup. I think we have two options in this regard: make the change now, and assume that STIX and CybOX will follow (which I’d personally say is likely), or wait until STIX and CybOX change and then follow suite. The problem with the former is that it’s not guaranteed that STIX and CybOX will make the same change, and even if they do, it will take a new major version which is probably a year away, at least. The problem with the latter is that it will require a new major version of MAEC, which is one of the reasons that I was leaning towards making the change now. However, given the fact that dealing with multiple ID syntaxes certainly seems painful (and will be a reality in MAEC v5.0 with this change, given that CybOX will still use QNames), perhaps we should table this change until a later date, to make life easier for both consumers and producers.

 

  1. Should VulnerabilityExploitType align as closely as possible with the STIXVulnerabilityType or is it better to take a more flexible approach by defining a new MAEC VulnerabilityReferenceType?
    [terry] - They must align in my opinion. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. There is a lot of benefit to be had by ensuring that consumers can find linkages between vulnerable systems, and malware that exploits those vulnerabilities. For this to happen it is imperative that STIX and MAEC align their descriptions, such that one can make a connection.

    I would posit that as the STIX ExploitTarget is designed to describe vulnerable systems that the STIXVulnerabilityType should be considered the 'standard' for vulnerability description, and that as MAEC is designed to describe malware and the exploits they contain that the MAEC Exploit descriptions should be considered the 'standard' for exploit description, and that they should leverage each others work.

   [Ivan] I definitely agree with your characterization of the purpose of MAEC’s VulnerabilityExploitType and the ExploitTarget from STIX. The main reason that we decided not to completely mirror the fields in the STIX VulnerabilityType is that, currently, the STIX VulnerabilityType is inflexible when it comes to vulnerability references, supporting only CVE and OSVDB. Therefore, there is some expectation that the STIX VulnerabilityType will be updated to accommodate other references (e.g., CWE for the underlying software flaw of the vulnerability). As such, given that STIX functions as the ‘standard’ for vulnerability description (which we 100% agree with), perhaps we should postpone this change and wait for the STIX VulnerabilityType to be updated?

 

[Terry] - It depends if there is urgent need for this at present. We can always make this change and feed back the need for alignment to the CTI STIX Sub-Committee. It all depends if the MAEC Community can wait.

 

[Paul] – I agree with Ivan in that the STIX VulnerabilityType is too restrictive.  If any one looks at the XML schema for CVE or CWE, you’ll see indications that the authors were considering a single VulnerabilityType that could be used to expresses vulnerabilities, weaknesses, and configuration issues.  I would suggest if we look to defining a new VulnerabilityType that it take into consideration that work as well as the unique requirements of STIX and MAEC.  Perhaps this is another instance of where there is a common type that isn’t defined by STIX or MAEC but rather is leveraged/extended by them.  I would also suggest that a closer look be taken as to whether a new vulnerability type should be extended with something like CVE/OSVDB/CWE/CCE (all of which are expressed in XML schemas ONLY) or just reference these external entities.  Part of my thinking is I don’t suspect most producers will likely populate all the fields defined by the extension, but would rather just provide a reference to them, and second these types of extensions result in duplication of data.


[Ivan] I don’t think there’s an urgent need for this change (the existing type can capture CVEs, which is the predominant identifier), rather it has been a longstanding issue on our end that we felt was useful to address in a major release. Paul, I agree that this is probably another place where having a common base layer would make sense. I too think that having extensions for the schemas from CVE/OSVDB/CWE/etc. would be overkill for this scenario, so having a fairly expressive VulnerabilityType would probably be the way to go.

 

 

 

Reply | Threaded
Open this post in threaded view
|

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

Kirillov, Ivan A.
I’ve modified the proposal for capturing malware instance/family names, per Terry and Paul’s feedback. Let me know what you think.

Regards,
Ivan

From: <Kirillov>, Ivan Kirillov <[hidden email]>
Reply-To: Ivan Kirillov <[hidden email]>
Date: Friday, July 17, 2015 at 9:43 AM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

Paul, Terry, great discussion. Replies inline below.

Regards,
Ivan

From: Paul Patrick <[hidden email]>
Reply-To: Paul Patrick <[hidden email]>
Date: Thursday, July 16, 2015 at 5:29 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

 

From: Terry MacDonald [[hidden email]]
Sent: Wednesday, July 15, 2015 4:36 PM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Hi Ivan,

 

Replies inline, with the unnecessary sections removed.

Cheers


Terry MacDonald | STIX, TAXII, CybOX Consultant

 

M: +61-407-203-026

 

 

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

  1. Do the defined types, their child properties, their datatypes, and their annotations makes sense? Should they be changed in any way?
    [terry] - My concern by lumping the various names that the malware is known as together into a pair of single fields is that we potentially lose sight of what the malware sample is called by the MAEC producer. I wonder if it is better to separate the aliases out into their own field. i.e. keep the Malware_Instance_Name and Malware_Family_Name (limited to 0-1), but also add Malware_Instance_Aliases and Malware_Family_Aliases (limited 0-N). In this way people can easily discern what the producer calls the malware, and they can also see what others call the malware sample. It allows for others to release details of similar malware under their own family names, and a relationship to still be discerned through the alias fields.

     [Ivan] That’s a good point – with the current approach, it’s unclear where the malware instance/family names (as captured in a MAEC instance document) came from. Capturing aliases as a separate field may be a viable solution, but I’m     

wondering if it might be simpler and more direct to just capture the source using a separate field (probably an @source attribute) for each Malware_Instance_Name and Malware_Family_Name. That way, the producer of the MAEC document can 

specify whether the name came from their own organization (e.g., @source=“MITRE” for me) or somewhere else. It might also be useful to capture a reference URL that goes along with the source (if availble), e.g., for publicly available malware analysis reports where the name may be referenced. What do you think?

 

[Terry] - I'm not so sold on the capturing all family names in a single place. Realistically a producer is not going to know which names came from which other vendors, as some may be produced by 3rd parties, and they may only hear of them second hand. The producer is only going to know a subset of that information. I do think that recording the name of what the producer calls the malware instance is important, and recording the information source is important, but that the alias information is useful, but not important. Ultimately I think a list of alias names should be separate from the malware names, and that it doesn't need a source tag. I also think that what the producer calls the malware instance is important, and that the source of the name could be important for Incident Responders who would like more information on the data.

 

[Paul] – I might suggest that rather than have 2 lists, that you might have a new MalwareAlias type that contains a single member for both name and family.  I would agree that the producer of the MAEC would likely have its own name and that is important.  But I would argue that the alias information is important.  Without alias, it becomes difficult that something reported by one producer can be correlated with another.  For example, image the same malware instance is submitted to multiple online sandboxes that produce results in MAEC format.  It likely that both sandboxes will assign their own unique name but may also be able to relate the instance to a given name and/or corresponding family.  Without the aliases, it’s very difficult to correlate across them.


[Ivan] Good point by Terry in that producers are unlikely to always know which names came from which vendors, so having the ability to identify a name as an alias would still be necessary. Paul, I think your point about having the ability to correlate multiple malware instance/family names is also well taken. It sounds like what Paul is suggesting is keeping the Malware_Instance_Name and Malware_Family_Name and then having an additional field (maybe something like Malware_Alias?) that can capture both instance and family aliases via a new MalwareAlias type. This seems sound to me, though it would probably also be useful to capture the source of the alias, if known; Im still on the side of having a simple @source field to keep things basic and lightweight, and also because we currently can’t use the STIX InformationSourceType – see comments below. What do you guys think?

 

I personally think you should leverage the InformationSourceType available in STIX if you want to tack the source, as that is comprehensive, and a good way of providing whatever level of flexibility the producer wants. It also contains the References section, which could be useful for tracking URLs for more information, if that is something you would like to see tracked within MAEC. 

 

[Paul] – I’m in agreement with Terry wrt leveraging some of the things in STIX (InformationSourceType, common vocabularies …) but I do have a concern of circular dependencies being created.  I think there is likely a number of things in STIX that should actually be in a common place and leveraged by STIX and MAEC.  A common base type of some of this that then could be extended by STIX and/or MAEC would definitely be a step in the right direction and I think the common base type that is based on a lot of what is in STIX would be a good start.


[Ivan] Yes, the primary reason that we don’t already import any STIX constructs is because of circular dependencies. Also, from a semantic perspective, it would be quite odd for MAEC to import STIX, given that STIX really sits at a much higher level of abstraction. I completely agree with Paul that we really need a common base “layer” where we can define common concepts like InformationSourceType, ConfidenceMeasureEnum, etc. I personally plan on bringing this up as part of the STIX/CybOX discussion in the OASIS CTI. For now though, we’ll have to make due with either duplicating types or creating divergent implementations. 

 

  1. Does it make sense to have a multiplicity of 0-N (unbounded) for malware instance and malware family names, or should it be bounded to 1?
    [terry] - I woulsd suggest bounded to 1 if you add the Malware_Instance_Aliases and Malware_Family_Aliases (unbounded).
  2. Does it make sense to assign a relative measure of confidence to malware instance and malware family names? Accordingly, do the values in the ConfidenceMeasureEnummake sense?
    [terry] - I would like to align the ConfidenceMeasureEnum values with the values in the STIX confidence (High, Medium, Low, None, Unknown).

     [Ivan] Agreed – I’ll update the proposal to align the values with the ConfidenceMeasureEnum. In the future, it would be nice to be able to use MAEC/STIX/CybOX vocabularies interchangeably. Currently this isn’t possible (at least with respect to STIX <-> MAEC/CybOX) because their vocabularies extend from different base types.

 

[Terry] - I would like to see a lot of things shared across MAEC.STIX/CybOX - Information source, reference URL structures as well as default vocabs. There is a reasonable scope for that. Maybe thats worth bringing up on the OASIS CTI Subcommittees.

 

[Paul] – I second Terry’s suggested.  I think there are already a couple of these types of instance that are emerging with likely more as we move forward.

 

  1. Does it make sense to make this field name change in MAEC?
    [terry] - Yes it makes sense.
  2. Does the proposed name make sense? Are there preferable alternatives?
  1. [terry] - what about renaming it simply 'observables', or 'instance_observables'? This would align somewhat with STIX.

    [Ivan] That would be closer to STIX, but not completely accurate as the field only supports capturing a CybOX Object (cybox:ObjectType). Maybe “Instance_Object” then?

 

[Terry] - Instance_Object could work.

[Paul] I could agree with that

[Ivan] Sounds good. Let’s go with “Instance_Object” then :)

 

Proposal: Deprecate Use of QNames for Ids

  1. Should URIs be used instead of QNames in IDs?
    [terry] - I'm in two minds here. I really dislike QNames as they complicate the processing involved in generating and consuming the XML output of STIX, CYBOX and MAEC. But, I am equally concerned that MAEC will be deprecating the use of QNames in IDs, when there has been no public discussion about doing the same within STIX or CybOX. I would hate for producers and consumers of threat intelligence to be forced to support two different ways of generating IDs within a single library if it could be avoided.

    In other words - has this been discussed with the STIX/CybOX communities to see if they would be open to changing the IDs to use URIs? I think a LOT of people would, but ti would be great to check this out and confirm it before changing MAEC. It would be far better to have MAEC the first of the related protocols to migrate, rather than it be the only one doing this change.

    [Ivan] As Jon mentioned in his response, this has been an outstanding issue for a while in STIX and CybOX, but hasn’t been brought up for explicit discussion because it would not be a backwards compatible change. Accordingly, we chose to do this now in MAEC because we felt it would be a good time (being a major version) to incorporate any backwards-incompatible changes that would be useful. We should certainly check with the STIX/CybOX communities to see if this is something that they may be interested in doing down the road. Also, I definitely agree that having to support multiple ID formats would be painful for content producers (and consumers as well), especially when dealing with embedded MAEC in STIX TTPs. However, with regards to that last point, this won’t be a (potential) issue until STIX is updated to support the embedding of MAEC v5.0 (STIX 1.2.x will be limited to MAEC v4.1).

 

[Terry] - OK, didn't know that. In that case, URIs are better :). 

 

With all the changes being discussed on the STIX/TAXII lists at present regtarding v2.0 or both TAXII and STIX, I wouldn't be surprised if we end up moving away from XML based documents to another structured data format. I'm really pushing for a 'review all the things' mentality for STIX/TAXII, as the opportunities for a major release don't come about very often. It will be interesting to see what impact that will have on MAEC in the future.

 

[Paul] – I think we are an interesting point in time since both STIX and MAEC depend upon CybOX which faces the same issue.  Unless the 3 aren’t updated consistently at roughly the same time, users are going to be faced with understanding different formats.  URIs (be they URLs or URNs) will definitely be better. 


[Ivan] Yup. I think we have two options in this regard: make the change now, and assume that STIX and CybOX will follow (which I’d personally say is likely), or wait until STIX and CybOX change and then follow suite. The problem with the former is that it’s not guaranteed that STIX and CybOX will make the same change, and even if they do, it will take a new major version which is probably a year away, at least. The problem with the latter is that it will require a new major version of MAEC, which is one of the reasons that I was leaning towards making the change now. However, given the fact that dealing with multiple ID syntaxes certainly seems painful (and will be a reality in MAEC v5.0 with this change, given that CybOX will still use QNames), perhaps we should table this change until a later date, to make life easier for both consumers and producers.

 

  1. Should VulnerabilityExploitType align as closely as possible with the STIXVulnerabilityType or is it better to take a more flexible approach by defining a new MAEC VulnerabilityReferenceType?
    [terry] - They must align in my opinion. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. There is a lot of benefit to be had by ensuring that consumers can find linkages between vulnerable systems, and malware that exploits those vulnerabilities. For this to happen it is imperative that STIX and MAEC align their descriptions, such that one can make a connection.

    I would posit that as the STIX ExploitTarget is designed to describe vulnerable systems that the STIXVulnerabilityType should be considered the 'standard' for vulnerability description, and that as MAEC is designed to describe malware and the exploits they contain that the MAEC Exploit descriptions should be considered the 'standard' for exploit description, and that they should leverage each others work.

   [Ivan] I definitely agree with your characterization of the purpose of MAEC’s VulnerabilityExploitType and the ExploitTarget from STIX. The main reason that we decided not to completely mirror the fields in the STIX VulnerabilityType is that, currently, the STIX VulnerabilityType is inflexible when it comes to vulnerability references, supporting only CVE and OSVDB. Therefore, there is some expectation that the STIX VulnerabilityType will be updated to accommodate other references (e.g., CWE for the underlying software flaw of the vulnerability). As such, given that STIX functions as the ‘standard’ for vulnerability description (which we 100% agree with), perhaps we should postpone this change and wait for the STIX VulnerabilityType to be updated?

 

[Terry] - It depends if there is urgent need for this at present. We can always make this change and feed back the need for alignment to the CTI STIX Sub-Committee. It all depends if the MAEC Community can wait.

 

[Paul] – I agree with Ivan in that the STIX VulnerabilityType is too restrictive.  If any one looks at the XML schema for CVE or CWE, you’ll see indications that the authors were considering a single VulnerabilityType that could be used to expresses vulnerabilities, weaknesses, and configuration issues.  I would suggest if we look to defining a new VulnerabilityType that it take into consideration that work as well as the unique requirements of STIX and MAEC.  Perhaps this is another instance of where there is a common type that isn’t defined by STIX or MAEC but rather is leveraged/extended by them.  I would also suggest that a closer look be taken as to whether a new vulnerability type should be extended with something like CVE/OSVDB/CWE/CCE (all of which are expressed in XML schemas ONLY) or just reference these external entities.  Part of my thinking is I don’t suspect most producers will likely populate all the fields defined by the extension, but would rather just provide a reference to them, and second these types of extensions result in duplication of data.


[Ivan] I don’t think there’s an urgent need for this change (the existing type can capture CVEs, which is the predominant identifier), rather it has been a longstanding issue on our end that we felt was useful to address in a major release. Paul, I agree that this is probably another place where having a common base layer would make sense. I too think that having extensions for the schemas from CVE/OSVDB/CWE/etc. would be overkill for this scenario, so having a fairly expressive VulnerabilityType would probably be the way to go.

 

 

 

Reply | Threaded
Open this post in threaded view
|

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

Paul Patrick

Ivan,

 

I think the revised proposal is much better, but got a couple more questions:

 

[1] I see we a means to specify a source for the alias but we don’t have a means to capture the source for the malware instance/family.  Perhaps we should add support for that

 

[2] I wondering if people see the Malware_Instance_Name and the Malware_Family_Name coupled where there is an implied relationship between the instance name and the family name to which is belongs.  If so, perhaps it would be better to have them together as a single type instead of independent fields.  This has the additional advantage that the source could then be a third member of that type.

 

 

Paul Patrick

 

 

 

 

From: Kirillov, Ivan A. [mailto:[hidden email]]
Sent: Tuesday, July 21, 2015 6:45 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

I’ve modified the proposal for capturing malware instance/family names, per Terry and Paul’s feedback. Let me know what you think.

 

Regards,

Ivan

 

From: <Kirillov>, Ivan Kirillov <[hidden email]>
Reply-To: Ivan Kirillov <[hidden email]>
Date: Friday, July 17, 2015 at 9:43 AM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Paul, Terry, great discussion. Replies inline below.

 

Regards,

Ivan

 

From: Paul Patrick <[hidden email]>
Reply-To: Paul Patrick <[hidden email]>
Date: Thursday, July 16, 2015 at 5:29 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

 

 

From: Terry MacDonald [[hidden email]]
Sent: Wednesday, July 15, 2015 4:36 PM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Hi Ivan,

 

Replies inline, with the unnecessary sections removed.

Cheers


Terry MacDonald | STIX, TAXII, CybOX Consultant

 

M: +61-407-203-026

 

 

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

  1. Do the defined types, their child properties, their datatypes, and their annotations makes sense? Should they be changed in any way?
    [terry] - My concern by lumping the various names that the malware is known as together into a pair of single fields is that we potentially lose sight of what the malware sample is called by the MAEC producer. I wonder if it is better to separate the aliases out into their own field. i.e. keep the Malware_Instance_Name and Malware_Family_Name (limited to 0-1), but also add Malware_Instance_Aliases and Malware_Family_Aliases (limited 0-N). In this way people can easily discern what the producer calls the malware, and they can also see what others call the malware sample. It allows for others to release details of similar malware under their own family names, and a relationship to still be discerned through the alias fields.

     [Ivan] That’s a good point – with the current approach, it’s unclear where the malware instance/family names (as captured in a MAEC instance document) came from. Capturing aliases as a separate field may be a viable solution, but I’m     

wondering if it might be simpler and more direct to just capture the source using a separate field (probably an @source attribute) for each Malware_Instance_Name and Malware_Family_Name. That way, the producer of the MAEC document can 

specify whether the name came from their own organization (e.g., @source=“MITRE” for me) or somewhere else. It might also be useful to capture a reference URL that goes along with the source (if availble), e.g., for publicly available malware analysis reports where the name may be referenced. What do you think?

 

[Terry] - I'm not so sold on the capturing all family names in a single place. Realistically a producer is not going to know which names came from which other vendors, as some may be produced by 3rd parties, and they may only hear of them second hand. The producer is only going to know a subset of that information. I do think that recording the name of what the producer calls the malware instance is important, and recording the information source is important, but that the alias information is useful, but not important. Ultimately I think a list of alias names should be separate from the malware names, and that it doesn't need a source tag. I also think that what the producer calls the malware instance is important, and that the source of the name could be important for Incident Responders who would like more information on the data.

 

[Paul] – I might suggest that rather than have 2 lists, that you might have a new MalwareAlias type that contains a single member for both name and family.  I would agree that the producer of the MAEC would likely have its own name and that is important.  But I would argue that the alias information is important.  Without alias, it becomes difficult that something reported by one producer can be correlated with another.  For example, image the same malware instance is submitted to multiple online sandboxes that produce results in MAEC format.  It likely that both sandboxes will assign their own unique name but may also be able to relate the instance to a given name and/or corresponding family.  Without the aliases, it’s very difficult to correlate across them.

 

[Ivan] Good point by Terry in that producers are unlikely to always know which names came from which vendors, so having the ability to identify a name as an alias would still be necessary. Paul, I think your point about having the ability to correlate multiple malware instance/family names is also well taken. It sounds like what Paul is suggesting is keeping the Malware_Instance_Name and Malware_Family_Name and then having an additional field (maybe something like Malware_Alias?) that can capture both instance and family aliases via a new MalwareAlias type. This seems sound to me, though it would probably also be useful to capture the source of the alias, if known; I’m still on the side of having a simple @source field to keep things basic and lightweight, and also because we currently can’t use the STIX InformationSourceType – see comments below. What do you guys think?

 

I personally think you should leverage the InformationSourceType available in STIX if you want to tack the source, as that is comprehensive, and a good way of providing whatever level of flexibility the producer wants. It also contains the References section, which could be useful for tracking URLs for more information, if that is something you would like to see tracked within MAEC. 

 

[Paul] – I’m in agreement with Terry wrt leveraging some of the things in STIX (InformationSourceType, common vocabularies …) but I do have a concern of circular dependencies being created.  I think there is likely a number of things in STIX that should actually be in a common place and leveraged by STIX and MAEC.  A common base type of some of this that then could be extended by STIX and/or MAEC would definitely be a step in the right direction and I think the common base type that is based on a lot of what is in STIX would be a good start.

 

[Ivan] Yes, the primary reason that we don’t already import any STIX constructs is because of circular dependencies. Also, from a semantic perspective, it would be quite odd for MAEC to import STIX, given that STIX really sits at a much higher level of abstraction. I completely agree with Paul that we really need a common base “layer” where we can define common concepts like InformationSourceType, ConfidenceMeasureEnum, etc. I personally plan on bringing this up as part of the STIX/CybOX discussion in the OASIS CTI. For now though, we’ll have to make due with either duplicating types or creating divergent implementations. 

 

  1. Does it make sense to have a multiplicity of 0-N (unbounded) for malware instance and malware family names, or should it be bounded to 1?
    [terry] - I woulsd suggest bounded to 1 if you add the Malware_Instance_Aliases and Malware_Family_Aliases (unbounded).
  2. Does it make sense to assign a relative measure of confidence to malware instance and malware family names? Accordingly, do the values in the ConfidenceMeasureEnummake sense?
    [terry] - I would like to align the ConfidenceMeasureEnum values with the values in the STIX confidence (High, Medium, Low, None, Unknown).

     [Ivan] Agreed – I’ll update the proposal to align the values with the ConfidenceMeasureEnum. In the future, it would be nice to be able to use MAEC/STIX/CybOX vocabularies interchangeably. Currently this isn’t possible (at least with respect to STIX <-> MAEC/CybOX) because their vocabularies extend from different base types.

 

[Terry] - I would like to see a lot of things shared across MAEC.STIX/CybOX - Information source, reference URL structures as well as default vocabs. There is a reasonable scope for that. Maybe thats worth bringing up on the OASIS CTI Subcommittees.

 

[Paul] – I second Terry’s suggested.  I think there are already a couple of these types of instance that are emerging with likely more as we move forward.

 

  1. Does it make sense to make this field name change in MAEC?
    [terry] - Yes it makes sense.
  2. Does the proposed name make sense? Are there preferable alternatives?
  1. [terry] - what about renaming it simply 'observables', or 'instance_observables'? This would align somewhat with STIX.

    [Ivan] That would be closer to STIX, but not completely accurate as the field only supports capturing a CybOX Object (cybox:ObjectType). Maybe “Instance_Object” then?

 

[Terry] - Instance_Object could work.

[Paul] I could agree with that

[Ivan] Sounds good. Let’s go with “Instance_Object” then :)

 

Proposal: Deprecate Use of QNames for Ids

  1. Should URIs be used instead of QNames in IDs?
    [terry] - I'm in two minds here. I really dislike QNames as they complicate the processing involved in generating and consuming the XML output of STIX, CYBOX and MAEC. But, I am equally concerned that MAEC will be deprecating the use of QNames in IDs, when there has been no public discussion about doing the same within STIX or CybOX. I would hate for producers and consumers of threat intelligence to be forced to support two different ways of generating IDs within a single library if it could be avoided.

    In other words - has this been discussed with the STIX/CybOX communities to see if they would be open to changing the IDs to use URIs? I think a LOT of people would, but ti would be great to check this out and confirm it before changing MAEC. It would be far better to have MAEC the first of the related protocols to migrate, rather than it be the only one doing this change.

    [Ivan] As Jon mentioned in his response, this has been an outstanding issue for a while in STIX and CybOX, but hasn’t been brought up for explicit discussion because it would not be a backwards compatible change. Accordingly, we chose to do this now in MAEC because we felt it would be a good time (being a major version) to incorporate any backwards-incompatible changes that would be useful. We should certainly check with the STIX/CybOX communities to see if this is something that they may be interested in doing down the road. Also, I definitely agree that having to support multiple ID formats would be painful for content producers (and consumers as well), especially when dealing with embedded MAEC in STIX TTPs. However, with regards to that last point, this won’t be a (potential) issue until STIX is updated to support the embedding of MAEC v5.0 (STIX 1.2.x will be limited to MAEC v4.1).

 

[Terry] - OK, didn't know that. In that case, URIs are better :). 

 

With all the changes being discussed on the STIX/TAXII lists at present regtarding v2.0 or both TAXII and STIX, I wouldn't be surprised if we end up moving away from XML based documents to another structured data format. I'm really pushing for a 'review all the things' mentality for STIX/TAXII, as the opportunities for a major release don't come about very often. It will be interesting to see what impact that will have on MAEC in the future.

 

[Paul] – I think we are an interesting point in time since both STIX and MAEC depend upon CybOX which faces the same issue.  Unless the 3 aren’t updated consistently at roughly the same time, users are going to be faced with understanding different formats.  URIs (be they URLs or URNs) will definitely be better. 

 

[Ivan] Yup. I think we have two options in this regard: make the change now, and assume that STIX and CybOX will follow (which I’d personally say is likely), or wait until STIX and CybOX change and then follow suite. The problem with the former is that it’s not guaranteed that STIX and CybOX will make the same change, and even if they do, it will take a new major version which is probably a year away, at least. The problem with the latter is that it will require a new major version of MAEC, which is one of the reasons that I was leaning towards making the change now. However, given the fact that dealing with multiple ID syntaxes certainly seems painful (and will be a reality in MAEC v5.0 with this change, given that CybOX will still use QNames), perhaps we should table this change until a later date, to make life easier for both consumers and producers.

 

  1. Should VulnerabilityExploitType align as closely as possible with the STIXVulnerabilityType or is it better to take a more flexible approach by defining a new MAEC VulnerabilityReferenceType?
    [terry] - They must align in my opinion. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. There is a lot of benefit to be had by ensuring that consumers can find linkages between vulnerable systems, and malware that exploits those vulnerabilities. For this to happen it is imperative that STIX and MAEC align their descriptions, such that one can make a connection.

    I would posit that as the STIX ExploitTarget is designed to describe vulnerable systems that the STIXVulnerabilityType should be considered the 'standard' for vulnerability description, and that as MAEC is designed to describe malware and the exploits they contain that the MAEC Exploit descriptions should be considered the 'standard' for exploit description, and that they should leverage each others work.

   [Ivan] I definitely agree with your characterization of the purpose of MAEC’s VulnerabilityExploitType and the ExploitTarget from STIX. The main reason that we decided not to completely mirror the fields in the STIX VulnerabilityType is that, currently, the STIX VulnerabilityType is inflexible when it comes to vulnerability references, supporting only CVE and OSVDB. Therefore, there is some expectation that the STIX VulnerabilityType will be updated to accommodate other references (e.g., CWE for the underlying software flaw of the vulnerability). As such, given that STIX functions as the ‘standard’ for vulnerability description (which we 100% agree with), perhaps we should postpone this change and wait for the STIX VulnerabilityType to be updated?

 

[Terry] - It depends if there is urgent need for this at present. We can always make this change and feed back the need for alignment to the CTI STIX Sub-Committee. It all depends if the MAEC Community can wait.

 

[Paul] – I agree with Ivan in that the STIX VulnerabilityType is too restrictive.  If any one looks at the XML schema for CVE or CWE, you’ll see indications that the authors were considering a single VulnerabilityType that could be used to expresses vulnerabilities, weaknesses, and configuration issues.  I would suggest if we look to defining a new VulnerabilityType that it take into consideration that work as well as the unique requirements of STIX and MAEC.  Perhaps this is another instance of where there is a common type that isn’t defined by STIX or MAEC but rather is leveraged/extended by them.  I would also suggest that a closer look be taken as to whether a new vulnerability type should be extended with something like CVE/OSVDB/CWE/CCE (all of which are expressed in XML schemas ONLY) or just reference these external entities.  Part of my thinking is I don’t suspect most producers will likely populate all the fields defined by the extension, but would rather just provide a reference to them, and second these types of extensions result in duplication of data.

 

[Ivan] I don’t think there’s an urgent need for this change (the existing type can capture CVEs, which is the predominant identifier), rather it has been a longstanding issue on our end that we felt was useful to address in a major release. Paul, I agree that this is probably another place where having a common base layer would make sense. I too think that having extensions for the schemas from CVE/OSVDB/CWE/etc. would be overkill for this scenario, so having a fairly expressive VulnerabilityType would probably be the way to go.

 

 

 

Reply | Threaded
Open this post in threaded view
|

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

Kirillov, Ivan A.
Thanks Paul. I think both points are quite sensible:

[1] Agreed – I don’t see why we can’t add a similar @source field to Malware_Instance_Name and Malware_Family_Name.

[2] I can’t think of any cases where, if both Malware_Instance_Name and Malware_Family_Name are specified, that there is not an implicit relationship stating that the instance belongs to the specified family. I agree that having a single field that encompasses both would make this clearer, and would still permit capturing the instance or family name separately. Does this make sense to everyone else?

Regards,
Ivan

From: Paul Patrick <[hidden email]>
Date: Tuesday, July 21, 2015 at 12:06 PM
To: Ivan Kirillov <[hidden email]>, maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: RE: [MAEC] MAEC v5.0 Proposals - Round 1

Ivan,

 

I think the revised proposal is much better, but got a couple more questions:

 

[1] I see we a means to specify a source for the alias but we don’t have a means to capture the source for the malware instance/family.  Perhaps we should add support for that

 

[2] I wondering if people see the Malware_Instance_Name and the Malware_Family_Name coupled where there is an implied relationship between the instance name and the family name to which is belongs.  If so, perhaps it would be better to have them together as a single type instead of independent fields.  This has the additional advantage that the source could then be a third member of that type.

 

 

Paul Patrick

 

 

 

 

From: Kirillov, Ivan A. [[hidden email]]
Sent: Tuesday, July 21, 2015 6:45 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

I’ve modified the proposal for capturing malware instance/family names, per Terry and Paul’s feedback. Let me know what you think.

 

Regards,

Ivan

 

From: <Kirillov>, Ivan Kirillov <[hidden email]>
Reply-To: Ivan Kirillov <[hidden email]>
Date: Friday, July 17, 2015 at 9:43 AM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Paul, Terry, great discussion. Replies inline below.

 

Regards,

Ivan

 

From: Paul Patrick <[hidden email]>
Reply-To: Paul Patrick <[hidden email]>
Date: Thursday, July 16, 2015 at 5:29 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

 

 

From: Terry MacDonald [[hidden email]]
Sent: Wednesday, July 15, 2015 4:36 PM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Hi Ivan,

 

Replies inline, with the unnecessary sections removed.

Cheers


Terry MacDonald | STIX, TAXII, CybOX Consultant

 

M: +61-407-203-026

 

 

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

  1. Do the defined types, their child properties, their datatypes, and their annotations makes sense? Should they be changed in any way?
    [terry] - My concern by lumping the various names that the malware is known as together into a pair of single fields is that we potentially lose sight of what the malware sample is called by the MAEC producer. I wonder if it is better to separate the aliases out into their own field. i.e. keep the Malware_Instance_Name and Malware_Family_Name (limited to 0-1), but also add Malware_Instance_Aliases and Malware_Family_Aliases (limited 0-N). In this way people can easily discern what the producer calls the malware, and they can also see what others call the malware sample. It allows for others to release details of similar malware under their own family names, and a relationship to still be discerned through the alias fields.

     [Ivan] That’s a good point – with the current approach, it’s unclear where the malware instance/family names (as captured in a MAEC instance document) came from. Capturing aliases as a separate field may be a viable solution, but I’m     

wondering if it might be simpler and more direct to just capture the source using a separate field (probably an @source attribute) for each Malware_Instance_Name and Malware_Family_Name. That way, the producer of the MAEC document can 

specify whether the name came from their own organization (e.g., @source=“MITRE” for me) or somewhere else. It might also be useful to capture a reference URL that goes along with the source (if availble), e.g., for publicly available malware analysis reports where the name may be referenced. What do you think?

 

[Terry] - I'm not so sold on the capturing all family names in a single place. Realistically a producer is not going to know which names came from which other vendors, as some may be produced by 3rd parties, and they may only hear of them second hand. The producer is only going to know a subset of that information. I do think that recording the name of what the producer calls the malware instance is important, and recording the information source is important, but that the alias information is useful, but not important. Ultimately I think a list of alias names should be separate from the malware names, and that it doesn't need a source tag. I also think that what the producer calls the malware instance is important, and that the source of the name could be important for Incident Responders who would like more information on the data.

 

[Paul] – I might suggest that rather than have 2 lists, that you might have a new MalwareAlias type that contains a single member for both name and family.  I would agree that the producer of the MAEC would likely have its own name and that is important.  But I would argue that the alias information is important.  Without alias, it becomes difficult that something reported by one producer can be correlated with another.  For example, image the same malware instance is submitted to multiple online sandboxes that produce results in MAEC format.  It likely that both sandboxes will assign their own unique name but may also be able to relate the instance to a given name and/or corresponding family.  Without the aliases, it’s very difficult to correlate across them.

 

[Ivan] Good point by Terry in that producers are unlikely to always know which names came from which vendors, so having the ability to identify a name as an alias would still be necessary. Paul, I think your point about having the ability to correlate multiple malware instance/family names is also well taken. It sounds like what Paul is suggesting is keeping the Malware_Instance_Name and Malware_Family_Name and then having an additional field (maybe something like Malware_Alias?) that can capture both instance and family aliases via a new MalwareAlias type. This seems sound to me, though it would probably also be useful to capture the source of the alias, if known; I’m still on the side of having a simple @source field to keep things basic and lightweight, and also because we currently can’t use the STIX InformationSourceType – see comments below. What do you guys think?

 

I personally think you should leverage the InformationSourceType available in STIX if you want to tack the source, as that is comprehensive, and a good way of providing whatever level of flexibility the producer wants. It also contains the References section, which could be useful for tracking URLs for more information, if that is something you would like to see tracked within MAEC. 

 

[Paul] – I’m in agreement with Terry wrt leveraging some of the things in STIX (InformationSourceType, common vocabularies …) but I do have a concern of circular dependencies being created.  I think there is likely a number of things in STIX that should actually be in a common place and leveraged by STIX and MAEC.  A common base type of some of this that then could be extended by STIX and/or MAEC would definitely be a step in the right direction and I think the common base type that is based on a lot of what is in STIX would be a good start.

 

[Ivan] Yes, the primary reason that we don’t already import any STIX constructs is because of circular dependencies. Also, from a semantic perspective, it would be quite odd for MAEC to import STIX, given that STIX really sits at a much higher level of abstraction. I completely agree with Paul that we really need a common base “layer” where we can define common concepts like InformationSourceType, ConfidenceMeasureEnum, etc. I personally plan on bringing this up as part of the STIX/CybOX discussion in the OASIS CTI. For now though, we’ll have to make due with either duplicating types or creating divergent implementations. 

 

  1. Does it make sense to have a multiplicity of 0-N (unbounded) for malware instance and malware family names, or should it be bounded to 1?
    [terry] - I woulsd suggest bounded to 1 if you add the Malware_Instance_Aliases and Malware_Family_Aliases (unbounded).
  2. Does it make sense to assign a relative measure of confidence to malware instance and malware family names? Accordingly, do the values in the ConfidenceMeasureEnummake sense?
    [terry] - I would like to align the ConfidenceMeasureEnum values with the values in the STIX confidence (High, Medium, Low, None, Unknown).

     [Ivan] Agreed – I’ll update the proposal to align the values with the ConfidenceMeasureEnum. In the future, it would be nice to be able to use MAEC/STIX/CybOX vocabularies interchangeably. Currently this isn’t possible (at least with respect to STIX <-> MAEC/CybOX) because their vocabularies extend from different base types.

 

[Terry] - I would like to see a lot of things shared across MAEC.STIX/CybOX - Information source, reference URL structures as well as default vocabs. There is a reasonable scope for that. Maybe thats worth bringing up on the OASIS CTI Subcommittees.

 

[Paul] – I second Terry’s suggested.  I think there are already a couple of these types of instance that are emerging with likely more as we move forward.

 

  1. Does it make sense to make this field name change in MAEC?
    [terry] - Yes it makes sense.
  2. Does the proposed name make sense? Are there preferable alternatives?
  1. [terry] - what about renaming it simply 'observables', or 'instance_observables'? This would align somewhat with STIX.

    [Ivan] That would be closer to STIX, but not completely accurate as the field only supports capturing a CybOX Object (cybox:ObjectType). Maybe “Instance_Object” then?

 

[Terry] - Instance_Object could work.

[Paul] I could agree with that

[Ivan] Sounds good. Let’s go with “Instance_Object” then :)

 

Proposal: Deprecate Use of QNames for Ids

  1. Should URIs be used instead of QNames in IDs?
    [terry] - I'm in two minds here. I really dislike QNames as they complicate the processing involved in generating and consuming the XML output of STIX, CYBOX and MAEC. But, I am equally concerned that MAEC will be deprecating the use of QNames in IDs, when there has been no public discussion about doing the same within STIX or CybOX. I would hate for producers and consumers of threat intelligence to be forced to support two different ways of generating IDs within a single library if it could be avoided.

    In other words - has this been discussed with the STIX/CybOX communities to see if they would be open to changing the IDs to use URIs? I think a LOT of people would, but ti would be great to check this out and confirm it before changing MAEC. It would be far better to have MAEC the first of the related protocols to migrate, rather than it be the only one doing this change.

    [Ivan] As Jon mentioned in his response, this has been an outstanding issue for a while in STIX and CybOX, but hasn’t been brought up for explicit discussion because it would not be a backwards compatible change. Accordingly, we chose to do this now in MAEC because we felt it would be a good time (being a major version) to incorporate any backwards-incompatible changes that would be useful. We should certainly check with the STIX/CybOX communities to see if this is something that they may be interested in doing down the road. Also, I definitely agree that having to support multiple ID formats would be painful for content producers (and consumers as well), especially when dealing with embedded MAEC in STIX TTPs. However, with regards to that last point, this won’t be a (potential) issue until STIX is updated to support the embedding of MAEC v5.0 (STIX 1.2.x will be limited to MAEC v4.1).

 

[Terry] - OK, didn't know that. In that case, URIs are better :). 

 

With all the changes being discussed on the STIX/TAXII lists at present regtarding v2.0 or both TAXII and STIX, I wouldn't be surprised if we end up moving away from XML based documents to another structured data format. I'm really pushing for a 'review all the things' mentality for STIX/TAXII, as the opportunities for a major release don't come about very often. It will be interesting to see what impact that will have on MAEC in the future.

 

[Paul] – I think we are an interesting point in time since both STIX and MAEC depend upon CybOX which faces the same issue.  Unless the 3 aren’t updated consistently at roughly the same time, users are going to be faced with understanding different formats.  URIs (be they URLs or URNs) will definitely be better. 

 

[Ivan] Yup. I think we have two options in this regard: make the change now, and assume that STIX and CybOX will follow (which I’d personally say is likely), or wait until STIX and CybOX change and then follow suite. The problem with the former is that it’s not guaranteed that STIX and CybOX will make the same change, and even if they do, it will take a new major version which is probably a year away, at least. The problem with the latter is that it will require a new major version of MAEC, which is one of the reasons that I was leaning towards making the change now. However, given the fact that dealing with multiple ID syntaxes certainly seems painful (and will be a reality in MAEC v5.0 with this change, given that CybOX will still use QNames), perhaps we should table this change until a later date, to make life easier for both consumers and producers.

 

  1. Should VulnerabilityExploitType align as closely as possible with the STIXVulnerabilityType or is it better to take a more flexible approach by defining a new MAEC VulnerabilityReferenceType?
    [terry] - They must align in my opinion. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. There is a lot of benefit to be had by ensuring that consumers can find linkages between vulnerable systems, and malware that exploits those vulnerabilities. For this to happen it is imperative that STIX and MAEC align their descriptions, such that one can make a connection.

    I would posit that as the STIX ExploitTarget is designed to describe vulnerable systems that the STIXVulnerabilityType should be considered the 'standard' for vulnerability description, and that as MAEC is designed to describe malware and the exploits they contain that the MAEC Exploit descriptions should be considered the 'standard' for exploit description, and that they should leverage each others work.

   [Ivan] I definitely agree with your characterization of the purpose of MAEC’s VulnerabilityExploitType and the ExploitTarget from STIX. The main reason that we decided not to completely mirror the fields in the STIX VulnerabilityType is that, currently, the STIX VulnerabilityType is inflexible when it comes to vulnerability references, supporting only CVE and OSVDB. Therefore, there is some expectation that the STIX VulnerabilityType will be updated to accommodate other references (e.g., CWE for the underlying software flaw of the vulnerability). As such, given that STIX functions as the ‘standard’ for vulnerability description (which we 100% agree with), perhaps we should postpone this change and wait for the STIX VulnerabilityType to be updated?

 

[Terry] - It depends if there is urgent need for this at present. We can always make this change and feed back the need for alignment to the CTI STIX Sub-Committee. It all depends if the MAEC Community can wait.

 

[Paul] – I agree with Ivan in that the STIX VulnerabilityType is too restrictive.  If any one looks at the XML schema for CVE or CWE, you’ll see indications that the authors were considering a single VulnerabilityType that could be used to expresses vulnerabilities, weaknesses, and configuration issues.  I would suggest if we look to defining a new VulnerabilityType that it take into consideration that work as well as the unique requirements of STIX and MAEC.  Perhaps this is another instance of where there is a common type that isn’t defined by STIX or MAEC but rather is leveraged/extended by them.  I would also suggest that a closer look be taken as to whether a new vulnerability type should be extended with something like CVE/OSVDB/CWE/CCE (all of which are expressed in XML schemas ONLY) or just reference these external entities.  Part of my thinking is I don’t suspect most producers will likely populate all the fields defined by the extension, but would rather just provide a reference to them, and second these types of extensions result in duplication of data.

 

[Ivan] I don’t think there’s an urgent need for this change (the existing type can capture CVEs, which is the predominant identifier), rather it has been a longstanding issue on our end that we felt was useful to address in a major release. Paul, I agree that this is probably another place where having a common base layer would make sense. I too think that having extensions for the schemas from CVE/OSVDB/CWE/etc. would be overkill for this scenario, so having a fairly expressive VulnerabilityType would probably be the way to go.

 

 

 

Reply | Threaded
Open this post in threaded view
|

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

Kirillov, Ivan A.
Resending Terry’s post below, as it was bounced from the listserv because it contained an image. I’ve since enabled image attachments.

Regards,
Ivan

From: Terry MacDonald <[hidden email]>
Date: Tuesday, July 21, 2015 at 7:26 PM
To: Ivan Kirillov <[hidden email]>
Cc: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

Hi All,

Regarding [2], having a relationship, and having them the same field are two different things in my opinion. We need to determine if anyone would ever need to map out relationships based on the Malware_Instance_Name as distinct from he Malware_Family_Name at any stage before we obfuscate that relationship with the structure changes.

By drawing a graph of the relationships as proposed by Ivan we get this: 
Inline images 1

This structure allows me to easily look for all instance names, so I could extract those and possibly look for searches of those names in outputs from other tools. 

Using a neo4j example: 

MATCH (cryptolocker:MalwareFamilyName {value: 'CryptoLocker'})<-[:IS_PART_OF_THE_FAMILY_OF]-()-[:IS_AN_INSTANCE_OF|:IS_ALSO_KNOWN_AS]->(malwarenames) RETURN malwarenames.value

would return:

Inline images 2
I really don't like the idea that we would squash them all together to lose that flexibility to pull them all apart again. 

Cheers

Terry MacDonald | STIX, TAXII, CybOX Consultant




Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.


On 22 July 2015 at 03:11, Kirillov, Ivan A. <[hidden email]> wrote:
Thanks Paul. I think both points are quite sensible:

[1] Agreed – I don’t see why we can’t add a similar @source field to Malware_Instance_Name and Malware_Family_Name.

[2] I can’t think of any cases where, if both Malware_Instance_Name and Malware_Family_Name are specified, that there is not an implicit relationship stating that the instance belongs to the specified family. I agree that having a single field that encompasses both would make this clearer, and would still permit capturing the instance or family name separately. Does this make sense to everyone else?

Regards,
Ivan

From: Paul Patrick <[hidden email]>
Date: Tuesday, July 21, 2015 at 12:06 PM
To: Ivan Kirillov <[hidden email]>, maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: RE: [MAEC] MAEC v5.0 Proposals - Round 1

Ivan,

 

I think the revised proposal is much better, but got a couple more questions:

 

[1] I see we a means to specify a source for the alias but we don’t have a means to capture the source for the malware instance/family.  Perhaps we should add support for that

 

[2] I wondering if people see the Malware_Instance_Name and the Malware_Family_Name coupled where there is an implied relationship between the instance name and the family name to which is belongs.  If so, perhaps it would be better to have them together as a single type instead of independent fields.  This has the additional advantage that the source could then be a third member of that type.

 

 

Paul Patrick

 

 

 

 

From: Kirillov, Ivan A. [[hidden email]]

Sent: Tuesday, July 21, 2015 6:45 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

I’ve modified the proposal for capturing malware instance/family names, per Terry and Paul’s feedback. Let me know what you think.

 

Regards,

Ivan

 

From: <Kirillov>, Ivan Kirillov <[hidden email]>
Reply-To: Ivan Kirillov <[hidden email]>
Date: Friday, July 17, 2015 at 9:43 AM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Paul, Terry, great discussion. Replies inline below.

 

Regards,

Ivan

 

From: Paul Patrick <[hidden email]>
Reply-To: Paul Patrick <[hidden email]>
Date: Thursday, July 16, 2015 at 5:29 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

 

 

From: Terry MacDonald [[hidden email]]
Sent: Wednesday, July 15, 2015 4:36 PM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Hi Ivan,

 

Replies inline, with the unnecessary sections removed.

Cheers


Terry MacDonald | STIX, TAXII, CybOX Consultant

 

M: <a href="tel:%2B61-407-203-026" value="&#43;61407203026" target="_blank"> +61-407-203-026

 

 

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

  1. Do the defined types, their child properties, their datatypes, and their annotations makes sense? Should they be changed in any way?
    [terry] - My concern by lumping the various names that the malware is known as together into a pair of single fields is that we potentially lose sight of what the malware sample is called by the MAEC producer. I wonder if it is better to separate the aliases out into their own field. i.e. keep the Malware_Instance_Name and Malware_Family_Name (limited to 0-1), but also add Malware_Instance_Aliases and Malware_Family_Aliases (limited 0-N). In this way people can easily discern what the producer calls the malware, and they can also see what others call the malware sample. It allows for others to release details of similar malware under their own family names, and a relationship to still be discerned through the alias fields.

     [Ivan] That’s a good point – with the current approach, it’s unclear where the malware instance/family names (as captured in a MAEC instance document) came from. Capturing aliases as a separate field may be a viable solution, but I’m     

wondering if it might be simpler and more direct to just capture the source using a separate field (probably an @source attribute) for each Malware_Instance_Name and Malware_Family_Name. That way, the producer of the MAEC document can 

specify whether the name came from their own organization (e.g., @source=“MITRE” for me) or somewhere else. It might also be useful to capture a reference URL that goes along with the source (if availble), e.g., for publicly available malware analysis reports where the name may be referenced. What do you think?

 

[Terry] - I'm not so sold on the capturing all family names in a single place. Realistically a producer is not going to know which names came from which other vendors, as some may be produced by 3rd parties, and they may only hear of them second hand. The producer is only going to know a subset of that information. I do think that recording the name of what the producer calls the malware instance is important, and recording the information source is important, but that the alias information is useful, but not important. Ultimately I think a list of alias names should be separate from the malware names, and that it doesn't need a source tag. I also think that what the producer calls the malware instance is important, and that the source of the name could be important for Incident Responders who would like more information on the data.

 

[Paul] – I might suggest that rather than have 2 lists, that you might have a new MalwareAlias type that contains a single member for both name and family.  I would agree that the producer of the MAEC would likely have its own name and that is important.  But I would argue that the alias information is important.  Without alias, it becomes difficult that something reported by one producer can be correlated with another.  For example, image the same malware instance is submitted to multiple online sandboxes that produce results in MAEC format.  It likely that both sandboxes will assign their own unique name but may also be able to relate the instance to a given name and/or corresponding family.  Without the aliases, it’s very difficult to correlate across them.

 

[Ivan] Good point by Terry in that producers are unlikely to always know which names came from which vendors, so having the ability to identify a name as an alias would still be necessary. Paul, I think your point about having the ability to correlate multiple malware instance/family names is also well taken. It sounds like what Paul is suggesting is keeping the Malware_Instance_Name and Malware_Family_Name and then having an additional field (maybe something like Malware_Alias?) that can capture both instance and family aliases via a new MalwareAlias type. This seems sound to me, though it would probably also be useful to capture the source of the alias, if known; I’m still on the side of having a simple @source field to keep things basic and lightweight, and also because we currently can’t use the STIX InformationSourceType – see comments below. What do you guys think?

 

I personally think you should leverage the InformationSourceType available in STIX if you want to tack the source, as that is comprehensive, and a good way of providing whatever level of flexibility the producer wants. It also contains the References section, which could be useful for tracking URLs for more information, if that is something you would like to see tracked within MAEC. 

 

[Paul] – I’m in agreement with Terry wrt leveraging some of the things in STIX (InformationSourceType, common vocabularies …) but I do have a concern of circular dependencies being created.  I think there is likely a number of things in STIX that should actually be in a common place and leveraged by STIX and MAEC.  A common base type of some of this that then could be extended by STIX and/or MAEC would definitely be a step in the right direction and I think the common base type that is based on a lot of what is in STIX would be a good start.

 

[Ivan] Yes, the primary reason that we don’t already import any STIX constructs is because of circular dependencies. Also, from a semantic perspective, it would be quite odd for MAEC to import STIX, given that STIX really sits at a much higher level of abstraction. I completely agree with Paul that we really need a common base “layer” where we can define common concepts like InformationSourceType, ConfidenceMeasureEnum, etc. I personally plan on bringing this up as part of the STIX/CybOX discussion in the OASIS CTI. For now though, we’ll have to make due with either duplicating types or creating divergent implementations. 

 

  1. Does it make sense to have a multiplicity of 0-N (unbounded) for malware instance and malware family names, or should it be bounded to 1?
    [terry] - I woulsd suggest bounded to 1 if you add the Malware_Instance_Aliases and Malware_Family_Aliases (unbounded).
  2. Does it make sense to assign a relative measure of confidence to malware instance and malware family names? Accordingly, do the values in the ConfidenceMeasureEnummake sense?
    [terry] - I would like to align the ConfidenceMeasureEnum values with the values in the STIX confidence (High, Medium, Low, None, Unknown).

     [Ivan] Agreed – I’ll update the proposal to align the values with the ConfidenceMeasureEnum. In the future, it would be nice to be able to use MAEC/STIX/CybOX vocabularies interchangeably. Currently this isn’t possible (at least with respect to STIX <-> MAEC/CybOX) because their vocabularies extend from different base types.

 

[Terry] - I would like to see a lot of things shared across MAEC.STIX/CybOX - Information source, reference URL structures as well as default vocabs. There is a reasonable scope for that. Maybe thats worth bringing up on the OASIS CTI Subcommittees.

 

[Paul] – I second Terry’s suggested.  I think there are already a couple of these types of instance that are emerging with likely more as we move forward.

 

  1. Does it make sense to make this field name change in MAEC?
    [terry] - Yes it makes sense.
  2. Does the proposed name make sense? Are there preferable alternatives?
  1. [terry] - what about renaming it simply 'observables', or 'instance_observables'? This would align somewhat with STIX.

    [Ivan] That would be closer to STIX, but not completely accurate as the field only supports capturing a CybOX Object (cybox:ObjectType). Maybe “Instance_Object” then?

 

[Terry] - Instance_Object could work.

[Paul] I could agree with that

[Ivan] Sounds good. Let’s go with “Instance_Object” then :)

 

Proposal: Deprecate Use of QNames for Ids

  1. Should URIs be used instead of QNames in IDs?
    [terry] - I'm in two minds here. I really dislike QNames as they complicate the processing involved in generating and consuming the XML output of STIX, CYBOX and MAEC. But, I am equally concerned that MAEC will be deprecating the use of QNames in IDs, when there has been no public discussion about doing the same within STIX or CybOX. I would hate for producers and consumers of threat intelligence to be forced to support two different ways of generating IDs within a single library if it could be avoided.

    In other words - has this been discussed with the STIX/CybOX communities to see if they would be open to changing the IDs to use URIs? I think a LOT of people would, but ti would be great to check this out and confirm it before changing MAEC. It would be far better to have MAEC the first of the related protocols to migrate, rather than it be the only one doing this change.

    [Ivan] As Jon mentioned in his response, this has been an outstanding issue for a while in STIX and CybOX, but hasn’t been brought up for explicit discussion because it would not be a backwards compatible change. Accordingly, we chose to do this now in MAEC because we felt it would be a good time (being a major version) to incorporate any backwards-incompatible changes that would be useful. We should certainly check with the STIX/CybOX communities to see if this is something that they may be interested in doing down the road. Also, I definitely agree that having to support multiple ID formats would be painful for content producers (and consumers as well), especially when dealing with embedded MAEC in STIX TTPs. However, with regards to that last point, this won’t be a (potential) issue until STIX is updated to support the embedding of MAEC v5.0 (STIX 1.2.x will be limited to MAEC v4.1).

 

[Terry] - OK, didn't know that. In that case, URIs are better :). 

 

With all the changes being discussed on the STIX/TAXII lists at present regtarding v2.0 or both TAXII and STIX, I wouldn't be surprised if we end up moving away from XML based documents to another structured data format. I'm really pushing for a 'review all the things' mentality for STIX/TAXII, as the opportunities for a major release don't come about very often. It will be interesting to see what impact that will have on MAEC in the future.

 

[Paul] – I think we are an interesting point in time since both STIX and MAEC depend upon CybOX which faces the same issue.  Unless the 3 aren’t updated consistently at roughly the same time, users are going to be faced with understanding different formats.  URIs (be they URLs or URNs) will definitely be better. 

 

[Ivan] Yup. I think we have two options in this regard: make the change now, and assume that STIX and CybOX will follow (which I’d personally say is likely), or wait until STIX and CybOX change and then follow suite. The problem with the former is that it’s not guaranteed that STIX and CybOX will make the same change, and even if they do, it will take a new major version which is probably a year away, at least. The problem with the latter is that it will require a new major version of MAEC, which is one of the reasons that I was leaning towards making the change now. However, given the fact that dealing with multiple ID syntaxes certainly seems painful (and will be a reality in MAEC v5.0 with this change, given that CybOX will still use QNames), perhaps we should table this change until a later date, to make life easier for both consumers and producers.

 

  1. Should VulnerabilityExploitType align as closely as possible with the STIXVulnerabilityType or is it better to take a more flexible approach by defining a new MAEC VulnerabilityReferenceType?
    [terry] - They must align in my opinion. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. There is a lot of benefit to be had by ensuring that consumers can find linkages between vulnerable systems, and malware that exploits those vulnerabilities. For this to happen it is imperative that STIX and MAEC align their descriptions, such that one can make a connection.

    I would posit that as the STIX ExploitTarget is designed to describe vulnerable systems that the STIXVulnerabilityType should be considered the 'standard' for vulnerability description, and that as MAEC is designed to describe malware and the exploits they contain that the MAEC Exploit descriptions should be considered the 'standard' for exploit description, and that they should leverage each others work.

   [Ivan] I definitely agree with your characterization of the purpose of MAEC’s VulnerabilityExploitType and the ExploitTarget from STIX. The main reason that we decided not to completely mirror the fields in the STIX VulnerabilityType is that, currently, the STIX VulnerabilityType is inflexible when it comes to vulnerability references, supporting only CVE and OSVDB. Therefore, there is some expectation that the STIX VulnerabilityType will be updated to accommodate other references (e.g., CWE for the underlying software flaw of the vulnerability). As such, given that STIX functions as the ‘standard’ for vulnerability description (which we 100% agree with), perhaps we should postpone this change and wait for the STIX VulnerabilityType to be updated?

 

[Terry] - It depends if there is urgent need for this at present. We can always make this change and feed back the need for alignment to the CTI STIX Sub-Committee. It all depends if the MAEC Community can wait.

 

[Paul] – I agree with Ivan in that the STIX VulnerabilityType is too restrictive.  If any one looks at the XML schema for CVE or CWE, you’ll see indications that the authors were considering a single VulnerabilityType that could be used to expresses vulnerabilities, weaknesses, and configuration issues.  I would suggest if we look to defining a new VulnerabilityType that it take into consideration that work as well as the unique requirements of STIX and MAEC.  Perhaps this is another instance of where there is a common type that isn’t defined by STIX or MAEC but rather is leveraged/extended by them.  I would also suggest that a closer look be taken as to whether a new vulnerability type should be extended with something like CVE/OSVDB/CWE/CCE (all of which are expressed in XML schemas ONLY) or just reference these external entities.  Part of my thinking is I don’t suspect most producers will likely populate all the fields defined by the extension, but would rather just provide a reference to them, and second these types of extensions result in duplication of data.

 

[Ivan] I don’t think there’s an urgent need for this change (the existing type can capture CVEs, which is the predominant identifier), rather it has been a longstanding issue on our end that we felt was useful to address in a major release. Paul, I agree that this is probably another place where having a common base layer would make sense. I too think that having extensions for the schemas from CVE/OSVDB/CWE/etc. would be overkill for this scenario, so having a fairly expressive VulnerabilityType would probably be the way to go.

 

 

 


Reply | Threaded
Open this post in threaded view
|

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

Paul Patrick

Ivan – thanks for forwarding with the graphic

 

Terry –

I’m completely in agreement with what you’ve described as I too am looking to build graphs, so I think in that respect we’re not the same page.  What I was suggesting was that there is a kind of association between the malware family name and the malware instance name.  What I also was suggesting was that either of those names together may also need to have a source associated with them in order to determine if they form a unique tuple.  By just having an instance name and a family name is not clear if the two are from the same source of different ones.  Adding a @source attribute to each makes it even more confusing.

 

My suggestion was to create a single type Malware_Name which contained members that comprised the name similar to what is achieved by the Computer Antivirus Research Organization (CARO) malware naming convention that is supported by a number of vendors.  Having a Malware_Name type would semantically convey that the family name, instance name, and any other members are associated.  This way a Malware_Name  type could be parsed into its component to form the graph like you’ve drawn below.

 

<Malware_Subject>

    <Malware_Name>

        <Malware_Instance_Name confidence=”Medium”>CryptoLocker.B</Malware_Instance_Name>

        <Malware_Family_Name confidence=”High”>CryptoLocker</Malware_Family_Name>

    </Malware_Name>

</Malware_Subject>

 

If the group were to agree to do down this path, I would suggest that we look closely at the CARO naming scheme to determine if there are other members that should also be represented as members of the Malware_Name type.

 

For those not aware of CARO, it is a naming convention that has been adopted by a number of the AV vendors, to create an identifier based on URI syntax for malware.  It is very similar to what was done for the Common Platform Enumerations (CPE).  Below is an example format where items enclosed between ‘[‘ and ‘]’ are optional.

 

[<malware_type>://][<platform>/]<family_name>[.<group_name>][.<infective_length>][.<sub-variant><devolution>]][<modifiers>]

 

I’m not suggesting that we replace the concept of Malware_Family_Name and Malware_Instance_Name with a CARO formatted value since that would require parsing, using a Malware_Name type based on the components of the CARO would allow MAEC to actually uses the components to build a CARO name that could be used to determine if two different Malware_Subjects created independently are actually referring to the same thing.

 

One other suggestion I might make based on the use of a Malware_Name type is that the Malware_Alias could actually be a reference (e.g., idref) so that MAEC could consistently refer to the same name in multiple places.

 

Hope this helps clarify what I was trying to convey.

 

 

Paul Patrick

 

From: Kirillov, Ivan A. [mailto:[hidden email]]
Sent: Wednesday, July 22, 2015 5:58 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Resending Terry’s post below, as it was bounced from the listserv because it contained an image. I’ve since enabled image attachments.

 

Regards,

Ivan

 

From: Terry MacDonald <[hidden email]>
Date: Tuesday, July 21, 2015 at 7:26 PM
To: Ivan Kirillov <[hidden email]>
Cc: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Hi All,

 

Regarding [2], having a relationship, and having them the same field are two different things in my opinion. We need to determine if anyone would ever need to map out relationships based on the Malware_Instance_Name as distinct from he Malware_Family_Name at any stage before we obfuscate that relationship with the structure changes.

 

By drawing a graph of the relationships as proposed by Ivan we get this: 

Inline images 1

 

This structure allows me to easily look for all instance names, so I could extract those and possibly look for searches of those names in outputs from other tools. 

 

Using a neo4j example: 

 

MATCH (cryptolocker:MalwareFamilyName {value: 'CryptoLocker'})<-[:IS_PART_OF_THE_FAMILY_OF]-()-[:IS_AN_INSTANCE_OF|:IS_ALSO_KNOWN_AS]->(malwarenames) RETURN malwarenames.value

 

would return:

 

Inline images 2

I really don't like the idea that we would squash them all together to lose that flexibility to pull them all apart again. 

 

Cheers


Terry MacDonald | STIX, TAXII, CybOX Consultant

 

M: +61-407-203-026

 

 

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

 

 

On 22 July 2015 at 03:11, Kirillov, Ivan A. <[hidden email]> wrote:

Thanks Paul. I think both points are quite sensible:

 

[1] Agreed – I don’t see why we can’t add a similar @source field to Malware_Instance_Name and Malware_Family_Name.

 

[2] I can’t think of any cases where, if both Malware_Instance_Name and Malware_Family_Name are specified, that there is not an implicit relationship stating that the instance belongs to the specified family. I agree that having a single field that encompasses both would make this clearer, and would still permit capturing the instance or family name separately. Does this make sense to everyone else?

 

Regards,

Ivan

 

From: Paul Patrick <[hidden email]>
Date: Tuesday, July 21, 2015 at 12:06 PM
To: Ivan Kirillov <[hidden email]>, maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: RE: [MAEC] MAEC v5.0 Proposals - Round 1

 

Ivan,

 

I think the revised proposal is much better, but got a couple more questions:

 

[1] I see we a means to specify a source for the alias but we don’t have a means to capture the source for the malware instance/family.  Perhaps we should add support for that

 

[2] I wondering if people see the Malware_Instance_Name and the Malware_Family_Name coupled where there is an implied relationship between the instance name and the family name to which is belongs.  If so, perhaps it would be better to have them together as a single type instead of independent fields.  This has the additional advantage that the source could then be a third member of that type.

 

 

Paul Patrick

 

 

 

 

From: Kirillov, Ivan A. [[hidden email]]

Sent: Tuesday, July 21, 2015 6:45 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

I’ve modified the proposal for capturing malware instance/family names, per Terry and Paul’s feedback. Let me know what you think.

 

Regards,

Ivan

 

From: <Kirillov>, Ivan Kirillov <[hidden email]>
Reply-To: Ivan Kirillov <[hidden email]>
Date: Friday, July 17, 2015 at 9:43 AM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Paul, Terry, great discussion. Replies inline below.

 

Regards,

Ivan

 

From: Paul Patrick <[hidden email]>
Reply-To: Paul Patrick <[hidden email]>
Date: Thursday, July 16, 2015 at 5:29 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

 

 

From: Terry MacDonald [[hidden email]]
Sent: Wednesday, July 15, 2015 4:36 PM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Hi Ivan,

 

Replies inline, with the unnecessary sections removed.

Cheers


Terry MacDonald | STIX, TAXII, CybOX Consultant

 

M: <a href="tel:%2B61-407-203-026" target="_blank">+61-407-203-026

 

 

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

  1. Do the defined types, their child properties, their datatypes, and their annotations makes sense? Should they be changed in any way?
    [terry] - My concern by lumping the various names that the malware is known as together into a pair of single fields is that we potentially lose sight of what the malware sample is called by the MAEC producer. I wonder if it is better to separate the aliases out into their own field. i.e. keep the Malware_Instance_Name and Malware_Family_Name (limited to 0-1), but also add Malware_Instance_Aliases and Malware_Family_Aliases (limited 0-N). In this way people can easily discern what the producer calls the malware, and they can also see what others call the malware sample. It allows for others to release details of similar malware under their own family names, and a relationship to still be discerned through the alias fields.

     [Ivan] That’s a good point – with the current approach, it’s unclear where the malware instance/family names (as captured in a MAEC instance document) came from. Capturing aliases as a separate field may be a viable solution, but I’m     

wondering if it might be simpler and more direct to just capture the source using a separate field (probably an @source attribute) for each Malware_Instance_Name and Malware_Family_Name. That way, the producer of the MAEC document can 

specify whether the name came from their own organization (e.g., @source=“MITRE” for me) or somewhere else. It might also be useful to capture a reference URL that goes along with the source (if availble), e.g., for publicly available malware analysis reports where the name may be referenced. What do you think?

 

[Terry] - I'm not so sold on the capturing all family names in a single place. Realistically a producer is not going to know which names came from which other vendors, as some may be produced by 3rd parties, and they may only hear of them second hand. The producer is only going to know a subset of that information. I do think that recording the name of what the producer calls the malware instance is important, and recording the information source is important, but that the alias information is useful, but not important. Ultimately I think a list of alias names should be separate from the malware names, and that it doesn't need a source tag. I also think that what the producer calls the malware instance is important, and that the source of the name could be important for Incident Responders who would like more information on the data.

 

[Paul] – I might suggest that rather than have 2 lists, that you might have a new MalwareAlias type that contains a single member for both name and family.  I would agree that the producer of the MAEC would likely have its own name and that is important.  But I would argue that the alias information is important.  Without alias, it becomes difficult that something reported by one producer can be correlated with another.  For example, image the same malware instance is submitted to multiple online sandboxes that produce results in MAEC format.  It likely that both sandboxes will assign their own unique name but may also be able to relate the instance to a given name and/or corresponding family.  Without the aliases, it’s very difficult to correlate across them.

 

[Ivan] Good point by Terry in that producers are unlikely to always know which names came from which vendors, so having the ability to identify a name as an alias would still be necessary. Paul, I think your point about having the ability to correlate multiple malware instance/family names is also well taken. It sounds like what Paul is suggesting is keeping the Malware_Instance_Name and Malware_Family_Name and then having an additional field (maybe something like Malware_Alias?) that can capture both instance and family aliases via a new MalwareAlias type. This seems sound to me, though it would probably also be useful to capture the source of the alias, if known; I’m still on the side of having a simple @source field to keep things basic and lightweight, and also because we currently can’t use the STIX InformationSourceType – see comments below. What do you guys think?

 

I personally think you should leverage the InformationSourceType available in STIX if you want to tack the source, as that is comprehensive, and a good way of providing whatever level of flexibility the producer wants. It also contains the References section, which could be useful for tracking URLs for more information, if that is something you would like to see tracked within MAEC. 

 

[Paul] – I’m in agreement with Terry wrt leveraging some of the things in STIX (InformationSourceType, common vocabularies …) but I do have a concern of circular dependencies being created.  I think there is likely a number of things in STIX that should actually be in a common place and leveraged by STIX and MAEC.  A common base type of some of this that then could be extended by STIX and/or MAEC would definitely be a step in the right direction and I think the common base type that is based on a lot of what is in STIX would be a good start.

 

[Ivan] Yes, the primary reason that we don’t already import any STIX constructs is because of circular dependencies. Also, from a semantic perspective, it would be quite odd for MAEC to import STIX, given that STIX really sits at a much higher level of abstraction. I completely agree with Paul that we really need a common base “layer” where we can define common concepts like InformationSourceType, ConfidenceMeasureEnum, etc. I personally plan on bringing this up as part of the STIX/CybOX discussion in the OASIS CTI. For now though, we’ll have to make due with either duplicating types or creating divergent implementations. 

 

  1. Does it make sense to have a multiplicity of 0-N (unbounded) for malware instance and malware family names, or should it be bounded to 1?
    [terry] - I woulsd suggest bounded to 1 if you add the Malware_Instance_Aliases and Malware_Family_Aliases (unbounded).
  2. Does it make sense to assign a relative measure of confidence to malware instance and malware family names? Accordingly, do the values in the ConfidenceMeasureEnummake sense?
    [terry] - I would like to align the ConfidenceMeasureEnum values with the values in the STIX confidence (High, Medium, Low, None, Unknown).

     [Ivan] Agreed – I’ll update the proposal to align the values with the ConfidenceMeasureEnum. In the future, it would be nice to be able to use MAEC/STIX/CybOX vocabularies interchangeably. Currently this isn’t possible (at least with respect to STIX <-> MAEC/CybOX) because their vocabularies extend from different base types.

 

[Terry] - I would like to see a lot of things shared across MAEC.STIX/CybOX - Information source, reference URL structures as well as default vocabs. There is a reasonable scope for that. Maybe thats worth bringing up on the OASIS CTI Subcommittees.

 

[Paul] – I second Terry’s suggested.  I think there are already a couple of these types of instance that are emerging with likely more as we move forward.

 

  1. Does it make sense to make this field name change in MAEC?
    [terry] - Yes it makes sense.
  2. Does the proposed name make sense? Are there preferable alternatives?
  1. [terry] - what about renaming it simply 'observables', or 'instance_observables'? This would align somewhat with STIX.

    [Ivan] That would be closer to STIX, but not completely accurate as the field only supports capturing a CybOX Object (cybox:ObjectType). Maybe “Instance_Object” then?

 

[Terry] - Instance_Object could work.

[Paul] I could agree with that

[Ivan] Sounds good. Let’s go with “Instance_Object” then :)

 

Proposal: Deprecate Use of QNames for Ids

  1. Should URIs be used instead of QNames in IDs?
    [terry] - I'm in two minds here. I really dislike QNames as they complicate the processing involved in generating and consuming the XML output of STIX, CYBOX and MAEC. But, I am equally concerned that MAEC will be deprecating the use of QNames in IDs, when there has been no public discussion about doing the same within STIX or CybOX. I would hate for producers and consumers of threat intelligence to be forced to support two different ways of generating IDs within a single library if it could be avoided.

    In other words - has this been discussed with the STIX/CybOX communities to see if they would be open to changing the IDs to use URIs? I think a LOT of people would, but ti would be great to check this out and confirm it before changing MAEC. It would be far better to have MAEC the first of the related protocols to migrate, rather than it be the only one doing this change.

    [Ivan] As Jon mentioned in his response, this has been an outstanding issue for a while in STIX and CybOX, but hasn’t been brought up for explicit discussion because it would not be a backwards compatible change. Accordingly, we chose to do this now in MAEC because we felt it would be a good time (being a major version) to incorporate any backwards-incompatible changes that would be useful. We should certainly check with the STIX/CybOX communities to see if this is something that they may be interested in doing down the road. Also, I definitely agree that having to support multiple ID formats would be painful for content producers (and consumers as well), especially when dealing with embedded MAEC in STIX TTPs. However, with regards to that last point, this won’t be a (potential) issue until STIX is updated to support the embedding of MAEC v5.0 (STIX 1.2.x will be limited to MAEC v4.1).

 

[Terry] - OK, didn't know that. In that case, URIs are better :). 

 

With all the changes being discussed on the STIX/TAXII lists at present regtarding v2.0 or both TAXII and STIX, I wouldn't be surprised if we end up moving away from XML based documents to another structured data format. I'm really pushing for a 'review all the things' mentality for STIX/TAXII, as the opportunities for a major release don't come about very often. It will be interesting to see what impact that will have on MAEC in the future.

 

[Paul] – I think we are an interesting point in time since both STIX and MAEC depend upon CybOX which faces the same issue.  Unless the 3 aren’t updated consistently at roughly the same time, users are going to be faced with understanding different formats.  URIs (be they URLs or URNs) will definitely be better. 

 

[Ivan] Yup. I think we have two options in this regard: make the change now, and assume that STIX and CybOX will follow (which I’d personally say is likely), or wait until STIX and CybOX change and then follow suite. The problem with the former is that it’s not guaranteed that STIX and CybOX will make the same change, and even if they do, it will take a new major version which is probably a year away, at least. The problem with the latter is that it will require a new major version of MAEC, which is one of the reasons that I was leaning towards making the change now. However, given the fact that dealing with multiple ID syntaxes certainly seems painful (and will be a reality in MAEC v5.0 with this change, given that CybOX will still use QNames), perhaps we should table this change until a later date, to make life easier for both consumers and producers.

 

  1. Should VulnerabilityExploitType align as closely as possible with the STIXVulnerabilityType or is it better to take a more flexible approach by defining a new MAEC VulnerabilityReferenceType?
    [terry] - They must align in my opinion. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. There is a lot of benefit to be had by ensuring that consumers can find linkages between vulnerable systems, and malware that exploits those vulnerabilities. For this to happen it is imperative that STIX and MAEC align their descriptions, such that one can make a connection.

    I would posit that as the STIX ExploitTarget is designed to describe vulnerable systems that the STIXVulnerabilityType should be considered the 'standard' for vulnerability description, and that as MAEC is designed to describe malware and the exploits they contain that the MAEC Exploit descriptions should be considered the 'standard' for exploit description, and that they should leverage each others work.

   [Ivan] I definitely agree with your characterization of the purpose of MAEC’s VulnerabilityExploitType and the ExploitTarget from STIX. The main reason that we decided not to completely mirror the fields in the STIX VulnerabilityType is that, currently, the STIX VulnerabilityType is inflexible when it comes to vulnerability references, supporting only CVE and OSVDB. Therefore, there is some expectation that the STIX VulnerabilityType will be updated to accommodate other references (e.g., CWE for the underlying software flaw of the vulnerability). As such, given that STIX functions as the ‘standard’ for vulnerability description (which we 100% agree with), perhaps we should postpone this change and wait for the STIX VulnerabilityType to be updated?

 

[Terry] - It depends if there is urgent need for this at present. We can always make this change and feed back the need for alignment to the CTI STIX Sub-Committee. It all depends if the MAEC Community can wait.

 

[Paul] – I agree with Ivan in that the STIX VulnerabilityType is too restrictive.  If any one looks at the XML schema for CVE or CWE, you’ll see indications that the authors were considering a single VulnerabilityType that could be used to expresses vulnerabilities, weaknesses, and configuration issues.  I would suggest if we look to defining a new VulnerabilityType that it take into consideration that work as well as the unique requirements of STIX and MAEC.  Perhaps this is another instance of where there is a common type that isn’t defined by STIX or MAEC but rather is leveraged/extended by them.  I would also suggest that a closer look be taken as to whether a new vulnerability type should be extended with something like CVE/OSVDB/CWE/CCE (all of which are expressed in XML schemas ONLY) or just reference these external entities.  Part of my thinking is I don’t suspect most producers will likely populate all the fields defined by the extension, but would rather just provide a reference to them, and second these types of extensions result in duplication of data.

 

[Ivan] I don’t think there’s an urgent need for this change (the existing type can capture CVEs, which is the predominant identifier), rather it has been a longstanding issue on our end that we felt was useful to address in a major release. Paul, I agree that this is probably another place where having a common base layer would make sense. I too think that having extensions for the schemas from CVE/OSVDB/CWE/etc. would be overkill for this scenario, so having a fairly expressive VulnerabilityType would probably be the way to go.

 

 

 

 

Reply | Threaded
Open this post in threaded view
|

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

Kirillov, Ivan A.
So, the crux of this discussion is around capturing associations between Malware Instance and Family names while retaining the ability to parse them into their components. My feeling is that the solution described by Paul below provides a way of doing this without too much additional overhead in terms of structure or complexity, at least with the assumption that the Family name shouldn’t be broken out from the Instance name. The only other way of capturing such associations from my perspective would be to keep the current structure and relate Malware Instance and Family names using first-class relationships, but that seems needlessly messy for such a relatively simple concept. 

Also, given Paul’s point about having one place for capturing source information for both Instance and Family names, I’m wondering if we should take this even further and add the corresponding capability to Aliases, along with the ability to capture both Family and Instance names? That way, both Malware_Name and Malware_Alias will be completely consistent in terms of structure, and accordingly we can define a single “MalwareNameType” to use in both.

Thus, we’d end up with something like:

<Malware_Subject>

    <Malware_Name>

        <Malware_Instance_Name confidence=”Medium”>CryptoLocker.B</Malware_Instance_Name>

        <Malware_Family_Name confidence=”High”>CryptoLocker</Malware_Family_Name>

    </Malware_Name>

    <Malware Aliases>

       <Malware_Alias>

         <Malware_Instance_Name>WORM_CRILOCK.A</Malware_Instance_Name>

         <Source>Trend Micro</Source>

       </Malware_Alias>

    </Malware_Aliases>

</Malware_Subject>


Terry, Paul, does that seem workable to you?

As far as CARO, I think it’s a useful concept, but from my experience very few AV vendors implement and use it consistently. Accordingly, the discussion of malware names seems to revolve primarily around instances and families, so for this sake and also to keep things simple and lightweight, my preference would be to focus exclusively on capturing instance and family names.

Regards,
Ivan

From: Paul Patrick <[hidden email]>
Reply-To: Paul Patrick <[hidden email]>
Date: Wednesday, July 22, 2015 at 1:57 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

Ivan – thanks for forwarding with the graphic

 

Terry –

I’m completely in agreement with what you’ve described as I too am looking to build graphs, so I think in that respect we’re not the same page.  What I was suggesting was that there is a kind of association between the malware family name and the malware instance name.  What I also was suggesting was that either of those names together may also need to have a source associated with them in order to determine if they form a unique tuple.  By just having an instance name and a family name is not clear if the two are from the same source of different ones.  Adding a @source attribute to each makes it even more confusing.

 

My suggestion was to create a single type Malware_Name which contained members that comprised the name similar to what is achieved by the Computer Antivirus Research Organization (CARO) malware naming convention that is supported by a number of vendors.  Having a Malware_Name type would semantically convey that the family name, instance name, and any other members are associated.  This way a Malware_Name  type could be parsed into its component to form the graph like you’ve drawn below.

 

<Malware_Subject>

    <Malware_Name>

        <Malware_Instance_Name confidence=”Medium”>CryptoLocker.B</Malware_Instance_Name>

        <Malware_Family_Name confidence=”High”>CryptoLocker</Malware_Family_Name>

    </Malware_Name>

</Malware_Subject>

 

If the group were to agree to do down this path, I would suggest that we look closely at the CARO naming scheme to determine if there are other members that should also be represented as members of the Malware_Name type.

 

For those not aware of CARO, it is a naming convention that has been adopted by a number of the AV vendors, to create an identifier based on URI syntax for malware.  It is very similar to what was done for the Common Platform Enumerations (CPE).  Below is an example format where items enclosed between ‘[‘ and ‘]’ are optional.

 

[<malware_type>://][<platform>/]<family_name>[.<group_name>][.<infective_length>][.<sub-variant><devolution>]][<modifiers>]

 

I’m not suggesting that we replace the concept of Malware_Family_Name and Malware_Instance_Name with a CARO formatted value since that would require parsing, using a Malware_Name type based on the components of the CARO would allow MAEC to actually uses the components to build a CARO name that could be used to determine if two different Malware_Subjects created independently are actually referring to the same thing.

 

One other suggestion I might make based on the use of a Malware_Name type is that the Malware_Alias could actually be a reference (e.g., idref) so that MAEC could consistently refer to the same name in multiple places.

 

Hope this helps clarify what I was trying to convey.

 

 

Paul Patrick

 

From: Kirillov, Ivan A. [[hidden email]]
Sent: Wednesday, July 22, 2015 5:58 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Resending Terry’s post below, as it was bounced from the listserv because it contained an image. I’ve since enabled image attachments.

 

Regards,

Ivan

 

From: Terry MacDonald <[hidden email]>
Date: Tuesday, July 21, 2015 at 7:26 PM
To: Ivan Kirillov <[hidden email]>
Cc: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Hi All,

 

Regarding [2], having a relationship, and having them the same field are two different things in my opinion. We need to determine if anyone would ever need to map out relationships based on the Malware_Instance_Name as distinct from he Malware_Family_Name at any stage before we obfuscate that relationship with the structure changes.

 

By drawing a graph of the relationships as proposed by Ivan we get this: 

Inline images 1

 

This structure allows me to easily look for all instance names, so I could extract those and possibly look for searches of those names in outputs from other tools. 

 

Using a neo4j example: 

 

MATCH (cryptolocker:MalwareFamilyName {value: 'CryptoLocker'})<-[:IS_PART_OF_THE_FAMILY_OF]-()-[:IS_AN_INSTANCE_OF|:IS_ALSO_KNOWN_AS]->(malwarenames) RETURN malwarenames.value

 

would return:

 

Inline images 2

I really don't like the idea that we would squash them all together to lose that flexibility to pull them all apart again. 

 

Cheers


Terry MacDonald | STIX, TAXII, CybOX Consultant

 

M: +61-407-203-026

 

 

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

 

 

On 22 July 2015 at 03:11, Kirillov, Ivan A. <[hidden email]> wrote:

Thanks Paul. I think both points are quite sensible:

 

[1] Agreed – I don’t see why we can’t add a similar @source field to Malware_Instance_Name and Malware_Family_Name.

 

[2] I can’t think of any cases where, if both Malware_Instance_Name and Malware_Family_Name are specified, that there is not an implicit relationship stating that the instance belongs to the specified family. I agree that having a single field that encompasses both would make this clearer, and would still permit capturing the instance or family name separately. Does this make sense to everyone else?

 

Regards,

Ivan

 

From: Paul Patrick <[hidden email]>
Date: Tuesday, July 21, 2015 at 12:06 PM
To: Ivan Kirillov <[hidden email]>, maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: RE: [MAEC] MAEC v5.0 Proposals - Round 1

 

Ivan,

 

I think the revised proposal is much better, but got a couple more questions:

 

[1] I see we a means to specify a source for the alias but we don’t have a means to capture the source for the malware instance/family.  Perhaps we should add support for that

 

[2] I wondering if people see the Malware_Instance_Name and the Malware_Family_Name coupled where there is an implied relationship between the instance name and the family name to which is belongs.  If so, perhaps it would be better to have them together as a single type instead of independent fields.  This has the additional advantage that the source could then be a third member of that type.

 

 

Paul Patrick

 

 

 

 

From: Kirillov, Ivan A. [[hidden email]]

Sent: Tuesday, July 21, 2015 6:45 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

I’ve modified the proposal for capturing malware instance/family names, per Terry and Paul’s feedback. Let me know what you think.

 

Regards,

Ivan

 

From: <Kirillov>, Ivan Kirillov <[hidden email]>
Reply-To: Ivan Kirillov <[hidden email]>
Date: Friday, July 17, 2015 at 9:43 AM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Paul, Terry, great discussion. Replies inline below.

 

Regards,

Ivan

 

From: Paul Patrick <[hidden email]>
Reply-To: Paul Patrick <[hidden email]>
Date: Thursday, July 16, 2015 at 5:29 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

 

 

From: Terry MacDonald [[hidden email]]
Sent: Wednesday, July 15, 2015 4:36 PM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Hi Ivan,

 

Replies inline, with the unnecessary sections removed.

Cheers


Terry MacDonald | STIX, TAXII, CybOX Consultant

 

M: <a href="tel:%2B61-407-203-026" target="_blank">+61-407-203-026

 

 

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

  1. Do the defined types, their child properties, their datatypes, and their annotations makes sense? Should they be changed in any way?
    [terry] - My concern by lumping the various names that the malware is known as together into a pair of single fields is that we potentially lose sight of what the malware sample is called by the MAEC producer. I wonder if it is better to separate the aliases out into their own field. i.e. keep the Malware_Instance_Name and Malware_Family_Name (limited to 0-1), but also add Malware_Instance_Aliases and Malware_Family_Aliases (limited 0-N). In this way people can easily discern what the producer calls the malware, and they can also see what others call the malware sample. It allows for others to release details of similar malware under their own family names, and a relationship to still be discerned through the alias fields.

     [Ivan] That’s a good point – with the current approach, it’s unclear where the malware instance/family names (as captured in a MAEC instance document) came from. Capturing aliases as a separate field may be a viable solution, but I’m     

wondering if it might be simpler and more direct to just capture the source using a separate field (probably an @source attribute) for each Malware_Instance_Name and Malware_Family_Name. That way, the producer of the MAEC document can 

specify whether the name came from their own organization (e.g., @source=“MITRE” for me) or somewhere else. It might also be useful to capture a reference URL that goes along with the source (if availble), e.g., for publicly available malware analysis reports where the name may be referenced. What do you think?

 

[Terry] - I'm not so sold on the capturing all family names in a single place. Realistically a producer is not going to know which names came from which other vendors, as some may be produced by 3rd parties, and they may only hear of them second hand. The producer is only going to know a subset of that information. I do think that recording the name of what the producer calls the malware instance is important, and recording the information source is important, but that the alias information is useful, but not important. Ultimately I think a list of alias names should be separate from the malware names, and that it doesn't need a source tag. I also think that what the producer calls the malware instance is important, and that the source of the name could be important for Incident Responders who would like more information on the data.

 

[Paul] – I might suggest that rather than have 2 lists, that you might have a new MalwareAlias type that contains a single member for both name and family.  I would agree that the producer of the MAEC would likely have its own name and that is important.  But I would argue that the alias information is important.  Without alias, it becomes difficult that something reported by one producer can be correlated with another.  For example, image the same malware instance is submitted to multiple online sandboxes that produce results in MAEC format.  It likely that both sandboxes will assign their own unique name but may also be able to relate the instance to a given name and/or corresponding family.  Without the aliases, it’s very difficult to correlate across them.

 

[Ivan] Good point by Terry in that producers are unlikely to always know which names came from which vendors, so having the ability to identify a name as an alias would still be necessary. Paul, I think your point about having the ability to correlate multiple malware instance/family names is also well taken. It sounds like what Paul is suggesting is keeping the Malware_Instance_Name and Malware_Family_Name and then having an additional field (maybe something like Malware_Alias?) that can capture both instance and family aliases via a new MalwareAlias type. This seems sound to me, though it would probably also be useful to capture the source of the alias, if known; I’m still on the side of having a simple @source field to keep things basic and lightweight, and also because we currently can’t use the STIX InformationSourceType – see comments below. What do you guys think?

 

I personally think you should leverage the InformationSourceType available in STIX if you want to tack the source, as that is comprehensive, and a good way of providing whatever level of flexibility the producer wants. It also contains the References section, which could be useful for tracking URLs for more information, if that is something you would like to see tracked within MAEC. 

 

[Paul] – I’m in agreement with Terry wrt leveraging some of the things in STIX (InformationSourceType, common vocabularies …) but I do have a concern of circular dependencies being created.  I think there is likely a number of things in STIX that should actually be in a common place and leveraged by STIX and MAEC.  A common base type of some of this that then could be extended by STIX and/or MAEC would definitely be a step in the right direction and I think the common base type that is based on a lot of what is in STIX would be a good start.

 

[Ivan] Yes, the primary reason that we don’t already import any STIX constructs is because of circular dependencies. Also, from a semantic perspective, it would be quite odd for MAEC to import STIX, given that STIX really sits at a much higher level of abstraction. I completely agree with Paul that we really need a common base “layer” where we can define common concepts like InformationSourceType, ConfidenceMeasureEnum, etc. I personally plan on bringing this up as part of the STIX/CybOX discussion in the OASIS CTI. For now though, we’ll have to make due with either duplicating types or creating divergent implementations. 

 

  1. Does it make sense to have a multiplicity of 0-N (unbounded) for malware instance and malware family names, or should it be bounded to 1?
    [terry] - I woulsd suggest bounded to 1 if you add the Malware_Instance_Aliases and Malware_Family_Aliases (unbounded).
  2. Does it make sense to assign a relative measure of confidence to malware instance and malware family names? Accordingly, do the values in the ConfidenceMeasureEnummake sense?
    [terry] - I would like to align the ConfidenceMeasureEnum values with the values in the STIX confidence (High, Medium, Low, None, Unknown).

     [Ivan] Agreed – I’ll update the proposal to align the values with the ConfidenceMeasureEnum. In the future, it would be nice to be able to use MAEC/STIX/CybOX vocabularies interchangeably. Currently this isn’t possible (at least with respect to STIX <-> MAEC/CybOX) because their vocabularies extend from different base types.

 

[Terry] - I would like to see a lot of things shared across MAEC.STIX/CybOX - Information source, reference URL structures as well as default vocabs. There is a reasonable scope for that. Maybe thats worth bringing up on the OASIS CTI Subcommittees.

 

[Paul] – I second Terry’s suggested.  I think there are already a couple of these types of instance that are emerging with likely more as we move forward.

 

  1. Does it make sense to make this field name change in MAEC?
    [terry] - Yes it makes sense.
  2. Does the proposed name make sense? Are there preferable alternatives?
  1. [terry] - what about renaming it simply 'observables', or 'instance_observables'? This would align somewhat with STIX.

    [Ivan] That would be closer to STIX, but not completely accurate as the field only supports capturing a CybOX Object (cybox:ObjectType). Maybe “Instance_Object” then?

 

[Terry] - Instance_Object could work.

[Paul] I could agree with that

[Ivan] Sounds good. Let’s go with “Instance_Object” then :)

 

Proposal: Deprecate Use of QNames for Ids

  1. Should URIs be used instead of QNames in IDs?
    [terry] - I'm in two minds here. I really dislike QNames as they complicate the processing involved in generating and consuming the XML output of STIX, CYBOX and MAEC. But, I am equally concerned that MAEC will be deprecating the use of QNames in IDs, when there has been no public discussion about doing the same within STIX or CybOX. I would hate for producers and consumers of threat intelligence to be forced to support two different ways of generating IDs within a single library if it could be avoided.

    In other words - has this been discussed with the STIX/CybOX communities to see if they would be open to changing the IDs to use URIs? I think a LOT of people would, but ti would be great to check this out and confirm it before changing MAEC. It would be far better to have MAEC the first of the related protocols to migrate, rather than it be the only one doing this change.

    [Ivan] As Jon mentioned in his response, this has been an outstanding issue for a while in STIX and CybOX, but hasn’t been brought up for explicit discussion because it would not be a backwards compatible change. Accordingly, we chose to do this now in MAEC because we felt it would be a good time (being a major version) to incorporate any backwards-incompatible changes that would be useful. We should certainly check with the STIX/CybOX communities to see if this is something that they may be interested in doing down the road. Also, I definitely agree that having to support multiple ID formats would be painful for content producers (and consumers as well), especially when dealing with embedded MAEC in STIX TTPs. However, with regards to that last point, this won’t be a (potential) issue until STIX is updated to support the embedding of MAEC v5.0 (STIX 1.2.x will be limited to MAEC v4.1).

 

[Terry] - OK, didn't know that. In that case, URIs are better :). 

 

With all the changes being discussed on the STIX/TAXII lists at present regtarding v2.0 or both TAXII and STIX, I wouldn't be surprised if we end up moving away from XML based documents to another structured data format. I'm really pushing for a 'review all the things' mentality for STIX/TAXII, as the opportunities for a major release don't come about very often. It will be interesting to see what impact that will have on MAEC in the future.

 

[Paul] – I think we are an interesting point in time since both STIX and MAEC depend upon CybOX which faces the same issue.  Unless the 3 aren’t updated consistently at roughly the same time, users are going to be faced with understanding different formats.  URIs (be they URLs or URNs) will definitely be better. 

 

[Ivan] Yup. I think we have two options in this regard: make the change now, and assume that STIX and CybOX will follow (which I’d personally say is likely), or wait until STIX and CybOX change and then follow suite. The problem with the former is that it’s not guaranteed that STIX and CybOX will make the same change, and even if they do, it will take a new major version which is probably a year away, at least. The problem with the latter is that it will require a new major version of MAEC, which is one of the reasons that I was leaning towards making the change now. However, given the fact that dealing with multiple ID syntaxes certainly seems painful (and will be a reality in MAEC v5.0 with this change, given that CybOX will still use QNames), perhaps we should table this change until a later date, to make life easier for both consumers and producers.

 

  1. Should VulnerabilityExploitType align as closely as possible with the STIXVulnerabilityType or is it better to take a more flexible approach by defining a new MAEC VulnerabilityReferenceType?
    [terry] - They must align in my opinion. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. There is a lot of benefit to be had by ensuring that consumers can find linkages between vulnerable systems, and malware that exploits those vulnerabilities. For this to happen it is imperative that STIX and MAEC align their descriptions, such that one can make a connection.

    I would posit that as the STIX ExploitTarget is designed to describe vulnerable systems that the STIXVulnerabilityType should be considered the 'standard' for vulnerability description, and that as MAEC is designed to describe malware and the exploits they contain that the MAEC Exploit descriptions should be considered the 'standard' for exploit description, and that they should leverage each others work.

   [Ivan] I definitely agree with your characterization of the purpose of MAEC’s VulnerabilityExploitType and the ExploitTarget from STIX. The main reason that we decided not to completely mirror the fields in the STIX VulnerabilityType is that, currently, the STIX VulnerabilityType is inflexible when it comes to vulnerability references, supporting only CVE and OSVDB. Therefore, there is some expectation that the STIX VulnerabilityType will be updated to accommodate other references (e.g., CWE for the underlying software flaw of the vulnerability). As such, given that STIX functions as the ‘standard’ for vulnerability description (which we 100% agree with), perhaps we should postpone this change and wait for the STIX VulnerabilityType to be updated?

 

[Terry] - It depends if there is urgent need for this at present. We can always make this change and feed back the need for alignment to the CTI STIX Sub-Committee. It all depends if the MAEC Community can wait.

 

[Paul] – I agree with Ivan in that the STIX VulnerabilityType is too restrictive.  If any one looks at the XML schema for CVE or CWE, you’ll see indications that the authors were considering a single VulnerabilityType that could be used to expresses vulnerabilities, weaknesses, and configuration issues.  I would suggest if we look to defining a new VulnerabilityType that it take into consideration that work as well as the unique requirements of STIX and MAEC.  Perhaps this is another instance of where there is a common type that isn’t defined by STIX or MAEC but rather is leveraged/extended by them.  I would also suggest that a closer look be taken as to whether a new vulnerability type should be extended with something like CVE/OSVDB/CWE/CCE (all of which are expressed in XML schemas ONLY) or just reference these external entities.  Part of my thinking is I don’t suspect most producers will likely populate all the fields defined by the extension, but would rather just provide a reference to them, and second these types of extensions result in duplication of data.

 

[Ivan] I don’t think there’s an urgent need for this change (the existing type can capture CVEs, which is the predominant identifier), rather it has been a longstanding issue on our end that we felt was useful to address in a major release. Paul, I agree that this is probably another place where having a common base layer would make sense. I too think that having extensions for the schemas from CVE/OSVDB/CWE/etc. would be overkill for this scenario, so having a fairly expressive VulnerabilityType would probably be the way to go.

 

 

 

 

Reply | Threaded
Open this post in threaded view
|

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

Paul Patrick

Ivan,

 

This makes sense to me and I like the idea of using it for aliases as well.  As for CARO, I’m on-board with your statements.

 

 

Paull

 

 

From: Kirillov, Ivan A. [mailto:[hidden email]]
Sent: Monday, July 27, 2015 7:17 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

So, the crux of this discussion is around capturing associations between Malware Instance and Family names while retaining the ability to parse them into their components. My feeling is that the solution described by Paul below provides a way of doing this without too much additional overhead in terms of structure or complexity, at least with the assumption that the Family name shouldn’t be broken out from the Instance name. The only other way of capturing such associations from my perspective would be to keep the current structure and relate Malware Instance and Family names using first-class relationships, but that seems needlessly messy for such a relatively simple concept. 

 

Also, given Paul’s point about having one place for capturing source information for both Instance and Family names, I’m wondering if we should take this even further and add the corresponding capability to Aliases, along with the ability to capture both Family and Instance names? That way, both Malware_Name and Malware_Alias will be completely consistent in terms of structure, and accordingly we can define a single “MalwareNameType” to use in both.

 

Thus, we’d end up with something like:

 

<Malware_Subject>

    <Malware_Name>

        <Malware_Instance_Name confidence=”Medium”>CryptoLocker.B</Malware_Instance_Name>

        <Malware_Family_Name confidence=”High”>CryptoLocker</Malware_Family_Name>

    </Malware_Name>

    <Malware Aliases>

       <Malware_Alias>

         <Malware_Instance_Name>WORM_CRILOCK.A</Malware_Instance_Name>

         <Source>Trend Micro</Source>

       </Malware_Alias>

    </Malware_Aliases>

</Malware_Subject>

 

Terry, Paul, does that seem workable to you?

 

As far as CARO, I think it’s a useful concept, but from my experience very few AV vendors implement and use it consistently. Accordingly, the discussion of malware names seems to revolve primarily around instances and families, so for this sake and also to keep things simple and lightweight, my preference would be to focus exclusively on capturing instance and family names.

 

Regards,

Ivan

 

From: Paul Patrick <[hidden email]>
Reply-To: Paul Patrick <[hidden email]>
Date: Wednesday, July 22, 2015 at 1:57 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Ivan – thanks for forwarding with the graphic

 

Terry –

I’m completely in agreement with what you’ve described as I too am looking to build graphs, so I think in that respect we’re not the same page.  What I was suggesting was that there is a kind of association between the malware family name and the malware instance name.  What I also was suggesting was that either of those names together may also need to have a source associated with them in order to determine if they form a unique tuple.  By just having an instance name and a family name is not clear if the two are from the same source of different ones.  Adding a @source attribute to each makes it even more confusing.

 

My suggestion was to create a single type Malware_Name which contained members that comprised the name similar to what is achieved by the Computer Antivirus Research Organization (CARO) malware naming convention that is supported by a number of vendors.  Having a Malware_Name type would semantically convey that the family name, instance name, and any other members are associated.  This way a Malware_Name  type could be parsed into its component to form the graph like you’ve drawn below.

 

<Malware_Subject>

    <Malware_Name>

        <Malware_Instance_Name confidence=”Medium”>CryptoLocker.B</Malware_Instance_Name>

        <Malware_Family_Name confidence=”High”>CryptoLocker</Malware_Family_Name>

    </Malware_Name>

</Malware_Subject>

 

If the group were to agree to do down this path, I would suggest that we look closely at the CARO naming scheme to determine if there are other members that should also be represented as members of the Malware_Name type.

 

For those not aware of CARO, it is a naming convention that has been adopted by a number of the AV vendors, to create an identifier based on URI syntax for malware.  It is very similar to what was done for the Common Platform Enumerations (CPE).  Below is an example format where items enclosed between ‘[‘ and ‘]’ are optional.

 

[<malware_type>://][<platform>/]<family_name>[.<group_name>][.<infective_length>][.<sub-variant><devolution>]][<modifiers>]

 

I’m not suggesting that we replace the concept of Malware_Family_Name and Malware_Instance_Name with a CARO formatted value since that would require parsing, using a Malware_Name type based on the components of the CARO would allow MAEC to actually uses the components to build a CARO name that could be used to determine if two different Malware_Subjects created independently are actually referring to the same thing.

 

One other suggestion I might make based on the use of a Malware_Name type is that the Malware_Alias could actually be a reference (e.g., idref) so that MAEC could consistently refer to the same name in multiple places.

 

Hope this helps clarify what I was trying to convey.

 

 

Paul Patrick

 

From: Kirillov, Ivan A. [[hidden email]]
Sent: Wednesday, July 22, 2015 5:58 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Resending Terry’s post below, as it was bounced from the listserv because it contained an image. I’ve since enabled image attachments.

 

Regards,

Ivan

 

From: Terry MacDonald <[hidden email]>
Date: Tuesday, July 21, 2015 at 7:26 PM
To: Ivan Kirillov <[hidden email]>
Cc: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Hi All,

 

Regarding [2], having a relationship, and having them the same field are two different things in my opinion. We need to determine if anyone would ever need to map out relationships based on the Malware_Instance_Name as distinct from he Malware_Family_Name at any stage before we obfuscate that relationship with the structure changes.

 

By drawing a graph of the relationships as proposed by Ivan we get this: 

Inline images 1

 

This structure allows me to easily look for all instance names, so I could extract those and possibly look for searches of those names in outputs from other tools. 

 

Using a neo4j example: 

 

MATCH (cryptolocker:MalwareFamilyName {value: 'CryptoLocker'})<-[:IS_PART_OF_THE_FAMILY_OF]-()-[:IS_AN_INSTANCE_OF|:IS_ALSO_KNOWN_AS]->(malwarenames) RETURN malwarenames.value

 

would return:

 

Inline images 2

I really don't like the idea that we would squash them all together to lose that flexibility to pull them all apart again. 

 

Cheers


Terry MacDonald | STIX, TAXII, CybOX Consultant

 

M: +61-407-203-026

 

 

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

 

 

On 22 July 2015 at 03:11, Kirillov, Ivan A. <[hidden email]> wrote:

Thanks Paul. I think both points are quite sensible:

 

[1] Agreed – I don’t see why we can’t add a similar @source field to Malware_Instance_Name and Malware_Family_Name.

 

[2] I can’t think of any cases where, if both Malware_Instance_Name and Malware_Family_Name are specified, that there is not an implicit relationship stating that the instance belongs to the specified family. I agree that having a single field that encompasses both would make this clearer, and would still permit capturing the instance or family name separately. Does this make sense to everyone else?

 

Regards,

Ivan

 

From: Paul Patrick <[hidden email]>
Date: Tuesday, July 21, 2015 at 12:06 PM
To: Ivan Kirillov <[hidden email]>, maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: RE: [MAEC] MAEC v5.0 Proposals - Round 1

 

Ivan,

 

I think the revised proposal is much better, but got a couple more questions:

 

[1] I see we a means to specify a source for the alias but we don’t have a means to capture the source for the malware instance/family.  Perhaps we should add support for that

 

[2] I wondering if people see the Malware_Instance_Name and the Malware_Family_Name coupled where there is an implied relationship between the instance name and the family name to which is belongs.  If so, perhaps it would be better to have them together as a single type instead of independent fields.  This has the additional advantage that the source could then be a third member of that type.

 

 

Paul Patrick

 

 

 

 

From: Kirillov, Ivan A. [[hidden email]]

Sent: Tuesday, July 21, 2015 6:45 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

I’ve modified the proposal for capturing malware instance/family names, per Terry and Paul’s feedback. Let me know what you think.

 

Regards,

Ivan

 

From: <Kirillov>, Ivan Kirillov <[hidden email]>
Reply-To: Ivan Kirillov <[hidden email]>
Date: Friday, July 17, 2015 at 9:43 AM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Paul, Terry, great discussion. Replies inline below.

 

Regards,

Ivan

 

From: Paul Patrick <[hidden email]>
Reply-To: Paul Patrick <[hidden email]>
Date: Thursday, July 16, 2015 at 5:29 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

 

 

From: Terry MacDonald [[hidden email]]
Sent: Wednesday, July 15, 2015 4:36 PM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Hi Ivan,

 

Replies inline, with the unnecessary sections removed.

Cheers


Terry MacDonald | STIX, TAXII, CybOX Consultant

 

M: <a href="tel:%2B61-407-203-026" target="_blank">+61-407-203-026

 

 

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

  1. Do the defined types, their child properties, their datatypes, and their annotations makes sense? Should they be changed in any way?
    [terry] - My concern by lumping the various names that the malware is known as together into a pair of single fields is that we potentially lose sight of what the malware sample is called by the MAEC producer. I wonder if it is better to separate the aliases out into their own field. i.e. keep the Malware_Instance_Name and Malware_Family_Name (limited to 0-1), but also add Malware_Instance_Aliases and Malware_Family_Aliases (limited 0-N). In this way people can easily discern what the producer calls the malware, and they can also see what others call the malware sample. It allows for others to release details of similar malware under their own family names, and a relationship to still be discerned through the alias fields.

     [Ivan] That’s a good point – with the current approach, it’s unclear where the malware instance/family names (as captured in a MAEC instance document) came from. Capturing aliases as a separate field may be a viable solution, but I’m     

wondering if it might be simpler and more direct to just capture the source using a separate field (probably an @source attribute) for each Malware_Instance_Name and Malware_Family_Name. That way, the producer of the MAEC document can 

specify whether the name came from their own organization (e.g., @source=“MITRE” for me) or somewhere else. It might also be useful to capture a reference URL that goes along with the source (if availble), e.g., for publicly available malware analysis reports where the name may be referenced. What do you think?

 

[Terry] - I'm not so sold on the capturing all family names in a single place. Realistically a producer is not going to know which names came from which other vendors, as some may be produced by 3rd parties, and they may only hear of them second hand. The producer is only going to know a subset of that information. I do think that recording the name of what the producer calls the malware instance is important, and recording the information source is important, but that the alias information is useful, but not important. Ultimately I think a list of alias names should be separate from the malware names, and that it doesn't need a source tag. I also think that what the producer calls the malware instance is important, and that the source of the name could be important for Incident Responders who would like more information on the data.

 

[Paul] – I might suggest that rather than have 2 lists, that you might have a new MalwareAlias type that contains a single member for both name and family.  I would agree that the producer of the MAEC would likely have its own name and that is important.  But I would argue that the alias information is important.  Without alias, it becomes difficult that something reported by one producer can be correlated with another.  For example, image the same malware instance is submitted to multiple online sandboxes that produce results in MAEC format.  It likely that both sandboxes will assign their own unique name but may also be able to relate the instance to a given name and/or corresponding family.  Without the aliases, it’s very difficult to correlate across them.

 

[Ivan] Good point by Terry in that producers are unlikely to always know which names came from which vendors, so having the ability to identify a name as an alias would still be necessary. Paul, I think your point about having the ability to correlate multiple malware instance/family names is also well taken. It sounds like what Paul is suggesting is keeping the Malware_Instance_Name and Malware_Family_Name and then having an additional field (maybe something like Malware_Alias?) that can capture both instance and family aliases via a new MalwareAlias type. This seems sound to me, though it would probably also be useful to capture the source of the alias, if known; I’m still on the side of having a simple @source field to keep things basic and lightweight, and also because we currently can’t use the STIX InformationSourceType – see comments below. What do you guys think?

 

I personally think you should leverage the InformationSourceType available in STIX if you want to tack the source, as that is comprehensive, and a good way of providing whatever level of flexibility the producer wants. It also contains the References section, which could be useful for tracking URLs for more information, if that is something you would like to see tracked within MAEC. 

 

[Paul] – I’m in agreement with Terry wrt leveraging some of the things in STIX (InformationSourceType, common vocabularies …) but I do have a concern of circular dependencies being created.  I think there is likely a number of things in STIX that should actually be in a common place and leveraged by STIX and MAEC.  A common base type of some of this that then could be extended by STIX and/or MAEC would definitely be a step in the right direction and I think the common base type that is based on a lot of what is in STIX would be a good start.

 

[Ivan] Yes, the primary reason that we don’t already import any STIX constructs is because of circular dependencies. Also, from a semantic perspective, it would be quite odd for MAEC to import STIX, given that STIX really sits at a much higher level of abstraction. I completely agree with Paul that we really need a common base “layer” where we can define common concepts like InformationSourceType, ConfidenceMeasureEnum, etc. I personally plan on bringing this up as part of the STIX/CybOX discussion in the OASIS CTI. For now though, we’ll have to make due with either duplicating types or creating divergent implementations. 

 

  1. Does it make sense to have a multiplicity of 0-N (unbounded) for malware instance and malware family names, or should it be bounded to 1?
    [terry] - I woulsd suggest bounded to 1 if you add the Malware_Instance_Aliases and Malware_Family_Aliases (unbounded).
  2. Does it make sense to assign a relative measure of confidence to malware instance and malware family names? Accordingly, do the values in the ConfidenceMeasureEnummake sense?
    [terry] - I would like to align the ConfidenceMeasureEnum values with the values in the STIX confidence (High, Medium, Low, None, Unknown).

     [Ivan] Agreed – I’ll update the proposal to align the values with the ConfidenceMeasureEnum. In the future, it would be nice to be able to use MAEC/STIX/CybOX vocabularies interchangeably. Currently this isn’t possible (at least with respect to STIX <-> MAEC/CybOX) because their vocabularies extend from different base types.

 

[Terry] - I would like to see a lot of things shared across MAEC.STIX/CybOX - Information source, reference URL structures as well as default vocabs. There is a reasonable scope for that. Maybe thats worth bringing up on the OASIS CTI Subcommittees.

 

[Paul] – I second Terry’s suggested.  I think there are already a couple of these types of instance that are emerging with likely more as we move forward.

 

  1. Does it make sense to make this field name change in MAEC?
    [terry] - Yes it makes sense.
  2. Does the proposed name make sense? Are there preferable alternatives?
  1. [terry] - what about renaming it simply 'observables', or 'instance_observables'? This would align somewhat with STIX.

    [Ivan] That would be closer to STIX, but not completely accurate as the field only supports capturing a CybOX Object (cybox:ObjectType). Maybe “Instance_Object” then?

 

[Terry] - Instance_Object could work.

[Paul] I could agree with that

[Ivan] Sounds good. Let’s go with “Instance_Object” then :)

 

Proposal: Deprecate Use of QNames for Ids

  1. Should URIs be used instead of QNames in IDs?
    [terry] - I'm in two minds here. I really dislike QNames as they complicate the processing involved in generating and consuming the XML output of STIX, CYBOX and MAEC. But, I am equally concerned that MAEC will be deprecating the use of QNames in IDs, when there has been no public discussion about doing the same within STIX or CybOX. I would hate for producers and consumers of threat intelligence to be forced to support two different ways of generating IDs within a single library if it could be avoided.

    In other words - has this been discussed with the STIX/CybOX communities to see if they would be open to changing the IDs to use URIs? I think a LOT of people would, but ti would be great to check this out and confirm it before changing MAEC. It would be far better to have MAEC the first of the related protocols to migrate, rather than it be the only one doing this change.

    [Ivan] As Jon mentioned in his response, this has been an outstanding issue for a while in STIX and CybOX, but hasn’t been brought up for explicit discussion because it would not be a backwards compatible change. Accordingly, we chose to do this now in MAEC because we felt it would be a good time (being a major version) to incorporate any backwards-incompatible changes that would be useful. We should certainly check with the STIX/CybOX communities to see if this is something that they may be interested in doing down the road. Also, I definitely agree that having to support multiple ID formats would be painful for content producers (and consumers as well), especially when dealing with embedded MAEC in STIX TTPs. However, with regards to that last point, this won’t be a (potential) issue until STIX is updated to support the embedding of MAEC v5.0 (STIX 1.2.x will be limited to MAEC v4.1).

 

[Terry] - OK, didn't know that. In that case, URIs are better :). 

 

With all the changes being discussed on the STIX/TAXII lists at present regtarding v2.0 or both TAXII and STIX, I wouldn't be surprised if we end up moving away from XML based documents to another structured data format. I'm really pushing for a 'review all the things' mentality for STIX/TAXII, as the opportunities for a major release don't come about very often. It will be interesting to see what impact that will have on MAEC in the future.

 

[Paul] – I think we are an interesting point in time since both STIX and MAEC depend upon CybOX which faces the same issue.  Unless the 3 aren’t updated consistently at roughly the same time, users are going to be faced with understanding different formats.  URIs (be they URLs or URNs) will definitely be better. 

 

[Ivan] Yup. I think we have two options in this regard: make the change now, and assume that STIX and CybOX will follow (which I’d personally say is likely), or wait until STIX and CybOX change and then follow suite. The problem with the former is that it’s not guaranteed that STIX and CybOX will make the same change, and even if they do, it will take a new major version which is probably a year away, at least. The problem with the latter is that it will require a new major version of MAEC, which is one of the reasons that I was leaning towards making the change now. However, given the fact that dealing with multiple ID syntaxes certainly seems painful (and will be a reality in MAEC v5.0 with this change, given that CybOX will still use QNames), perhaps we should table this change until a later date, to make life easier for both consumers and producers.

 

  1. Should VulnerabilityExploitType align as closely as possible with the STIXVulnerabilityType or is it better to take a more flexible approach by defining a new MAEC VulnerabilityReferenceType?
    [terry] - They must align in my opinion. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. There is a lot of benefit to be had by ensuring that consumers can find linkages between vulnerable systems, and malware that exploits those vulnerabilities. For this to happen it is imperative that STIX and MAEC align their descriptions, such that one can make a connection.

    I would posit that as the STIX ExploitTarget is designed to describe vulnerable systems that the STIXVulnerabilityType should be considered the 'standard' for vulnerability description, and that as MAEC is designed to describe malware and the exploits they contain that the MAEC Exploit descriptions should be considered the 'standard' for exploit description, and that they should leverage each others work.

   [Ivan] I definitely agree with your characterization of the purpose of MAEC’s VulnerabilityExploitType and the ExploitTarget from STIX. The main reason that we decided not to completely mirror the fields in the STIX VulnerabilityType is that, currently, the STIX VulnerabilityType is inflexible when it comes to vulnerability references, supporting only CVE and OSVDB. Therefore, there is some expectation that the STIX VulnerabilityType will be updated to accommodate other references (e.g., CWE for the underlying software flaw of the vulnerability). As such, given that STIX functions as the ‘standard’ for vulnerability description (which we 100% agree with), perhaps we should postpone this change and wait for the STIX VulnerabilityType to be updated?

 

[Terry] - It depends if there is urgent need for this at present. We can always make this change and feed back the need for alignment to the CTI STIX Sub-Committee. It all depends if the MAEC Community can wait.

 

[Paul] – I agree with Ivan in that the STIX VulnerabilityType is too restrictive.  If any one looks at the XML schema for CVE or CWE, you’ll see indications that the authors were considering a single VulnerabilityType that could be used to expresses vulnerabilities, weaknesses, and configuration issues.  I would suggest if we look to defining a new VulnerabilityType that it take into consideration that work as well as the unique requirements of STIX and MAEC.  Perhaps this is another instance of where there is a common type that isn’t defined by STIX or MAEC but rather is leveraged/extended by them.  I would also suggest that a closer look be taken as to whether a new vulnerability type should be extended with something like CVE/OSVDB/CWE/CCE (all of which are expressed in XML schemas ONLY) or just reference these external entities.  Part of my thinking is I don’t suspect most producers will likely populate all the fields defined by the extension, but would rather just provide a reference to them, and second these types of extensions result in duplication of data.

 

[Ivan] I don’t think there’s an urgent need for this change (the existing type can capture CVEs, which is the predominant identifier), rather it has been a longstanding issue on our end that we felt was useful to address in a major release. Paul, I agree that this is probably another place where having a common base layer would make sense. I too think that having extensions for the schemas from CVE/OSVDB/CWE/etc. would be overkill for this scenario, so having a fairly expressive VulnerabilityType would probably be the way to go.

 

 

 

 

Reply | Threaded
Open this post in threaded view
|

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

Terry MacDonald
Hi Ivan,

Yep, I like that structure as well.

Cheers
Terry MacDonald


On 28 July 2015 at 05:20, Paul B. Patrick <[hidden email]> wrote:

Ivan,

 

This makes sense to me and I like the idea of using it for aliases as well.  As for CARO, I’m on-board with your statements.

 

 

Paull

 

 

From: Kirillov, Ivan A. [mailto:[hidden email]]
Sent: Monday, July 27, 2015 7:17 AM


To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

So, the crux of this discussion is around capturing associations between Malware Instance and Family names while retaining the ability to parse them into their components. My feeling is that the solution described by Paul below provides a way of doing this without too much additional overhead in terms of structure or complexity, at least with the assumption that the Family name shouldn’t be broken out from the Instance name. The only other way of capturing such associations from my perspective would be to keep the current structure and relate Malware Instance and Family names using first-class relationships, but that seems needlessly messy for such a relatively simple concept. 

 

Also, given Paul’s point about having one place for capturing source information for both Instance and Family names, I’m wondering if we should take this even further and add the corresponding capability to Aliases, along with the ability to capture both Family and Instance names? That way, both Malware_Name and Malware_Alias will be completely consistent in terms of structure, and accordingly we can define a single “MalwareNameType” to use in both.

 

Thus, we’d end up with something like:

 

<Malware_Subject>

    <Malware_Name>

        <Malware_Instance_Name confidence=”Medium”>CryptoLocker.B</Malware_Instance_Name>

        <Malware_Family_Name confidence=”High”>CryptoLocker</Malware_Family_Name>

    </Malware_Name>

    <Malware Aliases>

       <Malware_Alias>

         <Malware_Instance_Name>WORM_CRILOCK.A</Malware_Instance_Name>

         <Source>Trend Micro</Source>

       </Malware_Alias>

    </Malware_Aliases>

</Malware_Subject>

 

Terry, Paul, does that seem workable to you?

 

As far as CARO, I think it’s a useful concept, but from my experience very few AV vendors implement and use it consistently. Accordingly, the discussion of malware names seems to revolve primarily around instances and families, so for this sake and also to keep things simple and lightweight, my preference would be to focus exclusively on capturing instance and family names.

 

Regards,

Ivan

 

From: Paul Patrick <[hidden email]>
Reply-To: Paul Patrick <[hidden email]>
Date: Wednesday, July 22, 2015 at 1:57 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Ivan – thanks for forwarding with the graphic

 

Terry –

I’m completely in agreement with what you’ve described as I too am looking to build graphs, so I think in that respect we’re not the same page.  What I was suggesting was that there is a kind of association between the malware family name and the malware instance name.  What I also was suggesting was that either of those names together may also need to have a source associated with them in order to determine if they form a unique tuple.  By just having an instance name and a family name is not clear if the two are from the same source of different ones.  Adding a @source attribute to each makes it even more confusing.

 

My suggestion was to create a single type Malware_Name which contained members that comprised the name similar to what is achieved by the Computer Antivirus Research Organization (CARO) malware naming convention that is supported by a number of vendors.  Having a Malware_Name type would semantically convey that the family name, instance name, and any other members are associated.  This way a Malware_Name  type could be parsed into its component to form the graph like you’ve drawn below.

 

<Malware_Subject>

    <Malware_Name>

        <Malware_Instance_Name confidence=”Medium”>CryptoLocker.B</Malware_Instance_Name>

        <Malware_Family_Name confidence=”High”>CryptoLocker</Malware_Family_Name>

    </Malware_Name>

</Malware_Subject>

 

If the group were to agree to do down this path, I would suggest that we look closely at the CARO naming scheme to determine if there are other members that should also be represented as members of the Malware_Name type.

 

For those not aware of CARO, it is a naming convention that has been adopted by a number of the AV vendors, to create an identifier based on URI syntax for malware.  It is very similar to what was done for the Common Platform Enumerations (CPE).  Below is an example format where items enclosed between ‘[‘ and ‘]’ are optional.

 

[<malware_type>://][<platform>/]<family_name>[.<group_name>][.<infective_length>][.<sub-variant><devolution>]][<modifiers>]

 

I’m not suggesting that we replace the concept of Malware_Family_Name and Malware_Instance_Name with a CARO formatted value since that would require parsing, using a Malware_Name type based on the components of the CARO would allow MAEC to actually uses the components to build a CARO name that could be used to determine if two different Malware_Subjects created independently are actually referring to the same thing.

 

One other suggestion I might make based on the use of a Malware_Name type is that the Malware_Alias could actually be a reference (e.g., idref) so that MAEC could consistently refer to the same name in multiple places.

 

Hope this helps clarify what I was trying to convey.

 

 

Paul Patrick

 

From: Kirillov, Ivan A. [[hidden email]]
Sent: Wednesday, July 22, 2015 5:58 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Resending Terry’s post below, as it was bounced from the listserv because it contained an image. I’ve since enabled image attachments.

 

Regards,

Ivan

 

From: Terry MacDonald <[hidden email]>
Date: Tuesday, July 21, 2015 at 7:26 PM
To: Ivan Kirillov <[hidden email]>
Cc: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Hi All,

 

Regarding [2], having a relationship, and having them the same field are two different things in my opinion. We need to determine if anyone would ever need to map out relationships based on the Malware_Instance_Name as distinct from he Malware_Family_Name at any stage before we obfuscate that relationship with the structure changes.

 

By drawing a graph of the relationships as proposed by Ivan we get this: 

Inline images 1

 

This structure allows me to easily look for all instance names, so I could extract those and possibly look for searches of those names in outputs from other tools. 

 

Using a neo4j example: 

 

MATCH (cryptolocker:MalwareFamilyName {value: 'CryptoLocker'})<-[:IS_PART_OF_THE_FAMILY_OF]-()-[:IS_AN_INSTANCE_OF|:IS_ALSO_KNOWN_AS]->(malwarenames) RETURN malwarenames.value

 

would return:

 

Inline images 2

I really don't like the idea that we would squash them all together to lose that flexibility to pull them all apart again. 

 

Cheers


Terry MacDonald | STIX, TAXII, CybOX Consultant

 

M: <a href="tel:%2B61-407-203-026" value="+61407203026" target="_blank">+61-407-203-026

 

 

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

 

 

On 22 July 2015 at 03:11, Kirillov, Ivan A. <[hidden email]> wrote:

Thanks Paul. I think both points are quite sensible:

 

[1] Agreed – I don’t see why we can’t add a similar @source field to Malware_Instance_Name and Malware_Family_Name.

 

[2] I can’t think of any cases where, if both Malware_Instance_Name and Malware_Family_Name are specified, that there is not an implicit relationship stating that the instance belongs to the specified family. I agree that having a single field that encompasses both would make this clearer, and would still permit capturing the instance or family name separately. Does this make sense to everyone else?

 

Regards,

Ivan

 

From: Paul Patrick <[hidden email]>
Date: Tuesday, July 21, 2015 at 12:06 PM
To: Ivan Kirillov <[hidden email]>, maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: RE: [MAEC] MAEC v5.0 Proposals - Round 1

 

Ivan,

 

I think the revised proposal is much better, but got a couple more questions:

 

[1] I see we a means to specify a source for the alias but we don’t have a means to capture the source for the malware instance/family.  Perhaps we should add support for that

 

[2] I wondering if people see the Malware_Instance_Name and the Malware_Family_Name coupled where there is an implied relationship between the instance name and the family name to which is belongs.  If so, perhaps it would be better to have them together as a single type instead of independent fields.  This has the additional advantage that the source could then be a third member of that type.

 

 

Paul Patrick

 

 

 

 

From: Kirillov, Ivan A. [[hidden email]]

Sent: Tuesday, July 21, 2015 6:45 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

I’ve modified the proposal for capturing malware instance/family names, per Terry and Paul’s feedback. Let me know what you think.

 

Regards,

Ivan

 

From: <Kirillov>, Ivan Kirillov <[hidden email]>
Reply-To: Ivan Kirillov <[hidden email]>
Date: Friday, July 17, 2015 at 9:43 AM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Paul, Terry, great discussion. Replies inline below.

 

Regards,

Ivan

 

From: Paul Patrick <[hidden email]>
Reply-To: Paul Patrick <[hidden email]>
Date: Thursday, July 16, 2015 at 5:29 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

 

 

From: Terry MacDonald [[hidden email]]
Sent: Wednesday, July 15, 2015 4:36 PM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Hi Ivan,

 

Replies inline, with the unnecessary sections removed.

Cheers


Terry MacDonald | STIX, TAXII, CybOX Consultant

 

M: <a href="tel:%2B61-407-203-026" target="_blank">+61-407-203-026

 

 

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

  1. Do the defined types, their child properties, their datatypes, and their annotations makes sense? Should they be changed in any way?
    [terry] - My concern by lumping the various names that the malware is known as together into a pair of single fields is that we potentially lose sight of what the malware sample is called by the MAEC producer. I wonder if it is better to separate the aliases out into their own field. i.e. keep the Malware_Instance_Name and Malware_Family_Name (limited to 0-1), but also add Malware_Instance_Aliases and Malware_Family_Aliases (limited 0-N). In this way people can easily discern what the producer calls the malware, and they can also see what others call the malware sample. It allows for others to release details of similar malware under their own family names, and a relationship to still be discerned through the alias fields.

     [Ivan] That’s a good point – with the current approach, it’s unclear where the malware instance/family names (as captured in a MAEC instance document) came from. Capturing aliases as a separate field may be a viable solution, but I’m     

wondering if it might be simpler and more direct to just capture the source using a separate field (probably an @source attribute) for each Malware_Instance_Name and Malware_Family_Name. That way, the producer of the MAEC document can 

specify whether the name came from their own organization (e.g., @source=“MITRE” for me) or somewhere else. It might also be useful to capture a reference URL that goes along with the source (if availble), e.g., for publicly available malware analysis reports where the name may be referenced. What do you think?

 

[Terry] - I'm not so sold on the capturing all family names in a single place. Realistically a producer is not going to know which names came from which other vendors, as some may be produced by 3rd parties, and they may only hear of them second hand. The producer is only going to know a subset of that information. I do think that recording the name of what the producer calls the malware instance is important, and recording the information source is important, but that the alias information is useful, but not important. Ultimately I think a list of alias names should be separate from the malware names, and that it doesn't need a source tag. I also think that what the producer calls the malware instance is important, and that the source of the name could be important for Incident Responders who would like more information on the data.

 

[Paul] – I might suggest that rather than have 2 lists, that you might have a new MalwareAlias type that contains a single member for both name and family.  I would agree that the producer of the MAEC would likely have its own name and that is important.  But I would argue that the alias information is important.  Without alias, it becomes difficult that something reported by one producer can be correlated with another.  For example, image the same malware instance is submitted to multiple online sandboxes that produce results in MAEC format.  It likely that both sandboxes will assign their own unique name but may also be able to relate the instance to a given name and/or corresponding family.  Without the aliases, it’s very difficult to correlate across them.

 

[Ivan] Good point by Terry in that producers are unlikely to always know which names came from which vendors, so having the ability to identify a name as an alias would still be necessary. Paul, I think your point about having the ability to correlate multiple malware instance/family names is also well taken. It sounds like what Paul is suggesting is keeping the Malware_Instance_Name and Malware_Family_Name and then having an additional field (maybe something like Malware_Alias?) that can capture both instance and family aliases via a new MalwareAlias type. This seems sound to me, though it would probably also be useful to capture the source of the alias, if known; I’m still on the side of having a simple @source field to keep things basic and lightweight, and also because we currently can’t use the STIX InformationSourceType – see comments below. What do you guys think?

 

I personally think you should leverage the InformationSourceType available in STIX if you want to tack the source, as that is comprehensive, and a good way of providing whatever level of flexibility the producer wants. It also contains the References section, which could be useful for tracking URLs for more information, if that is something you would like to see tracked within MAEC. 

 

[Paul] – I’m in agreement with Terry wrt leveraging some of the things in STIX (InformationSourceType, common vocabularies …) but I do have a concern of circular dependencies being created.  I think there is likely a number of things in STIX that should actually be in a common place and leveraged by STIX and MAEC.  A common base type of some of this that then could be extended by STIX and/or MAEC would definitely be a step in the right direction and I think the common base type that is based on a lot of what is in STIX would be a good start.

 

[Ivan] Yes, the primary reason that we don’t already import any STIX constructs is because of circular dependencies. Also, from a semantic perspective, it would be quite odd for MAEC to import STIX, given that STIX really sits at a much higher level of abstraction. I completely agree with Paul that we really need a common base “layer” where we can define common concepts like InformationSourceType, ConfidenceMeasureEnum, etc. I personally plan on bringing this up as part of the STIX/CybOX discussion in the OASIS CTI. For now though, we’ll have to make due with either duplicating types or creating divergent implementations. 

 

  1. Does it make sense to have a multiplicity of 0-N (unbounded) for malware instance and malware family names, or should it be bounded to 1?
    [terry] - I woulsd suggest bounded to 1 if you add the Malware_Instance_Aliases and Malware_Family_Aliases (unbounded).
  2. Does it make sense to assign a relative measure of confidence to malware instance and malware family names? Accordingly, do the values in the ConfidenceMeasureEnummake sense?
    [terry] - I would like to align the ConfidenceMeasureEnum values with the values in the STIX confidence (High, Medium, Low, None, Unknown).

     [Ivan] Agreed – I’ll update the proposal to align the values with the ConfidenceMeasureEnum. In the future, it would be nice to be able to use MAEC/STIX/CybOX vocabularies interchangeably. Currently this isn’t possible (at least with respect to STIX <-> MAEC/CybOX) because their vocabularies extend from different base types.

 

[Terry] - I would like to see a lot of things shared across MAEC.STIX/CybOX - Information source, reference URL structures as well as default vocabs. There is a reasonable scope for that. Maybe thats worth bringing up on the OASIS CTI Subcommittees.

 

[Paul] – I second Terry’s suggested.  I think there are already a couple of these types of instance that are emerging with likely more as we move forward.

 

  1. Does it make sense to make this field name change in MAEC?
    [terry] - Yes it makes sense.
  2. Does the proposed name make sense? Are there preferable alternatives?
  1. [terry] - what about renaming it simply 'observables', or 'instance_observables'? This would align somewhat with STIX.

    [Ivan] That would be closer to STIX, but not completely accurate as the field only supports capturing a CybOX Object (cybox:ObjectType). Maybe “Instance_Object” then?

 

[Terry] - Instance_Object could work.

[Paul] I could agree with that

[Ivan] Sounds good. Let’s go with “Instance_Object” then :)

 

Proposal: Deprecate Use of QNames for Ids

  1. Should URIs be used instead of QNames in IDs?
    [terry] - I'm in two minds here. I really dislike QNames as they complicate the processing involved in generating and consuming the XML output of STIX, CYBOX and MAEC. But, I am equally concerned that MAEC will be deprecating the use of QNames in IDs, when there has been no public discussion about doing the same within STIX or CybOX. I would hate for producers and consumers of threat intelligence to be forced to support two different ways of generating IDs within a single library if it could be avoided.

    In other words - has this been discussed with the STIX/CybOX communities to see if they would be open to changing the IDs to use URIs? I think a LOT of people would, but ti would be great to check this out and confirm it before changing MAEC. It would be far better to have MAEC the first of the related protocols to migrate, rather than it be the only one doing this change.

    [Ivan] As Jon mentioned in his response, this has been an outstanding issue for a while in STIX and CybOX, but hasn’t been brought up for explicit discussion because it would not be a backwards compatible change. Accordingly, we chose to do this now in MAEC because we felt it would be a good time (being a major version) to incorporate any backwards-incompatible changes that would be useful. We should certainly check with the STIX/CybOX communities to see if this is something that they may be interested in doing down the road. Also, I definitely agree that having to support multiple ID formats would be painful for content producers (and consumers as well), especially when dealing with embedded MAEC in STIX TTPs. However, with regards to that last point, this won’t be a (potential) issue until STIX is updated to support the embedding of MAEC v5.0 (STIX 1.2.x will be limited to MAEC v4.1).

 

[Terry] - OK, didn't know that. In that case, URIs are better :). 

 

With all the changes being discussed on the STIX/TAXII lists at present regtarding v2.0 or both TAXII and STIX, I wouldn't be surprised if we end up moving away from XML based documents to another structured data format. I'm really pushing for a 'review all the things' mentality for STIX/TAXII, as the opportunities for a major release don't come about very often. It will be interesting to see what impact that will have on MAEC in the future.

 

[Paul] – I think we are an interesting point in time since both STIX and MAEC depend upon CybOX which faces the same issue.  Unless the 3 aren’t updated consistently at roughly the same time, users are going to be faced with understanding different formats.  URIs (be they URLs or URNs) will definitely be better. 

 

[Ivan] Yup. I think we have two options in this regard: make the change now, and assume that STIX and CybOX will follow (which I’d personally say is likely), or wait until STIX and CybOX change and then follow suite. The problem with the former is that it’s not guaranteed that STIX and CybOX will make the same change, and even if they do, it will take a new major version which is probably a year away, at least. The problem with the latter is that it will require a new major version of MAEC, which is one of the reasons that I was leaning towards making the change now. However, given the fact that dealing with multiple ID syntaxes certainly seems painful (and will be a reality in MAEC v5.0 with this change, given that CybOX will still use QNames), perhaps we should table this change until a later date, to make life easier for both consumers and producers.

 

  1. Should VulnerabilityExploitType align as closely as possible with the STIXVulnerabilityType or is it better to take a more flexible approach by defining a new MAEC VulnerabilityReferenceType?
    [terry] - They must align in my opinion. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. There is a lot of benefit to be had by ensuring that consumers can find linkages between vulnerable systems, and malware that exploits those vulnerabilities. For this to happen it is imperative that STIX and MAEC align their descriptions, such that one can make a connection.

    I would posit that as the STIX ExploitTarget is designed to describe vulnerable systems that the STIXVulnerabilityType should be considered the 'standard' for vulnerability description, and that as MAEC is designed to describe malware and the exploits they contain that the MAEC Exploit descriptions should be considered the 'standard' for exploit description, and that they should leverage each others work.

   [Ivan] I definitely agree with your characterization of the purpose of MAEC’s VulnerabilityExploitType and the ExploitTarget from STIX. The main reason that we decided not to completely mirror the fields in the STIX VulnerabilityType is that, currently, the STIX VulnerabilityType is inflexible when it comes to vulnerability references, supporting only CVE and OSVDB. Therefore, there is some expectation that the STIX VulnerabilityType will be updated to accommodate other references (e.g., CWE for the underlying software flaw of the vulnerability). As such, given that STIX functions as the ‘standard’ for vulnerability description (which we 100% agree with), perhaps we should postpone this change and wait for the STIX VulnerabilityType to be updated?

 

[Terry] - It depends if there is urgent need for this at present. We can always make this change and feed back the need for alignment to the CTI STIX Sub-Committee. It all depends if the MAEC Community can wait.

 

[Paul] – I agree with Ivan in that the STIX VulnerabilityType is too restrictive.  If any one looks at the XML schema for CVE or CWE, you’ll see indications that the authors were considering a single VulnerabilityType that could be used to expresses vulnerabilities, weaknesses, and configuration issues.  I would suggest if we look to defining a new VulnerabilityType that it take into consideration that work as well as the unique requirements of STIX and MAEC.  Perhaps this is another instance of where there is a common type that isn’t defined by STIX or MAEC but rather is leveraged/extended by them.  I would also suggest that a closer look be taken as to whether a new vulnerability type should be extended with something like CVE/OSVDB/CWE/CCE (all of which are expressed in XML schemas ONLY) or just reference these external entities.  Part of my thinking is I don’t suspect most producers will likely populate all the fields defined by the extension, but would rather just provide a reference to them, and second these types of extensions result in duplication of data.

 

[Ivan] I don’t think there’s an urgent need for this change (the existing type can capture CVEs, which is the predominant identifier), rather it has been a longstanding issue on our end that we felt was useful to address in a major release. Paul, I agree that this is probably another place where having a common base layer would make sense. I too think that having extensions for the schemas from CVE/OSVDB/CWE/etc. would be overkill for this scenario, so having a fairly expressive VulnerabilityType would probably be the way to go.

 

 

 

 


Reply | Threaded
Open this post in threaded view
|

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

Kirillov, Ivan A.
Thanks Terry and Paul. I’ve updated the proposal accordingly:
Regards,
Ivan

From: Terry MacDonald
Reply-To: Terry MacDonald
Date: Monday, July 27, 2015 at 6:13 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

Hi Ivan,

Yep, I like that structure as well.

Cheers
Terry MacDonald


On 28 July 2015 at 05:20, Paul B. Patrick <[hidden email]> wrote:

Ivan,

 

This makes sense to me and I like the idea of using it for aliases as well.  As for CARO, I’m on-board with your statements.

 

 

Paull

 

 

From: Kirillov, Ivan A. [mailto:[hidden email]]
Sent: Monday, July 27, 2015 7:17 AM


To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

So, the crux of this discussion is around capturing associations between Malware Instance and Family names while retaining the ability to parse them into their components. My feeling is that the solution described by Paul below provides a way of doing this without too much additional overhead in terms of structure or complexity, at least with the assumption that the Family name shouldn’t be broken out from the Instance name. The only other way of capturing such associations from my perspective would be to keep the current structure and relate Malware Instance and Family names using first-class relationships, but that seems needlessly messy for such a relatively simple concept. 

 

Also, given Paul’s point about having one place for capturing source information for both Instance and Family names, I’m wondering if we should take this even further and add the corresponding capability to Aliases, along with the ability to capture both Family and Instance names? That way, both Malware_Name and Malware_Alias will be completely consistent in terms of structure, and accordingly we can define a single “MalwareNameType” to use in both.

 

Thus, we’d end up with something like:

 

<Malware_Subject>

    <Malware_Name>

        <Malware_Instance_Name confidence=”Medium”>CryptoLocker.B</Malware_Instance_Name>

        <Malware_Family_Name confidence=”High”>CryptoLocker</Malware_Family_Name>

    </Malware_Name>

    <Malware Aliases>

       <Malware_Alias>

         <Malware_Instance_Name>WORM_CRILOCK.A</Malware_Instance_Name>

         <Source>Trend Micro</Source>

       </Malware_Alias>

    </Malware_Aliases>

</Malware_Subject>

 

Terry, Paul, does that seem workable to you?

 

As far as CARO, I think it’s a useful concept, but from my experience very few AV vendors implement and use it consistently. Accordingly, the discussion of malware names seems to revolve primarily around instances and families, so for this sake and also to keep things simple and lightweight, my preference would be to focus exclusively on capturing instance and family names.

 

Regards,

Ivan

 

From: Paul Patrick <[hidden email]>
Reply-To: Paul Patrick <[hidden email]>
Date: Wednesday, July 22, 2015 at 1:57 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Ivan – thanks for forwarding with the graphic

 

Terry –

I’m completely in agreement with what you’ve described as I too am looking to build graphs, so I think in that respect we’re not the same page.  What I was suggesting was that there is a kind of association between the malware family name and the malware instance name.  What I also was suggesting was that either of those names together may also need to have a source associated with them in order to determine if they form a unique tuple.  By just having an instance name and a family name is not clear if the two are from the same source of different ones.  Adding a @source attribute to each makes it even more confusing.

 

My suggestion was to create a single type Malware_Name which contained members that comprised the name similar to what is achieved by the Computer Antivirus Research Organization (CARO) malware naming convention that is supported by a number of vendors.  Having a Malware_Name type would semantically convey that the family name, instance name, and any other members are associated.  This way a Malware_Name  type could be parsed into its component to form the graph like you’ve drawn below.

 

<Malware_Subject>

    <Malware_Name>

        <Malware_Instance_Name confidence=”Medium”>CryptoLocker.B</Malware_Instance_Name>

        <Malware_Family_Name confidence=”High”>CryptoLocker</Malware_Family_Name>

    </Malware_Name>

</Malware_Subject>

 

If the group were to agree to do down this path, I would suggest that we look closely at the CARO naming scheme to determine if there are other members that should also be represented as members of the Malware_Name type.

 

For those not aware of CARO, it is a naming convention that has been adopted by a number of the AV vendors, to create an identifier based on URI syntax for malware.  It is very similar to what was done for the Common Platform Enumerations (CPE).  Below is an example format where items enclosed between ‘[‘ and ‘]’ are optional.

 

[<malware_type>://][<platform>/]<family_name>[.<group_name>][.<infective_length>][.<sub-variant><devolution>]][<modifiers>]

 

I’m not suggesting that we replace the concept of Malware_Family_Name and Malware_Instance_Name with a CARO formatted value since that would require parsing, using a Malware_Name type based on the components of the CARO would allow MAEC to actually uses the components to build a CARO name that could be used to determine if two different Malware_Subjects created independently are actually referring to the same thing.

 

One other suggestion I might make based on the use of a Malware_Name type is that the Malware_Alias could actually be a reference (e.g., idref) so that MAEC could consistently refer to the same name in multiple places.

 

Hope this helps clarify what I was trying to convey.

 

 

Paul Patrick

 

From: Kirillov, Ivan A. [[hidden email]]
Sent: Wednesday, July 22, 2015 5:58 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Resending Terry’s post below, as it was bounced from the listserv because it contained an image. I’ve since enabled image attachments.

 

Regards,

Ivan

 

From: Terry MacDonald <[hidden email]>
Date: Tuesday, July 21, 2015 at 7:26 PM
To: Ivan Kirillov <[hidden email]>
Cc: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Hi All,

 

Regarding [2], having a relationship, and having them the same field are two different things in my opinion. We need to determine if anyone would ever need to map out relationships based on the Malware_Instance_Name as distinct from he Malware_Family_Name at any stage before we obfuscate that relationship with the structure changes.

 

By drawing a graph of the relationships as proposed by Ivan we get this: 

Inline images 1

 

This structure allows me to easily look for all instance names, so I could extract those and possibly look for searches of those names in outputs from other tools. 

 

Using a neo4j example: 

 

MATCH (cryptolocker:MalwareFamilyName {value: 'CryptoLocker'})<-[:IS_PART_OF_THE_FAMILY_OF]-()-[:IS_AN_INSTANCE_OF|:IS_ALSO_KNOWN_AS]->(malwarenames) RETURN malwarenames.value

 

would return:

 

Inline images 2

I really don't like the idea that we would squash them all together to lose that flexibility to pull them all apart again. 

 

Cheers


Terry MacDonald | STIX, TAXII, CybOX Consultant

 

M: <a href="tel:%2B61-407-203-026" value="&#43;61407203026" target="_blank">+61-407-203-026

 

 

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

 

 

On 22 July 2015 at 03:11, Kirillov, Ivan A. <[hidden email]> wrote:

Thanks Paul. I think both points are quite sensible:

 

[1] Agreed – I don’t see why we can’t add a similar @source field to Malware_Instance_Name and Malware_Family_Name.

 

[2] I can’t think of any cases where, if both Malware_Instance_Name and Malware_Family_Name are specified, that there is not an implicit relationship stating that the instance belongs to the specified family. I agree that having a single field that encompasses both would make this clearer, and would still permit capturing the instance or family name separately. Does this make sense to everyone else?

 

Regards,

Ivan

 

From: Paul Patrick <[hidden email]>
Date: Tuesday, July 21, 2015 at 12:06 PM
To: Ivan Kirillov <[hidden email]>, maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: RE: [MAEC] MAEC v5.0 Proposals - Round 1

 

Ivan,

 

I think the revised proposal is much better, but got a couple more questions:

 

[1] I see we a means to specify a source for the alias but we don’t have a means to capture the source for the malware instance/family.  Perhaps we should add support for that

 

[2] I wondering if people see the Malware_Instance_Name and the Malware_Family_Name coupled where there is an implied relationship between the instance name and the family name to which is belongs.  If so, perhaps it would be better to have them together as a single type instead of independent fields.  This has the additional advantage that the source could then be a third member of that type.

 

 

Paul Patrick

 

 

 

 

From: Kirillov, Ivan A. [[hidden email]]

Sent: Tuesday, July 21, 2015 6:45 AM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

I’ve modified the proposal for capturing malware instance/family names, per Terry and Paul’s feedback. Let me know what you think.

 

Regards,

Ivan

 

From: <Kirillov>, Ivan Kirillov <[hidden email]>
Reply-To: Ivan Kirillov <[hidden email]>
Date: Friday, July 17, 2015 at 9:43 AM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Paul, Terry, great discussion. Replies inline below.

 

Regards,

Ivan

 

From: Paul Patrick <[hidden email]>
Reply-To: Paul Patrick <[hidden email]>
Date: Thursday, July 16, 2015 at 5:29 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion <[hidden email]>
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

 

 

From: Terry MacDonald [[hidden email]]
Sent: Wednesday, July 15, 2015 4:36 PM
To: [hidden email]
Subject: Re: [MAEC] MAEC v5.0 Proposals - Round 1

 

Hi Ivan,

 

Replies inline, with the unnecessary sections removed.

Cheers


Terry MacDonald | STIX, TAXII, CybOX Consultant

 

M: <a href="tel:%2B61-407-203-026" target="_blank"> +61-407-203-026

 

 

Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

  1. Do the defined types, their child properties, their datatypes, and their annotations makes sense? Should they be changed in any way?
    [terry] - My concern by lumping the various names that the malware is known as together into a pair of single fields is that we potentially lose sight of what the malware sample is called by the MAEC producer. I wonder if it is better to separate the aliases out into their own field. i.e. keep the Malware_Instance_Name and Malware_Family_Name (limited to 0-1), but also add Malware_Instance_Aliases and Malware_Family_Aliases (limited 0-N). In this way people can easily discern what the producer calls the malware, and they can also see what others call the malware sample. It allows for others to release details of similar malware under their own family names, and a relationship to still be discerned through the alias fields.

     [Ivan] That’s a good point – with the current approach, it’s unclear where the malware instance/family names (as captured in a MAEC instance document) came from. Capturing aliases as a separate field may be a viable solution, but I’m     

wondering if it might be simpler and more direct to just capture the source using a separate field (probably an @source attribute) for each Malware_Instance_Name and Malware_Family_Name. That way, the producer of the MAEC document can 

specify whether the name came from their own organization (e.g., @source=“MITRE” for me) or somewhere else. It might also be useful to capture a reference URL that goes along with the source (if availble), e.g., for publicly available malware analysis reports where the name may be referenced. What do you think?

 

[Terry] - I'm not so sold on the capturing all family names in a single place. Realistically a producer is not going to know which names came from which other vendors, as some may be produced by 3rd parties, and they may only hear of them second hand. The producer is only going to know a subset of that information. I do think that recording the name of what the producer calls the malware instance is important, and recording the information source is important, but that the alias information is useful, but not important. Ultimately I think a list of alias names should be separate from the malware names, and that it doesn't need a source tag. I also think that what the producer calls the malware instance is important, and that the source of the name could be important for Incident Responders who would like more information on the data.

 

[Paul] – I might suggest that rather than have 2 lists, that you might have a new MalwareAlias type that contains a single member for both name and family.  I would agree that the producer of the MAEC would likely have its own name and that is important.  But I would argue that the alias information is important.  Without alias, it becomes difficult that something reported by one producer can be correlated with another.  For example, image the same malware instance is submitted to multiple online sandboxes that produce results in MAEC format.  It likely that both sandboxes will assign their own unique name but may also be able to relate the instance to a given name and/or corresponding family.  Without the aliases, it’s very difficult to correlate across them.

 

[Ivan] Good point by Terry in that producers are unlikely to always know which names came from which vendors, so having the ability to identify a name as an alias would still be necessary. Paul, I think your point about having the ability to correlate multiple malware instance/family names is also well taken. It sounds like what Paul is suggesting is keeping the Malware_Instance_Name and Malware_Family_Name and then having an additional field (maybe something like Malware_Alias?) that can capture both instance and family aliases via a new MalwareAlias type. This seems sound to me, though it would probably also be useful to capture the source of the alias, if known; I’m still on the side of having a simple @source field to keep things basic and lightweight, and also because we currently can’t use the STIX InformationSourceType – see comments below. What do you guys think?

 

I personally think you should leverage the InformationSourceType available in STIX if you want to tack the source, as that is comprehensive, and a good way of providing whatever level of flexibility the producer wants. It also contains the References section, which could be useful for tracking URLs for more information, if that is something you would like to see tracked within MAEC. 

 

[Paul] – I’m in agreement with Terry wrt leveraging some of the things in STIX (InformationSourceType, common vocabularies …) but I do have a concern of circular dependencies being created.  I think there is likely a number of things in STIX that should actually be in a common place and leveraged by STIX and MAEC.  A common base type of some of this that then could be extended by STIX and/or MAEC would definitely be a step in the right direction and I think the common base type that is based on a lot of what is in STIX would be a good start.

 

[Ivan] Yes, the primary reason that we don’t already import any STIX constructs is because of circular dependencies. Also, from a semantic perspective, it would be quite odd for MAEC to import STIX, given that STIX really sits at a much higher level of abstraction. I completely agree with Paul that we really need a common base “layer” where we can define common concepts like InformationSourceType, ConfidenceMeasureEnum, etc. I personally plan on bringing this up as part of the STIX/CybOX discussion in the OASIS CTI. For now though, we’ll have to make due with either duplicating types or creating divergent implementations. 

 

  1. Does it make sense to have a multiplicity of 0-N (unbounded) for malware instance and malware family names, or should it be bounded to 1?
    [terry] - I woulsd suggest bounded to 1 if you add the Malware_Instance_Aliases and Malware_Family_Aliases (unbounded).
  2. Does it make sense to assign a relative measure of confidence to malware instance and malware family names? Accordingly, do the values in the ConfidenceMeasureEnummake sense?
    [terry] - I would like to align the ConfidenceMeasureEnum values with the values in the STIX confidence (High, Medium, Low, None, Unknown).

     [Ivan] Agreed – I’ll update the proposal to align the values with the ConfidenceMeasureEnum. In the future, it would be nice to be able to use MAEC/STIX/CybOX vocabularies interchangeably. Currently this isn’t possible (at least with respect to STIX <-> MAEC/CybOX) because their vocabularies extend from different base types.

 

[Terry] - I would like to see a lot of things shared across MAEC.STIX/CybOX - Information source, reference URL structures as well as default vocabs. There is a reasonable scope for that. Maybe thats worth bringing up on the OASIS CTI Subcommittees.

 

[Paul] – I second Terry’s suggested.  I think there are already a couple of these types of instance that are emerging with likely more as we move forward.

 

  1. Does it make sense to make this field name change in MAEC?
    [terry] - Yes it makes sense.
  2. Does the proposed name make sense? Are there preferable alternatives?
  1. [terry] - what about renaming it simply 'observables', or 'instance_observables'? This would align somewhat with STIX.

    [Ivan] That would be closer to STIX, but not completely accurate as the field only supports capturing a CybOX Object (cybox:ObjectType). Maybe “Instance_Object” then?

 

[Terry] - Instance_Object could work.

[Paul] I could agree with that

[Ivan] Sounds good. Let’s go with “Instance_Object” then :)

 

Proposal: Deprecate Use of QNames for Ids

  1. Should URIs be used instead of QNames in IDs?
    [terry] - I'm in two minds here. I really dislike QNames as they complicate the processing involved in generating and consuming the XML output of STIX, CYBOX and MAEC. But, I am equally concerned that MAEC will be deprecating the use of QNames in IDs, when there has been no public discussion about doing the same within STIX or CybOX. I would hate for producers and consumers of threat intelligence to be forced to support two different ways of generating IDs within a single library if it could be avoided.

    In other words - has this been discussed with the STIX/CybOX communities to see if they would be open to changing the IDs to use URIs? I think a LOT of people would, but ti would be great to check this out and confirm it before changing MAEC. It would be far better to have MAEC the first of the related protocols to migrate, rather than it be the only one doing this change.

    [Ivan] As Jon mentioned in his response, this has been an outstanding issue for a while in STIX and CybOX, but hasn’t been brought up for explicit discussion because it would not be a backwards compatible change. Accordingly, we chose to do this now in MAEC because we felt it would be a good time (being a major version) to incorporate any backwards-incompatible changes that would be useful. We should certainly check with the STIX/CybOX communities to see if this is something that they may be interested in doing down the road. Also, I definitely agree that having to support multiple ID formats would be painful for content producers (and consumers as well), especially when dealing with embedded MAEC in STIX TTPs. However, with regards to that last point, this won’t be a (potential) issue until STIX is updated to support the embedding of MAEC v5.0 (STIX 1.2.x will be limited to MAEC v4.1).

 

[Terry] - OK, didn't know that. In that case, URIs are better :). 

 

With all the changes being discussed on the STIX/TAXII lists at present regtarding v2.0 or both TAXII and STIX, I wouldn't be surprised if we end up moving away from XML based documents to another structured data format. I'm really pushing for a 'review all the things' mentality for STIX/TAXII, as the opportunities for a major release don't come about very often. It will be interesting to see what impact that will have on MAEC in the future.

 

[Paul] – I think we are an interesting point in time since both STIX and MAEC depend upon CybOX which faces the same issue.  Unless the 3 aren’t updated consistently at roughly the same time, users are going to be faced with understanding different formats.  URIs (be they URLs or URNs) will definitely be better. 

 

[Ivan] Yup. I think we have two options in this regard: make the change now, and assume that STIX and CybOX will follow (which I’d personally say is likely), or wait until STIX and CybOX change and then follow suite. The problem with the former is that it’s not guaranteed that STIX and CybOX will make the same change, and even if they do, it will take a new major version which is probably a year away, at least. The problem with the latter is that it will require a new major version of MAEC, which is one of the reasons that I was leaning towards making the change now. However, given the fact that dealing with multiple ID syntaxes certainly seems painful (and will be a reality in MAEC v5.0 with this change, given that CybOX will still use QNames), perhaps we should table this change until a later date, to make life easier for both consumers and producers.

 

  1. Should VulnerabilityExploitType align as closely as possible with the STIXVulnerabilityType or is it better to take a more flexible approach by defining a new MAEC VulnerabilityReferenceType?
    [terry] - They must align in my opinion. MAEC is more focused on describing the exploit and what vulnerabilities it exploits, whereas ExploitTarget is focused on the Vulnerable systems and the vulnerabilities they have. There is a lot of benefit to be had by ensuring that consumers can find linkages between vulnerable systems, and malware that exploits those vulnerabilities. For this to happen it is imperative that STIX and MAEC align their descriptions, such that one can make a connection.

    I would posit that as the STIX ExploitTarget is designed to describe vulnerable systems that the STIXVulnerabilityType should be considered the 'standard' for vulnerability description, and that as MAEC is designed to describe malware and the exploits they contain that the MAEC Exploit descriptions should be considered the 'standard' for exploit description, and that they should leverage each others work.

   [Ivan] I definitely agree with your characterization of the purpose of MAEC’s VulnerabilityExploitType and the ExploitTarget from STIX. The main reason that we decided not to completely mirror the fields in the STIX VulnerabilityType is that, currently, the STIX VulnerabilityType is inflexible when it comes to vulnerability references, supporting only CVE and OSVDB. Therefore, there is some expectation that the STIX VulnerabilityType will be updated to accommodate other references (e.g., CWE for the underlying software flaw of the vulnerability). As such, given that STIX functions as the ‘standard’ for vulnerability description (which we 100% agree with), perhaps we should postpone this change and wait for the STIX VulnerabilityType to be updated?

 

[Terry] - It depends if there is urgent need for this at present. We can always make this change and feed back the need for alignment to the CTI STIX Sub-Committee. It all depends if the MAEC Community can wait.

 

[Paul] – I agree with Ivan in that the STIX VulnerabilityType is too restrictive.  If any one looks at the XML schema for CVE or CWE, you’ll see indications that the authors were considering a single VulnerabilityType that could be used to expresses vulnerabilities, weaknesses, and configuration issues.  I would suggest if we look to defining a new VulnerabilityType that it take into consideration that work as well as the unique requirements of STIX and MAEC.  Perhaps this is another instance of where there is a common type that isn’t defined by STIX or MAEC but rather is leveraged/extended by them.  I would also suggest that a closer look be taken as to whether a new vulnerability type should be extended with something like CVE/OSVDB/CWE/CCE (all of which are expressed in XML schemas ONLY) or just reference these external entities.  Part of my thinking is I don’t suspect most producers will likely populate all the fields defined by the extension, but would rather just provide a reference to them, and second these types of extensions result in duplication of data.

 

[Ivan] I don’t think there’s an urgent need for this change (the existing type can capture CVEs, which is the predominant identifier), rather it has been a longstanding issue on our end that we felt was useful to address in a major release. Paul, I agree that this is probably another place where having a common base layer would make sense. I too think that having extensions for the schemas from CVE/OSVDB/CWE/etc. would be overkill for this scenario, so having a fairly expressive VulnerabilityType would probably be the way to go.