I submitted the required artifacts [System Authorization Access Request (SAAR) and Enterprise Mission Assurance Support Service (eMASS) Computer Based Training (CBT) and Cyber Awareness Challenge (CAC) Training Certificates] for obtaining an eMASS account, but still do not have an account? The artifacts are prerequisites for obtaining an eMASS account. In order to complete the process, Industry users must register for a National Industrial Security Program (NISP) eMASS Account at https://nisp.emass.apps.mil/. Detailed instructions on obtaining an eMASS account, training links, and required forms are available at the NISP eMASS Information and Resource Center: https://www.dcsa.mil/mc/ctp/tools

I registered for an eMASS account, but was denied. What did I overlook? In order to obtain an eMASS account, cleared Industry must complete ALL of the actions listed below:

• Submit all required artifacts
• Defense Information Systems Agency (DISA) eMASS Computer Based Training (CBT) Training Certificate,
• DISA Cyber Awareness Challenge (CAC) Training Certificate
• Defense Counterintelligence and Security Agency (DCSA) Industrial Security Field Operations (IO) SAAR) to DCSA NAO eMASS mailbox: dcsa.quantico.dcsa.mbx.emass@mail.mil
• Access NISP eMASS instance (https://nisp.emass.apps.mil/) and complete user registration.

I am attempting to complete the “New User Registration” in eMASS and cannot locate my Commercial and Government Entity (CAGE) Code.  How do I proceed? Please contact the DCSA NAO eMASS mailbox: dcsa.quantico.dcsa.mbx.emass@mail.mil and provide the CAGE Code and organization name. The DCSA NAO eMASS team will ensure the CAGE Code specified has the appropriate level of safeguarding approved, and will create an eMASS container.

My eMASS account was deactivated due to inactivity. What actions are required to activate my account? The eMASS user accounts are automatically deactivated after 30 days of inactivity (no log-in). Ten days and three days prior to deactivation, eMASS will send the user a reminder notification e-mail. After 30 days of inactivity (no log-in), eMASS will automatically deactivate the account and send an e‑mail notifying the user the account is deactivated. Inactive users will receive a warning message when accessing eMASS after account deactivation. When inactive users select [Click Here], an account reactivation request is sent to eMASS system administrators. When a deactivated user account is reactivated by an administrator, that user will receive an e-mail notifying them of the account reactivation. If an eMASS user’s last login date is greater than 90 days, the user must submit a new DSCA SAAR and the required training certificates (eMASS CBT and DISA CAC Training) to the DCSA NAO eMASS mailbox: dcsa.quantico.dcsa.mbx.emass@mail.mil. Training certificate completion dates cannot be greater than one year of the reactivation request.

How do Industry users request a modification to their eMASS account? Requests to modify an existing NISP eMASS user account are processed via the DCSA NAO eMASS team. If an additional eMASS role and/or CAGE Code access is required, Industry must submit an updated DCSA SAAR to the DCSA NAO eMASS mailbox: dcsa.quantico.dcsa.mbx.emass@mail.mil. The SAAR (Block 13) must contain the updated role and/or CAGE Code information. In addition, the Facility Security Officer (FSO) or a cleared Key Management Personnel (KMP) member from each CAGE Code must sign the DCSA SAAR. The SAAR (Box 27) has space for additional signatures. Ensure the e-mail subject line states the following: “Modification to an Existing eMASS User Account”.

How do Industry users add new credentials to their existing eMASS account? If a user has an existing eMASS account but needs to add a new DoD Public Key Infrastructure (PKI) certificate, the user will enter the e-mail address that matches the one associated with their new certificate at the eMASS login and click [Save]. A confirmation message appears and eMASS sends the user a confirmation e-mail. Upon receiving the automatically generated confirmation e-mail, a user should click the verification link embedded within the e-mail body. After verification by the user, the eMASS system administrators will receive a workload task alerting them of a new PKI certificate request awaiting approval. Once the eMASS system administrators approve the new certificate request, the user will receive a confirmation e-mail. The new certificates will be added and displayed under “Current Certificates” on the “User Details” screen.

I have the eMASS IAM role for my facility container, but I am unable to access the systems under my CAGE Code. How do I obtain access to the systems in order to work on the security plans? In order for users to access systems within a container, they must be an assigned user. Roles are assigned to systems during “New System Registration”. An assigned IAM can go back and assign additional users by doing the following:

• Select the System
• Click the Management Tab
• Select Personnel
• Click Edit in the Control Approval Chain (CAC)/Package Approval Chain (PAC)
• Select the applicable users in the IAM Available Users column and drag to the Assigned Users list box

I am trying to access the Risk Management Knowledge Service portal to take the eMASS Training, but I am experiencing application errors. How do I correct the issue? DCSA does not own/manage the RMF Knowledge Service. For application issues, contact the RMF Technical Inquiries Team at:

osd.pentagon.dod-cio.mbx.support-rmfknowledgeservice@mail.mil

The following information must be included with each help desk ticket submission:

• Contact information
• Domain: NIPR
• Errors: What type of error? What does the error say? When do you receive the error? If possible, provide screenshots.

I have IAM access, but I do not have permissions to start a Package Workflow for Assess & Authorize. How do I submit a system for authorization? Industry users are not required to initiate a workflow to submit a system for authorization. Follow the guidance in the NISP eMASS Industry Operation Guide [located here: https://www.dcsa.mil/mc/ctp/tools/ (eMASS Tab/Resources)]. Industry will use the Bulk Processing feature in eMASS to submit controls to the Information Systems Security Professional (ISSP) in the CAC - 2 Role for validation. The ISSP will complete the control validation/assessment. When the validation process is complete, the ISSP will initiate the PAC workflow.

How can I tell if I successfully submitted the security controls to the ISSP (SCA/CAC Role 2)? To check the security controls status in the CAC, IAM users that either registered the system or have an assigned IAM role for a system package can run a CAC History Report (Reports > CAC History Report > Select the System Acronym from the drop-down menu > Generate Report). This report allows users to see the system's status within the CAC. Users can also see the location of the security controls by viewing the Control Approval Chain (CAC) History in Control Details. Throughout the CAC process, users can review all comments applied to a control via [Show History].

I followed the guidance in the NISP eMASS Industry Operation Guide and successfully submitted all the security controls to the ISSP (SCA/CAC – 2 Role). I need to edit a security control, but I am receiving an error. How do I correct this issue? In order for the IAM (CAC – 1 Role) to edit security controls and/or add test results after submitting to the ISSP (SCA/CAC – 2 Role), they will need to contact their assigned ISSP and request that the security controls be returned to the CAC – 1 (IAM/Industry). The IAM will not be able to edit the security controls until the controls are returned to their role.

What is the “Overall Risk Score” in eMASS? Is this new? How do I obtain this information?  The eMASS was recently updated and now requires the Overall Risk Score to be entered in the Authorization Information section. The overall risk score is based upon the Risk Assessment Report (RAR) results. (See the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-30, Revision 1, Guide for Conducting Risk Assessments.)

How does an organization receive authorization for a Common Control Provider (CCP) plan? Organizations need to submit a CCP plan (CAGE Code-CCP-System Name) in eMASS. A CCP plan will enable an organization to document their common controls. This will ensure consistency and streamline assessment and authorization processes. The CCP package will be used to identify the common controls and all the associated procedures and artifacts. In addition, it will specify if the common controls provide the required protection fully or in hybrid fashion. The requirements for the CCP plan are the same as other system security plans. Organizations will be required to address System Details, Control Information (Implementation Plan, System Level Continuous Monitoring (SLCM)), Test Results (all CCIs/Assessment Procedures), and upload all associated artifacts. Security controls that will not be addressed in the CCP plan will be marked as Not Applicable. In addition, organizations must include a digitally signed document detailing the CAGE Codes and locations of the facilities authorized to inherit from the CCP. This document will be used as a supporting artifact and will be uploaded into the Artifacts tab.

Once the CCP plan is developed, the organization will submit the package and request authorization to allow systems to inherit the common controls. The CCP will require re-authorization when common controls are modified or added. These controls cannot be inherited on any authorized system until authorization is granted by the AO. CCP plans created for a single location should select their local ISSP for the SCA role and the appropriate Regional AO for the AO role. If the CCP plan covers more than one facility within a region, contact your local ISSP to determine the appropriate ISSP to assign in the SCA role, the Regional AO will be selected for the AO role.

If the CCP plan covers all DCSA regions, organizations will assign "NAO Headquarters" for the SCA role and "NAO Headquarters - TL" for the TL role.  The NAO, Karl Hellmann, will be the AO. 

How many security controls should be marked Not Applicable Official (NAO) after applying the MUSA baseline?  When applying only the DCSA Baseline Overlay, 9 controls will be marked NAO.  When applying both, the DCSA Baseline and MUSA Overlay, 120 controls will be marked NAO.  This will be shown on the Controls > Listing under "By Control Status".  If test results for controls marked NAO are edited, the status will change to Not Applicable Unofficial (NAUO).  For this reason, users must follow the guidance in the NISP eMASS Industry Operation Guide and work with their assigned ISSP.

How do users tailor in and tailor out controls within eMASS? Guidance for tailoring security controls is provided in the NISP eMASS Industry Operation Guide [located here:  https://www.dcsa.mil/mc/ctp/tools/ (eMASS Tab/Resources)].

Tailoring out controls:  If it is deemed that a baseline security control is Not Applicable (NA), the user can set the control as “Not Applicable” from the “Control Information and Actions” section on the [Control Details] page.  If “Not Applicable” is selected from the dropdown menu, a comment box appears.  The “Comments” text field is mandatory and is used to provide justification for this status.  Enter comments and click [Save].

Tailoring in controls: The “Manage Security Controls” page allows users to add additional (i.e., tailor in) controls to the system’s baseline security controls. Click “Add Additional Controls” to open the “Add Additional Controls” screen. Conduct the following actions:

• Select “Controls” search for the desired control to add to the system record’s baseline security control set by clicking [Search]
• Select the [+] button next to each control that will be added to the system’s baseline control set
• Provide justification for adding the security controls
• Click “Apply”; the selected controls will now be displayed
• Review the controls that will be included in the system’s baseline security control set
• Click “SAVE”

What defines a Risk Management Strategy? Where do I get guidance on developing a Risk Management Strategy? Reference NIST SP 800-30, Revision 1, Guide for Conducting Risk Assessments and NIST SP 800-37 Revision 2, Risk Management Framework for Information Systems and Organizations – A System Life Cycle Approach for Security and Privacy. The DCSA Assessment and Authorization Process Manual (DAAPM) provides these references. As stated in NIST SP 800-30, “The purpose of the risk framing component is to produce a risk management strategy that addresses how organizations intend to assess risk, respond to risk, and monitor risk—making explicit and transparent the risk perceptions that organizations routinely use in making both investment and operational decisions. The risk management strategy establishes a foundation for managing risk and delineates the boundaries for risk-based decisions within organizations.”

As stated in NIST SP 800-37, “This strategy includes the strategic-level decisions and considerations for how senior leaders and executives are to manage security and privacy risks (including supply chain risks) to organizational operations, organizational assets, individuals, other organizations, and the Nation. The risk management strategy includes an expression of organizational risk tolerance; acceptable risk assessment methodologies and risk response strategies; a process for consistently evaluating security and privacy risks organization-wide; and approaches for monitoring risk over time.” When conducting risk assessments and completing the RAR, Industry should also be referencing national level guidance.

Is there guidance for “Developing and implementing an organization-wide strategy for monitoring control effectiveness”? Reference NIST SP 800-37 Revision 2, Risk Management Framework for Information Systems and Organizations – A System Life Cycle Approach for Security and Privacy and NIST SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations. The DAAPM provides these references. As stated in NIST SP 800-37, “The organizational continuous monitoring strategy addresses monitoring requirements at the organization, mission/business process, and information system levels. The continuous monitoring strategy identifies the minimum monitoring frequency for implemented controls across the organization; defines the ongoing control assessment approach; and describes how ongoing assessments are to be conducted (e.g., addressing the use and management of automated tools, and instructions for ongoing assessment of controls for which monitoring cannot be automated).”

Is Two Person Integrity (TPI) and Dual Authorization the same? No. Dual Authorization and TPI are two different things. As stated in AC-3(2) Supplemental Guidance, Dual Authorization may also be known as Two-Person Control. The definition for Dual Authorization is the approval of two authorized individuals to execute. This includes the technical separation of roles (e.g., Data Transfer Agent (DTA), Information Systems Security Manager (ISSM), and/or designated representative). DTAs are the only individuals authorized to transfer data from a classified system to removable media and only the ISSM and/or designated representatives are authorized to enable permissions to transfer removable media. TPI requires that all actions involve the presence of two authorized individuals. Two authorized individuals must be physically present during the entire process. As stated in the DAAPM, TPI is only required for High-to-Low data transfers. The Information Owner may leverage additional requirements for any data transfer to media.

When the DAAPM (Appendix P) refers to Data Transfers, do these requirements only apply when transferring data to/from removable media? Or do Data Transfer/Assured File Transfer (AFT) procedures apply when transferring data over a network between two authorized systems on the same Local Area Network (LAN)/Wide Area Network (WAN)? DAAPM Appendix P focuses on conducting manual transfers of data between security domains. However, Industry is required to implement information flow enforcement (Example: AC-4) through the use of controlled interfaces and any other applicable controls in Appendix A of the DAAPM.

When addressing CCIs/Assessment Procedures (APs), Industry is documenting the results of their self-assessment and determining if all aspects of the security control, including the CCIs, are compliant, non-compliant, or not applicable. The Test Results section of eMASS is required and used to provide confirmation that the security controls are applied and meet the security requirements for the system. Industry should not be repeating what is already documented in the DAAPM. When documenting the test results, Industry needs to show the ISSP how they completed the assessment and how/why the control compliance status was determined. DCSA understands that breaking down security control compliance to the CCI level is a time consuming process. However, assessing security controls is an integral part of the RMF process and must be completed.

What is an acceptable response for the implementation plan? Am I required to address implementation if I am in compliance with the DAAPM? Implementation responses are required and unique to each system/organization. Industry must document the implementation strategy and functional description of security control implementation (including planned inputs, expected behavior, and expected outputs). The response must detail how the security capability is achieved.

What is “security relevant”?  Security relevant is any hardware or software that is "security enforcing," "security supporting," or "security non-interfering" which can affect a system's configuration, functionality, or users' privileges, and has the potential to change the risk imposed on the system.

Security Enforcing: Operating System (OS), access control applications, audit applications, device control applications, second party applications that perform information assurance, account management, anti-virus, firewall; capable of making changes to the security substructure of the system: modifies a user's account or changes permissions on objects such as enforcing Discretionary Access Control (DAC), Mandatory Access Control (MAC), and Network Access Control (NAC).

Security Supporting:  Impacts a security process or procedures (e.g., software used to perform technical review for AFT, software that is only used by privileged users of the system in the performance of their duties, removing a backup server which may affect availability, and code or script that authenticates the user and determines authorization).

Security Non-Interfering:  Does not enforce or support any aspect of the system security policy, but due to its presence inside the security boundary (e.g., code running a privileged hardware mode within the OS) risk is elevated.

Guidance is provided in DAAPM Appendix A – CM-2(1) and CM-3 (DCSA Supplemental Guidance).

What type of artifacts should Industry provide to DCSA when requesting authorization of special purpose and/or tactical hardware that cannot implement all security controls? Industry must coordinate with the Information Owner (IO) and provide evidence that this type of system is contractually required. For controls tailored out based on contractual requirements, the Authorizing Official (AO) must be provided with the complete rationale and justification via a Statement of Work (SOW), DD Form 254, or artifact from the IO. In addition, the RAR must detail the specific security controls that cannot be implemented.