Out with the DIACA AP, In with the DIARMF Say Goodbye to Certificatio n and Accreditation (C&A) and Hello to the Risk Management Framework (RMF) Author: Rebecca Onuskanich Program Manager, Lunarline LUNARLINE, INC.. 3300 N. FAIRFAX DR., SUITE 308 ARLIGTON, VA 22201 571-481-9300 December 12, 2011 0
Out with the DIACAP, In with the DIARMF Say Goodbye to Certification and Accreditation (C&A) and Hello to the Risk Management Framework (RMF) Table of Contents INTRODUCTION... 3 THE PRINCIPLES OF SYSTEM AUTHORIZATION... 4 WHAT IS ASSESSMENT & AUTHORIZATION (A&A)?... 4 WHY CONDUCT A&A?... 4 WHAT IS THE RMF?... 4 WHY TRANSITION? AND WHY NOW?... 5 DOD PUBLICATIONS... 5 ROLES IN THE A&A PROCESS... 6 HEAD OF AGENCY OR CHIEF EXECUTIVE OFFICER (CEO)... 6 RISK EXECUTIVE (FUNCTION) (REF)... 6 CHIEF INFORMATION OFFICER (CIO)... 7 INFORMATION OWNER/STEWARD... 7 SENIOR AGENCY INFORMATION SECURITY OFFICER (SAISO)... 7 AUTHORIZING OFFICIAL (AO)... 7 AUTHORIZING OFFICIAL DESIGNATED REPRESENTATIVE... 7 COMMON CONTROL PROVIDER... 7 INFORMATION SYSTEM OWNER... 8 INFORMATION SYSTEM SECURITY MANAGER (ISSM)... 8 INFORMATION SYSTEM SECURITY OFFICER (ISSO)... 8 INFORMATION SECURITY ARCHITECT (ISA)... 8 INFORMATION SYSTEM SECURITY ENGINEER (ISSE)... 8 SECURITY CONTROL ASSESSOR (SCA)... 8 RISK MANAGEMENT FRAMEWORK (RMF) STEPS... 9 STEP 1: CATEGORIZE THE INFORMATION SYSTEM... 9 INITIATE THE SYSTEM SECURITY PLAN... 9 IDENTIFY THE IS A&A TEAM... 10 STEP 2: SELECT THE IA CONTROLS... 10 STEP 3: IMPLEMENT ASSIGNED IA CONTROLS... 11 STEP 4: ASSESS IA CONTROLS... 11 CONDUCT ASSESSMENT ACTIVITIES... 11 RECORD COMPLIANCE STATUS... 11 PREPARE AN IT SECURITY POA&M... 12 PREPARE SECURITY ASSESSMENT REPORT (SAR)... 12 STEP 5: AUTHORIZE THE IS... 12 1
AUTHORIZATION CONSIDERATIONS FOR SPECIAL IS CONFIGURATIONS... 13 AUTHORIZATION DECISIONS... 14 STEP 6: MONITOR THE IA CONTROLS... 16 MAINTAIN SITUATIONAL AWARENESS (ALSO KNOWN AS INFORMATION SECURITY CONTINUOUS MONITORING)... 16 MAINTAIN IA POSTURE... 17 PERFORM REVIEWS... 17 INITIATE REAUTHORIZATION... 17 DECOMMISSION... 17 DIARMF A&A DOCUMENTATION... 17 SIP... 18 A&A SCORECARD... 18 IT PLAN OF ACTION & MILESTONES (POA&M)... 18 SUMMARY... 19 REFERENCES... 20 GLOSSARY AND ACRONYMS... 21 2
Introduction Certification and Accreditation (C&A) has long since been thought of as the long-pole in the tent 1 and a purely document-focused process when it comes to Department of Defense Information Technology (IT) projects. The process has been accused of delaying project deployment anywhere from 6-12 months on average without bringing additional security value or enhancing standardization across Federal agencies. In 2007, the National Institute of Standards and Technology (NIST), the Intelligence Community (IC), the Department of Defense (DoD), academia, and commercial industry collaborated to initiate a transformation of C&A to a more standardized, streamlined and effective process. This process, now captured in NIST Special Publication (SP) 800-37 2, has been adopted by all Federal agencies. DOD has begun its initial steps towards initiating the transition from the current C&A process defined in the DoD Information Assurance C&A Process (DIACAP) to the streamlined and effective NIST processes. This process, known as the Risk Management Framework (RMF), will be titled the Department of Defense Information Assurance Risk Management Framework (DIARMF) by the DoD as it implements the transition. Source: DIACAP Knowledge Service The transition to the RMF includes the adoption of a new lexicon. One of the most immediate changes is the replacement of the term C&A with Assessment & Authorization (A&A) 3. The Designated Accrediting/Approving Authority (DAA) will assume the title of Authorizing Official (AO). Other changes in terminology will be introduced throughout the white paper. 1 Normally used as an expression to label what is the hardest or most challenging obstacle in a list of obstacles that needs to be overcome or considered. Read more: http://wiki.answers.com/q/what_is_the_long_pole_in_the_tent#ixzz1glo8thwe 2 NIST SP 800 37, Guide to Applying the Risk Management Framework to Federal Information Systems. 3 For the sake of consistency, the term A&A will be used throughout this document instead of C&A. 3
The Principles of System Authorization What is Assessment & Authorization (A&A)? A&A (formerly C&A) is the process of comprehensively evaluating technical and non-technical features of an information system in the intended environment so that an Authorizing Official (AO), formally referred to as the Designated Approving Authority (DAA), can determine whether or not the system is approved to operate at an acceptable level of security risk based on the implementation of an approved set of technical, managerial, and procedural countermeasures or mitigations. During A&A activities, the security profile of a system is represented as a snapshot in time: it does not provide real time and ongoing security risk insight without the incorporation of a continuous monitoring process. Why Conduct A&A? A&A is a critical part of the System Development Life Cycle (SDLC) and is performed because threats to and vulnerabilities in information systems can negatively affect people s lives and/or the ability to perform military or business missions. It assists organizations in ensuring that security is not an afterthought, but that it is baked in to the system development and deployment process. A&A can also be an effective risk management tool that addresses threats, vulnerabilities and exposures of information and information systems. Threats are active agents that attempt, maliciously or unintentionally, to do harm to information, an information system, and its users. Vulnerabilities are weaknesses in a system that can be exploited by a threat agent to allow harm to the information, the system, and its users. The combination of threats and vulnerabilities creates risk. The reality is that threats and vulnerabilities are always present; therefore, some element of risk always exists. Any entity with system access, with authorization or not, can pose a potential threat to a system; however, a system that has no vulnerabilities may be so limited in functionality that it cannot do useful work. It is prudent to cost-effectively mitigate risk to protect lives and missions. All risks cannot be mitigated or eliminated. Any risk that cannot be mitigated or eliminated costeffectively is referred to as residual risk and must be assessed as part of the decision process before authorizing a system for operation. In addition to the above reasons for executing A&A, there is also the compliance dimension. The Federal Information Security Management Act (FISMA), Title III of the E-Government Act (Public Law 107-347) dated December 2002, requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source. System authorization is considered one of the mandatory reporting elements of a Federal information security program. What is the RMF? The Risk Management Framework (RMF) is the common information security framework for federal government and its information and information systems. The stated goals of the RMF are: To improve information security To strengthen the risk management processes 4
To encourage reciprocity among federal agencies Through implementation of RMF, federal agencies can support compliance with policy directives such as the Federal Information Security Management Act (FISMA) and Office of Management and Budget (OMB) Circular A-130. The RMF effectively transforms traditional C&A into A&A by introducing a six-step system life cycle process consisting of: 1. Categorization of information systems 2. Selection of security controls 3. Implementation of security controls 4. Assessment of security controls 5. Authorization of information systems 6. Monitoring of security controls These steps will be addressed in additional detail later in this paper. Why Transition? And Why Now? Currently, the DoD utilizes DoDI 8510.01, DoD Information Assurance Certification and Accreditation Process (DIACAP), as the process for implementing C&A within an information system. The Information Assurance (IA) Controls, or security measures that must be in place on a system, are outlined in the DoDI 8500.2, Information Assurance (IA) Implementation. The control selection is based on the Mission Assurance Category (MAC) 4 and Confidentiality Level (CL). There are significant differences between the existing DIACAP process and the RMF, which has been adopted by all of the other Federal agencies, to include the Intelligence Community (IC) except the DoD. 5 Consequently, one of the primary reasons for the transition to A&A and the RMF is to enable reciprocity between Federal agencies, including the DoD. It gives Federal agencies common processes, security controls, testing activities and outcomes, as well as a common lexicon among organizations. Moving to a common process will also reduce costs related to the activities associated with system authorization. A great example would be a medical system that has been purchased by the DoD for their Military Treatment Facilities (MTF), as well as by the Veterans Administration (VA) for use in their hospitals. Under the current situation, this new system would be required to undergo two separate processes: a C&A utilizing DIACAP for the DoD and a system authorization based on NIST for the VA hospitals. The cost for purchasing and deploying that system has now significantly increased as a consequence of the requirement for distinctly separate processes. If all Federal information systems were authorized under the NIST 800-37 Rev 1 process, reciprocity could be facilitated and the information system might not need to be authorized separately by each agency or organization. DoD Publications 4 MAC combines availability and integrity as part of the process for determining the protection requirements for a DoD information system under the current DIACAP.
As part of the transition, DoD will align the DoD 8500 series with the NIST transformation-related issuances. 1. DoD Instruction (DoDI) 8500.2 will implement CNSSI 1253 Security Categorization and Control Selection for National Security Systems and NIST SP 800-53 Recommended Security Controls for Federal Information Systems and Organizations. This regulation will describe the: a. Sunsetting of DoDI 8500.2 controls b. Transition to NIST SP 800-53 controls c. System categorization and security control selection per CNSSI 1253 2. DoDI 8510.01 (DIACAP) will be DoD s implementation of the common process under the Risk Management Framework (RMF) (NIST SP 800-37). The DIACAP already implements a similar process Source: DIACAP Knowledge Service through a senior risk management framework (PAAs and DISN GIG Flag Panel) a. DIACAP is already largely aligned with the Risk Management Framework b. Some minor fine tuning (will include a name change) 3. The DIACAP Knowledge Service (KS) will continue to be the DoD authoritative source for security controls and validation procedures. This will include a. DoD security control baselines containing controls selected from the NIST SP 800-53 catalog of security controls b. DoD-specific security control implementation procedures c. Catalog of NIST SP 800-53A validation procedures tailored for DoD Roles in the A&A Process Before we jump into a discussion of the steps of the process, it s important to understand who plays a role and what are their responsibilities. As part of the transition, DoD will be adopting much of the same taxonomy as other Federal Agencies. Let s take a look at some of these as they are defined in NIST SP 800-37, including where the roles and lexicon might differ from the current DIACAP roles and responsibilities. Head of Agency or Chief Executive Officer (CEO) The highest-level senior official or executive within an organization with the overall responsibility to provide information security protections commensurate with the risk and magnitude of harm (i.e., impact) to organizational operations and assets, individuals, other organizations, and the Nation resulting from unauthorized access, use, disclosure, disruption, modification, or destruction of information and information systems. Risk Executive (Function) (REF) An individual or group within an organization that helps to ensure that risk-related considerations for individual information systems, to include authorization decisions, are viewed from an organization- 6
wide perspective with regard to the overall strategic goals and objectives of the organization in carrying out its core missions and business functions. This function does not currently exist in the DIACAP. In the new draft regulations, DoD has defined that this function will be executed by the Principal Authorizing Officials 5 (PAOs) for the DoD Mission Areas (MAs) and the Defense Information System Network (DISN)/Global Information Grid (GIG) Flag Panel. Chief Information Officer (CIO) Agency official responsible for: (i) Providing advice and other assistance to the head of the executive agency and other senior management personnel of the agency to ensure that information technology is acquired and information resources are managed in a manner that is consistent with laws, Executive Orders, directives, policies, regulations, and priorities established by the head of the agency; (ii) Developing, maintaining, and facilitating the implementation of a sound and integrated information technology architecture for the agency; and (iii) Promoting the effective and efficient design and operation of all major information resources management processes for the agency, including improvements to work processes of the agency. 6 Information Owner/Steward Organizational official with statutory, management, or operational authority for specified information and the responsibility for establishing the policies and procedures governing its generation, collection, processing, dissemination, and disposal. This role does not currently exist under the DIACAP, but will be included in the new DoD regulations. Senior Agency Information Security Officer (SAISO) Official responsible for carrying out the CIO responsibilities under FISMA and serving as the CIO s primary liaison to the agency s authorizing officials, information system owners, and information system security officers. 7 7 Authorizing Official (AO) Senior official or executive with the authority to formally assume responsibility for operating an information system at an acceptable level of risk to organizational operations and assets, individuals, other organizations, and the Nation. DoD will be using this designation to replace the current designation of Designated Accrediting/Authorizing Official (DAA). Authorizing Official Designated Representative An organizational official that acts on behalf of an authorizing official to coordinate and conduct the required day-to-day activities associated with the security authorization process. This role does not currently exist under the DIACAP, but will be included in the new DoD regulations. Common Control Provider 5 Principal Authorizing Official (PAO) replaces the term Principal Accrediting Authority (PAA). 6 Note: Organizations subordinate to federal agencies may use the term Chief Information Officer to denote individuals filling positions with similar security responsibilities to agency-level Chief Information Officers. 7 Note: Organizations subordinate to federal agencies may use the term Senior Information Security Officer (SISO) or Chief Information Security Officer (CISO) to denote individuals filling positions with similar responsibilities to Senior Agency Information Security Officers. DoD entities may use the term Senior Information Assurance Officer (SIAO).
An individual, group, or organization responsible for the development, implementation, assessment, and monitoring of common controls (i.e., security controls inherited by information systems). This role does not currently exist under the DIACAP, but will be included in the new DoD regulations. Information System Owner An organizational official responsible for the procurement, development, integration, modification, operation, maintenance, and disposal of an information system. This role is similar to the one currently executed by the program or system manager (PM/SM) in DoD. Information System Security Manager (ISSM) Individual responsible for developing and maintaining an organization or DoD IS-level IA program that identifies IA architecture, requirements, objectives and policies; IA personnel, and IA processes and procedures. DoD will be using this designation to replace the current designation of Information Assurance Manager (IAM). Information System Security Officer (ISSO) An individual responsible for ensuring that the appropriate operational security posture is maintained for an information system and as such, works in close collaboration with the information system owner. The information system security officer also serves as a principal advisor on all matters, technical and otherwise, involving the security of an information system. This role corresponds to the Information Assurance Officer (IAO) currently in the DIACAP; the taxonomy will be made consistent in the new DoD regulations. Information Security Architect (ISA) An individual, group, or organization responsible for ensuring that the information security requirements necessary to protect the organization s core missions and business processes are adequately addressed in all aspects of enterprise architecture including reference models, segment and solution architectures, and the resulting information systems supporting those missions and business processes. This role does not currently exist under the DIACAP, but will be included in the new DoD regulations. Information System Security Engineer (ISSE) An individual, group, or organization responsible for conducting information system security engineering activities. This role does not currently exist under the DIACAP, but will be included in the new DoD regulations together with specific certification requirements that are identified in DOD 8570-M, Information Assurance Workforce Improvement Program. Security Control Assessor (SCA) An individual, group, or organization responsible for conducting a comprehensive assessment of the management, operational, and technical security controls employed within or inherited by an information system to determine the overall effectiveness of the controls (i.e., the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system). This role corresponds to the Certifying Authority (CA) in the DIACAP. 8
Risk Managem ent Framework (RMF) Steps The RMF uses a six (6)-step process in which the ultimatee goal is to minimize risk to an acceptable level. The RMF is defined in NIST SP 800-37 Guide for Applying the Risk Management Framework to Federal Informationn Systems, which provides a disciplined and structured process that integrates information security and risk management activities into the system development life cycle (SDLC). Step 1: Categorize the Information System DoD will follow the security categorization process defined in CNSSI 1253 for alll DoD information systems (IS). The categorization process identifies the potential impact (low, moderate, or high) resulting from loss of confidentiality, integrity, and availability forr the information processed, transmitted, or stored by the IS should a security breach occur. During and subsequent to the transition, the DIARMF Knowledge System (KS) will provide the detailed procedures on system categorization. This step also includes registering the system with the governing DoD Component IA program, identifying the A&A Team for the IS, and initiatingg the IS s System Security Plan. Initiate the System Security Plan Step 1 includes the initial preparation of the System Security Plan (SSP). Within the DoD, a System Security Plan consists of a Controls Implementation Plann (ConIP) (formerly known as the DIACAP Implementation Plan or DIP) and a Systems Identification Profile (SIP). Then, initiate the ConIP by documenting the results of the IS categorization. In a future step, the ConIP will be populated with the IS s assigned IA controls, including inherited IA controls, based on the categorization results. DoDI 8500.02 and the DIARMF KS will provide the ConIP templatee and detailed procedures for completion. 9
Next, initiate the SIP by completing the system identification elements of the profile and register the System with the DoD IA Program. The SIP template and instructions will be made available in the DIARMF KS. Identify the IS A&A Team The members of the IS A&A Team are required to meet the trustworthiness investigative levels for users with IA management access to DoD unclassified ISs. Document the team assignments in the SIP. Step 2: Select the IA 8 Controls IA controls are the management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an IS or platform IT system to protect the confidentiality, integrity, and availability of the system and its information (Reference (r)). Security controls are expressed in a specified format (i.e., a control number, a control name, control text, enhancement text, and a control. The IA controls currently used by the Department of Defense are included in the NIST SP 800-53 Rev 3 security control catalog with supporting validation procedures in NIST SP 800-53A Rev 1. DoD-specific implementation guidance and validation procedures will be developed and available in the DIACAP Knowledge Service at https://diacap.isportal.navy.mil. In this step, the applicable IA controls for an information system are determined based on the IS categorization. This step includes: 1. Choosing the initial security control baseline from CNSSI 1253 based on the information system categorization. 2. Identifying any overlays that apply to the information system or its environment of operation. Overlays modify the initial security control baseline to address the unique security protection needs associated with specific types of information or operational scenarios. Overlays reduce the need for ad hoc/case-by-case tailoring by allowing communities of interest to develop standardized overlays that address their unique needs and scenarios. Examples of overlays include those that accommodate tactical environments or instances where Personally Identifiable Information (PII), Health Information Portability and Accountability Act (HIPAA) requirements, cross domain requirements, or classified information are present. Guidance regarding how to determine which overlays, if any, apply is included in the DIACAP Knowledge Service. 3. After selecting the initial security control baseline and overlays, the information owner/steward and information system owner initiates the tailoring process to appropriately modify and more closely align the controls with the conditions specific to the information system or its environment of operation. The tailoring process may include applying scoping guidance to the initial set of security controls, selecting or specifying compensating controls to adjust the initial set of security controls to obtain an equivalent set deemed to be more feasible to implement, or specifying organization-defined parameters in the security controls via explicit assignment and selection statements to complete the definition of the tailored profile. 8 NOTE: In the NIST SP 800-37 RMF, this step is called Select Security Controls. DoD intends to retain the use of the term information assurance. 10
4. The tailored profile is supplemented based on the organization s assessment of risk. In some cases, additional security controls or control enhancements may be needed to address unique threats or vulnerabilities in a particular information system. 5. The resulting set of security controls along with the supporting rationale for selection decisions and any information system use restrictions are documented in the security plan for the information system (i.e., the DIACAP Implementation Plan). Additional guidance in included on the DIACAP Knowledge Service. 6. Common controls are security controls that are developed, assessed, and maintained by one organization and inherited by other DoD information systems. Document the selected controls in the ConIP. Step 3: Implement Assigned IA Controls In this step, security controls are implemented consistent with DoD and Component IA architecture, employing system and software engineering methodologies, security engineering principles, and secure coding techniques. PMs/SMs shall ensure early involvement by information system (IS) security engineers to translate IA control requirements into the system specifications, and ensure the successful integration of those capabilities into the IS. In many cases security control requirements may be satisfied through inheritance, whereby a hosting enclave provides a control solution as a service to hosted ISs (e.g. physical security). In addition, mandatory configuration settings are established and implemented on information technology products in accordance with federal and DoD policies. The evolving status of IA control implementation is maintained in the ConIP. Step 4: Assess IA Controls This step includes conducting assessment activities, preparing the IT Security Plan of Action and Milestones (POA&M), and compiling the assessment results in the IS A&A Scorecard 9. Conduct Assessment Activities NIST SP 800-53A Rev1 is the source for control assessment procedures, which will be tailored for DoD use, maintained through the DIARMF Chance Control Process and published in the DIARMF KS. Each assessment procedure will contain descriptions of the requisite preparatory steps and conditions, actual assessment steps, expected results, and criteria and protocols for recording actual results. Each procedure includes associated supporting background material, sample results, or links to automated testing tools. Actual results are recorded according to the criteria and protocols specified in the assessment procedure and are made a permanent part of the comprehensive IS A&A documentation package, along with any artifacts produced during the assessment (e.g., output from automated test tools or screen shots that depict aspects of system configuration). For inherited IA controls, assessment test results and supporting documentation are maintained by the originating IS and are made available to SCAs of receiving ISs on request. Record Compliance Status The status of each assigned IA control is indicated on the IS A&A Scorecard. An example of a Scorecard and discussion of its fields are provided in the DIARMF KS. 9 NOTE: NIST does not include a Scorecard as part of its processes. This will remain unique to DoD. 11
Compliant (C) IA controls are those for which the expected results for all associated assessment procedures have been achieved. Non-compliant (NC) IA controls are those for which one or more of the expected results for all associated assessment procedures are not achieved. Not achieving expected results for all assessment procedures does not necessarily equate to unacceptable risk. Not applicable (NA) IA controls are those that do not impact the IA posture of the IS as determined by the AO. Prepare an IT Security POA&M An IT Security POA&M identifies tasks that need to be accomplished. It specifies resources required to accomplish the elements of the plan and milestones for completing tasks, along with their scheduled completion dates. IT Security POA&Ms are permanent records. Once posted, weaknesses will be updated, but not removed, after correction or mitigation actions are completed. Inherited weaknesses are reflected on the IT Security POA&Ms. IT Security POA&Ms may be active or inactive throughout a system s life cycle as weaknesses are newly identified or closed. The DoD Component CIOs are responsible for monitoring and tracking the overall execution of system-level IT Security POA&Ms until identified security weaknesses have been closed and the A&A documentation appropriately adjusted. The AOs are responsible for monitoring and tracking overall execution of system-level IT Security POA&Ms. The PM or SM is responsible for implementing the corrective actions identified in the IT Security POA&M and, with the support and assistance of the ISSM, provides visibility and status to the AO, the SIAO, and the governing DoD Component CIO. In order to reflect the complete IA posture of a DoD IS at all times in a single document, the IT Security POA&M is also used to document AO-accepted Non-Compliant (NC) IA controls and baseline IA controls that are Not Applicable (NA) because of the nature of the system. A full discussion and templates for preparing an IT Security POA&M are provided in the DIARMF KS. Prepare Security Assessment Report (SAR) The SCA prepares and issues an assessment report that documents the SCA s determination of the degree to which a system complies with assigned IA controls based on assessment results. It is based on the actual assessment results. It considers IA controls in a non-compliant status, associated severity categories, expected exposure time and cost to correct or mitigate IA security weaknesses. A SAR is always required before an authorization decision. If a compelling mission or business need requires the rapid introduction of a new DoD IS into the GIG, assessment activity and a SAR are still required. If the operation will be required beyond the time period of an IATO, a complete assessment should be initiated immediately. The weaknesses identified on the IT Security POA&M reflect residual risk to the system, and shall be incorporated into the SAR. Step 5: Authorize the IS The traditional authorization process is conducted by one Authorizing Official (AO), where a single official in a senior leadership position is both responsible and accountable for an information system. The official also accepts the information system-related security risks that may impact organizational operations and assets, individuals, other organizations, or the Nation. Joint authorization, is employed when multiple officials either from the same or different organizations, have a shared interest in authorizing an information system. The officials collectively are responsible and accountable for the information system and jointly accept the information 12
system-related security risks that may adversely impact organizational operations and assets, individuals, other organizations, and the Nation. A similar authorization process is followed as in the first approach with the essential difference being the addition of multiple authorizing officials. Organizations choosing a joint authorization approach are expected to work together on the planning and the execution of A&A tasks, and to document their agreement and progress in implementing the tasks. Collaborating on the security categorization, selection of IA controls, plan for assessing the controls to determine effectiveness, plan of action and milestones, and continuous monitoring strategy, is necessary for a successful joint authorization. The specific terms and conditions of the joint authorization are established by the participating parties in the joint authorization including for example, the process for ongoing determination and acceptance of risk. The joint authorization remains in effect only as long as there is mutual agreement among authorizing officials and the authorization meets the requirements established by federal and/or organizational policies. Leveraged authorization, is employed when an AO chooses to accept some or all of the information in an existing authorization package generated by another federal agency or other DoD Component (hereafter referred to as the owning organization) based on a need to use the same information resources (e.g., information system and/or services provided by the system). The DoD Component AO reviews the owning organization s authorization package as the basis for determining risk to the leveraging organization. It is DoD policy that the reciprocal acceptance of existing DoD and other Federal agency and department information system authorizations (i.e. leveraged authorizations), and the artifacts contributing to the authorization decisions, shall be employed to the maximum extent. See the DIARMF KS for additional procedural guidance regarding reciprocity and procedures related to leveraged authorizations. Authorization Considerations for Special IS Configurations Type Authorization The type authorization is the official authorization to employ identical copies of a system in specified environments. This form of A&A allows a single IS A&A documentation package (i.e., System Security Plan, supporting documentation for certification, IS A&A Scorecard, and IT Security POA&M (if required)) to be developed for an archetype (common) version of an IS. The IS can then be deployed to multiple locations with a set of installation and configuration requirements or operational security needs that will be assumed by the hosting location. Stand-Alone IS Authorization Stand-alone ISs are treated as special types of enclaves that are not interconnected to any other network. Stand-alone systems do not transmit, receive, route, or interchange information outside of the system s authorization boundary. IA requirements for a stand-alone system are determined through the categorization and controls selection steps just as for other DoD ISs. Stand-alone systems must always be clearly identified as such on the IT Security POA&M, the SIP, and the IS A&A Scorecard. Because of the unique architecture of a stand-alone system, certain IA controls do not pose a risk to the system as a result of their non-implementation and thus are considered NA. NA IA controls are labeled as NA on the IS A&A Scorecard and addressed on the IT Security POA&M simply as a means to document and explain why the IA control is NA in the comments column. Refer to the KS for a discussion of IA controls that may be considered NA for stand-alone systems. Additionally, stand-alone systems that are deployed to multiple locations may be type authorized. 13
Outsourced IT-Based Processes Outsourced IT-based processes supported by private sector ISs, outsourced ISs, and outsourced information services fall into two sub-categories that are treated differently for A&A purposes. Outsourced IT-Based Processes Established for DoD Purposes Only. Outsourced IT-based processes that are dedicated to DoD processing and are effectively under DoD configuration control (e.g., the Navy Marine Corps Intranet) are assessed and authorized as DoD enclaves. Typically, outsourced IT-based processes that are MAC I are in this sub-category and those that process classified information can only be in this sub-category. Outsourced IT-Based Processes That Also Support Non-DoD Users. Outsourced IT-based processes that may also support non-dod users or processes must still be certified and authorized by DoD entities. IA requirements for DoD information in an outsourced environment are determined by its MAC and classification or sensitivity and need-to-know just as for other DoD ISs. However, the following also applies. Technical security of the outsourced environment is the responsibility of the service provider. Outsourced applications that are accessed by DoD users from DoD enclaves (e.g., Powertrack) are subject to DoD enclave boundary defense IA controls for incoming traffic (e.g., ports and protocols and mobile code). Responsibility for procedural and administrative security is shared between the service provider and the supported DoD entity contracting for the service. Security responsibilities of the service provider down to the control level are made explicit in the contract, along with any other performance and service-level parameters by which the Department of Defense shall measure the IA profile of the outsourced IT-based process for the purpose of A&A. Any baseline IA controls that are not explicit in the contract or otherwise covered by a service level agreement are categorized as NC. All such NC IA controls must be documented in an IT Security POA&M with an explanation as to why accepting the risk of operating the outsourced IT-based process with that control in an NC status is acceptable. Security roles and responsibilities are to be made explicit in the acquisition along with the performance and service-level parameters by which the Department of Defense shall measure the IA profile of the outsourced IT-based process. The PM for an outsourced IT-based process will need to carefully define and assess the functions to be performed and identify the technical and procedural security requirements that must be satisfied in the acquisition in order to protect DoD information in the service provider s operating environment and interconnected DoD ISs. Authorization Decisions The AO issues authorization decisions. An authorization decision is communicated via the A&A Scorecard and accompanying IT Security POA&M, if required. Documentation (e.g., artifacts, actual assessment results) supporting an authorization decision will be provided in electronic form if requested by AOs of interconnecting systems. 14
An authorization decision always applies to a specifically identified DoD IS and is based on a balance of mission or business need, protection of personal privacy, protection of the information being processed, and protection of the information environment and thus, by extension, protection of other missions or business functions reliant on the shared information environment. An authorization decision always requires an assessment report. If the assessment is abbreviated as a result of mission urgency, the authorization decision cannot exceed an IATO. If operation will be required beyond the time period of an IATO, a complete assessment should be initiated immediately. When there is compelling operational necessity, DoD ISs may be allowed to operate despite IT security weaknesses that cannot be corrected or adequately mitigated within prescribed timeframes because of technology limitations or, in rare cases, prohibitive costs. Such instances must be fully justified, approved, and documented. An authorization decision is expressed as an ATO, an IATO, an IATT, or a DATO. A system is considered unauthorized if an authorization decision has not been made. ATO An ATO authorization decision must specify an authorization termination date that is within 3 years of the authorization date. A system with a CAT I 10 weakness may not be granted an ATO. A system can operate with a CAT I weakness only when it is critical to military operations as determined by affected military commanders and if failure to deploy or allow continued operation for deployed systems will preclude mission accomplishment. When requested by an affected military commander, the DoD Component CIO shall authorize operation of a system with a CAT I weakness through an IATO. This responsibility cannot be delegated below the DoD Component CIO, and a signed copy of the authorization memorandum with supporting rationale shall be provided to the DoD SIAO and the system s DAA. A system with a CAT II weakness can be granted an ATO only when there is clear evidence that the CAT II weakness can be corrected or satisfactorily mitigated within 180 days of the authorization decision. 15 An ATO can be granted with CAT III weaknesses. The AO will determine if these weaknesses will be corrected or the risk accepted. CAT III weaknesses accepted by the AO will appear on the IT Security POA&M with the Resources Required, Scheduled Completion Date, Milestones with Completion Dates, and Milestone Changes columns marked NA, and with the Status column marked Risk Accepted by AO. IATO 11 An IATO authorization decision is intended to manage IA security weaknesses while allowing system operation. It is not intended to be a device for signaling an evolutionary acquisition. A version of a DoD IS acquired in one of a planned series of acquisition increments or development spirals should be granted an ATO, even if additional or enhanced capabilities and services are planned for future increments or spirals. The ATO authorization decision should not be reserved for DoD ISs for which no change is planned or foreseen. Such thinking engenders an abuse of the IATO authorization status and is an inaccurate portrayal of the DoD ISs IA posture. 10 NOTE: The use of the CAT system for categorizing security impact is unique to DoD. 11 NOTE: NIST SP 800-37 only has two authorization decisions: authorize the information system or deny authorization. The IATO and IATT accreditation decisions are unique to DoD.
An IATO authorization decision must specify an ATD that is within 180 days of the authorization date. An AO may not grant consecutive IATOs totaling more than 360 days. A request for an IATO must be accompanied by an IT Security POA&M that documents identified weaknesses and specifies corrective measures, as appropriate. Corrective actions specified in the IT Security POA&M must be achievable within the authorization period and resourced accordingly. If CAT II weaknesses have not been corrected or satisfactorily mitigated after system operation under IATOs for a total of 360 days, the AO will normally issue a DATO that will remain in effect until all corrective actions identified in the IT Security POA&M are implemented satisfactorily and the AO is able to grant an ATO. The DoD Component CIO may authorize continuation of operation under IATO for systems with CAT II weaknesses that have operated for 360 consecutive days. This responsibility cannot be delegated below the DoD Component CIO. The AO must certify in writing or through DoD PKI-certified digital signature that continued system operation is critical to mission accomplishment. A copy of the authorization to continue system operation with supporting rationale shall be provided to the DoD SIAO. IATT The IATT authorization decision is a special case for authorizing testing in an operational information environment or with live data for a specified time period. IATTs should be granted only when operational environment/live data is required to complete specific test objectives (e.g., replicating certain operating conditions in the test environment is impractical). All applicable IA controls should be tested and satisfied prior to testing in an operational environment or with live data except for those which can only be tested in an operational environment. In consultation with the PM or SM, the DAA will determine which IA controls can only be tested in an operational environment. An IATT may not be used to avoid ATO or IATO assessment activity and assessment report requirements for authorizing a system to operate. Operation of a system under an IATT in an operational environment is for testing purposes only (i.e., the system will not be used for operational purposes during the IATT period). DATO A DATO will be issued if the AO determines that a DoD IS should not operate because the IA design is inadequate, assigned IA controls are not adequately implemented, or because of a lack of other adequate security is revealed through certification activities and there are no compelling reasons to allow system operation. If the system is already operational, the AO has the authority to issue a DATO and halt operation of the system immediately. Step 6: Monitor the IA Controls Continued ATO is contingent on the sustainment of an acceptable IA posture. The DoD IS ISSM has primary responsibility for maintaining situational awareness and initiating actions to improve or restore IA posture. Maintain Situational Awareness (also Known as Information Security Continuous Monitoring) 16
Included in the IA controls assigned to all DoD ISs are IA controls related to configuration and vulnerability management, performance monitoring, and periodic independent evaluations (e.g., penetration testing). The ISSM continuously monitors the system or information environment for security-relevant events and configuration changes that negatively impact IA posture and periodically assesses the quality of IA controls implementation against performance indicators such as security incidents, feedback from external inspection agencies (e.g., IG DoD, Government Accountability Office (GAO)), exercises, and operational evaluations. In addition the ISSM may, independently or at the direction of the SCA or AO, schedule a reassessment of any or all IA controls at any time. Reference (a) requires reassessment of a select number of IA controls at least annually. Maintain IA Posture The ISSM may recommend changes or improvement to the implementation of assigned IA controls, the assignment of additional IA controls, or changes or improvements to the design of the IS itself. Perform Reviews The ISSM shall annually provide a written or DoD PKI-certified digitally signed statement to the AO and the SCA that indicates the results of the required annual security review of all IA controls and the testing of selected IA controls. The review will either confirm the effectiveness of assigned IA controls and their implementation, or it will recommend: changes such as those described in Maintain IA Posture; a change in authorization status (e.g., authorization status is downgraded to IATO or DATO); or development of an IT Security POA&M. The SCA and AO shall review the ISSM statement in light of mission and information environment indicators and determine a course of action that will be provided to the concerned CIO or SIAO for reporting requirements described in FISMA. The date of the annual security review will be recorded in the SIP. An AO may downgrade or revoke an authorization decision at any time if risk conditions or concerns so warrant. 17 Initiate Reauthorization In accordance with OMB Circular A-130 (Reference (r)), an IS must be reassessed and reauthorized once every 3 years. The results of an annual review or a major change in the IA posture at any time may also indicate the need for reassessment and reauthorization of the IS. Decommission When a DoD IS is removed from operation, a number of DIARMF-related actions are required. Prior to decommissioning, any control inheritance relationships should be reviewed and assessed for impact. Once the system has been decommissioned, Lines 8, IS A&A Step, and 9, System Life Cycle Phase, of the SIP should be updated to reflect the IS decommissioned status. Concurrently, the A&A Scorecard and any POA&Ms should also be removed from all tracking systems. Other artifacts and supporting documentation should be disposed of according to its sensitivity or classification. Data or objects in IA infrastructures that support the GIG, such as key management, identity management, vulnerability management, and privilege management, should be reviewed for impact. DIARMF A&A Documentation The IS A&A documentation package is developed through A&A activity and maintained throughout a system s life cycle. Implementing the activities of the A&A process generates the results listed in the Comprehensive Package column in the table below. The Executive Package column lists the
minimum information necessary for an authorization decision. Note that the documents listed in the table are not meant to describe a fixed document requirement. Each AO will determine what information is necessary to make an authorization decision. Most importantly, A&A documentation should add value, not simply be thrown together just to satisfy the requirements of the A&A process and then become shelf ware when the process is complete. Comprehensive Package System Identification Profile (SIP) Executive Package SIP Controls Implementation Plan (ConIP) (formerly the DIP) IA controls inherited and implemented Implementation status Responsible entities Resources Estimated completion date for each IA control Supporting Assessment Documentation Actual assessment results Artifacts associated with implementation of IA controls Other A&A Scorecard A&A Scorecard Assessment determination Authorization decision Assessment determination Authorization decision IT Security POA&M (If required) IT Security POA&M (If required) SIP The SIP is compiled during IS A&A registration and maintained throughout the system life cycle. A&A Scorecard The A&A Scorecard is a summary report that conveys information on the IA posture of a DoD IS succinctly in a format that can be exchanged electronically. Additional data elements may be specified by CIOs, AOs, or other enterprise users of the A&A Scorecard. IT Plan of Action & Milestones (POA&M) An IT Security POA&M is required for any authorization decision that requires corrective action and is also used to document NC or NA IA controls that have been accepted by the responsible AO. The IT Security POA&M addresses: 18
Why the system needs to operate. Any operational restrictions imposed to lessen the risk during an interim authorization. The AO s rationale for accepting certain IA controls that are categorized as NC or NA. Specific corrective actions necessary to ensure that assigned IA controls have been implemented correctly and are effective. The agreed-upon timeline for completing and validating corrective actions. The resources necessary and available to properly complete the corrective actions. As mentioned above, the AO may require additional documents beyond those listed on the table above. In addition to an A&A Plan that may be developed as an agreement between the key A&A roles, the Concept of Operations (CONOPS) is written as a resource for stakeholders involved with the system. The CONOPS drives the Security Policy and security requirements (i.e., in the Security Requirements Traceability Matrix or SRTM) that apply, and the Architecture must meet the applicable requirements. The Administrator s/ User s Guides provide direction to the ISSO/ISSM on how to operate the environment and the resident software. Test Plans are developed to demonstrate that the system, as architected and operated, meets the security requirements. The Test Results capture the results of testing, and the POA&M captures mitigations for failed test results. Memoranda of Understanding (MOUs) and A&A Letters are collected as the A&A effort progresses. The SSP is an executive summary of all of this A&A evidence that is updated throughout the A&A process to focus the AO on important information. While A&A evidence is always required, it does not have to be newly created. In fact, most of the evidence that goes into a A&A effort should already exist if the site is following a sound software engineering process. If done correctly, the A&A process is able to capitalize on the activities included in the system and the software engineering processes. Summary Transitioning to the DIARMF has been in the works for many years and is being executed with the collaborated efforts of the DoD, NIST and Director of National Intelligence (DNI). The decision to rely heavily on the established and effective Risk Management Framework and the NIST SP 800-37 A&A process will prove to be extremely beneficial, particularly when reciprocity is implemented across agencies. The NIST SP 800-53 Revision 3 security controls were thoroughly reviewed and modified as required to incorporate the DoD and DNI requirements for their special mission systems. The success of the transition will rely heavily on the support of leadership and the synchronization of joint efforts across the DoD services. The DIACAP process was developed with the intention of streamlining the DoD C&A process and ensuring that the processes incorporated security engineering and the SDLC; however, each service and organization modified the process for their individual agencies. This resulted in the exact scenario that DoD was attempting to avoid and severely limited any efforts for standardization, consistency, and reciprocity. Let s hope that the DIARMF accomplishes the goal of standardizing and streamlining the process. The result would be increased security and decreased costs since many agencies and vendors will not have to expend limited resources in executing multiple A&A processes in order to deploy their systems to different organizations. 19
References DRAFT DoD Instruction 8500.2, Information Assurance (IA) Implementation. DRAFT DoD Directive 8500.01E, Information Assurance (IA). CNSSI No. 4009, National Information Assurance (IA) Glossary, April 26, 2010. NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems and Organizations, February 2009. NIST Special Publication 800-53A, Guide for Assessing the Security Controls in Federal Information Systems, June 2010. DoD Instruction 8510.01, The DoD Information Assurance Certification and Accreditation Process, November 28, 2007, or successor. DoDI 8580.01, Information Assurance (IA) in the Defense Acquisition System, July 9, 2004. DoD Directive 8570.01, Information Assurance Training, Certification, and Workforce Management, Certified Current as of April 23, 2007. DoD 8570.01-M, Information Assurance Workforce Improvement Program, Dec 19, 2005 with CH 1 (5/15/2008) and CH 2 (4/20/2010). CNSSP 22, Information Assurance Risk Management Policy for National Security Systems, February 2009 NIST Special Publication 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems, February 2010. CNSSI 1253, Security Categorization and Control Selection for National Security Systems, October 2009 NIST SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations, September 2011. Office of Management and Budget Circular A-130. Intelligence Community Directive Number 503, Intelligence Community Information Technology Systems Security Risk Management, Certification and Accreditation, 15 September 2008 20
Glossary and Acronyms Term/Acronym A&A AO ATO C&A CEO CIO CISO CL CNSS CNSSI ConIP CONOPS DAA DATO DIACAP DIARMF DNI DoD DoDD DoDI HIPAA FISMA IA IATO IATT IC IS ISA Definition Assessment & Authorization Authorizing Official Authorization to Operate Certification & Accreditation Chief Executive Officer Chief Information Officer Chief Information Security Officer Confidentiality Level Committee for National Security Systems Committee for National Security Systems Instructions Controls Implementation Plan Concept of Operations Designated Accrediting/Approving Authority Denial of Authority to Operate DoD Information Assurance Certification & Accreditation Process DoD Information Assurance Risk Management Framework Director of National Intelligence Department of Defense Department of Defense Directive Department of Defense Instruction Health Information Portability and Accountability Act Federal Information Security Management Act Information Assurance Interim Authority to Operate Interim Authority to Test Intelligence Community Information System Information Security Architect 21
ISSE ISSM ISSO IT KS MAC MTF MOA MOU NA NC NIST OMB PAA PAO PII PM POA&M REF RMF Information System Security Engineer Information System Security Manager Information System Security Officer Information Technology Knowledge Service Mission Assurance Category Military Treatment Facility Memorandum of Agreement Memorandum of Understanding Not Applicable Non-Compliant National Institute of Standards & Technology Office of Management & Budget Principal Approving/Accrediting Authority Principal Approving/Accrediting Official Personally Identifiable Information Program or Project Manager Plan of Action & Milestones Risk Executive Function Risk Management Framework S(A)ISO SAR SCA SDLC SIAO SIP SM SP SRTM SSP VA Senior (Agency) Information Security Officer Security Assessment Report Security Control Assessor System Development Lifecycle Senior Information Assurance Officer System Identification Profile System Manager Special Publication Security Requirements Traceability Matrix System Security Plan Veterans Administration 22