MOTAR ATO/Compliance
This page provides details on the Authorization to Operate (ATO) for MOTAR and how content activated on MOTAR can leverage the ATO.

MOTAR is working towards an ATO for their Impact Level (IL) 4 environment. IL4 authorization covers Controlled Unclassified Information (CUI), which may include data that is For Official Use Only (FOUO), Law Enforcement Sensitive (LES), or Sensitive security information. The MOTAR ATO will ensure Personally Identifiable Information (PII) is protected with the Privacy Overlay included.

MOTAR is categorized as Moderate-Moderate-Moderate with Privacy Overlay.

Cybersecurity Maturity Model Certification (CMMC) is a system of compliance levels that helps the DoD determine whether a vendor has the security necessary to work with controlled or otherwise vulnerable data. An ATO is a risk-based decision made by the Authorizing Official for an information system. While there are similarities in the security control requirements, the key point of distinction is that an ATO is for an information system, whereas CMMC is for a vendor/company.

Dynepic will work to build an IL6 environment (Secret) in 2022 which will allow vendors to build applications that can include up to Secret data. The goal is to have an ATO for the IL6 environment by the middle of 2023.

The goal of a CDS is to allow a trusted network domain to exchange information with other domains, either one-way or bidirectionally, without introducing the potential for security threats of data spillage. The vision of MOTAR is to have a CDS where the information from MOTAR IL4 can be shared with MOTAR IL6, as well as the CUI and non-sensitive data from MOTAR IL6 to be shared with MOTAR IL4. What this means is that a Commander can log into his/her MOTAR IL6 dashboard and see all training records for airmen in his/her command, and if they log into their MOTAR IL4 dashboard they will see limited fields from the classified training (prevent data spillage).

MOTAR is classified as Moderate-Moderate-Moderate for Confidentiality, Integrity, and Availability, with Personally Identifiable Information, therefore the Privacy security control overlay is included. A working group is currently reviewing all the controls and assessment procedures for this classification level to determine what can be inherited from applications that will reside within the MOTAR authorization boundary. The review should be complete by the end of February 2022, and all inheritable controls will be identified in a Memorandum of Agreement (MoA). The MoA will need to be signed by both the MOTAR Program Manager (PM) as well as the Application PM so both entities understand their respective security responsibilities.

Security is paramount within MOTAR, having defense-in-depth measures at all phases of the OSI Model. MOTAR follows a modular, open systems approach (MOSA) and a zero-trust architecture through a net-centric, data-governed, and architecturally-compliant system. Encryption of data at rest and data in transit is implemented in accordance with FIPS 140-2 standards.

MOTAR follows NIST SP 800-204A, which addresses building secure microservices-based applications using service-mesh architecture. Key concepts include proper configuration for the following elements:
  • communication for service proxies
  • ingress proxies
  • access to external services
  • identity and access management
  • monitoring capabilities
  • network resilient techniques
  • cross-origin resource sharing
  • permissions for administrative operations
The need to keep pace with the elastic, dynamic nature of cloud-native applications and containers makes automation a strategic tenant of MOTAR security. We have a CI/CD pipeline with toll gates to ensure security checks are completed and vulnerabilities eliminated before any software is pushed through the process to the Production environment. The MOTAR Software Factory looks for vulnerabilities at all levels, to include at the OS level, within the containers and within the application code.

MOTAR is hosted within AWS GovCloud. MOTAR inherits controls and assessment procedures from DoD, Air Force, and AWS Gov Cloud. For those security and privacy controls that cannot be inherited, MOTAR effectively implements the necessary controls, which are assessed by the AETC Security Control Assessor Representative Team and validated by the AETC SCAR. For any controls that are Non- Compliant or Not Applicable, MOTAR develops a Plan of Action & Milestone (POA&M) on how the vulnerability will be fixed as well as the defense in depth measures currently in place to mitigate the risk.

A fault-tolerant environment has no service interruption but a significantly higher cost, while a highly available environment has minimal service interruption. While MOTAR is categorized as moderate for availability, it leverages AWS GovCloud's high availability for minimal downtime. High availability means that a system will almost always maintain uptime, albeit sometimes in a degraded state. AWS defines high availability as 99.999% uptime, also known as "five nines". To put that in perspective, the system would be down for a mere five minutes and fifteen seconds a year. MOTAR achieves high availability by utilizing three availability zones within the AWS GovCloud West Region, meaning that even if two of the availability zones are not functioning MOTAR can still maintain the functionality of the platform.

Endpoint devices (such as headsets, gloves, and laptops) will not be included in the MOTAR authorization boundary but will be tracked for security compliance. MOTAR is developing a process for asset management and ensuring the proper configuration and security of these end devices.

Impact Levels are the combination of the sensitivity of the information to be stored and/or processed in the cloud; and the potential impact of an event that results in the loss of confidentiality, integrity, or availability of that information.
IL 2 – Includes public or non-critical mission information. Access to IL2 environments can be through the Internet, and personnel require a National Agency Check and Inquiries (NACI) investigation.
IL 4 – Can include up to CUI data, but not National Security Systems (NSS) data. Access to IL4 is via NIPRNet through a cloud access point (CAP), and personnel require a Tier 2 investigation (Public Trust).
IL 6 – Can include up to Secret level data. Access to IL6 environments is through SIPRNet only, with DoD SIPRNet enclave connection approval, and personnel require a Secret clearance.
Dynepic is working towards an ATO for the MOTAR IL4 environment, meaning vendors can develop applications that include up to CUI data. The developers of these applications must have a Public Trust investigation complete, and they must also have an IAT Level 2 certification to obtain privileged access required for development work.
Dynepic will work to build an IL6 environment in 2023 which will allow vendors to build applications that can include up to Secret data. The developers of these applications must have a Secret clearance.
Copy link
On this page
Does MOTAR have an ATO?
What is the MOTAR categorization level and any applicable overlays?
What is the difference between ATO and CMMC compliance?
Is there a classified version of MOTAR?
Will MOTAR provide a cross-domain solution (CDS) for both the classified and unclassified realm?
What controls can be inherited from MOTAR?
What defense in-depth security mechanisms are in place for MOTAR?
What security mechanisms are in place for the containerized environment?
Where is MOTAR hosted and what security controls are in place?
Is MOTAR fault-tolerant or highly available, and what is the difference between the two concepts?
Are endpoint devices included within the MOTAR ATO?
What is the difference between the Impact Levels? What do the different impact levels mean for vendors developing applications within MOTAR?