Risk Management Framework (RMF): The Future of DoD Cyber Security is Here

Transcription

1 Risk Management Framework (RMF): The Future of DoD Cyber Security is Here Authors: Rebecca Onuskanich William Peterson 3300 N Fairfax Drive, Suite 308 Arlington, VA Phone: Fax:

2 In 2008, the Intelligence Community (IC) CIO, the Department of Defense (DoD) CIO, the Committee on National Security Systems (CNSS), and the National Institute of Standards and Technology (NIST) formed the Joint Task Force (JTF) Transformation Initiative Interagency Working Group. This interagency working group s effort is to produce a holistic, common process for security risk management, as documented in NIST Special Publications (SP) designated as JTF Transformation Initiative documents. The initial transformation plan laid out seven goals: 1. Define a common set of trust (impact) levels and adopt and apply them across the IC and DoD. Organizations will no longer use different levels with different names based on unlike criteria. (CNSSI-1253: Security Categorization and Control Selection for National Security Systems, dated October 2009 via DoDI ) 2. Adopt reciprocity as the norm, enabling organizations to accept the approvals by others without retesting or reviewing. (NIST SP , Revision 1: Guide for Applying the Risk Management Framework to Federal Information Systems via DoDI ) 3. Define, document, and adopt common security controls, using NIST Special Publication (SP) as a baseline. (NIST SP , Revision 3: Recommended Security Controls for Federal Information Systems and Organizations via DoDI ) 4. Adopt a common lexicon, using CNSS Instruction 4009 as a baseline; thereby providing DoD and IC a common language understanding. (CNSSI National Information Assurance Glossary) 5. Institute a Senior Risk Executive Function (REF), which bases decisions on an enterprise view of risk considering all factors, including mission, Information Technology (IT), budget, and security. (NIST SP , Rev 1 via DoDI ) 6. Incorporate information assurance (IA) into Enterprise Architectures and deliver IA as common enterprise services across the IC and DoD. (NIST SP , Rev 1 via DoDI and DoDI ) 7. Enable a common process that incorporates security within the lifecycle processes and eliminate security-specific processes. The common process will be adaptable to various development environments. (NIST SP , Rev 1 via DoDI and DoDI ) The DoD CIO developed control level mapping between NIST SP and DoDI in collaboration with Department of the Navy (DON) CIO and posted to the DoD Information Assurance Certification and Accreditation Process (DIACAP) Knowledge Risk Management Framework: The Future of DoD Cyber Security is Here 1

3 Service for review and feedback. The mapping intended to inform the community on the relationships between the DoDI and NIST SP security controls not become directive in nature. This was intended as an evolving product and the community has been encouraged to provide input and comment on the mapping. The goal of the transition in the DoD is that there will be no hard-right turns. IA is already embedded throughout DoD s acquisition and capabilities development lifecycles with the current DIACAP process. The NIST SP , Risk Management Framework (RMF), aligns closely with the DIACAP process and the RMF will be implemented via the DIACAP Knowledge Service and DoDD/I updates. The main concern for the DoD will be the use of NIST SP Rev 4 for the security controls and the changes in terminology. The DoD will be reissued as an instruction and incorporate DoDI IA Implementation. It changes the name from Information Assurance to Cybersecurity, a standard throughout the community. The updated policy will also provide the following: Extend applicability to all IT processing DoD information; Emphasize operational resilience, integration and interoperability; Align with Joint transformation Transitions to NIST SP Control Catalog; Adopt a common lexicon; Provide more leverage of federal policies and standards; Adopt reciprocity as the norm; Incorporate security early and continuously within the acquisition lifecycle; Emphasize continuous monitoring and timely correction of deficiencies; and Facilitate multinational information sharing efforts DIACAP will be renamed to the Risk Management Framework for DoD Information Technology and align with the Joint Transformation goals. It provides clarity on which IT systems, devices, applications, etc. should undergo the RMF process, how it should be implemented, and codifies reciprocity, a theme throughout the transition and the RMF. The DoD will implement CNSSI 1253 Security Categorization and Control Selection for National Security Systems and NIST SP Recommended Security Controls for Federal Information Systems and Organizations. In addition, there will be a Risk Management Framework: The Future of DoD Cyber Security is Here 2

4 sunsetting of DoDI controls and a transition to NIST SP controls. System categorization will shift from the use of a Mission Assurance Category (MAC) and Confidentiality Level (CL) to the utilization of the CNSSI NIST SP A, Guide for Assessing the Security Controls in Federal Information Systems: Building Effective Assessment Plans will be the guide for assessing the controls, taking the place of the validation spreadsheet. It will not however, replace the Security Technical Implementation Guides (STIGs), but provide support for the security requirements. The documentation that the DoD will be leveraging to support the process include the following: NIST Special Publications (SP) Joint Task Force (JTF) Initiative documents NIST SP , Security and Privacy Controls for Federal Information Systems and Organizations NIST SP A, Guide for Assessing the Security Controls in Federal Information Systems and Organizations, Building Effective Security Assessment Plans NIST SP , Guide for Applying the Risk Management Framework to Federal Information Systems NIST SP , Managing Information Security Risk: Organization, Mission, and Information System View NIST SP , Guide for Conducting Risk Assessments CNSSI 1253, Security Categorization and Control Selection for National Security Systems The RMF process is composed of six Steps: Step 1 Categorize Information System Step 2 Select Security Controls Step 3 Implement Security Controls Step 4 Assess Security Controls Step 5 Authorize Information System Step 6 Monitor Security Controls Risk Management Framework: The Future of DoD Cyber Security is Here 3

5 The output of the RMF process includes current security authorization artifacts (submitted as part of the Security Authorization Package) for the Information System (IS) that the Authorizing Official (AO) will use to determine whether deployment of the IS presents, or continues to present, an acceptable level of risk to organizational operations, organizational assets, individuals, other organizations, and the Nation. Security artifacts include, but are not limited to: System Security Plan (SSP), Risk Assessment Report (RAR), Information Security Continuous Monitoring (ISCM) Plan, Security Assessment Report (SAR), and Plan of Action and Milestones (POA&M). The transition for the DoD can be almost seamless to the organizations if they properly train their personnel and prepare for the changes. Organizations must understand that there will be a period of time in which they must manage accreditation packages under both DIACAP and the RMF, to include differences in security controls and documentation. The ultimate goal would be not to focus so much on the differences in Risk Management Framework: The Future of DoD Cyber Security is Here 4

6 the process and packages, but understanding that they both are emphasizing risk management. Each organization will need to develop a transition plan that works for them effectively and efficiently. The last thing that needs to happen is significant delays in the approval process due to a change in the accreditation process. There are already significant issues in many DoD organizations with systems getting through the accreditation process in an acceptable period of time. I personally have worked on accreditations for systems that have taken over three years. By the time the approval to operate (ATO) was signed, a newer version of the operating system had already been migrated in the DoD, which obviously caused significant issues and additional delays. DoD Instructions and Agency Regulations provide the minimal requirements and guidelines for DoD specific implementation of security, STIGs are provided as a guideline to developing a baseline security for a system, and NIST Special Publications are written to provide a framework and minimal recommendation for security for systems and organizations. The authorization process is a unique balance of security, operations and budget. The cost of security should not be more than the value of the system or the data it stores, transmits and processes. Organizations need to understand that the AO is the only person that can accept risk. This means that they are not to halt packages from moving through the approval process due to open vulnerabilities alone. Paragraph of DODI states Severity categories are expressed as category (CAT) I, CAT II, and CAT III. Severity categories are assigned after considering all possible mitigation measures that have been implemented within system design and architecture limitations for the DoD IS in question. For instance, what may be a CAT I weakness in a component part of a system (e.g., a workstation or server) may be offset or mitigated by other protections within hosting enclaves so that the overall risk to the system is reduced to a CAT II. On multiple occasions, we have been told by DoD IA personnel that a DoD site s security posture (firewalls, IDS, IPS, ect) cannot be considered as a mitigation for a vendor s application or system that will reside within the DOD site s enclave. This begs the question: Has the site implemented multilevel security architecture as required by DoD regulation or is the IA staff neither properly trained nor experienced enough to understand the site s security implementation or are they merely unfamiliar with the directives and instructions inherent to their position? In order to effectively transition to the RMF, we must train our personnel. There are currently not enough security engineers to fill the available positions in the DoD and therefore, personnel are filling the roles of Information Assurance Manager, Validator, Certifier, and Security Engineer who do not have the knowledge and experience. This is causing significant issues in the process. I have attended validation testing for my system and the security engineer conducting the validation testing could not get the vulnerability assessment tool to run and did not know what many of the manual checks in the STIGs were asking them to validate. My team eventually ran the scans while the Risk Management Framework: The Future of DoD Cyber Security is Here 5

7 validator watched. This is not risk management or vulnerability assessment, but a complete waste of time for six people since we provided the exact tests and reports the week before, along with all supporting evidence for False Positives and items needing to be annotated as an acceptable risk mitigated by defense in depth strategies. Another key issue that the RMF emphasizes is Reciprocity. While DIACAP Reciprocity was directed in July of 2009, and I am sure there may be some implementation of reciprocity somewhere in the DOD I have yet to see any organization implement an instance of reciprocity. While all DAA s have their own pain threshold for risk acceptance, I do not believe the vast majority of DAA s and IAM s have the training or experience to understand, let alone implement reciprocity. This lack of implementation causes all parties (DOD and vendors supporting the DOD) an excessive loss of manhours due to duplication of efforts. Currently the Reciprocity Memorandum is a paper tiger, without teeth. A mandate without enforcement is useless. The RMF also assists with the approval and use of Commercial Cloud Service Providers (CSPs). The Federal Risk and Authorization Management Program (FedRAMP) Joint Authorization Board (JAB) provides a streamlined avenue for federal agencies to utilize the CSPs as a way to store, transmit and process federal information and potentially save significant costs. CSPs can receive a Provisional Authorization after undergoing a third-party interdependent security assessment by an accredited Third-Party Assessment Organizations (3PAO), such as Lunarline. The benefit to the DoD here is that the FedRAMP process is governed by the JAB who have representatives from the Department of Homeland Security (DHS), the General Services Administration (GSA), and the Department of Defense (DoD). It has been agreed upon that the JAB can issue Provisional Authorizations for CSP s identified as Mission Assurance Category (MAC) II, Sensitive by the DoD. This again is another way in which the entire transformation is helping to speed up the process and reduce costs by leveraging reciprocity. It is my hope that as an organization, the DoD can work to get qualified individuals in the cyber security positions and work to appropriately train those already filling the positions. As well, the transition to the RMF will require planning, coordination and education to all personnel involved in the process. The most advantageous piece of this transition is that federal agencies have been following this process for years and there is an enormous amount of people who can provide guidance, lessons learned and recommendations for the transition. There is no reason to go at this alone and try to recreate the process to make a name for ourselves. The process is thoroughly documented, the templates are in place and proven, and the training is widely available. Let s leverage it this time. For detailed information on the DoD s interpretation of the RMF please see the previously documented White Paper. rmf%20-%20lunarline%20white%20paper_dec%2011.pdf Risk Management Framework: The Future of DoD Cyber Security is Here 6