Most people can probably recall playing games as kids and asking playmates: “Which way did they go?” The friends would respond, “They went that way,” and point in all directions—meaning that they really did not know which way they went. Such is the case when selecting a certification and accreditation process (CAP) for a US federal information system. The process of selecting a CAP is not dependent upon the formatting of the documents but on the degree of detail that is needed for the information system.
Certification and accreditation (C&A) of an information system is a confusing, rigorous and costly process for any organization to follow.
In 1987, the US Congress passed Public Law 100-235, known as the Computer Security Act of 1987.1 This act has led to many different interpretations of how to manage computers. This early interpretation resulted in the development of a process called system development life cycle, which can be traced back to the Computer Security Act of 1987:
The National Bureau of Standards shall...have the mission of developing standards, guidelines, and associated methods and techniques for computer systems.
Within one year after the date of enactment of this Act, each such agency shall, consistent with the standards, guidelines, policies, and regulations prescribed pursuant to section 111(d) of the Federal Property and Administrative Services Act of 1949, establish a plan for the security and privacy of each Federal computer system identified by that agency pursuant to subsection (a) that is commensurate with the risk and magnitude or the harm resulting from the loss, misuse, or unauthorized access to or modification of the information contained in such system. Copies of each such plan shall be transmitted to the National Bureau of Standards and the National Security Agency for advice and comment. A summary of such plan shall be included in the agency's five-year plan required by section 3505 of title 44, United States Code. Such plan shall be subject to disapproval by the Director of the Office of Management and Budget. Such plan shall be revised annually as necessary.
The most interesting portion of that excerpt is found in the first line, which requires each agency to develop a plan for the purpose of security and privacy. This plan has been labeled a systems security plan (SSP), system security authorization agreement (SSAA), concept of operations, system identification profile (SIP) or as a business impact assessment (BIA).
The SSP is not a single document but a collection of documents that support the overall functionality of the SSP. The SSP is available through a different CAP. A CAP has different terms that need to be explained in some detail to understand the overall process involved. The major advantage of the CAP is that it helps provide a better understanding of how an information system is supposed to function, compared to how it is currently operating. The downside to C&A is the time and cost involved in conducting a CAP for a single information system.
The US National Security Telecommunications and Information Systems Security Committee (NSTISSC)2 defines certification as the "comprehensive evaluation of the technical and nontechnical security safeguards of an information system to support the accreditation process that establishes the extent to which a particular design and implementation meets a set of specified security requirements.” Accreditation is defined as a “formal declaration by a designated approving authority that an IS is approved to operate in a particular security mode at an acceptable level of risk, based on the implementation of an approved set of technical, managerial, and procedural safeguards."3
As stated in the Computer Security Act of 1987, copies of each security plan shall be transmitted to the US National Bureau of Standards and the National Security Agency for advice and comment. The National Bureau of Standards is now known as the National Institute of Standards and Technology (NIST). As is currently stated in the US Federal Information Security Management Act (FISMA):
The Administrator shall work with the Administrator of the Office of Information and Regulatory Affairs and with other offices within the Office of Management and Budget to oversee implementation of electronic Government under this chapter, chapter 35, the E-Government Act of 2002, and other relevant statutes, in a manner consistent with law, relating to: (8) Assist the Director in establishing policies which shall set the framework for information technology standards for the Federal Government developed by the National Institute of Standards and Technology and promulgated by the Secretary of Commerce under section 11331 of title 40, taking into account, if appropriate, recommendations of the Chief Information Officers Council, experts, and interestedparties from the private and nonprofit sectors and State, local, and tribal governments, and maximizing the use of commercial standards as appropriate, including the following:
(A) Standards and guidelines for interconnectivity and interoperability as described under section 3504.
(B) Consistent with the process under section 207(d) of the E-Government Act of 2002, standards and guidelines for categorizing Federal Government electronic information to enable efficient use of technologies, such as through the use of extensible markup language.
(C) Standards and guidelines for Federal Government computer system efficiency and security.4
What has become most interesting about the previous statements is the lack of advancement in the understanding of what is to be accredited by today's standards. The old standards of accrediting an information system are rooted in the early definitions, provided by both the US Office of Management and Budget (OMB) and NIST, as either a major application (MA) or a general support system (GSS) as described in the following paragraphs:
Major Application [OMB Circular A-130, Appendix III] an application that requires special attention to security due to the risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of the information in the application.
General Support System [OMB Circular A-130, Appendix III] an interconnected set of information resources under the same direct management control that shares common functionality. It normally includes hardware, software, information, data, applications, communications, and people.
These two definitions are further enhanced by providing additional requirements in identifying supporting documentation in the protection of an MA or a GSS. What is most interesting is that the MA does not mention hardware, but leaves this requirement up to the GSS. OMB has initially identified only 11 procedural requirements, while NIST has expanded these requirements to 36 (see figure 1).
Based on historical definitions, why is it that requirements for an MA and a GSS have not evolved with the evolution of the IT field? According to OMB's definition of an MA, the only two categories for accreditation would fall to the application and a database.
However, if accrediting a GSS, the following components would be accredited (including any combinations listed below):
- Workstations (laptops, personal computers):
- Stand-alone workstations (not connected to a network)
- Single workstation in a room
- Multiple workstations in a room
- By a floor
- By a building
- By a group of buildings
- By a site
- By a group of sites
- Database server
- Personnel folder
- Local area network, wide area network, virtual private network
- Tactical systems
- Weapon systems
- Communications systems:
- Video teleconference systems
- Satellite system
- Public broadcast
- Wireless (radio)
This list is in a constant state of flux due to the everchanging IT field.
The CAP, or portions thereof, is intended not only for federal agencies such as the US Internal Revenue Service, Department of Agriculture, Department of Homeland Security, Department of Defense, Department of the Navy and the Coast Guard, but also for US commercial entities, private and homeowners.
The following four statements from four different documents show the complexity in creating an SSP, as they allow individual agencies to create their own format:
- NIST SP 800-18 states in section 1.6, Recommended Format:
While the format in this guide is recommended, it is recognized that some agencies have developed plans using other formats that meet the A-130 requirements described in this document. This document is intended as guidance only and should not be construed as the only format allowed. A standardized approach, however, not only makes the development of the plan easier by providing examples, but also provides a baseline to review plans. The level of detail included within the plan should be consistent with the criticality and value of the system to the organization's mission (i.e., a more detailed plan is required for systems critical to the organization's mission). The security plan should fully identify and describe the controls currently in place or planned for the system.
- DoD Instruction 5200.40, E188.8.131.52:
The System Security Authorization Agreement (SSAA) is intended to reduce the need for extensive documentation by consolidation of security related documentation into one master document. That eliminates the redundancy and potential confusion as multiple documents describe the system, security policy, system and security architecture, etc. When feasible, the SSAA can be tailored to incorporate other documents as appendices or by reference to the pertinent document. An outline of the SSAA is found in enclosure E6.
- US Department of Defense (DoD) 8510.1-M, DoD Information Technology Security Certification Accreditation Process (DITSCAP), C3.1.2:
Phase 1 tasks define the C&A level of effort, identify the principal C&A roles and responsibilities, and culminate with an agreement on the method for implementing the security requirements. This agreement is documented in the SSAA. The SSAA also describes the applicable set of planning and certification actions, resources, and documentation required for the C&A. The SSAA outline, Appendix 1, lists information that should be included.
- Director Central Intelligence Directive (DCID) 6/3 states in Appendix C:
C.A This appendix provides Information System Security Officers (ISSOs) an annotated outline for preparing System Security Plans (SSP) that includes the necessary overviews, descriptions, listings, and procedures that help meet the requirements contained in this document. ISSOs may modify the outline as necessary to address the unique characteristics of specific systems, including creating additional subtitles to accommodate any information that does not appropriately fit less than one of those subsections provided. This outline is not directive in nature; the contents and format of the SSP are at the discretion of the Designated Approving Authority (DAA).
References to the DITSCAP Instruction and Application Manual are used as examples only, as it has been replaced with the DoD Information Assurance Certification Accreditation Process (DIACAP) SIP document.
When an organization or a person(s) prepares to conduct a C&A, the first step is to decide which process to follow, if any. The process selected to do a C&A provides only a generalized format for supporting documentation.
It is interesting to examine the processes that have been developed over the years by various groups to display the methodology of protecting an information system. These processes are:
- NIST Special Publication 800-18
- DoDI 5200.40, DITSCAP, July 2000
- DoD 8510.1-Manual (M) DITSCAP Application Manual
- US Air Force Instruction 33-202, 30 September 2004, Communications and Information, Computer Security
- DCID 6/3 (Administrative Update May 2002 edition cancels May 1998 edition)
- NIST Special Publication 800-37 (cancels Federal Information Process Standards [FIPS] 102)
(no established format)
- NSTISSC National Information Assurance Certification and Accreditation Process (NIACAP) 1000, dated April 2000
- Joint DoD Intelligence Information Systems (DoDIIS)/Cryptologic SCI Information Systems Security Standards (JDCSISSS), dated 11 April 2003, revision 3
- DoDIIS Security Certification and Accreditation Guide, dated April 2001, DS-2610-142-01
- Interim DIACAP, dated July 2006
This is only a partial listing of available CAPs; every federal agency has its own process or follows one used by another agency. For example, the DoD follows the DIACAP (the application manual has not been issued at the time of this article); the Intelligence Community varies from the DS 2610- 142-1 (DoDIIS) to the JDCSISSS to the DCID 6/3 (DCID 6/3 Annotated); and the Air Force has its own version, Air Force Instruction 33-202.
This collection of various CAPs is much like walking down the up escalator. When each process is lined up next to each other process, the gradual lengthening of the process due to the additional information requirements in the next process is evident. Like the escalator, if one steps to the next processes, it pushes back because more information is required to fill the void left by the previous process.
In May 2004, NIST published NIST SP 800-37 “Guide for the Security Certification and Accreditation of Federal Information Systems.” What is most interesting to note is that this publication replaced the FIPS 102. The 102 had an established format for the SSP and an established process to follow; however, the 800-37 has an established process to follow (DoDI 5200.40) but has no established format in which to list information for the C&A packet. As previously noted, each organization is left to devise its own format.
C&A is much like a tornado; from the top, there is a big opening from which a huge effort is thrown into the funnel cloud to accredit the information system. As it gets closer to the ground, less effort is used to maintain the documentation of the information system until such time as it meets the ground and the old system is discarded for the new system. C&A is an ever-evolving tornado that is in constant motion from updating hardware and software to installing patches to protect the system from unscrupulous people who wish to do harm. As an evolving process, C&A must also evolve into a more simplified process. However, this process cannot be simplified unless people learn to share their information with each other.
The publication of the DIACAP shows intelligence in trying to ease the process by streamlining the overall process, but still fails to show the process of connecting two information systems to form a more robust network. The DIACAP is necessary in showing how to consolidate the documentation for connectivity, but the DoD will still have to produce much of the same documentation found in the DITSCAP. The DIACAP has a hidden requirement in paragraph E3.3.1 that requires a CNDSP rating for an approval to operate. This rating is based on the evaluation of the Evaluators Scoring Matrix, based on an analysis of 120 questions with two sections for the provider and the system user. These two sections have more than 600 bullets relating to the various references listed at the bottom of each question.
The longevity of C&A is now at such a stage that it is clear that a single process needs to be defined and managed by a single federal source. This federal source must have the responsibility for identifying the necessary components of the process and the authority to investigate violations and levy fines against agencies that violate or misuse this process.
Experience has shown that C&A is a confusing process that grows exponentially as time progresses due to untrained and inexperienced personnel. Without a standardized process and shared information in preparing C&A documentation, no single organization will be able to properly accredit its information system.
1 P.L. 100-235 has been superseded with the publication of FISMA.
2 The NSTISSC has been restated as the Committee for National Security Systems (NSS). This committee has roughly 22 voting members and about 50 attending federal agencies and departments.
3 NSTISSC, National Information Systems Security (INFOSEC) Glossary, NSTISSI (Instruction) No. 4009, September 2000
4 US Federal Information Security Management Act of 2002
has more than 30 years of experience in supporting various security functions, as a federal employee with the Department of the US Navy and Department of the US Air Force and as consultant with Booz Allen Hamilton, Northrop Grumman, Beta Analytics Incorporated (BAI), Xacta Corp. and Computer Science Corp. He has supported various federal agencies such as the DoD, US Army, US Navy, US Air Force, Department of Homeland Security, Department of Justice, Library of Congress, Federal Aviation Administration and other federal agencies in creating and maintaining C&A documentation. He has also prepared various threat and risks assessments.
Information Systems Control Journal, formerly the IS Audit & Control Journal, is published by the ISACA. Membership in the association, a voluntary organization of persons interested in information systems (IS) auditing, control and security, entitles one to receive an annual subscription to the Information Systems Control Journal.
Opinions expressed in the Information Systems Control Journal represent the views of the authors and advertisers. They may differ from policies and official statements of the Information Systems Audit and Control Association and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors' employers, or the editors of this Journal. Information Systems Control Journal does not attest to the originality of authors' content.
Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articles owned by the Information Systems Audit and Control Association Inc., for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.