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.

If I am a vendor that will build an application, can I leverage the MOTAR ATO?

The MOTAR Live (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 be built 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) and a MOTAR Fastlane app deployment pipeline, 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.

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?

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 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?

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.

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?

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.

What is the process for applications to obtain an ATO for use within MOTAR?

There are currently three options available:

1. Leverage the MOTAR ATO and be included in the MOTAR authorization boundary

2. Assess Only and be included in the MOTAR ATO package (but still have security responsibilities)

3. The application obtains its own ATO and once achieved develops an Interconnection Service Agreement (ISA) with MOTAR

Do I need to purchase scanning licenses for my application?

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.