Frequently Asked Questions (FAQs)

  1. General
  2. MAEC Language
  3. Using MAEC
  4. Relationships to Other Efforts
  5. MAEC Community
Back to top

General

A1. What is MAEC?

Malware Attribute Enumeration and Characterization (MAEC™) is a structured language for encoding and communicating high fidelity information about malware based upon attributes such as behaviors, artifacts, and attack patterns.

Back to top

A2. How is "MAEC" pronounced?

MAEC is pronounced as "mike." This pronunciation stems from classical Latin, in which the diphthong 'ae' is pronounced as a long 'i'. Examples of other words that use the same pronunciation are maestro and alumnae.

Back to top

A3. Is a specification available for the MAEC Language?

Both a PDF and Word version of the current "MAEC Language Specification" are available on the Documents page of this website.

Back to top

A4. Where can I find examples of what I can capture and do with MAEC?

Examples can be found on the MAEC Examples page, and in the MAEC Schemas MAECProject repository on GitHub.com.

Back to top

A5. Why was MAEC developed?

MAEC was developed to eliminate the ambiguity and inaccuracy that currently exists in malware descriptions. By reducing reliance on signatures, MAEC aims to improve human-to-tool, tool-to-tool, and tool-to-human communication about malware; allow for faster development of countermeasures by enabling the ability to leverage responses to previously observed malware instances; and reduce potential duplication of malware analysis efforts by researchers.

Back to top

A6. How was MAEC developed?

MAEC is a community-developed effort and has received input from members of various communities, including those from industry, academia, and government. The MITRE Corporation maintains MAEC and its public website presence and provides impartial technical guidance to the MAEC Community throughout the process to ensure MAEC serves the public interest. MAEC is sponsored by the office of Cybersecurity and Communications at the U.S. Department of Homeland Security.

Back to top

A7. Where can I get MAEC?

The current MAEC schema, as well as example files, schematron rules, and related documentation, are available in the MAEC Language section of this MAEC Web site and in the MAEC Schemas in the MAECProject repository on GitHub.com.

Back to top

A8. Is MAEC a formal standard?

MAEC is not currently being pursued in a formal standards body. However, once an appropriate level of maturity, stability, and use is achieved, international standardization will be sought.

Back to top

A9. How is MAEC licensed?

See the "License" section of the Terms of Use.

Back to top

A10. How can my organization and I get involved?

There are several opportunities to get involved. The MAEC Community Email Discussion List is where community members discuss the latest drafts of the MAEC schemas, utilities and other items integral to the ongoing development of MAEC.

The MAEC Development Group on MITRE's Handshake collaboration Web site allows the MAEC Community to more easily share and revise information and files and to post items such as example content in a more secure environment. Please email maec@mitre.org to join the Handshake group.

Visit the MAEC Community page for additional information.

Back to top

A11. How can I make contributions to MAEC development?

The MAECProject repositories on GitHub.com are the central location for MAEC Community members to make open-source contributions to MAEC development and manage issue tracking for the MAEC schemas, utilities, and other supporting information and items. Please visit the MAECProject GitHub repositories or email maec@mitre.org for further information.

Back to top

A12. How do I submit questions related to this effort?

We encourage you to submit questions to the general MAEC Community Email Discussion List which we actively read and monitor. You may also submit questions directly to maec@mitre.org if you do not wish to hold the discussion in a public venue.

Back to top

A13. What is MAEC Compatibility?

MAEC Compatibility provides for a product, service, or repository to be reviewed and registered as officially "MAEC-Compatible," thereby assisting organizations in understanding and leveraging the three different types of capabilities that can leverage the MAEC Language.

If your organization uses or is planning to use MAEC, please refer to the MAEC Compatibility Program and How to Make a Declaration for instructions on how to participate, and/or contact maec@mitre.org for additional information.

Back to top

A14. Is someone from MAEC available to speak or participate on panel discussion at industry-related events, meetings, etc.?

Yes, contact maec@mitre.org to have the MAEC Team present a briefing or participate in a panel discussion about MAEC and/or information sharing at your event.

Back to top

MAEC Language

B1. What is included in a MAEC release?

A MAEC release includes individually-versioned MAEC schemas (i.e., Bundle, Package, and Container schemas) and the latest versions of the independently-versioned MAEC vocabulary schemas.

MAEC releases are packaged in two different ways:

  1. A zipped bundle to support local development, with local references and including copies of all imported or utilized schemas.
  2. A zipped bundle to support development with Internet access, with only remote references to imported schemas.

Additionally, a version is hosted on maec.mitre.org to enable validation.

Back to top

B2. What tools or utilities are available to help me use or develop MAEC content?

MAEC can be manipulated manually or programmatically. If using MAEC manually, such as to capture malware analysis results, no tools are currently provided, but use of an XML editor is recommended.

For programmatic development and use, some MAEC scripts and translator utilities are hosted in separate MAECProject GitHub repositories. In addition, a Python API for parsing, manipulating, and generating MAEC content is hosted in the MAECProject Python-MAEC GitHub repository.

Back to top

B3. Is there a GUI of some sort that will help me select MAEC elements?

A GUI is not available at this time, but such a tool could be available in the future.

Back to top

B4. Are there plans to support other forms of data interchange for MAEC (e.g., JSON, YAML, etc.)?

Yes. Eventually, a formal MAEC implementation-independent specification will be produced, to include guidance for developing technology-specific implementations such as JavaScript Object Notation (JSON), Resource Description Framework (RDF)/Web Ontology Language (OWL), YAML Ain't Markup Language (YMAL), or other implementations. XML was used in the initial release to enable rapid development and implementation.

Back to top

B5. Where can I find examples of MAEC data? Are there any MAEC repositories?

See the Examples page on this MAEC Web site.

At present, there are no public repositories of MAEC data, nor are there plans by MITRE to establish one. However, community members interested in hosting a MAEC data repository are strongly encouraged to do so.

Back to top

Using MAEC

Some of the FAQs in this section are somewhat technical in nature. Please refer to the "MAEC Language Specification" on the Documents page of this website for further information.

C1. MAEC seems complicated – is it too expansive for my use?

The MAEC schema was developed to enable analysts to capture a full gamut of information about malware. However, a MAEC Bundle is valid with very little information: it is only necessary to define a unique identifier and to specify the MAEC schema version. All other fields are optional.

Back to top

C2. Why are so many things optional in MAEC?

Aside from a unique identifier and the MAEC schema version, all objects are optional in MAEC. This was done to make the language as flexible as possible: a user is able to capture exactly what they want and nothing more.

Back to top

C3. How does the xsi:type extension mechanism work?

The xsi:type XML schema extension mechanism works by allowing for the substitution of types that are created as derivatives of an existing abstract type. As such, one must simply include the xsi:type attribute on an element that uses the parent abstract type, and accordingly specify the name of the type that one wishes to substitute for this element inside this attribute. For example, if one wishes to use the FileObj:FileObjectType type from Cyber Observables Expression (CybOX™) in the Properties element (which uses the abstract cyboxCommon:ObjectPropertiesType) of the Malware Instance Object Attributes in a MAEC Bundle, they would specify the xsi:type attribute on this element with the name of the object type inside:

<maecBundle:Malware_Instance_Object_Attributes>
<cybox:Properties xsi:type="FileObj:FileObjectType">
<FileObj:File_Name>dg003_improve_8080_V132.exe</FileObj:File_Name>
<FileObj:Size_In_Bytes>196608</FileObj:Size_In_Bytes>
</cybox:Properties>
</maecBundle:Malware_Instance_Object_Attributes>

Back to top

C4. What if I need to define something that isn't part of the MAEC schema?

MAEC is very flexible and can accommodate custom fields and objects. For example, one can use the Custom Properties/Property fields at the root level of the larger Cyber Observables Expression (CybOX™) ObjectType specify a set of custom attributes that are not defined elsewhere. Accordingly, it is possible to define a new type of CybOX Object that can then be plugged into the Property field of the CybOX ObjectType using the xsi:type extension mechanism (e.g., xsi:type="CustomObj:CustomObjectType").

In addition, the MAEC development team encourages the community to engage in the ongoing discussion so that new fields and fields can be defined and integrated into future versions of MAEC as necessary. Please consider joining the public MAEC Community Email Discussion List and/or the MAEC Development Group on Handshake (email maec@mitre.org to request access).

Back to top

C5. Can the same information be captured in multiple places in MAEC?

Yes. MAEC is very flexible and there are often a multiple places that the same characterized information, e.g., a particular Action or Behavior, can be captured.

Back to top

C6. Can I share a simple Bundle, or do I need a Package?

If one would like to exchange information about a single malware instance, a MAEC Bundle can be shared without being embedded in a MAEC Package. In such a case, the MAEC Bundle must include the Malware Instance Object Attributes field, for characterizing the malware instance object that the data pertains to, and the defined_subject field at the root level of the Bundle must be set to 'true'.

Back to top

C7. What happens when a standalone Bundle becomes part of a Package?

If a MAEC Bundle is contained inside a MAEC Package, the defined_subject field of the MAEC Bundle MUST be set to 'false' and the attributes of the Object representing the malware instance SHOULD be captured in the Malware Instance Object Attributes field at the MAEC Package level. In this case, the content of the Malware Instance Object Attributes field MAY remain in the MAEC Bundle or MAY be removed; the MAEC Bundle content will be superseded by the content of the Malware Instance Object Attributes field at the MAEC Package level.

The Malware Instance Object Attributes field at the MAEC Package level MAY reference the Malware Instance Object Attributes field at the MAEC Bundle level via IDREF attribute. In this case, the content of the Malware Instance Object Attributes field MUST remain in the MAEC Bundle.

Back to top

C8. What if I don't want to share everything in a Bundle or Package?

An organization can choose what they want to share in a MAEC Bundle or MAEC Package by creating a new MAEC Bundle or MAEC Package with the shareable data. Accordingly, a MAEC Bundle is valid with minimal content.

Back to top

C9. I want to use a MAEC Bundle to share my analysis information, but it doesn’t encompass all of the details that I want to include such as analysis tool information. What should I do?

A MAEC Bundle contains the analysis output for a single malware instance. If more content is desired, such as information about the analysis environment, a MAEC Package should be used.

Back to top

C10. I have a standalone Bundle. How do I know which Package it belongs to?

A MAEC Bundle does not reference its parent MAEC Package. However, if the MAEC Bundle is referenced through its ID as part of a Findings Bundles field within a Malware Subject in a MAEC Package, the MAEC Bundle ID can be used in reverse to traverse up the document tree and identify the Malware Subject and consequently the MAEC Package that contains the MAEC Bundle.

Back to top

C11. If I share just a Bundle, how does the recipient know what malware it relates to?

A standalone MAEC Bundle should contain a Malware Instance Object Attributes field, which will provide the MAEC Bundle recipient with the information they require about the malware instance object. Note that this field is equivalent to the Malware Instance Object Attributes field that is contained inside of a Malware Subject in the MAEC Package, and is therefore only required if this MAEC Bundle is to be used in a stand-alone fashion.

Back to top

C12. Why can there be multiple Malware Subjects in a Package?

A MAEC Package is most often used to capture a group of Malware Subjects that are related in some way. For example, the Malware Subjects may all come from the same malware family or they may be part of the same intrusion set. This relationship information can be captured in the Grouping Relationships field.

Back to top

C13. How do I capture relationships between the Malware Subjects in a Package? For example, malware that is in the same family?

The Grouping Relationships field within a MAEC Package specifies how the Malware Subjects in the MAEC Package are related. The associated enumeration includes relationships of 'same malware family', 'clustered together', 'observed together', 'part of intrusion set', and 'same malware toolkit.'

Back to top

C14. What does it mean to have multiple Bundles in the Findings Bundles field in a Malware Subject? Why not define just one Bundle?

The results of individual analyses can potentially be returned as separate MAEC Bundle fields in the Finding Bundles field, so rather than trying to aggregate and de-duplicate analysis data into a single MAEC Bundle, the Findings Bundles field is a way of storing each of these MAEC Bundles individually.

If analysis is done manually, then a single MAEC Bundle may be defined. However, if a collection of analysis tools is run in an automated fashion, it is easier to create new and separate MAEC Bundles to contain the output of each tool.

Back to top

C15. How is a Finding Bundles field associated with one or more Analyses?

The MAEC Bundles in a Findings Bundles field, used to capture the findings of some particular Analysis fields performed on the Malware Subject, do not by themselves link directly to Analyses. However, individual MAEC Bundles can be referenced from an Analysis using the Findings Bundle Reference object. The reference is uni-directional: an Analysis can reference a MAEC Bundle, but a MAEC Bundle does not contain a reference to an associated Analysis.

Back to top

C16. How are extracted features and other findings associated with an Analysis?

Only features that are stored in a MAEC Bundle can be associated with an Analysis, as opposed to features that are stored as part of the Malware Instance Object Attributes. As discussed above, an Analysis field in a Malware Subject contains a Findings Bundle Reference field, which associates a particular MAEC Bundle with the Analysis.

Back to top

C17. Can an Analysis result in more than one Bundle? And can more than one Bundle be referenced in an Analysis?

An Analysis resulting in more than one MAEC Bundle is possible but unlikely because the output of a single tool run or manual analysis can be captured in a single MAEC Bundle, which is the recommended way of encapsulating all of the MAEC-field level findings for a particular Analysis. Accordingly, an Analysis can reference only a single Findings-Bundle Reference field.

Back to top

C18. Can the same Bundle be referenced by more than one Analysis?

It is possible (though probably unlikely), for two or more different analyses to report identical findings. As such, it is valid to have more than one Analysis field reference the same MAEC Bundle, which can be used to implicitly state that the Analysis fields resulted in the same findings.

Back to top

C19. Why are some fields (e.g., Object, Action) not defined directly in the MAEC schema?

Some fields are commonly used across the cyber observable domain. Therefore, rather than defining the fields in a variety of similar contexts, they are defined in the Cyber Observables Expression (CybOX™) language and referenced by other data models as needed.

Back to top

C20. Where are extracted features typically captured?

The preferred method is to create a MAEC Bundle with an Object that contains the extracted features. For example, to capture the output of a packer detection tool (e.g., PEiD), one could create a MAEC Bundle with a single Cyber Observables Expression (CybOX™) Object field (inside the Bundle's Objects field of type ObjectListType) that uses the FileObjectType type from the CybOX File Object data model in its Properties field to capture the packer information.

Note that when using this method, an entire CybOX Object field is created, which should not be mistakenly identified as a newly found file (it merely captures extracted features from the file already defined inside the Malware Instance Object Attributes field). To make this explicit, the content_type attribute of the MAEC Bundle should be set to 'extracted from subject.'

Alternatively, extracted features can be defined inside of the existing File field that is contained in the Malware Instance Object Attributes field. If captured here, it would be redundant to capture the same information in a separate Object.

Back to top

C21. Where would features such as extracted strings be stored?

Extracted features are not stored in a single, general location. They are typically stored on a per-feature basis because sometimes an extracted feature is best stored at a particular level of hierarchy within an Object (e.g., section hashes are stored in the corresponding Sections field of the Windows Executable File field of type WinExecutableFileObj:WindowsExecutableFileObjectType).

Basic extracted features, and strings in particular, are typically stored as an Extracted Features field in the File object, which is then encapsulated in a Cyber Observables Expression (CybOX™) Object in a MAEC Bundle within a Findings Bundles field (see C20. "Where are extracted features typically captured?").

Alternatively, the set of strings or other extracted features can be stored as one or more Objects in an Object Collection in the MAEC Bundle, which permits for the specification of the types of features that the strings represent, e.g., IP Addresses.

Back to top

C22. When does one use the "method" and "type" fields in an Analysis field versus the "type" field in a Bundle?

These fields capture different pieces of metadata relevant to their parent field and any or all can be used as the MAEC Bundle or MAEC Package creator sees fit. In an Analysis field, the method (e.g., 'static') and type (e.g., 'triage') fields are used to indicate details specific to the analysis. In a MAEC Bundle, the type (e.g., 'dynamic analysis tool output') field is used to capture information regarding the general content of the MAEC Bundle.

Back to top

C23. Where would simple, computed attributes such as file size or hash value be stored?

File size and hash values are captured in a CybOX File field (of type FileObj:FileObjectType), specifically through the Size In Bytes and Hashes fields, respectively. The File field can then be plugged into the Properties field of a CybOX Object (of type cybox:ObjectType), which is used in many locations throughout MAEC such as the Malware Instance Object Attributes field in the MAEC Bundle and Malware Subject and the Associated Objects/Associated Object field in the MAEC Action.

Back to top

C24. How does one capture the relationship between an analysis and the tool(s) performing it?

Each tool used in an analysis may be captured in the Tools/Tool field of the Analysis field, which uses the ToolInformationType from the CybOX Common data model. For tools that are used in more than one analysis, there are two options: their definitions may be repeated in each Analysis field, or they may be defined once in an Analysis and then referenced in others by their ID. We generally recommend the latter approach to reduce duplication of data in a MAEC document.

Back to top

C25. How can an analyst specify whether an analysis was done manually or automatically or whether it was a static or dynamic (run-time) analysis?

As is often the case with MAEC, there is more than one way to capture this information. Within the Analysis field of a MAEC Package, the type and method fields, respectively, can be used to specify whether the type of analysis performed is 'triage' or 'manual' and whether the method used was 'static', 'dynamic', or a 'combination.'

In addition, this can be specified implicitly through the content_type field of a MAEC Bundle, which uses an enumeration with values including 'dynamic analysis tool output,' 'static analysis tool output,' 'manual analysis output,' 'extracted from subject,' 'mixed,' and 'other.'

Back to top

C26. I use automated tools that don’t output their analysis information using MAEC. Is there a way to easily translate the information?

Proof-of-concept translator scripts have been developed for translating the output of some tools into MAEC XML. These translators can be found in the MAECProject GitHub repositories. If a tool does not have a translator written for it, output can be manually converted into a MAEC-compatible format; however, the process generally requires a good familiarity with the MAEC schema. Please email us at maec@mitre.org with any questions related to this process.

Back to top

C27. Will malware analysis tool vendors adopt MAEC?

Now that the MAEC schema is fairly mature and stable, we anticipate that analysis tool vendors will either begin producing MAEC-compatible native output or that they will work to develop appropriate translators. Some open-source tools, such as Cuckoo Sandbox, have already adopted MAEC as a form of native output.

Back to top

C28. Is it okay to define the same tool in multiple Analyses

Preferably, a tool will only be defined once in a MAEC Package (as a field within a single Analysis field of a Malware Subject). Other Analyses would then reference the tool via its unique ID. However, a MAEC Package with duplicate Tool information (although necessarily different identifiers) is still valid; the MAEC Package will just contain redundant information.

Back to top

C29. How can one understand why different Malware Subjects are in the same Package?

The Grouping Relationship field is used to specify the particular relationships that serve to group the Malware Subjects within the MAEC Package. Types of relationships include Malware Subjects that are in the same variant family, Malware Subjects that are clustered by a similarity algorithm, and Malware Subjects that are part of the same intrusion set. We will expand this field to support additional types of grouping relationships in future MAEC releases.

Back to top

C30. How does one specify the malicious entities that Candidate Indicators refer to?

Indicators that specify the particular entities that may signify the presence of the malware instance on a host system or network are defined as Candidate Indicator fields within a MAEC Bundle. The actual components associated with the indicator are specified via references to Objects, Actions, and Behaviors already defined in the MAEC document.

Back to top

C31. At a high level, what does an Analysis field contain?

An Analysis field contains all of the metadata relevant to the analysis, including the type (triage or manual), method (static, dynamic, or combination), the analysts who performed it, the tools used, a summary of the analysis, any comments about the analysis, a way of capturing the analysis report, information about the analysis environment, and any metadata specific to dynamic analysis (the command line used to launch the process, etc.). Also, an Analysis field can reference a particular MAEC Bundle (via the Findings Bundle Reference field) that encapsulates the MAEC-field characterized results of the Analysis.

Back to top

C32. When are Collections used?

MAEC Collections are containers for abstract grouping of MAEC Bundle level entities, i.e., Behaviors, Actions, Objects, and Candidate Indicators. Typically, they are used to group and organize some particular set of related MAEC entities, with the nature of the relationship captured through the name field on the MAEC Collection. For example, MAEC Collections can be used when translating the output of dynamic analysis tools for the purpose of binning the Actions that operate on the same type of Object into their respective buckets (e.g., file actions, mutex actions, process actions, etc.). Another example usage of collections is for capturing some set of information that was extracted from a malware instance, such as all of the IP addresses that the instance may attempt to connect to.

Back to top

Relationships to Other Efforts

D1. What is the relationship between MAEC and CybOX?

The Cyber Observable eXpression (CybOX™) is a related U.S. Department of Homeland Security–led effort of the office of Cybersecurity and Communications that provides a structured language for describing elements within the cyber operational environment. MAEC uses components of the CybOX language for characterizing cyber observables associated with malware. In particular, MAEC makes use of CybOX's Object and Action fields (which are extended in MAEC's MalwareActionType type) to characterize malware-related system artifacts and low-level behaviors, respectively.

Back to top

D2. What is the relationship between MAEC and STIX?

The Structured Threat Information eXpression (STIX™) is a related U.S. Department of Homeland Security–led effort of the office of Cybersecurity and Communications to characterize a rich set of cyber threat information in a standardized and structured manner. STIX can describe malware using MAEC characterizations through use of the MAEC schema extension for the TTP schema and can also characterize indicators in a fashion similar to MAEC's Candidate Indicators.

Back to top

D3. When would STIX be used to capture malware information and when would MAEC be used?

Structured Threat Information eXpression (STIX™) is used to describe high-level cyber threat information to include indicators, as well as information about threat actors, campaigns, incidents, and other related entities. On the other hand, MAEC is used to describe malware attributes of one or more malware instances at various levels of abstraction. Certainly, there is overlap between the two languages, particularly when it comes to capturing indicator information (e.g., file sizes, file hashes) through the common use of Cyber Observable eXpression (CybOX™).

While there are no definite rules for what is most appropriately captured with MAEC versus STIX, MAEC will typically be used to capture malware information that is gathered through the analysis process, and STIX will be used to capture information related to the interpretation of the analysis results in a broader, threat-based context. For example, while MAEC would capture the particular details of the behaviors and artifacts associated with a malware instance, STIX would be used to capture additional details regarding the particular threat actors that may make use of the malware instance. Thus, when malware analysis information beyond simple indicator information is to be captured by STIX, the STIX schema extension for MAEC should be used to leverage the MAEC data model.

Back to top

D4. What is the relationship between MAEC and TAXII?

The Trusted Automated eXchange of Indicator Information (TAXII™) is a related U.S. Department of Homeland Security–led effort of the office of Cybersecurity and Communications to define a set of services and message exchanges for securely sharing automated cyber threat information. TAXII uses Structured Threat Information eXpression (STIX™) to represent cyber threat information in a standardized and structured manner (STIX characterizes what is being shared, while TAXII defines how the STIX payload is shared). STIX is one payload that TAXII can convey, and STIX can describe malware using MAEC.

Back to top

MAEC Community

E1. What is the role of the MAEC Community and how can I join?

The MAEC Community comprises members from across the international cyber security community who have come together to help build MAEC. There are multiple options available for involvement:

  • The MAEC Community Email Discussion List is where community members discuss the latest drafts of the MAEC schemas, utilities, and other items integral to the ongoing development of MAEC.
  • The MAECProject GitHub repositories are the central location for MAEC Community members to make open-source contributions to MAEC tool and API development and manage issue tracking for the MAEC schemas, utilities, and other supporting information and items.
  • The MAEC Development Group on MITRE's Handshake collaboration Web site allows the MAEC Community to more easily share and revise information and files and to post items such as example content in a more secure environment. To join Handshake and the MAEC Development group, please email us at maec@mitre.org for an invitation.

For more information on the community and how to join, please visit the MAEC Community page.

Back to top

E2. What is MITRE?

In partnership with government clients, The MITRE Corporation (MITRE) is a not-for-profit corporation working in the public interest. It addresses issues of critical national importance, combining systems engineering and information technology to develop innovative solutions that make a difference.

MITRE's work is focused within Federally Funded Research and Development Centers (FFRDCs) for the Department of Defense, Federal Aviation Administration, Internal Revenue Service and Department of Veterans Affairs, Department of Homeland Security, Administrative Office of the U.S. Courts; and the Centers for Medicare and Medicaid Services.

Back to top

E3. What is MITRE's role in MAEC?

MITRE manages the development of the MAEC Language, MAEC Web site, community engagement, and discussion lists to enable open and public collaboration with all stakeholders.

Back to top

E4. Why is MITRE maintaining MAEC, and how long does MITRE plan to maintain it?

In accordance with its mission, MITRE has traditionally acted in the public interest. Its unique role allows it to provide an objective perspective to this effort. MITRE will maintain MAEC as long as it serves the community to do so.

Back to top

E5. Who pays for MAEC? Who is the Sponsor?

MAEC is sponsored by the office of Cybersecurity and Communications at the U.S. Department of Homeland Security.

Back to top

E6. What is the relationship between MAEC and DHS?

MAEC is a U.S. Department of Homeland Security–led effort of the office of Cybersecurity and Communications.

MITRE Corporation, operating as DHS's Federally Funded Research and Development Center (FFRDC), manages the development of the MAEC Language, MAEC Web site, community engagement, and discussion lists to enable open and public collaboration with all stakeholders.

Back to top

Page Last Updated: August 26, 2014