Attachment_15_MCSC_SIAT_RMF_Process_Guide_20160525.pdf
PDF 830 KB Posted
- Solicitation number
- M67854-16-R-4001
- Issued by
-
United States Marine Corps
About this file
Attachment 15 (RMF Process Guide)
View the file
Other files
| File | Type | Posted |
|---|---|---|
| NACCR_AMENDMENT_0002_17_OCT_2016.pdf | ||
| NACCR_CONTRACT_DATA_REQUIREMENTS_Final_5_oct_16.pdf | ||
| NACCR_Questions_and_Answers_05_Oct_FINAL.pdf | ||
| NACCR_Amendment_0001_(MOD_DOC)_10-6_NRJ_RELEASED.pdf | ||
| Attachment_1_of_52.212-1.xlsx | XLSX spreadsheet | |
| NACCR_CDRLs.pdf | ||
| M67854-16-R-4001.pdf | ||
| Attachment_14_QASP.pdf | ||
| Attachment_2_of_52.212-1.xlsx | XLSX spreadsheet | |
| Attachment_3_Of_52.212-1.xls | XLS spreadsheet | |
| Draft_NACCR_PWS_25_Aug16.pdf | ||
| NACCR_PRESOLICITATION_NOTICE__25_August_2016_Final.pdf |
Show all 12
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
MARINE CORPS SYSTEMS COMMAND
SYSTEMS ENGINEERING,
INTEROPERABILITY, ARCHITECTURES
AND TECHNOLOGIES
RISK MANAGEMENT FRAMEWORK
PROCESS GUIDE
Version 1.0 25 May 2016
Jimmy Clevenger
Director Systems Security Engineering Division Systems Engineering, Interoperability, Architectures and Technologies (SIAT)
Marine Corps Systems Command
USMC MCSC RMF Process Guide
UNCLASSIFIED ii
THIS PAGE IS INTENTIONALLY LEFT BLANK.
UNCLASSIFIED iii
RECORD OF CHANGES
The table below identifies revisions to this document. The version number, date, and description of change for each revision are noted in the table.
Version Number Date of Issue Section(s) Change
Code* Brief Description of Revision
*A – Added M – Modified D – Deleted
Direct any questions and concerns about this guide to the Marine Corps Systems Command SIAT Systems Security Engineering Division, Cybersecurity Engineering Branch. People submitting comments should complete the comment resolution matrix (Appendix L) and send it to SIAT SSE via the C&A Manager ticketing system.1
1 https://mcscviper.usmc.mil/sites/SIAT/Architecture/CE/CAM/SitePages/Home.aspx
UNCLASSIFIED iv
TABLE OF CONTENTS
1 INTRODUCTION
1.1 Purpose
1.2 Scope
1.3 Background
1.4 How to Use This Guide
2 USMC RMF Roles and Responsibilities
2.1 RMF Personnel Qualifications
2.2 Role Descriptions
2.2.1 Authorizing Official (AO)
2.2.2 Authorizing Official Cybersecurity Analyst (AO CSA)
2.2.3 Security Control Assessor (SCA)
2.2.4 Security Control Validator (SCV)
2.2.5 Program Manager (PM)
2.2.6 Information Owner (IO)
2.2.7 User Representative (UR)
2.2.8 Information System Security Manager (ISSM)
2.2.9 Information System Security Officer (ISSO)
2.2.10 Information System Security Engineer (ISSE)
3 Authorization Types
4 RMF Process
4.1 RMF Step 1 - Categorize System
4.1.1 Assign Qualified Personnel to Stakeholder Roles
4.1.2 Create MCCAST Record
4.1.3 Identify DFIA Defense Level
4.1.4 Categorize the System
4.1.5 Identify CYBERSAFE Grade
4.2 RMF Step 2 - Select Controls
4.2.1 Generate Controls
4.2.2 Assess Initial Control Set
4.2.3 Initiate ISCM Strategy
4.2.4 Provide Recommendation (MCSC Gate 1)
4.2.5 Approve
4.2.6 Initiate Security Assessment Plan (SAP)
4.3 RMF Step 3 - Implement Security Controls
UNCLASSIFIED v
4.3.1 Implement Controls
4.3.2 Evaluate Security Authorization Package (MCSC Gate 2)
4.3.3 Conduct Pre-Assessment
4.3.4 Seek AO Acceptance of Risk
4.3.5 Provide Recommendation
4.3.6 Approve
4.4 RMF Step 4 – Assess Security Controls
4.4.1 Conduct Security Assessment
4.4.2 Create Security Assessment Report
4.4.3 Update POA&M
4.4.4 Update MCCAST Record
4.4.5 Submit Package
4.5 RMF Step 5 – Authorize System
4.5.1 Provide Recommendation (MCSC Gate 3)
4.5.2 Authorization Decision
4.5.3 Update Security Authorization Package
4.6 RMF Step 6 – Monitor Security Controls
4.6.1 Maintain Security Posture
4.6.2 Risk below Threshold
References ......................................................................................................... A-1 Appendix A
Acronyms .......................................................................................................... B-1 Appendix B
Reciprocity ........................................................................................................ C-1 Appendix C
MARINE CORPS Certified Application .......................................................... D-1 Appendix D
Plan of Action and Milestones ........................................................................... E-1 Appendix E
System Categorization ........................................................................................ F-1 Appendix F Defining System Categorization .............................................................................................. F-1
How to Categorize a System .................................................................................................... F-2
Risk Assessment Report .................................................................................... G-1 Appendix G Security Assessment Plan .................................................................................. H-1 Appendix H
Security Assessment Report ................................................................................ I-1 Appendix I
Security plan ....................................................................................................... J-1 Appendix J Security Plan Content .............................................................................................................. J-1
Command Cyber Readiness Inspections ........................................................... K-6 Appendix K Comment Resolution Matrix .............................................................................. L-1 Appendix L
UNCLASSIFIED vi
LIST OF TABLES
Table 1-1: RMF Required Documentation Table 2-1: MCSC RMF Roles/Stakeholders Table 3-1: Authorization Types Table 4-1: RASCI Definitions Table 4-2: RMF Steps Responsibility Assignment Table 4-3: DFIA-Related Definitions Table 4-4: DFIA Defense Levels Table 4-5: CYBERSAFE Grades and Characterization Table F-1: Impact Values from FIPS Pub 199............................................................................. F-1 Table F-2: Example of Information Types and Security Categorization ..................................... F-3 Table G-1 RAR Fields ................................................................................................................ G-3 Table G-2 Vulnerability Severity or Pervasiveness .................................................................... G-6 Table G-3 Threat Relevance ....................................................................................................... G-7 Table G-4 Likelihood Descriptions ............................................................................................ G-9 Table G-5 Overall Likelihood Rating ....................................................................................... G-10 Table G-6 Impact Descriptions ................................................................................................. G-11 Table G-7 Risk Descriptions ..................................................................................................... G-12 Table G-8 Risk .......................................................................................................................... G-12
LIST OF FIGURES
Figure 3-1: DoD IT Classification Breakdown Figure 4-1: RMF Process Flow Diagram Figure E-1: POA&M Layout ....................................................................................................... E-1
UNCLASSIFIED 1
1 INTRODUCTION
DoD Instruction (DoDI) 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT), implements the RMF for DoD IT, adopts the related National Institute of Standards and Technology (NIST) RMF guidelines, and provides the framework to manage life-cycle cybersecurity risk to DoD IT. The RMF uses a risk-based cybersecurity approach for authorization of IT systems and services. The RMF establishes and enforces a tailored set of security controls, and focuses on security as an integral part of a system’s overall lifecycle.
1.1 Purpose
This guide describes Marine Corps Systems Command’s (MCSC) processes to properly manage the risk of US Marine Corps (USMC) IT in accordance with the DoDI 8510.01 (reference (a)), taking into account USMC-unique operational and environmental needs. This guide also establishes the roles and responsibilities for RMF stakeholders and provides USMC Program Managers and the cybersecurity workforce with a practical guide for implementing RMF to facilitate Assessment and Authorization (A&A) and to operate IT with an acceptable level of risk.
This guide is not intended to duplicate existing NIST and DoD policy, directives, or guidance beyond what is required to define the MCSC process for RMF A&A. As this process evolves, SIAT SSE will update this guide.
1.2 Scope
The MCSC RMF Process Guide provides an overview and a process for MCSC IT to be assessed and authorized for MCSC IT that will receive, process, store, display, or transmit DoD information at the secret and below levels. These technologies are defined by the DoD as Information Systems (IS); Platform IT (PIT), including its sub-categories of PIT components, PIT systems, and standalone PIT systems; IT services; IT products; and stand-alone systems.
(The USMC has chosen not to classify any of its DoD IT as PIT.) This guide also describes the roles and responsibilities of the stakeholders in the six steps of the RMF process. It is written for users with a basic knowledge of USMC cybersecurity and A&A, and can help the cybersecurity workforce with the concepts and requirements incorporated into the Marine Corps Certification and Accreditation Support Tool (MCCAST).
Consistent with the DoD RMF policy, the USMC will require an Information System Continuous Monitoring (ISCM) Strategy as part of every IT’s Security Authorization Package, which section
4.2.3 addresses. The monitoring strategy describes the plan to continuously monitor the effectiveness of security controls employed within or inherited by the system and to monitor changes to the system and its operational environment. A DoD directive on ISCM is forthcoming, and as the USMC defines its ISCM requirements, this information will be incorporated into the guide.
The initial release of this process guide is limited to the process steps that will enable A&A under RMF, given the constraints associated with the current USMC operating environment.
Future releases of this guide will include additional expansion of the RMF process as it applies to
UNCLASSIFIED 2
the USMC. This guide, along with the USMC Enterprise Cybersecurity Directive (ECSD) 018 (reference (m)) and the MCCAST training guidance, forms the authoritative source to implement the RMF process within Marine Corps Systems Command.
1.3 Background
DoDI 8510.01 and DoDI 8500.01 (references (a) and (b), respectively) define the transition from Certification and Accreditation (C&A) under the DoD Information Assurance Certification and Accreditation Process (DIACAP) to the RMF A&A process. These DoD instructions point to compliance with overarching Federal guidelines, including the Committee on National Security Systems Instruction (CNSSI) 1253, Security Categorization and Control Selection for National Security Systems (reference (c)); Federal Information Processing Standard Publication (FIPS) 199, Standards for Security Categorization of Federal Information and Information Systems (reference (f)); and multiple NIST Special Publications 800 series.
While RMF for DoD IT provides a framework for achieving A&A, it leaves several key implementation aspects to the DoD components to define. Examples of component-specific details include the following:
• Roles and responsibilities
• Process for assessing IT services and IT products for inclusion in authorization boundaries
• Identification of common controls that are component-wide, or applicable to a subset of the components, and how those controls may be inherited
• Process for inter/intra-component reciprocity, using a centralized Authorizing Official
(AO)
• Definition of risk tolerance levels
• Assignment of organizationally defined control values
1.4 How to Use This Guide
This guide provides a two-part approach to presenting the RMF process. The first part depicts the overall RMF process in a single Responsible, Accountable, Supportive, Consulted, and Informed (RASCI) table, Table 4-1. The table gives a high-level outline of the six steps of RMF according to the USMC approach to the A&A. The reader will gain an understanding of the minimum activities required for the RMF process. The second part will then explain in more detail what happens during each step, who is responsible, what tools should be used, and what the input and output expectations are for each RMF step.
The remainder of this guide is devoted to an in-depth discussion of the major areas and deliverables that comprise the RMF process and Security Authorization Package. These include the following:
• System Security Categorization
• Security Plan (SP)
UNCLASSIFIED 3
• ISCM Strategy
• Security Assessment Plan (SAP)
• Risk Assessment Report (RAR)
• Security Assessment Report (SAR)
• Plan of Action and Milestones (POA&M) The USMC RMF stakeholders should rely on the Headquarters Marine Corps (HQMC) Command, Control, Communications, and Computers (C4) C&A/A&A website2 for the most up-to-date USMC-specific policy and guidance and the SIAT Cyber-Engineering Division website3 for MCSC-related guidance. The RMF Knowledge Service (KS)4 hosts wider DoD policy, and the USMC C&A/A&A portal may reference it as required to maintain consistency with the DoD's evolving policy and guidance.
Table 1-1 identifies the minimum documentation required to prepare a complete Security Authorization Package as required by RMF policy and includes an overview of the MCSC RMF Process Guide terminology. While this documentation should be generated by MCCAST, the tool’s capability is still evolving to support the creation of all this RMF documentation. If MCCAST is not able to generate the specific RMF document in a USMC-approved format, an uploaded artifact in MCCAST will be accepted until such time as the tool can generate the necessary RMF documentation. Specific guidance will be provided to the cybersecurity workforce via meetings and emails.
Table 1-1: RMF Required Documentation
DoD RMF Term Description USMC Term (Acronym) Reference
Security Authorization Package
The set of required documents developed for authorizing officials. The base package contains
(1) the security plan, (2) the security assessment report, and (3) the plan of action and milestones. The security authorization documentation is maintained throughout a system’s lifecycle, includes the authorization decision document, and is the minimum information necessary for the acceptance of an IS by a receiving organization.
Security Authorization Package
DoDI 8510.01;
NIST
Special Publication 800-37;
RMF KS
2 The HQMC C4 C&A/A&A site at https://eis.usmc.mil/sites/c4/cy1/default.aspx 3 SIAT Cyber Engineering site at https://mcscviper.usmc.mil/sites/SIAT/Architecture/CE/SitePages/Home.aspx 4 The RMF KS at https://rmfks.osd.mil
UNCLASSIFIED 4
DoD RMF Term Description USMC Term (Acronym) Reference
Security Plan Provides an overview of the security requirements for a system and describes the security controls in place or planned for meeting those requirements and implementation status.
Security Plan
(SP)
DoDI 8510.01;
NIST
Special Publication 800-37, 800-18;
RMF KS
Security Assessment Plan
Describes the objectives of the security control assessment and provides a detailed roadmap for conducting the assessment.
Security Assessment Plan (SAP)
NIST
Special Publication 800-53A;
RMF KS
Security Assessment Report
Describes the results of the security control assessment to determine the effectiveness of the security controls employed within or inherited by the information system, including recommendations for correcting any weaknesses in the controls.
Security Assessment Report (SAR)
NIST
Special Publication 800-37;
RMF KS
Risk Assessment Report
Provides risk assessment of Non-Compliant (NC) security controls and addresses vulnerabilities displayed in the SAR after the security control assessment has been completed.
Risk Assessment Report (RAR)
RMF KS
Plan of Action and Milestones
Addresses the residual vulnerabilities in the system. The POA&M lists the tasks to be accomplished, resources required, milestones for meeting the tasks, and scheduled completion dates for the milestones.
Plan of Action and Milestones
(POA&M)
SIAT CE
C&A website;
RMF KS
UNCLASSIFIED 5
2 USMC RMF ROLES AND RESPONSIBILITIES
Dedicated and qualified personnel are the most important aspect to ensure USMC systems adequately implement RMF cybersecurity requirements. This section describes the roles, responsibilities, and required qualifications for each role under the USMC RMF process.
Table 2-1 identifies the USMC-assigned RMF roles by appointment, consistent with DoDI
8500.01 (reference (b)), as well as the MCSC RMF Process Guide terminology for each role.
MCCAST identifies these roles as stakeholders.
Table 2-1: MCSC RMF Roles/Stakeholders
DoD RMF Role USMC Term Appointed By5
Authorizing Official (AO) AO USMC Chief Information Officer
(CIO)
----- AO Cybersecurity Analyst (AO
CSA) AO
DoD Component Senior Information Security Officer
(SISO)
SISO Department of Navy (DON) CIO
Security Control Assessor
(SCA) SCA AO
----- SCA Analyst SCA
----- Security Control Validator
(SCV) AO
----- Information Owner (IO) <Program-specific>
Program Manager (PM) PM CG Marine Corps Systems Command
----- Information System Security Engineer (ISSE) <Program-specific>
Information System Security Manager (ISSM) ISSM SCA
Information System Security Officer (ISSO) ISSO ISSM
User Representative (UR) UR CG Marine Corps Combat Development Command
(MCCDC)
5 Appointed by is the authority who appoints the individual to the role.
UNCLASSIFIED 6
2.1 RMF Personnel Qualifications
The PM for the system being assessed is responsible for identifying the RMF stakeholders within MCCAST. For roles assigned by the PM, qualified cybersecurity support personnel must be identified (e.g., SCVs fully qualified by the AO). Personnel serving in RMF roles must meet the suitability and fitness requirements established in DoDI 5200.02 (reference (d)). RMF personnel must also meet the cybersecurity workforce qualification standards in accordance with the latest DoD and USMC policy. (Refer to ECSD 024 (reference (u)) for the USMC cybersecurity workforce standards.) Personnel supporting RMF should have a commitment to and knowledge of the system(s) to which they are assigned. The PM must ensure RMF activities are planned and resourced for continued cybersecurity sustainment throughout the system lifecycle.
2.2 Role Descriptions
The following role descriptions briefly describe the USMC RMF stakeholder responsibilities as they relate to RMF. USMC ECSD 018 (reference (m)) is the authoritative source with more details of USMC cybersecurity roles and responsibilities and other specific qualifications required for stakeholder roles.
2.2.1 Authorizing Official (AO)
The USMC has one Service AO who is responsible for implementing the RMF. The USMC CIO is responsible for appointing the AO. The AO function is resident in HQMC C4 Cybersecurity Division.
The AO is responsible and accountable for system-related security risks. The AO makes an authorization decision based on the system-related security risks that may impact organizational operations and assets, individuals, other organizations, or the nation.
The AO has the following cybersecurity responsibilities:
• Performing all required and approved AO RMF process steps discussed in Section 4 of this guide
• Making a risk-based authorization decision for systems to operate in the USMC
• Rendering a final determination of risk to DoD operations and assets, individuals, other organizations, and the nation from the operation and use of the system
• Making a risk-based authorization decision to accept and use a DoD system through cybersecurity reciprocity, promoting reciprocity to the maximum extent possible
• Making a risk-based authorization decision for cloud solutions that meet the NIST definition of cloud computing and are subject to cloud policy (e.g., Federal Risk and Authorization Management Program).
• Approving system security categorizations and final security control sets for systems
• Establishing guidance for and overseeing system-level risk management activities
• Approving the SP, SAP, and system-level ISCM Strategy submitted by the PM and establishing reauthorization requirements based on the ISCM Strategy
UNCLASSIFIED 7
• Monitoring and tracking overall execution of POA&Ms
• Establishing minimum qualifications for SCVs
• Authorizing SCVs per USMC-established requirements
• Issuing Authorization to Operate (ATO) (and Authorization to Connect [ATC] to the Marine Corps Enterprise Network [MCEN]); Interim Authorization to Test (IATT);
Interim Authority to Build (IATB); or Denial of Authorization to Operate (DATO) for every system assessed and authorized through the RMF process
• Appointing RMF stakeholders as identified in Table 2-1.
2.2.2 Authorizing Official Cybersecurity Analyst (AO CSA)
To perform the AO function in the most efficient manner, the USMC will use a team of AO Cybersecurity Analysts (CSAs) to assist with AO responsibilities. AO CSAs reside in HQMC C4 Cybersecurity Division and report directly to the AO.
The AO CSA has the following cybersecurity responsibilities:
• Reviewing and concurring with system security categorization decisions
• Reviewing final security control sets for DoD systems and providing recommendation to
AO
• Reviewing the SP and system-level ISCM Strategy submitted by the PM and providing recommendation to AO
• Ensuring RMF process steps are followed and adhered to by RMF stakeholders
• Establishing and/or providing guidance to RMF stakeholders on RMF processes and procedures
• Ensuring AO authorization decisions are supported by sufficient documentation and risk assessments
• Ensuring authorization recommendations comply with higher level policy as defined by DoD/USMC policy
• Providing technical analysis of RMF artifacts to inform the authorization decision, in support of the AO
2.2.3 Security Control Assessor (SCA)
The MCSC SCA provides oversight and technical expertise to conduct RMF assessment activities throughout a system's lifecycle. Assessment activities are based on security requirements outlined in DoDI 8510.01 and ECSD 018 (references (a) and (m), respectively).
For MCSC, the Director SIAT, System Security Engineering (SSE) Division is the MCSC SCA.
The SCA maintains oversight of the cybersecurity risk assessment process within the overall RMF A&A process, assists with the assessment of the security controls, and certifies the residual risk in support of an RMF authorization. To determine the overall effectiveness of the security controls, the SCA conducts an independent, comprehensive assessment of the managerial, UNCLASSIFIED 8 operational, and technical controls employed within or inherited by a USMC system (i.e., an independent verification and validation). To help perform the SCA function, the USMC uses SCA Analysts and SCVs to assist with SCA responsibilities.
The SCA has the following cybersecurity responsibilities:
• Performing SCA RMF process steps, as provided in Section 4 of this guide
• Assessing and quantifying aggregate cybersecurity risk
• Documenting the SCA’s determination of compliance with the assigned security controls
• Conducting a threat and vulnerability-based cybersecurity risk assessment. The risk assessment evaluates threats, vulnerabilities, and potential impacts as well as existing and planned risk mitigation. The risk assessment must address the impact of all NC controls, and must clearly communicate the SCA’s conclusion on system cybersecurity risk, and any recommendations for special instructions to accompany the authorization decision.
• Preparing the RMF risk determination via the SAR, and making a recommendation to the AO for system authorization
• Preparing the SAR Executive Summary as the final and official document that certifies the risk as part of A&A
• Providing guidance on the MCSC RMF process, in alignment with USMC RMF guidance
• Supporting DoD and USMC continuous monitoring requirements
• Appointing RMF stakeholders as identified in Table 2-1.
2.2.3.1 SCA Analyst
The SCA has a team of analysts to help execute the SCA responsibilities. The SCA Analyst will act as the SCA’s representative and will interface with the PMs, ISSMs/ISSOs, ISSEs, SCVs, as directed. The SCA Analyst should be considered a risk assessment subject matter expert and provide support and assistance in the A&A effort.
The SCA Analyst has the following cybersecurity responsibilities:
• Assisting the SCA in executing SCA RMF process steps, as provided in Section 4 of this guide
• Assessing technical and non-technical security features of a system to address known threats and vulnerabilities. The analyst must consider and identify impacts as well as consider existing risk mitigation strategies.
• Acting as an independent and impartial assessor to determine and certify aggregate cybersecurity risk for recommendation to the SCA
• Reviewing the SAP for quality assurance and providing initial concurrence on behalf of the SCA for the SAP, and ensuring all appropriate security controls were assessed for compliance
UNCLASSIFIED 9
• Providing SAR analysis to the SCA and the PM
• Auditing RMF authorization packages
• Ensuring RMF A&A packages are correctly entered into MCCAST
• Guiding SCVs with the following:
o Understanding of the RMF risk assessment process o Applicability of security controls o Use of appropriate test procedures and tools o Recommending mitigation measures for specific vulnerabilities o Completing residual risk assessment o Traceability of test results to system components and the risk assessment, as reflected in the relevant RMF documentation o Understanding of cybersecurity policies and the effects of specific policies to the risk of a system
2.2.4 Security Control Validator (SCV)
The SCV, who is appointed by the AO, is an independent6 third party assessor who verifies and validates the system has implemented the approved security control baseline. The SCV acts as a trusted agent to the SCA; so while the PM funds the SCV, the SCV must remain independent of the design or development of the system in order to conduct an impartial assessment. The SCV should use the SCA Analyst as an advisor to assist in all matters of validation, documentation, vulnerability mitigation, and residual risk determination.
A program management office may hire a government or contractor support to act as the SCV for that program management office’s portfolio. However, that SCV must meet the definition of independence as shown in the footnote below.
SCVs must complete the USMC validator training requirements, which include the following, before they are added to the AO-approved list of SCVs:
• HQMC C4 Cybersecurity Cyber Assessment Methodology Course
• CNSSI 4016 Risk Management
• MCCAST training
• Information Assurance Technical Level II (or greater)
The SCV has the following cybersecurity responsibilities:
• Performing all required and approved SCV RMF process steps, as provided in Section 4 of this guide
6 The term “independent” in this context means the validator is free from any perceived or actual conflicts of interest with respect to the development, operation, and/or management of the information system. (See NIST SP 800-53A, Section 3.1.)
UNCLASSIFIED 10
• Preparing and submitting the SAP with program assistance
• Assisting with required MCCAST data entry requirements
• Conducting a complete security control assessment of technical and non-technical security features of a system to address known threats and vulnerabilities. The assessment must identify impacts and consider existing risk mitigation strategies.
• Completing a SAR in conjunction with the ISSM based on the security control assessment results
• Developing the initial RAR and POA&M based on the assessment results. For a security control assessment, the SCV will complete those portions of the POA&M to identify weakness, affected device, raw CAT, control, mitigated CAT, mitigation, source identifying weakness, status and comments.
• Ensuring traceability of all vulnerabilities from raw assessment results to the POA&M
• Conducting required vulnerability analysis to support mitigation and residual risk determination
• Completing the SAR Executive Summary, with all assessment results, for SCA Analyst review and SCA certification and signature
• Coordinating with the SCA Analyst in all matters of risk determination should questions or issues occur
• Supporting the execution of the continuous monitoring strategy to support continuing authorization requirements or ongoing authorizations
2.2.5 Program Manager (PM)
The PM represents the interests of the system throughout its lifecycle (acquisition, lifecycle schedules, funding responsibility, system operation, system performance, and maintenance). The PM leads the organization that has been assigned system lifecycle management and ensures the appropriation of funds to support cybersecurity standards through the lifecycle of the system.
The PM integrates security requirements into the system solution, thereby ensuring an acceptable level of risk is maintained within the operational environment. This must be accurately documented in the RMF package.
Note: NIST Special Publication 800-37 Rev 1 (reference (g)) states the “Information System Owner (or Program Manager)” is the “official responsible for the overall procurement, development, integration, modification, or operation and maintenance of an information system.”
However, DoDI 8510.01 (reference (a)) states the term ISO is not synonymous with PM as indicated in Reference NIST Special Publication 800-37. This guide uses the term PM.
The PM has the following cybersecurity responsibilities:
• Performing, or having a designated PM representative perform, all required and approved PM RMF process steps, as provided in Section 4 of this guide
• Implementing the RMF security controls for the PM’s systems
• Enforcing AO authorization decisions for hosted, standalone, or interconnected systems
UNCLASSIFIED 11
• Coordinating system security requirements, including inheritance agreements, with receiving organizations early and throughout system development to support reciprocity
• Complying with statutory law, such as (1) the Federal Information Security Modernization Act (FISMA), which is tracked in DITPR-DON, and (2) the Clinger- Cohen Act, of which the Cybersecurity Strategy is a component
• Assisting with development, maintenance, and execution of the SP
• Ensuring POA&M development, execution, and maintenance
• Assigning resources, milestones, resource funding, and estimated completion dates to the
POA&M
• Implementing continuous monitoring in accordance with the ISCM Strategy
• Maintaining Information Assurance Vulnerability Alert (IAVA), Information Assurance Vulnerability Bulletin (IAVB), and Communications Task Ordering (CTO) compliance and reporting (reference (n)).
• Managing risk
2.2.6 Information Owner (IO)
The IO represents the end users of the system in the intended operational environment. As such, the IO has overall ownership of the information transmitted, processed, and stored by the system.
The IO has the following cybersecurity responsibilities:
• Performing all required and approved IO RMF process steps, as provided in Section 4 of this guide
• Assisting the user representative with system security categorization
• Maintaining the security posture of the fielded system in accordance with the ISCM Strategy and instructions from the PM
2.2.7 User Representative (UR)
The UR represents the operational interests of the user community and is the stakeholder who formally defines and clarifies requirements to ensure the IS meets the user needs. In the USMC this responsibility is fulfilled by MCCDC. The UR must provide cybersecurity requirements to the PM so that the A&A record is accurate and the development effort can properly integrate cybersecurity into the system lifecycle. The UR identifies any security controls that could potentially interfere with mission execution.
The UR has the following cybersecurity responsibilities:
• Performing all required and approved UR RMF process steps, as provided in Section 4 of this guide
• Providing input to the security control selection process
UNCLASSIFIED 12
• Identifying the Defense-in-Depth Functional Implementation Architecture (DFIA) defense level at which the system resides
• Identifying the system security categorization
• Identifying the system’s Cybersecurity Safety (CYBERSAFE) grade
2.2.8 Information System Security Manager (ISSM)
The ISSM is responsible for the planning and execution of the cybersecurity requirements of DoD IT and for ensuring adherence to the USMC RMF process. The ISSM must be a government employee or uniformed service member. The ISSM supports a PM in delivering a Program of Record (POR) with cybersecurity integrated throughout the system development lifecycle and for implementing RMF within the program. Often the ISSM will delegate authorities during A&A to an ISSO or ISSE, but the ISSM retains overall responsibility.
The ISSM has the following cybersecurity responsibilities:
• Performing all required and approved ISSM RMF process steps, as provided in Section 4 of this guide
• Supporting implementation of the RMF for assigned programs, organizations, systems, or enclaves
• Maintaining and reporting system’s A&A status and issues
• Ensuring the SP is developed and maintained for assigned systems
• Supporting the PM for the continuous monitoring of assigned systems
• Performing annual security reviews, annual testing of security controls, and annual testing of the contingency plan to maintain FISMA compliance
• Managing POA&M entries and ensuring vulnerabilities are properly tracked and mitigated or remediated. Specific POA&M entries the ISSM will complete on the initial POA&M received from the SCV include POC, resources, scheduled completion date, and comments. Throughout the POA&M lifecycle, the ISSM will also update the status and comments.
• Assisting with identification of the security control baseline set and applicable overlays
• Managing cybersecurity testing
• Assessing the initial control set to ensure controls are properly documented for AO review
• Assembling the Security Authorization Package
• Registering the system in MCCAST
• Planning and performing cybersecurity testing to assess security controls and recording security control compliance status during sustainment
• Appointing RMF stakeholders as identified in Table 2-1.
UNCLASSIFIED 13
• Ensuring personnel filling the ISSO or ISSE roles meet the cybersecurity certification requirements.
2.2.9 Information System Security Officer (ISSO)
The ISSO, who is appointed by the ISSM, assists the ISSM in the planning and execution of the cybersecurity requirements of DoD IT and for ensuring adherence to the USMC RMF process.
Some ISSMs may appoint ISSOs to ensure the A&A activities are integrated into the project planning and executed as planned while the lead ISSM retains key decision-making authority.
2.2.10 Information System Security Engineer (ISSE)
The ISSE conducts information system security engineering activities on behalf of the ISSM to ensure cybersecurity is integrated into the IT during the acquisition lifecycle, to include post-deployment software support. The ISSE develops and maintains the cybersecurity architecture for the POR. If a project does not have an assigned ISSE, then the systems engineer for the program should function in the ISSE role.
The ISSE has the following cybersecurity responsibilities:
• Overseeing the development and maintenance of a system’s cybersecurity solutions
• Ensuring cybersecurity requirements are fully developed and integrated into system acquisition design and configuration
• Supporting identification of the system type (IS, IT product, IT service) and any special considerations including multi-service/agency, joint, cross domain, Personally Identifiable Information (PII), protected health information, tactical, space, etc., to support RMF Step 1 System Categorization
• Applying the security control baseline set and applicable overlays
• Assisting with development and update of the cybersecurity documentation
• Leading the security control implementation and testing efforts
• Assisting with risk assessments for the system
• Assisting with any security testing required as part of A&A or annual reviews
• Assisting in the mitigation and closure of open vulnerabilities
UNCLASSIFIED 14
3 AUTHORIZATION TYPES
As explained in DoDI 8510.01 (reference (a)), DoD IT varies greatly in size and complexity, from stand-alone hardware and applications to large computing environments and enclaves.
Figure 3-1, taken from DoDI 8510.01, shows the classification breakout of DoD IT:
Figure 3-1: DoD IT Classification Breakdown
Of the four categories of IT shown in Figure 3-1, the USMC AO does not classify any IT as PIT.
USMC IT requiring authorization under the RMF methodology will fall under one of five authorization types, which are described in Table 3-1. ECSD 018 (reference (m)) provides more detail about each of the authorization types. It is important to note MCSC SIAT SSE Division processes the following authorization types: Major Application, which results in an authorization decision; Application, which results in a Marine Corps Certified Application (MCCA); and on rare occasions, Site authorizations. USMC programs processing for an MCCA will not implement many of the RMF steps; for example, there will be no need to identify the DFIA defense level or do security categorization.
UNCLASSIFIED 15
Table 3-1: Authorization Types
Authorization Type Description Organizational Level of
Applicability Commercial Internet
Service Provider
(C-ISP)
The DoD considers commercial connections/networks as outsourced IT-based services, and these services must undergo assessment and authorization prior to use.
HQMC C4 Cybersecurity
Exercise Organizations routinely conduct exercises at garrison or deployed locations, and this activity involves ISs that either already reside at the location or are deployed to that location. The exercise authorization type is very similar to a site authorization in that the ISs involved in an exercise are controlled by a single management authority, but for only a specified period of time.
HQMC C4 Cybersecurity
Application An application is software fielded without hardware, but hosted on an IS. As such, it cannot be tested without having a representative IS in place. The goal of testing an application is to ensure it does not require modifications to its hosting system that could introduce additional risk to the MCEN. An application is assessed under the MCCA process. Refer to Appendix D for more about MCCA.
MCSC
Site A site equates to an enclave, base, post, or station, whether in garrison or deployed.
Site authorization is practical when different ISs are controlled by a single management authority within a well-defined physical location.
HQMC C4 Cybersecurity, MCSC
Major Application An IS often consists of common hardware, software, and firmware. For MCSC, the AO authorizes a baseline system. The subsequent ATO allows the system to be fielded at one or more locations. For MCSC, tactical enclaves fall under this authorization type.
MCSC
MCSC uses the authorization types, as described above, to authorize ISs and applications developed within the USMC acquisition realm. If another service has authorized a system, the USMC could leverage the lead service’s Security Authorization Package to complete a USMC assessment and authorization. The RMF calls this a leveraged authorization, and it follows the
UNCLASSIFIED 16
DoD reciprocity agreement to use other services’ system authorizations to the maximum extent possible.
Per the reciprocity section of DoDI 8510.01 (reference (a)), the USMC AO will evaluate the other component’s security assessment and artifacts to assess potential risk. The AO could decide to either accept the risk as is or have the USMC implement more stringent (or more lenient) mitigations before allowing the system to operate.
Refer to Appendix C for more specific details on the MCSC approach to reciprocity.
Note: This guide uses the terms “system” and “application.” The context of these terms follows the definitions from the DITPR-DON Policy Guidelines (reference (v)):
• A system is defined as any solution that requires a combination of two or more interacting, interdependent, and/or interoperable hardware, software, and/or firmware to satisfy a requirement or capability.
• An application is defined as any software application that uses an existing operating system software program to provide the user with a specific capability or function that is independent of other “applications.” If it is dependent on other applications it becomes a system.
UNCLASSIFIED 17
4 RMF PROCESS
This section provides an overview of the USMC process for the execution of the RMF assessment and authorization methodology. Figure 4-1 is the MCSC’s high-level process flow for the six RMF steps. Table 4-1 identifies the stakeholders who are responsible, accountable, supporting, consulting, or informed for the fundamental activities in each RMF step. The color scheme for each block in the process flow pictured in Figure 4-1 indicates the stakeholder who is responsible for executing the action for the associated process block, per the definition of “Responsible” in Table 4-1. The “Responsible” stakeholder is acting under the authority of the “Authority” stakeholder. Sometimes the “Responsible” and “Accountable” stakeholder are the same.
The sub-sections give a more detailed description of each of the six RMF steps, the actions for the step, artifacts or products associated with the RMF step, entry and exit criteria for the step, and data that must be populated within MCCAST.
The sub-tasks for each RMF step do not have to be completed sequentially as depicted in the RMF Process Flow diagram (Figure 4-1). Some sub-tasks may occur simultaneously. Nor will all activities for a sub-task necessarily be completed before the next sub-task is started. For example, a program may know only some stakeholders at program initiation and may have to wait for some stakeholder assignments, such as the SCV.
The term SCA refers to the SCA team and comprises the SCA and the SCA Analysts. Likewise, the term ISSM includes ISSO and ISSE, whereby the ISSM could delegate action to the ISSO or ISSE in the execution of the sub-task. If the sub-task is specific to the ISSO or ISSE, then that position will be specifically cited. Finally, the term PM refers to the program manager and anyone on his or her staff designated to fulfill program-related duties.
UNCLASSIFIED 18
Figure 4-1: RMF Process Flow Diagram
UNCLASSIFIED 19
Table 4-1 identifies the RASCI personnel for the fundamental activities of RMF Steps 1-6, and is the legend for understanding the notations in the final column, RASCI, in Table 4-2. The last column in Table 4-2 uses the first letter from these RASCI definitions to identify the stakeholders’ level of participation in the RMF steps.
Note: The Responsible and Accountable stakeholders have the key roles in the RMF steps; the former for executing the task, the latter for final authority for the task. The stakeholders designated with the other RASCI definitions (i.e., Supportive, Consulted, or Informed) will either assist the Responsible stakeholder, as needed, or affect the sub-task’s completion. Readers should focus mainly on the Responsible and Accountable stakeholders for the sub-tasks.
Table 4-1: RASCI Definitions
Responsible Those who do the work to achieve the subtask. There is typically one role with a participation type of Responsible, although others can be delegated to assist in the work required (see Support).
Accountable The Approver or final Approving authority; those who are ultimately accountable for the correct and thorough completion of the deliverable or subtask, and the one to whom Responsible is accountable. In other words, an Accountable must sign off (Approve) on work that Responsible provides. There must be only one Accountable specified for each task or deliverable.
Supportive Resources allocated to Responsible. Unlike Consulted, who may provide input to the subtask, Support will assist in completing the subtask.
Consulted Those whose independent opinions and review are sought, and with whom there is two-way communication.
Informed People who are affected by the activity/decision and, therefore, need to be kept informed, but do not participate in performing the actual subtask. Position that needs to know of the decision or action.
UNCLASSIFIED 20
Table 4-2: RMF Steps Responsibility Assignment
Task Subtask Description RASCI
RMF Step 1:
Categorize
System
1.1 Assign qualified personnel
The PM identifies the RMF personnel for the system.
R - PM
A - AO
S - SCA
C - SCA
I - None identified
1.2 Create MCCAST record
The ISSM creates a new authorization package (record) in MCCAST.
R - ISSM
A - PM
S – ISSO/ISSE
C - SCA
I - SCV
1.3 Identify DFIA defense level (DL)
The UR identifies the defense level of the system using the DFIA model.
R - UR
A - UR
S - SCA, ISSM
C - IO
I - SCV
1.4 Categorize the system
The UR, with support from the SCA and ISSM, categorizes the system in accordance with
CNSSI 1253.
R - UR
A - UR
S - SCA, ISSM
C - IO
I - SCV
1.5 Identify CYBERSAFE grade
The UR determines the CYBERSAFE grade for the system. (The USMC implementation of the CYBERSAFE process is to be determined.)
R - UR
A - UR
S - SCA, ISSM
C - IO
I - SCV
UNCLASSIFIED 21
Task Subtask Description RASCI
RMF Step 2:
Select
Security Controls
2.1 Generate controls
The ISSM, with support of the ISSE, applies the DFIA defense level, system security categorization, and applicable overlays to generate the system’s security controls.
R - ISSM
A - PM
S - ISSE
C - SCA, SCV
I - None identified
2.2 Assess initial control set
The ISSM reviews the initial control set and ensures controls are suitably documented. Only controls that are deemed NC for implementation will require AO review/approval.
R - ISSM
A - PM
S - ISSE
C - SCA, SCV
I - None identified
2.3 Initiate ISCM Strategy
The PM develops the initial ISCM Strategy.
R - PM
A - PM
S - ISSM
C - SCA, SCV
I - None identified
2.4 Provide recommendation
The SCA reviews the initial control set, justification for NC controls, the SP, and the ISCM Strategy and provides a recommendation to the AO. The SCA will coordinate with the PM and ISSM to recommend changes prior to AO review.
(MCSC Gate 1)
R - SCA
A - SCA
S - ISSM, PM
C - SCV
I - AO
2.5 Approve?
The AO reviews control selection, SP and ISCM.
If AO approves, then the security assessment plan can be initiated. If AO does not approve, then ISSM will have to reassess initial control set.
(AO approval of the controls constitutes the initial risk assessment.)
R - AO
A - AO
S - None identified
C - SCA, PM, ISSM
I - SCV
2.6 Initiate SAP
Working with the ISSE and ISSM, the SCV develops a SAP to assess the resulting applicable security controls per the SP.
R - SCV
A - SCA
S - ISSE
C - ISSM
I - PM
UNCLASSIFIED 22
Task Subtask Description RASCI
RMF Step 3:
Implement
Security Controls
3.1 Implement controls
The PM, with the support of the ISSE, implements the security controls as approved in the SP.
R - PM
A - PM
S - ISSM, ISSE
C - SCA
I - SCV
3.2 Evaluate Security Authorization
Package
The SCA evaluates the Security Authorization Package, specifically the SP, SAP, and ISCM Strategy. The SCA can recommend changes to the PM and ISSM prior to self-assessment.
(MCSC Gate 2)
R - SCA
A - SCA
S - PM, ISSM
C - SCV
I - None identified
3.3 Conduct pre-assessment
The ISSE performs a pre-assessment of the security controls as part of the security engineering process to verify the required security controls are implemented. The ISSE initiates a risk assessment report for any findings that will not be fixed prior to formal assessment in Step 4.
R - ISSM
A - PM
S - ISSE, SCV
C - SCA
I - None identified
(Steps 3.4-3.6 are optional and only necessary if, during pre-assessment of the controls, the program believes it cannot comply with previously-approved controls and wants to seek early AO acceptance of risk so as to determine course of action.)
3.4 Seek AO acceptance of risk?
The program may decide to seek AO acceptance of risk for some pre-assessment findings. If so, then the SCA will provide a recommendation to the AO on the pre-assessment risk results. If the program does not seek AO acceptance of risk from the pre-assessment, then the program will request the SCV to conduct the formal security assessment.
R - PM
A - PM
S - ISSM, SCA
C - SCV
I - None identified
3.5 Provide recommendation
If the program is seeking AO acceptance of risk for pre-assessment findings, then the SCA provides a recommendation.
R - SCA
A - SCA
S - ISSM
C - SCV
I - AO
3.6 Approve?
The AO accepts or rejects the pre-assessment risk for any issues that cannot be resolved prior to operations. If the AO accepts, then the program proceeds to Step 4, Assess. If the AO rejects, then the program must address the AO’s risk concerns.
R - AO
A - AO
S - SCA
C - ISSM
I - SCV
UNCLASSIFIED 23
Task Subtask Description RASCI
RMF Step 4:
Assess
Security Controls
4.1 Conduct security assessment
The SCV performs the official security assessment using the SAP, which the SCV updates prior to assessment.
R - SCV
A - SCA
S - PM, ISSM
C - None identified I - None identified
4.2 Create SAR
The SCV initiates the SAR based on the results of the assessment and provides it to the PM and ISSM. The SCV will need support from the ISSM and ISSE to complete the risk assessment for open findings.
R - SCV
A - SCA
S - ISSM
C - None identified I - None identified
4.3 Update POA&M
The ISSM updates the POA&M with support from the SCV and ISSE based on the assessed open vulnerabilities in the SAR.
R - ISSM
A - PM
S - SCV, ISSE
C - None identified I - None identified
4.4 Update MCCAST record
The ISSM updates the Security Authorization Package in MCCAST to ensure it is ready for submission.
R - ISSM
A - PM
S - SCV, ISSE
C - None identified I - None identified
4.5 Submit package?
The ISSM, with concurrence from the PM, submits the Security Authorization Package -including applicable artifacts - to the SCA for review and recommendation.
R - ISSM
A - PM
S - ISSE
C - None identified
I - SCA
UNCLASSIFIED 24
Task Subtask Description RASCI
RMF Step 5:
Authorize
System
5.1 Provide recommendation
The SCA, after reviewing the SP and SAR, completes the risk assessment for the SAR. The SCA may recommend changes to the Security Authorization Package, to include the RAR, prior to completing the risk assessment and submitting the package to the AO.
(MCSC Gate 3)
R - SCA
A - SCA
S - SCV, ISSM
C - None Identified
I - AO
5.2 Authorization decision?
The AO reviews the Security Authorization…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .