Understanding Certification and Accreditation

In many environments, formal methods must be applied to ensure that the appropriate information system security safeguards are in place and that they are functioning per the specifications. In addition, an authority must take responsibility for putting the system into operation. These actions are known as Certification and Accreditation (C&A), respectively.

System Authorization

System Authorization is the risk management process of assessing risk associated with a system and, when necessary, taking steps to mitigate vulnerabilities to reduce risk to an acceptable level. As defined elsewhere in this book, risk management is the total process of identifying, controlling, and mitigating IT system-related risks. Risk management includes cost benefit analysis, risk assessment, and the selection, implementation, test, and evaluation of security controls.

System Authorization mandates the creation of a System Authorization Plan (SAP), which is a comprehensive and uniform approach to the System Authorization Process. The SAP is comprised of four phases:

• Phase 1 - Pre-certification
• Phase 2 - Certification
• Phase 3 - Authorization
• Phase 4 - Post-Authorization

A Select History of Systems Authorization

Beginning in the 1950s the United States Government created a classified set of standards for limiting electric or electromagnetic radiation emanations from electronic equipment, known as TEMPEST (Telecommunications Electronics Material Protected from Emanating Spurious Transmissions). This program focused on evaluating and screening companies and equipment to ensure that electromagnetic radiation from information-handling devices is eliminated or controlled.

Since then, the government has issued several guidelines and standards relating to computer security and the proper handling of computer information. It also created a method, known as Certification and Accreditation (C&A), to ensure that an information system has met all its security requirements prior to becoming operational.

Many of these standards are described in other sections of this book; let’s touch on the major standards here.

Federal Information Processing Standard (FIPS) 102

Federal Information Processing Standard (FIPS) 102, the Guideline for Computer Security Certification and Accreditation, was published on September 27, 1983. FIPS 102 is a comprehensive guide explaining how to establish a C&A program and execute a complete C&A. FIPS 102 defined Certification and Accreditation as:

• Certification - The technical evaluation, made as part of and in support of the accreditation process, that establishes the extent to which a particular computer system or network design and implementation meet a prespecified set of security requirements
• Accreditation - The authorization and approval granted to an ADP system or network to process data in an operational environment, and made on the basis of a certification by designated technical personnel of the extent to which design and implementation of the system meet prespecified requirements for achieving adequate security

FIPS 102 was designed to certify an application by executing a six-step technical security evaluation:

1. Planning
2. Data collection
3. Basic evaluation
4. Detailed evaluation
5. Report of findings
6. Accreditation

FIPS 102 defines four roles: the accreditor, the program manager, the certification manager, and the evaluator. The Computer Security Act of 1987 provided a provision to allow agencies to waive mandatory FIPS. This waiver provision, in effect, significantly dampened the effectiveness of FIPS and was later removed by the Federal Information Security Management Act (FISMA).

Trusted Computer System Evaluation Criteria (TCSEC)

The Department of Defense (DoD) issued the Trusted Computer System Evaluation Criteria (TCSEC), DoD 5200.28-STD in December 1985. Commonly referred to as the Orange Book, it provided computer security guidance for Automated Information Systems (AISs). The Orange Book was then followed by the Trusted Network Evaluation Criteria (the White Book), which later evolved into the Common Criteria.

Office of Management and Budget Circular A-130

In 1987, the Government issued the Office of Management and Budget (OMB) Circular A-130, Management of Federal Information Resources. This circular provided uniform, government-wide information resources management policies for Federal information resources as required by the Paperwork Reduction Act of 1980.

Appendix III, “Security of Federal Automated Information Resources,” requires accreditation for an information system to operate based on an assessment of management, operational, and technical controls. The security plan documents the security controls that are in place and are planned for future implementation. This includes the requirement that all general support systems and major applications must be authorized before the system or application is placed in operation.

DoD Information Technology Security Certification and Accreditation Process (DITSCAP)

The Office of Assistant Secretary of Defense directed the Defense-wide Information Systems Security Program (DISSP) to create standardized requirements and processes for accreditation of computers, systems, and networks in its August 19, 1992, memorandum, “The Defense Information Systems Security Program.” A security process improvement working group was formed to develop this standard process. Their task was to develop a standard C&A process that would meet the policies defined in DoD Directive 5200.28; Public Law (P. L.) 100-235 (1988); Office of Management and Budget (OMB) Circular A-130, Appendix III; Director of Central Intelligence (DCID) 1/16; and DoD Directive 5220.22.

The result, DoD Directive 5200.40, “DoD Information Technology Security Certification and Accreditation Process (DITSCAP),” established the DITSCAP as the standard C&A process for the Department of Defense. DITSCAP establishes a standard process, a set of activities, general task descriptions, and a management structure to certify and accredit the IT systems that will maintain the required security posture. This process is designed to certify that the IT system meets the accreditation requirements and that the system will maintain the accredited security posture throughout its life cycle.

The objective of the DITSCAP is to establish a DoD standard, infrastructure-centric approach that protects and secures the entities constituting the Defense Information Infrastructure (DII). The set of activities presented in the DITSCAP standardizes the C&A process for single IT entities and leads to more secure system operations and a more secure DII. The process considers the system mission, environment, and architecture while assessing the impact of operation of that system on the DII.

As shown in Figure 11-1, DITSCAP is designed to be adaptable to any type of IT system and any computing environment and mission. It may be adapted to include existing system certifications and evaluated products, use new security technology or programs, and adjust to applicable standards. DITSCAP may be mapped to any system life-cycle process but is independent of the life-cycle strategy. DITSCAP is designed to adjust to the development, modification, and operation of life-cycle phases.

Figure 11-1: DITSCAP overview

The primary elements of DITSCAP are that it:

• Implements policies, assigns responsibilities, and prescribes procedures under reference (a) for Certification and Accreditation (C&A) of information technology (IT), including automated information systems, networks, and sites in the Department of Defense
• Creates the DoD IT Security Certification and Accreditation Process (DITSCAP) for security C&A of unclassified and classified IT to implement references (a) through (d)
• Stresses the importance of a life-cycle management approach to the C&A and reaccreditations of DoD IT

DITSCAP applies to the Office of the Secretary of Defense (OSD), the Military Departments, the Chairman of the Joint Chiefs of Staff, the Combatant Commands, the Inspector General of the Department of Defense (IG, DoD), the Defense Agencies, and the DoD Field Activities (hereafter referred to collectively as “the DoD Components”), their contractors, and agents. It also applies to the acquisition, operation, and sustainment of any DoD system that collects, stores, transmits, or processes information, unclassified or classified. It applies to any IT or information system life cycle, including the development of new IT systems, the incorporation of IT systems into an infrastructure, the incorporation of IT systems outside the infrastructure, the development of prototype IT systems, the reconfiguration or upgrade of existing systems, and legacy systems.

Two important documents created during the DITSCAP process are the Requirements Traceability Matrix (RTM) and the System Security Authorization Agreement (SSAA).

The System Security Authorization Agreement (SSAA)

An important element in the DITSCAP is the System Security Authorization Agreement (SSAA). The SSAA is a formal agreement among the Designated Approving Authority (DAA, or accreditor), certifier, user representative, and program manager. The objective of the SSAA is to establish an evolving yet binding agreement on the level of security required, before the system development begins or changes to a system are made.

The SSAA is used throughout the entire DITSCAP to guide actions, document decisions, specify IA requirements, document certification tailoring and level of effort, identify possible solutions, and maintain operational systems security. After accreditation, the SSAA becomes the baseline security configuration document.

The SSAA:

• Describes the operating environment and threat
• Describes the system security architecture
• Establishes the C&A boundary of the system to be accredited
• Documents the formal agreement among the DAA(s), certifier, program manager, and user representative
• Documents all requirements necessary for accreditation
• Minimizes documentation requirements by consolidating applicable information into the SSAA (security policy, concept of operations, architecture description, test procedures, and so on)
• Documents the NIACAP plan
• Documents test plans and procedures, certification results, and residual risk
• Forms the baseline security configuration document

The National Information Assurance Certification and Accreditation Process (NIACAP)

The National Security Telecommunications and Information Systems Security Instruction (NSTISSI) No. 1000 defines the National Information Assurance Certification and Accreditation Process (NIACAP). The NIACAP establishes the minimum national standards for certifying and accrediting national security systems. This process provides a standard set of activities, general tasks, and a management structure to certify and accredit systems that maintain the information assurance and the security posture of a system or site. The NIACAP is designed to certify that the information system meets the documented accreditation requirements and will continue to maintain the accredited security posture throughout the system’s life cycle.

Under Executive Order (E.O.) 13231 of October 16, 2001, Critical Infrastructure Protection in the Information Age, the National Security Telecommunications and Information Systems Security Committee (NSTISSC) has been redesignated the Committee on National Security Systems (CNSS). The Department of Defense continues to chair the committee under the authorities established by NSD-42 (www.nstissc.gov/).

Because of the different nature of the information being protected, the NIACAP takes a slightly different approach to C&A than the DITSCAP. Both the DITSCAP and NIACAP use the four-phased approach of: Definition, Verification, Validation, and Post-Accreditation. Unlike the DITSCAP, however, the NIACAP doesn’t require an Information Systems Security Officer (ISSO).

Also, the NIACAP defines the creation of a System Security Plan (SSP) rather than a SSAA. Otherwise, the NIACAP is virtually identical to the DITSCAP and establishes the minimum standards required for certifying and accrediting non-DoD national security systems.

NIACAP and NSTISSP # 6

The NIACAP provides guidance on how to implement the NSTISSP No. 6 policy, which establishes the requirement for federal departments and agencies to implement a C&A process for national security systems. The requirements of the NSTISSI No. 6 apply to all U.S. government executive branch departments, agencies, and their contractors and consultants.

The process is started when the concept design of a new information system or modification to an existing system is begun in response to an identified business case, operational requirement, or mission need. Any security-relevant changes should initiate the NIACAP for any existing or legacy IS.

NSTISSP No. 6 determines that all federal government departments and agencies establish and implement programs mandating the certification and accreditation (C&A) of national security systems under their operational control. These C&A programs must ensure that information processed, stored, or transmitted by national security systems is adequately protected for confidentiality, integrity, and availability.

NSTISSP No. 6 specifically determines that C&A programs established to satisfy this policy be based on the following principles:

• Certification of national security systems shall be performed and documented by competent personnel in accordance with specified criteria, standards, and guidelines.
• Accreditation of national security systems shall be performed by competent management personnel in a position to balance operational mission requirements and the residual risk of system operation. All accreditation decisions shall be documented and contain a statement of residual risk.
• Departments and agencies shall freely exchange technical C&A information, coordinate programs, and participate in cooperative projects wherever possible.
• To promote cost-effective security across the federal government, department and agency programs for the C&A of national security systems shall be developed in concert with similar programs that address security of sensitive information pursuant to the Computer Security Act of 1987 (Public Law 100-235).
• As cornerstones of a continuous process of effective security management, activities in support of certification and accreditation shall be performed at appropriate points throughout the total system life cycle.

NSTISSP No. 6 defines responsibilities at a high level by stating that heads of U.S. Government departments and agencies shall:

• Ensure that C&A programs consistent with the policy and principles set forth in this NSTISSP are established and implemented.
• Ensure that a DAA is identified for each system under their operational control, and that DAAs have the ability to influence the application of resources to achieve an acceptable level of security.

NIACAP Accreditation Types

There are three types of NIACAP accreditation, depending on what is being certified. They are:

1. Site accreditation - Evaluates the applications and systems at a specific, self-contained location
2. Type accreditation - Evaluates an application or system that is distributed to a number of different locations
3. System accreditation - Evaluates a major application or general support system

The NIACAP applies to each of these accreditation types and can be tailored to meet the specific needs of the organization and IS.

Defense Information Assurance Certification and Accreditation Process (DIACAP)

The Defense Information Assurance Certification and Accreditation Process (DIACAP) instruction guide DoD 8510.bb, is the long-awaited update to DITSCAP. Part of the DoD 8500 series, it’s not merely an upgraded DITSCAP but an entirely new process designed to be more easily completed than the typical DITSCAP C&A.

DIACAP replaces the DoD 5200.40, DITSCAP, and DoD 8510.1-M, DITSCAP Application Manual.

DIACAP is a Web-based process. The DIACAP Knowledge Service will service the Information Assurance communities with a portal providing training, information on recent developments, and a community discussion forum.

An additional service, the Enterprise Mission Assurance Support System (eMass), is an automated suite of tools to help guide an agency through the DIACAP process.

The DIACAP road map consists of three branches:

1. If the system is currently under a DITSCAP Approval To Operate (ATO), that ATO is good until its expiration.
2. If the agency is in the middle of the DITSCAP and has finished Phase 1, the agency will be able to continue to accredit through DITSCAP with some minor changes.
3. If the system has not started the C&A process yet, the C&A will begin with DIACAP.

The DIACAP applies to the “acquisition, operation and sustainment of all DoD-owned or controlled information systems that receive, process, store, display, or transmit DoD information, regardless of classification or sensitivity of the information or information system.”

The DIACAP specifies four Information System categories:

1. Enclave
2. AIS application or service
3. Outsourced information technology (IT)-based process
4. Platform IT interconnection

The DIACAP is expected to ease the burden of documentation requirements, for example, SSAAs will no longer be necessary. Although the standard is still being designed (as of this writing), a typical DIACAP package will contain a minimal set of documentation which can include:

• System Identification Profile
• DIACAP Strategy
• IA Implementation Plan
• DIACAP Scorecard
• Certification Determination
• DIACAP Plan of Actions and Milestones
• Accreditation Decision
• Artifacts and Evidence of Compliance

The DIACAP Scorecard is the “report card” of how the system compared against mandatory IA Controls.

British Standard 7799 and ISO/IEC 17799

The British Standard BS7799 for information security was released in 1995. Developed by the British Standards Institute, the standard focused mainly on nontechnical IT management systems issues.

This standard became the International Organization for Standardization/ International Electrotechnical Commission (ISO/IEC) 17799, the Code of Practice for Information Security Management, in 2000. ISO/IEC 17799 organizes information security into 10 main sections:

• Security Policy
• Security Organization
• Asset Classification and Control
• Personnel Security
• Physical and Environmental Security
• Communications and Operations Management
• Access Control
• Systems Development and Maintenance
• Business Continuity Management
• Compliance

Common Criteria ISO/IEC 15408

TCSEC, ITSEC, and the Canadian Trusted Computer Product Evaluation Criteria (CTCPEC) have evolved into one set of evaluation criteria called the Common Criteria. The initial version of the Common Criteria, Version 1.0, was completed in January 1996. Based on a number of trial evaluations and an extensive public review, Version 1.0 was extensively revised, and Version 2.0 was produced in April of 1998.

In 1999, the Common Criteria were revised in order to align them with ISO/IEC 154508, Evaluation Criteria for IT Security. Whereas ISO/IEC 17799 was the management standard, the Common Criteria were the technical standard intended to support the specification and technical evaluation of IT security features in products.

The Common Criteria define a Protection Profile (PP), which is an implementation-independent specification of the security requirements and protections of a product that could be built. The Common Criteria terminology for the degree of examination of the product to be tested is the Evaluation Assurance Level (EAL). EALs range from EA1 (functional testing) to EA7 (detailed testing and formal design verification). The Common Criteria TOE refers to the product to be tested. A Security Target (ST) is a listing of the security claims for a particular IT security product. Also, the Common Criteria describe an intermediate grouping of security requirement components as a package. The term functionality in the Common Criteria refers to standard and well-understood functional security requirements for IT systems. These functional requirements are organized around TCB entities that include physical and logical controls, startup and recovery, reference mediation, and privileged states.

Federal Information Security Management Act (FISMA)

The E-Government Act of 2002 contained the Federal Information Security Management Act (FISMA). FISMA requires government agencies and components to improve security by setting forth fundamental Security Objectives for information and information systems, making Federal Information Processing Standards (FIPS) mandatory. There is no longer a statutory provision allowing agencies to waive mandatory Federal Information Processing Standards. Since FISMA supersedes the Computer Security Act of 1987; the references to the “waiver process” contained in many FIPS are no longer relevant.

Federal Information Technology Security Assessment Framework (FITSAF)

On December 8, 2000, the Chief Information Officers (CIO) Council released the first version of the Federal Information Technology Security Assessment Framework (FITSAF). It was prepared for its Security, Privacy, and Critical Infrastructure Committee by the National Institute of Standards and Technology (NIST), Computer Security Division Systems and Network Security Group.

The Federal Information Technology (IT) Security Assessment Framework provides a method for agency officials to determine the current status of their security programs relative to existing policy and to establish a target for improvement. The framework does not create new security requirements but provides a vehicle to consistently and effectively apply existing policy and guidance.

Also, FITSAF may be used to assess the status of security controls for a given asset or collection of assets. These assets include information; individual systems (e.g., major applications, general support systems, and mission critical systems), or a logically related grouping of systems, that support operational programs; or the operational programs themselves (e.g., air traffic control, Medicare, student aid). Assessing all asset security controls and all interconnected systems that the asset depends on produces a picture of both the security condition of an agency component and of the entire agency.

FITSAF is divided into five levels (see Figure 11-2), based on SEI’s Capability Maturity Model (CMM). Each level represents a more complete and effective security program:

• Level 1 reflects that an asset has documented a security policy.
• Level 2 shows that the asset has documented procedures and controls to implement the policy.
• Level 3 indicates that these procedures and controls have been implemented.
• Level 4 shows that the procedures and controls are tested and reviewed.
• Level 5 shows that the asset has procedures and controls fully integrated into a comprehensive program.

Figure 11-2: FITSAF security assessment framework levels.

The security status is measured by determining whether specific security controls are documented, implemented, tested, reviewed, and incorporated into a cyclical review/improvement program, as well as whether unacceptable risks are identified and mitigated. Agencies are expected to bring all assets to level 4 and ultimately level 5. When an individual system does not achieve level 4, agencies should determine whether that system meets the criteria found in OMB Memorandum M00-07 (February 28, 2000), “Incorporating and Funding Security in Information Systems Investments.”

FIPS 199

In 2003, NIST developed a new C&A guideline resulting in FIPS 199, the Standards for Security Categorization of Federal Information and Information Systems, replacing FIPS 102. FIPS 199 defined three levels of potential impact:

• Low - Causing a limited adverse effect
• Medium - Causing a serious adverse effect
• High - Causing a severe or catastrophic adverse effect

FIPS 200

As of this writing, NIST Special Publication 800-53, “Security Controls for Federal Information Systems,” is expected to become approved as FIPS 200, Minimum Security Controls for Federal Information Systems. With the exception of systems designed for national security, the IT departments of all systems at civilian federal agencies must implement strategies and processes to:

• Secure all assets and services
• Ensure service levels, policy compliance, and appropriate risk management
• Reduce the cost and complexity of heterogeneous IT infrastructure management

More and More Standards

There are still more standards, policies, legislation, and guidance documents that apply to C&A. Some of these include:

• Computer Security Act of 1987
• Paperwork Reduction Act of 1995
• Clinger-Cohen Act of 1996
• Joint Department of Defense Intelligence Information Systems (DoDIIS)/Cryptologic Secure Compartmented Information (SCI) Information Systems Security Standards (JDCSISSS)
• Health Insurance Portability and Accountability Act of 1996 (HIPAA)
• National Security Telecommunications and Information Systems Security Policy (NSTISSP) No. 11
• DoD 5200.1-R, “Information Security Program Regulation”
• DoD 5200.22-M, “National Industrial Security Program Operating Manual”
• DoD 7950.1-M, “Defense Automation Resources Management Manual”
• DoDD 8000.1, “Defense Information Management (IM) Program”
• DoD 8910.1, “Management and Control of Information Requirements”
• GAO/AIMD-12.19.6, FISCAM
• NIST Special Publication 800-14, “GSSP”
• OMB Memorandum 99-18, “Privacy Policies on Federal Web Sites”

What Is Certification and Accreditation?

Certification is the comprehensive evaluation of the technical and nontechnical security features of an information system and the other safeguards created in support of the accreditation process, to establish the extent in which a particular design and implementation meets the set of specified security requirements.

Accreditation is the formal declaration by a Designated Approving Authority (DAA) that an information system is approved to operate in a particular security mode by using a prescribed set of safeguards at an acceptable level of risk. Recertification and reaccreditation are required when changes occur in the system and/or its environment, or after a defined period of time after accreditation.

C&A is required for all federal government departments and agencies, as determined by the National Policy on Certification and Accreditation of National Security Telecommunications and Information Systems, issued April 8, 1994. The policy is intended to provide the national security community with standard methodologies for C&A processes, assign authority and responsibilities, and lay a basis for mutual recognition of certification results in order to ensure the security of national security systems. Its goals are the development of cost-effective policies, procedures, and methodologies for the C&A of national telecommunications and information systems.

Two of the most used C&A standards are the aforementioned NIACAP and DITSCAP. As mentioned in the previous section of this chapter, the Defense Information Assurance Certification and Accreditation Process (DIACAP) was recently developed to replace DITSCAP, and is intended to make DoD C&A easier. We will describe each of these processes in detail later in the subsection on C&A phases.

NIST C A Documents

NIST has developed a suite of documents for conducting C&A, including:

• Special Publication 800-37, “Guide for the Security Certification and Accreditation of Federal Information Systems”
• Special Publication 800-53, “Security Controls for Federal Information Systems (interim guidance)”
• Special Publication 800-53A, “Techniques and Procedures for Verifying the Effectiveness of Security Controls in Federal Information Systems”
• NIST Special Publication 800-59, “Guideline for Identifying an Information System as a National Security System”
• NIST Special Publication 800-60, “Guide for Mapping Types of Information and Information Systems to Security Objectives and Risk Levels”

C A Roles and Responsibilities

Many roles are involved in the C&A process. Several of these roles, such as the system owner, system manager, configuration manager, systems administrator, and risk analyst, are defined in other chapters of this book.

Using the DITSCAP as a model, the four minimum roles needed to perform a C&A are the:

1. IS program manager
2. Designated Approving Authority (DAA), also referred to as the accreditor
3. Certification agent (certifier)
4. User representative

The individuals in these roles tailor and scope the C&A efforts to the particular mission, environment, system architecture, threats, funding, and schedule of the system. These individuals resolve critical schedule, budget, security, functionality, and performance issues. We’ll examine these roles in more detail in the following subsections.

Additional roles may be added to increase the integrity and objectivity of C&A decisions. For example, the Information Systems Security Officer (ISSO) usually performs a key role in the maintenance of the security posture after the accreditation and may also play a key role in the C&A of the system.

Program Manager

The program manager represents the interests of the system in areas such as:

• Acquisition
• Life cycle schedules
• Funding responsibility
• System operation
• System performance
• Maintenance

Which organization the program manager represents is determined by the phase in the life cycle of the system. The program manager coordinates all aspects of the system from initial concept, through development, to implementation and system maintenance. The DAA, certifier, and user representative give advice, information, and guidance to the program manager throughout the C&A.

The program manager:

• Is the primary authorization advocate
• Is responsible for the IS throughout the life cycle (cost, schedule, and performance of the system development)
• Ensures that the security requirements are integrated in a way that will result in an acceptable level of risk to the operational infrastructure as documented in the System Security Authorization Agreement (SSAA)
• Keeps all C&A participants informed of life cycle actions, security requirements, and documented user needs

Additionally, the program manager provides details of the system and its life cycle management to the DAA, certifier, and user representative during Phase 2. The program manager must verify that the implementation of the system is consistent with the system security characteristics reflected in the SSAA.

As additional system details become available, the program manager ensures the SSAA is updated. At the end of Phase 2, the program manager ensures that a configuration management procedure is in place and that the system is properly controlled during the certification process.

The PM also ensures that the certification-ready system is under configuration management during Phase 3. The DAA, certifier, and user representative validate that the operational environment and system configuration are consistent with the security characteristics reflected in the SSAA.

Designated Approving Authority (DAA)

The DAA is the primary government official responsible for implementing system security. The DAA is an executive with the authority and ability to balance the needs of the system with the security risks. He or she determines the acceptable level of residual risk for a system and must have the authority to oversee the budget and IS business operations of systems under his or her purview.

Based on the information available in the SSAA, the DAA can grant the accreditation, an Interim Approval to Operate (IATO), or may determine that the system’s risks are not at an acceptable level and it is not ready to be operational. In reaching these decisions, the DAA is supported by all the documentation provided in the SSAA.

Certification Agent

The certifier (or certification team) provides the technical expertise to conduct the certification throughout the system’s life cycle based on the security requirements documented in the SSAA. The certifier determines the existing level of residual risk and makes an accreditation recommendation to the DAA. The certifier is the technical expert who documents tradeoffs among security requirements, cost, availability, and schedule to manage security risk.

The certifier determines whether a system is ready for certification and conducts the certification process - a comprehensive evaluation of the technical and nontechnical security features of the system. At the completion of the certification effort, the certifier reports the status of certification and recommends to the DAA whether to accredit the system based on documented residual risk.

To avoid conflicts of interest, the certifier should be independent from the organization responsible for the system development or operation. Organizational independence of the certifier ensures the most objective information for the DAA to make accreditation decisions.

User Representative

The operational interests of system users are vested in the user representative. In the C&A process, the user representative is concerned with system availability, access, integrity, functionality, performance, and confidentiality as they relate to the mission environment.

Users and their representatives are found at all levels of an agency. As noted in the SSAA, the user representative:

• Is responsible for the identification of operational requirements
• Is responsible for the secure operation of a certified and accredited IS
• Represents the user community
• Assists in the C&A process
• Functions as the liaison for the user community throughout the life cycle of the system
• Defines the system’s operations and functional requirements
• Is responsible for ensuring that the user’s operational interests are maintained throughout system development, modification, integration, acquisition, and deployment

Information Systems Security Officer (ISSO)

The ISSO is the person responsible to the DAA for ensuring that security is provided for and implemented throughout the life cycle of an AS from the beginning of the system concept development phase through its design, development, operation, maintenance, and secure disposal. As per NIST 800-37, the ISSO is the agency official responsible for carrying out the Chief Information Officer responsibilities under FISMA.

NIACAP Roles

The NIACAP roles are virtually identical to the DITSCAP roles. The four minimum roles needed to perform a NIACAP security assessment are the:

• IS program manager
• Designated Approving Authority (DAA), also referred to as the accreditor
• Certification agent (certifier)
• User representative

The individuals in these roles tailor and scope the C&A efforts to the particular mission, environment, system architecture, threats, funding, and schedule of the system. These individuals resolve critical schedule, budget, security, functionality, and performance issues.

DIACAP ROLES

The DIACAP is intended to make C&A easier than either the DITSCAP or the NIACAP, as we will see in later chapters. The key participants in the DIACAP process are:

• DAA
• Information Assurance Manager
• Program Manager
• User Representative
• Certification Authority

NIST C&A Roles

NIST publication 800-37, “Guide for the Security Certification and Accreditation of Federal Information Systems,” describes these roles a little differently. For example, the DAA is referred to as the Authorizing Official.

NIST 800-37 also defines the role of Chief Information Officer. The Chief Information Officer is the agency official responsible for:

• Designating a senior agency information security officer
• Developing and maintaining information security policies, procedures, and control techniques to address all applicable requirements
• Training and overseeing personnel with significant responsibilities for information security
• Assisting senior agency officials concerning their security responsibilities
• Reporting annually, in coordination with other senior agency officials, to the agency head on the effectiveness of the agency information security program, including progress of remedial actions

C A Phases

The phases of DITSCAP and NIACAP are also virtually identical. C&A is commonly composed of four phases:

1. Definition - This phase is focused on understanding the IS business case, the mission, environment, and architecture to determine the security requirements and level of effort necessary to achieve certification and accreditation. The objective of Phase 1 is to agree on the security requirements, C&A boundary, schedule, level of effort, and resources required.
2. Verification - Phase 2 confirms the evolving or modified system’s compliance with the information in the SSAA (or the System Security Plan in NIACAP). The objective of Phase 2 is to ensure that the fully integrated system will be ready for certification testing.
3. Validation - Phase 3 confirms compliance of the fully integrated system with the security policy and requirements stated in the SSAA. The objective of Phase 3 is to produce the required evidence to support the DAA in making an informed decision to grant approval to operate the system (accreditation or Interim Approval to Operate [IATO]).
4. Post Accreditation - The Post Accreditation phase starts after the system has been certified and accredited for operations. Phase 4 includes those activities necessary for the continuing operation of the accredited IS in its computing environment and for addressing the changing threats and small-scale changes a system faces through its life cycle. The objective of Phase 4 is to ensure secure system management, operation, and maintenance to preserve an acceptable level of residual risk. Phase 4 continues until the information system is removed from service (decommissioned), undergoes major revisions, or requires a periodic compliance validation.

Each phase consists of defined activities with specific tasks and procedures, as will be seen in later chapters.

DIACAP Phases

The DIACAP process is a little different from DITSCAP or NIACAP. Figure 11-3 shows a diagram of the expected DIACAP phases.

Figure 11-3: DIACAP overview.

The overall process is similar to other C&A activities. The DIACAP process is expected to consist of five phases, with subordinate tasks:

1. Initiate and Plan IA C&A:
   • Register system with DoD Component IA Program.
   • Assign IA controls.
   • Assemble DIACAP team.
   • Develop DIACAP strategy.
   • Initiate IA implementation plan.

1. Implement and Validate Assigned IA Controls:
   • Execute and update IA implementation plan.
   • Conduct validation activities.
   • Combine validation results in DIACAP Scorecard.

1. Make Certification Determination and Accreditation Decisions:
   • Analyze residual risk.
   • Issue certification determination.
   • Make accreditation decision.

1. Maintain Authority to Operate and Conduct Reviews:
   • Initiate and update lifecycle implementation plan for IA controls.
   • Maintain situational awareness.
   • Maintain IA posture.

1. Decommission System:
   • Conduct activities related to the disposition of the system data and objects.

Assessment Questions

You can find the answers to the following questions in Appendix A.

Answers