Per ARCYBER OPORD 2018-097, published April 20, 2018, the RMF Assess Only process will be implemented NLT July 2, 2018 to replace the Army CoN process.The OPORD and NETCOM Operational TTP are both published on the RMF Knowledge Service (
RMFKS). Access the link below, for the OPORD see the Orders and Fragos folder, for the TTP see the TTPs folder:
https://rmfks.osd.mil/rmf/collaboration/Component%20Workspaces/USArmyCW/USArmyOperations/Pages/default.aspx
NETCOM Risk Management Framework Assessment Only Operational Tactics, Techniques, and Procedures, Version 1, April 2018 describes the current "Assess Only" process for the Army. The following is a summary of the guidance.
- The Assess Only process applies to Army Information Technology (IT) that does not meet the Assess and Authorize (e.g. full RMF) criteria as described by DoDI 8510.01. This includes Platform IT (PIT), IT Services (Internal and External), and IT Products (Applications, Software, and Hardware).
- The RMF applies to all DoD IT that receive, process, store, transmit, or display DoD Information (see DoDI 8510.01). DoD Information is any information that has not been cleared for public release and that has been collected, developed, received, transmitted, used, or stored by DoD, or by a non-DoD entity in support of an official DoD activity (DoDD 5230.09). DoD Information is also any official DoD information that pertains to military matters, national security issues, or subjects of significant concern tot he DoD (DoDD 5230.09).
- The Information System Owner (ISO)/Program Manager (PM) will determine the IT type for the entity being considered for Assess Only by using the IT Type Wizard on the RMF Knowledge Service. Note that a Major Application, which will require Assess & Authorize (A&A), is any application that is a product or deliverable of an Acquisition Category I through III program as defined in Enclosure 1 of DoDI 5000.02 "Operation of the Defense Acquisition System," January 7, 2015.
- The ISO/PM will identify the mission category and the requirements to protect the confidentiality, integrity, and availability (CIA) of the information being processed. The mission category will be assigned a value of: MISSION SUPPORT, MISSION ESSENTIAL, OR MISSION CRITICAL. Available assignment values for categorization are Low, Moderate, or High for each security objective. Note that depending on the mission category, an application may be designated as a Major Application and thus disqualified for the Assess Only process (e.g. a Support application processing {H,H,H} information types).
- The Assess Only decision process is depicted as follows.
- For the Assess Only process, the Security Control Assessor - Organization (SCA-O) is responsible for performing the validation activities usually performed by the SCA-Validator (SCA-V). The SCA-O role is intended to be a title used by the Organization or Program Information System Security Manager (ISSM) or any other staff member supporting the AO that the AO chooses to delegate.
- IT being assessed will either have results recorded in an existing eMASS record a new Assess Only eMASS record.
- The security control baseline for Assess Only registrations is pre-defined based on the Application Security and Development STIG.
- For IT that does not fit into one of the pre-defined paths in the Assess Only process, the NETCOM Cybersecurity Directorate (CDS), as the designated SCA-Army, will triage the IT being considered for Assess Only.
- DISA IASE STIG Viewer assessment result checklist file (.CKL) or Continuous Monitoring Risk Scoring (.CMRS) will be used to import into the Assets module in eMASS. DISA's ACAS will be used for vulnerability scan results.
- The Information System Owner (ISO)/Program Manager (PM) will establish the relationships between the Assess Only registration(s) and authorized computing environment/enclaves (Assess and Authorize registrations). Any association, internal or external, requires evidence to support the documentation of inherited controls (this will happen automatically for internal associations; manual entries will be required for external associations).
- Fielding IT from any DoD approved program as a one-time deployment into an existing boundary does not require a new eMASS record. The eMASS record of the authorization boundary where the IT is being deployed (e.g. RNEC ICAN) will be utilized to record security control implementation and POA&M approval.
- Fielding a single hardware or software item into a one-time single deployment into an existing authorization boundary does not require a new eMASS record. The software must be assessed with named STIG (SRG not acceptable).
- Fielding IT from a DoD approved program as part of a managed solution or Program of Record (PoR) will require a new eMASS Assess Only registration, where the AO of the managed solution or PoR will be the approver.
- Fielding a single hardware or software item into multiple authorization boundaries in which the single software item will be centrally managed will require a new eMASS record. The ISO/PM responsible for managing the single software item will maintain the eMASS record.
- Any combination of hardware, software, or applications that are being fielded into an authorized computing environment can be approved via the Assess Only process and will require a new eMASS record.
- Platform IT requires a new eMASS record to support Assess Only approval.
Once the decision has been made whether to create a new eMASS record or use an existing eMASS record, the IT type is assessed as follows:
- ISO/PM identifies the applicable STIGs to be used to assess the IT type. The DISA SRG/STIG Applicability Guide and Collection Tool can be used. The ISO/PM lists the applicable STIGs in an Excel file and uploads them to the appropriate eMASS record.
- The ISO/PM reviews the security controls in Appendix C of the TTP as well as those security controls contained in the applicable STIGs. If any of the applicable security controls are not included in the initial security controls baseline, the ISO/PM will tailor in the additional security controls by updating the Implementation Plan in the eMASS record. The ISO/PM will ensure that any required overlays are tailored to the security controls baseline. The following security controls are listed in Appendix C: AC (20), AT (1), AU (23) , CA (1), CM (13), CP (3), IA (23), MA (4), MP (1), PM (1), SA (7), SC (22), SI (9).
- The ISO/PM performs STIG assessment and uploads the results as a CMRF export (.XCCDF) and checklist (.CKL). The ISO/PM will also import the CMRS export files into the Asset Manager module of the eMASS record where the IT type is being deployed. The ISO/PM will ensure all failed STIG rules are mapped to applicable security controls and that non-compliant test results are created.
- When all test results are recorded, complete the second step of the Control Approval Chain (CAC). The SCA-O will review and validate all controls.
- The SCA-O in conjunction with the Organizational ISSM will populate the Risk Assessment tap in eMASS, identifying the Vulnerability Summary and the Recommendations for vulnerability mitigation or remediation. The SCA-O can refer to the Security Control Assessor-Validator TTP, Appendix D, for assistance in calculating risk.
- The ISO/PM will create POA&M vulnerabilities for all non-compliant security controls. The ISO/PM will ensure that the POA&M Vulnerability Description matches the Vulnerability Summary from the Risk Assessment block.
- For IT being added to an existing eMASS record, the ISO/PM will create a POA&M Approval Package in eMASS. The Program ISSM will review the risk of any non-compliant security controls and compare that risk to the current approved residual risk level assigned to the authorization of the computing environment where the IT will be deployed. If the risk of accpeting the IT does not increase the risk of the authorized computing environment, the Program ISSM can approve i the AO role of eMASS. If the risk is increased, the AO must approve accepting the IT.
- For new Assess Only registrations in eMASS, the ISO/PM will create and submit an Assess Only Package for approval. The package will be routed through the Assess Only Package Approval Chain (PAC) for approval.
DOD
Instruction 5000.02, "Operation of the Defense Acquisition System",
January 7, 2015, defines Mission Critical and Mission Essential:
Mission-Critical Information System. A system that meets
the definitions of "information system" and "national
security system" in the Clinger-Cohen Act (Subtitle III of title 40 of U.S. Code (Reference (p))),
the loss of which would cause the stoppage of warfighter operations or
direct mission support of warfighter operations. (The designation of mission
critical will be made by a DoD Component head, a Combatant Commander, or their
designee. A financial management IT system will be considered a
mission-critical IT system as defined by the Under Secretary of Defense
(Comptroller) (USD(C)).) A "Mission-Critical Information Technology
System" has the same meaning as a "Mission-Critical Information System."
Mission-Essential Information System. A system that meets
the definition of "information system" in 44 U.S.C. 3502
(Reference (aw)), that the acquiring DoD Component Head or designee determines is basic and
necessary for the accomplishment of the organizational mission. (The
designation of
mission-essential will be made by a DoD Component head, a
Combatant Commander, or their designee. A financial management IT system
will be considered a mission-essential IT system as defined by
the USD(C).) A "Mission-Essential Information Technology
System" has the same meaning as a "Mission-Essential Information System."
Mission Support are information systems that do not fall
into either Mission Critical or Mission Essential.
The NETCOM Assess Only Tracker page is here:
https://army.deps.mil/NETCOM/sites/RMF/SitePages/Assess_Only_Tracker.aspx
The following paragraph concerns the old Army CoN process and is included here for historical record.
In accordance with
AR 25-1, paragraph 6-8, a Certificate of Networthiness (CoN) is required for all applications that are deployed on the Land Warrior Network, or LandWarNet (LWN). LWN is the Army's contribution to the global information grid (GIG), currently known as the DoD Information Network (DODIN), which consists of the globally interconnected, end-to-end set of Army information capabilities; associated processes; and personnel for collecting, processing, storing, disseminating, and managing information on demand to support Warfighters, policy makers, and support personnel. LWN includes all Army-owned, leased, and leveraged DoD, Joint communications and computing systems and services; software (including applications); data-security services; and other associated services (
AR 25-2, paragraph 1-5c). The Army Network Enterprise Technology Command (NETCOM) manages CoN processing through the
Networthiness SharePoint Portal. NETCOM, formerly a Direct Reporting Unit (DRU) to the Army CIO/G-6, is now a subordinate command to ARCYBER/2nd Army (effective 2014).
Many people ask whether they need a CoN or an Authority to Operate (ATO) (or both). The Army CIO/G-6 Cyber Directorate Office of Information Assurance or Accreditation (IACorA) has prepared the following guidance:
Application or Information System Determination: Definitions, Scenarios, Illustrations and Decision Tree, Version 1.1 23 January 2013. This 20-page document provides guidance necessary to make the distinction between application and system. Generally, if an application can be installed through "Add/Remove Programs" and has no server component, then it is an "application" (and thus only requires a CoN). There are scenerios (e.g. Scenerio 9) where an server can be categorized as an application if it a web service that is installed on an approved operating system and does not include other dedicated supporting servers or services. If the application is delivered as a solution (i.e. acts as a server, is delivered with an operating system, and/or opens up port(s) for unsolicited client communication, then it is a "system" (and thus requires an ATO). Under RMF, refer to DoDI 8510.01 or
Define DoD Information Technology Type on the RMF Knowledge Service site. Sometimes the easiest way to make the determination is to apply for a CoN and see if it gets processed. All Information Systems ("systems"), which include Major Applications and Enclaves, as well as Platform IT (PIT) Systems must be assessed and authorized per
DODI 8500.1 (see 9a, Figure 2) IAW
DODI 8510.01 (was DIACAP, now RMF for DoD). Note that systems that are "type" accredited must be issued a CoN prior to deployment on LWN. This also applies to systems that are under development and have been approved for testing and granted an IATT - a Test CoN (T-CoN) is required also. For more details concerning CoN processing, see
External SOP v0.9.
Per NETCOM's Memorandum "
Certificate of Networthiness Expiration Dates" issued April 1, 2013, CoNs are valid for three years and are good for the major version of the application (i.e. if version 1.0 is approved, version 1.x is approved up to version 2.0). Depending on factors such as licensing agreements, functionality provided by the application, etc. a Limited CoN (LCoN) may be issued. LCoNs are not applicable Army-wide and you must fall into the scope of the LCoN to be allowed to use the application.
CoNs are more concerned with configuration management (keeping an application inventory for the Army, eliminating redundant applications, etc.) versus security. Other than looking out foreign ownership or control, there is little security analysis performed as part of the CoN process.
References:
