MOTAR
Search…
Vendor / Application Responsibilities
This page provides details on the Authorization to Operate (ATO) for MOTAR and how content activated on MOTAR can leverage the ATO.

Dynepic (MOTAR vendor) is complaint with CMMC 1.0 requirements and is currently evaluating CMMC 2.0 requirements.
The MOTAR IL4 environment is aligned with DoD DevSecOps Reference Design and will include its own Software Factory for Continuous Integration/Continuous Deployment (CI/CD) implementation, continuous monitoring, and automation. For applications that can build out using Software Development Kits (SDKs) and tools within the MOTAR authorization boundary, these applications can reside within the MOTAR authorization boundary and not require their own ATO (aligned with the Platform One Certificate to Field model).
So long as the application is able to utilize MOTAR’s existing HW/SW List and Ports, Protocols, Service Management (PPSM), it would be a viable candidate to be within the MOTAR authorization boundary. We are currently reviewing all controls and assessment procedures to determine what controls the application can inherit from MOTAR and what would need to be completed by the application within their system security plan. This inheritance model and the security responsibilities of both MOTAR and the application will be spelled out in a Memorandum of Agreement (MoA) between MOTAR and the application. If however, the application requires HW/SW not already included within MOTAR or requires external communications not covered by the MOTAR PPSM, then the application will most likely need to obtain its own ATO.
Hint: The more your applications can utilize the MOTAR services (Authentication, data storage, LCMS, etc.), the easier it will be for your application to fall in our ATO boundary.

The MOTAR PPSM is not yet approved, but once approved we will share with the vendor community so they are aware of what ports, protocols, and services are authorized within MOTAR.

If the application will be within the MOTAR authorization boundary, there is no requirement for the application to have a SIEM solution. MOTAR has a SIEM solution in place (as well as audit logging) for all elements within MOTAR. For applications that are not within the MOTAR authorization boundary, they are responsible to develop their own SIEM solution.

If applications want to be within the MOTAR authorization boundary, the vendor will need to link their code repository to the MOTAR Software Factory where security mechanisms will make sure the code will not introduce vulnerabilities into the platform. If vendors do not feel comfortable providing the source code to the MOTAR Software Factory for vulnerability scanning, they can certainly look to achieve their own ATO and develop an interconnection service agreement (ISA) with MOTAR so their application/content is visible within the MOTAR Platform.

MOTAR contains a plug-in called Cyber-Security Assurance Readiness (CSAR) tool that enables applications to participate in the Risk Management Framework (RMF) activities during the development phase. CSAR offers a wizard-like interface for application owners to navigate RMF steps with a Human-in-the-Loop advising the application team throughout their RMF journey. CSAR offers various assessment levels to achieve a rapid ATO, real-time feedback focused on risk, and has a mechanism to complete mandatory forms.
There are currently three options available:
  1. 1.
    Leverage the MOTAR ATO and be included in the MOTAR authorization boundary
  2. 2.
    Assess Only and be included in the MOTAR ATO package (but still have security responsibilities)
  3. 3.
    The application obtains its own ATO and once achieved develops an Interconnection Service Agreement (ISA) with MOTAR

MOTAR will be responsible to scan the environment and applications within the MOTAR environment for any vulnerabilities. It will be the responsibility of the application team to fix any vulnerabilities identified from the security scans. For applications that will require their own ATO, it will be the responsibility of those applications to purchase scanning licenses/tools to help identify vulnerabilities in their environment and application code.

Yes, Cloud One requires developers to obtain an IAT Level 2 certification for privileged access to Cloud One required for development work.
Copy link
On this page
If I am a vendor that will build an application, can I leverage the MOTAR ATO?
Is the MOTAR PPSM available so vendors can determine what ports, protocols, and services are available for applications they want to include within the MOTAR authorization boundary?
If my application resides within MOTAR, am I responsible to have a security incident and event management (SIEM) solution? Do I have any responsibilities from an incident response perspective?
Will MOTAR require the application source code so it can be run through the MOTAR software factory prior to including it in the MOTAR authorization boundary? What if I am not comfortable providing the source code?
What is the process for applications to obtain an ATO for use within MOTAR?
Do I need to purchase scanning licenses for my application?
Will app developers require an IAT Level II security certification to obtain privileged access to complete their duties?