CHAPTER 11:
C&A IN THE US DEPARTMENT OF DEFENSE
The DIACAP policy is a very critical policy that will set in place a transformative process for having enterprise certification and accreditation…DIACAP is a very important bedrock policy as we move in a net-centric fashion.100
Bob Lentz, Director of Information Assurance, DOD CIO/ASC NII
In this chapter:
Introduction to the DIACAP
DIACAP governance
The DIACAP roadmap
DIACAP support tools
C&A and the DOD components
In the preceding chapters, we provided you with a generic approach to the information system authorization process – one that could be used in federal agencies, the DOD, or even in the commercial sector. In the next few chapters you will notice similarities between elements of the generic process and the individual processes currently being used in different parts of the federal government. You will also notice the differences. So, let’s start with the processes used in the US DOD.
The US Department of Defense (DOD) took the lead in the early 2000s in recognizing the need for a certification and accreditation process that embraced the new and emerging technologies and that considered the ever-increasing levels of interconnectivity. It also had to be a C&A process that aligned more directly with the system (development) life cycle.
The result was the development and publication of the Department of Defense Information Assurance Certification & Accreditation Process (DIACAP), which was signed into effect in November 2007. The DIACAP replaced the earlier methodology, known as the DOD Information Technology Security C&A Process (DITSCAP).
The DITSCAP had long been viewed as onerous and overly resource intensive – particularly when considered in light of the real security benefits emerging from the process. The primary differences between the DITSCAP and DIACAP are:
The DIACAP is aligned to the system life cycle and supports the way DOD acquires and builds information technology.
The DIACAP improves compatibility and reciprocity with C&A processes in the federal and intelligence communities.
The DIACAP represents a focus shift from securing the individual system to supporting security of the enterprise.
The DIACAP provides both the content and tools to enhance consistency, standardization, and repeatability as well as re-use of C&A products.
The On Cyber Patrol© cartoon and supporting articles are created and made available by the US Army’s Office of Information Assurance and Compliance, NETCOM, CIO/G6.
For the purpose of our discussion in this chapter, we will use terminology that is current in the DOD, some of which represents a deviation from that used elsewhere in the book and in federal agencies. So, here is a quick translation of the terms we will use:
Certification and accreditation (C&A) process instead of authorization process.
Information assurance (IA) control instead of security control.
Designated accrediting authority instead of approving official.
Certifying agent instead of security controls assessor.
Introduction to the DIACAP
The fundamental security requirements for DOD information systems are expressed in the form of graded baseline IA controls (called security controls in federal agencies.) The IA controls for a management framework for the implementation, verification, and monitoring of information systems security are consistent with the federal requirements of OMB A-130.
DODD 8500.1, Information Assurance, defines an IA control as an objective IA condition of integrity, availability, or confidentiality achieved through the application of specific safeguards or through the regulation of specific activities. Selected management, personnel, operational, and technical controls are applied to each DOD information system to achieve an appropriate level of integrity, availability, and confidentiality.
The IA controls serve as a common management language for expressing information system security and protection requirements. They also lay a foundation for a shared security dialogue between information owners, program managers, service providers, network and enclave managers, certifying and accrediting authorities, and information system security engineers.
The IA controls and how to use them
DOD’s IA controls are found in DODI 8500.2, Information Assurance Implementation. They provide the fundamental IA requirements for securing DOD information systems. Unlike the security categorization process described earlier, DOD information systems base their IA controls selection on a determination of mission assurance category (MAC) and confidentiality level (CL).
Table 28: MAC & CL
|
Requirement |
Description |
Security focus |
|
Mission assurance category (MAC) |
Criticality of the information system to the component; need for availability of the information system to support the mission |
Availability and integrity |
|
Confidentiality level (CL) |
Criticality of the information’s protection to the mission |
Confidentiality |
There are a total of 157 individual IA controls, from which the baseline set of assigned IA controls is derived. Each IA control describes an objective security condition which can be attained through the implementation of specific technical safeguards or through the use of specified procedures.
The IA controls also provide a common language for expressing IA needs and status. The use of a standard language for information systems security enables a dialogue among DOD information owners, managers, C&A authorities, and others.
Determining mission assurance category
There are three levels of mission assurance category based on the information system’s need for availability and integrity.
Mission assurance category I (MAC I) is assigned to information systems determined to be vital to the operational readiness or mission effectiveness of deployed and/or contingency forces. The consequences of a loss of integrity or availability would be unacceptable and could result in the immediate and sustained loss of mission capability. MAC I information systems are subject to the most stringent protective measures.
Mission assurance category II (MAC II) is assigned to information systems which are considered important to deployed and/or contingency forces. Consequences of a loss of integrity are unacceptable. Loss of availability would be difficult to manage and could only be tolerated for a short period of time. The consequences could include a delay or degradation in providing important services and could seriously impact mission effectiveness or operational readiness. MAC II information systems require additional safeguards that extend beyond best practices.
Mission assurance category III (MAC III) information systems handle information necessary for the execution of DOD’s day-to-day business functions, but do not directly or materially affect deployed and/or contingency forces in the short term. Consequences as a result of a loss of integrity and/or availability are tolerable or could be overcome without significant impact on mission effectiveness or operational readiness. Consequences could include the delay or degradation of services or commodities associated with routing DOD activities. MAC III information systems require protective measures commensurate with commercial best practices.
Table 29: Mission assurance category
Determining confidentiality level
In the DOD, the confidentiality level (CL) is primarily used to establish acceptable access criteria for the information system and its information. It is based on the consideration of requirements, such as security clearance, access and need-to-know requirements.
There are three CLs:
Classified, which is assigned to a DOD information system processing any level of classified information.
Sensitive, which is assigned to a DOD information system processing information whose loss, unauthorized access to, or misuse of could adversely affect the national interest, federal programs, or individual privacy. This is unclassified information which should not wind up on the front page of The Washington Post or any other national newspaper. Examples include financial, logistics, or medical information.
Public information refers to content which has been reviewed and approved for public release by a cognizant authority and/or the information owner. The primary regulatory guideline for the release of public information is DOD Directive 5230.9, Clearance of DOD Information for Public Release, current as of July 1999.
Table 30: Confidentiality level
|
Definition |
Confidentiality level |
|
Information system processing CLASSIFIED information. |
CLASSIFIED (HIGH) |
|
Information system processing SENSITIVE information or unclassified information that has not been cleared for public release. |
SENSITIVE (MEDIUM) |
|
Information system processing PUBLIC information or unclassified information that has been specifically cleared for public release. |
PUBLIC (BASIC) |
Selecting the IA control set: Putting MAC and CL together
Assigning the appropriate MAC and CL to information may not be quite as easy as it seems. Well, assigning the CL is usually fairly straightforward. Information is either classified or not; information can either be released to the public or not.
Quantifying requirements for availability and integrity may not be quite as simple. This is usually based on a rather subjective risk assessment based on the information system’s operating environment.
Generally, most organizations have at least a general idea of the target operating environment for an information system. A risk-based assessment of this target environment will usually provide the type of information needed to make a valid decision about information and mission integrity and availability requirements. For example, an information system that supports the warfighting environment would usually have higher availability and integrity requirements than one intended for use only as an office administration system.
The following diagram provides a matrix for assigning the MAC and CL. In this particular example, the information system in question processes classified information (=CL CLASSIFIED), has a high integrity and a medium availability requirement (= MAC II). In order to determine the baseline list of IA controls for this information system, you would refer to DODI 8500.2, Information Assurance:
CLASSIFIED information: the IA controls are listed in Enclosure 4, Attachment 4
MAC II: the IA controls are listed in Enclosure 4, Attachment 2.
Figure 21: Matrix for assigning MAC and CL
Source: Adapted from DIACAP Knowledge Service
IA control subject areas
While the NIST SP 800-53 talks about controls in terms of “families,” DOD refers to IA control subject areas. The set of IA controls contained in DODI 8500.2 is organized into eight subject areas, which indicate the major subject or focus area of a specific safeguard or countermeasure. The following table shows how the IA controls are organized by subject area.
Table 31: IA control subject areas
As you can see, similar to the security controls specified under NIST, the DOD controls are also categorized as management, operation, or technical controls.
Management controls focus on the management of risk or information system security. These can refer to policies and regulations intended to protect technical environments, information and information system resources, and to guide personnel behaviors. These include security controls addressing areas such as:
• Risk management: the process of identifying, measuring, and minimizing or reducing security risk to information and information systems. You will note that risk management is a fundamental process within the execution of the C&A process, as well as an individual IA control.
• Annual reviews: under OMB Circular A-130, security controls must be reviewed annually and reports generated.
• Life cycle planning: includes the management process for phasing in of new components and phasing out of old, as well as changes in technology, mission or acquisition process.
Operational controls focus on the day-to-day execution of the activities related to the implementation and maintenance of the security safeguards. Examples of operational controls include:
• Personnel security: more often than not, the greatest harm or disruption to an information system is a result of the intentional or unintentional actions of individuals. The operational controls focused on personnel are intended to reduce the human potential for damage to the system or the information.
• Physical security: controls focus on access to and protection of the environment.
• Contingency planning: describes the mechanisms needed for the recovery of data and/or information systems in the event of a disruption.
• Security training: a mandatory requirement under the Computer Security Act. Initial, refresher, awareness and job-specific security training are considered essential.
• Incident response: refers to those procedures needed to ensure an incident response capability.
Technical controls describe safeguards focused on protection of the hardware, software, and firmware, as well as boundary defense for the information system. Examples of technical controls include:
• Identification and authentication: technical measures that prevent unauthorized personnel and/or processes from accessing an information system.
• Auditing: the means to maintain a record of system activity by system or application processes and by user activity.
IA control naming convention
Each of the IA controls is uniquely named and catalogued, which allows it to be referenced, measured, and reported against throughout the life cycle of the information system to which it is applied. Each unique name is composed of several elements:
IA control subject area – indicating which one of the eight groups to which the control is assigned.
IA control name – a brief phrase with a high level reference to the nature of the individual control.
IA control number – provides a quick reference to the control as well as an indication of the level of robustness for the IA control. There are three levels of robustness and the higher the number, the more robust the requirements of the control (e.g. a 3 would indicate the highest level of robustness.)
The diagram below provides an example of DOD’s IA control naming convention.
Figure 22: IA control naming convention
Source: Adapted from DIACAP Knowledge Service
In this particular example, the subject area is security design and configuration, the IA control is compliance testing, and the level of robustness is 1, or the lowest level of the safeguard. There will be more detail about assigning the IA controls in the section on DIACAP stages or activities.
DIACAP governance structure
DOD has established a DIACAP governance structure that is intended to manage and integrate DIACAP relevant activities across all levels of the DOD (e.g. agencies, services, mission areas) and events across the system life cycle (e.g. concept, development, deployment, and operations). There are three primary components of the governance structure:
An accreditation structure
A C&A configuration management structure
C&A process structure.
Figure 23: DIACAP governance structure
Source: Adapted from DODI 8510.01
The accreditation sub-structure
Principal accrediting authorities (PAA) are appointed for each of the global information grid (GIG) mission areas (MA).101 The PAAs have the authority to directly appoint a DAA for information systems that directly support their respective mission area and the associated community of interest (COI).
The Defense Information Systems Network (DISN) flag panel acts on behalf and in support of the PAAs. The panel advises the PAAs, has a role in assessing enterprise risk, authorizes information exchanges, and approves proposed changes to the DOD IA control baseline.
The Defense IA Security Working Group (DSAWG), which is under the DISN flag panel, serves as the community forum for reviewing and resolving any C&A decisions and considering the risk to the community of operating an information system. The DSAWG also develops and provides guidance to DOD DAAs on connecting their information systems to the GIG.
Configuration control and management sub-structure
The DIACAP Technical Advisory Group (TAG) provides detailed analysis and authoring support for the enterprise component of the DIACAP Knowledge Service. The TAG interfaces with the DOD components102, mission areas, IA COIs, and other specialized entities to address issues that are common to all DOD agencies.
The TAG is represented in the DIACAP Knowledge Service. The DIACAP Knowledge Service provides the forum and the structure for the TAG’s functions and activities, including: authoring, voting, membership, and configuration control of the IA controls and their content.
101 The GIG MAs are: business mission area, intelligence mission area, warfighting mission area, and enterprise information environment mission area.
102 A DOD component is defined as a service, agency or combatant command.
C&A process sub-structure
The DOD senior information assurance officer (SIAO)103 directs and coordinates the DOD IA program. Each of the DOD component SIAOs has authority and responsibility for certification and serves as the certifying authority (CA) for all of the information systems assigned to or governed by the DOD component CIO and supporting IA program.
Each CA may task, organize, staff, and centralize or delegate certifying activities – and you will find that each DOD component approaches this very differently. Regardless of the adopted model, the DOD component’s SIAO bears the final responsibility for certification quality, capacity, visibility, and effectiveness.
In addition, each DOD CIO, supported by an appointed SIAO, has overall responsibility for administration of the overall C&A process. This includes:
the integration of certification with all of the other DIACAP activities;
participation in the DIACAP configuration management process;
visibility and sharing of the C&A status of assigned ISs;
enforcement of training requirements for persons participating in the DIACAP;
support to DAAs; and
responsiveness to the DOD CIO.
The information assurance senior leadership (IASL) serves as a community forum for assessing and improving C&A process administration. The IASL, which represents and supports the SIAOs, provides strategic direction and guidance to ensure that IA is integrated across the DOD. It provides for the integrated planning, coordination, and oversight of DOD’s IA programs.
This high-level DOD governance structure is supported by a number of other roles and responsibilities at the DOD component
level. With the exception of the unique role of the PAA, the following roles are very similar to those described in Chapter 5. The following table lists the DOD roles and their respective appointment/delegation authorities.
Table 32: DOD roles
|
DOD C&A role |
Appointed/delegated by |
|
PAA |
Mission area owner |
|
DAA |
DOD component head; PAA for MA-managed information systems |
|
CIO |
DOD component head |
|
SIAO |
DOD component CIO (or in organizations where a CIO does not exist, by the DOD component head)104 |
|
CA |
SIAO usually serves as the CA, but may delegate the CA role as required |
|
IAM |
Program/system manager |
|
IAO |
IAM |
|
User representative |
Information owner |
|
DIACAP TAG representative |
DOD component SIAO or CIO |
A DIACAP roadmap (guide to the stages or activities)
Certification and accreditation of DOD information systems consists of a series of activities or stages and tasks, which may even occur concurrently or at varied frequencies throughout the system
life cycle. To the greatest extent possible, the DIACAP parallels the system life cycle.
Ideally, it should be initiated at system inception (e.g. documented during capabilities identification or at the implementation of a major system modification). But note, failure to initiate the DIACAP process at system inception does not mean that you cannot bring the information system into compliance later in the life cycle. However, the earlier the DIACAP is initiated in the system life cycle, generally the implementation of IA services and safeguards will be less expensive and problematic.
Figure 24: DIACAP stages or activities
Source: Adapted from the DIACAP Knowledge Service
This diagram depicts the various stages or activities of the DIACAP. We will now discuss each of these in additional detail.
Initiate & plan IA C&A
Initiation and planning for the certification and accreditation process is the first stage or activity in the DIACAP. In involves the following sub-activities:
Register system with the DOD component IA program.
Assign IA controls.
Assemble the DIACAP team.
Initiate the DIACAP implementation plan.
Let’s talk more about each of these individual sub-activities.
Register the information system with the DOD component IA program
In the requirements of the DIACAP, registration of the information system ensures that the system is “visible” to the DOD CIO/SIAO and to the governing component’s information assurance leadership. Once an information system is visible, certain management indicators (e.g. C&A status) and FISMA requirements can be more effectively monitored.
The process of registration starts the C&A process between the DOD information system and the responsible elements within the DOD component. These are usually the DOD component’s CIO and SIAO. A dialogue regarding requirements and implementation starts with registration and – hopefully – continues until the information system is decommissioned.
There are several events that can start this conversation:
A new information system development or acquisition has been started and the C&A process is initiated at the same time (the ideal situation!).
A new information system is being deployed and requires C&A.
An existing information system is discovered to have no authorization to operate.
An existing information system has an expiring authorization to operate.
As discussed earlier, there are many ways in which an information system can be registered. The overall DOD registry is called the DOD Information Technology Portfolio Repository (DITPR). The DITPR was designated as “the Enterprise Shared Space for IT Portfolio Management data for all DOD business IT systems” by the DOD deputy CIO on March 17, 2005. The DITPR is also used as the official unclassified DOD data source for FISMA, e-authentication, portfolio management,105 privacy impact assessments, and the inventory of all mission critical/mission essential/mission support systems. Even though each of the DOD components has its version of an IT portfolio management system, they must be able to automatically populate information about their systems into the DITPR. Each DOD component also has an agency that controls these databases, for example, the Air Force has the Air Force Communications Agency (AFCA), and the Army has the Installation Management Agency (IMA).
Figure 25: DOD Information Technology Portfolio Repository (DITPR) Connections
105 Portfolio management is the management of selected groupings of IT investments using strategic planning, architectures, and outcome-based performance measures to achieve a mission capability.
The Air Force’s version is the Enterprise Information Technology Data Repository (EITDR). EITDR is used to keep track of new information system acquisitions, new DOD compliance mandates, information technology program management and system engineering documentation. In support of C&A in the Air Force, EITDR also contains a function called security, interoperability, supportability, sustainability and usability (SISSU) for all applicable systems.
The Army Portfolio Management System (APMS) is the Army’s IT portfolio management system. APMS is designated as the database of record for Army IT systems. The Army also uses APMS to monitor the C&A and FISMA reporting status of Army information systems.
The Navy uses the DITPR-Department of the Navy (DITPR-DON). DITPR-DON is the single, authoritative source for data regarding DON IT systems, including national security systems. It also has FISMA reporting requirements, and maintains the IT system inventory for compliance with congressional requirements. DITPR-DON is used as a repository for the C&A status of mission critical (MC), mission essential (ME), and mission support (MS) DON IT systems and networks.
The primary means used to initiate the DIACAP process and register the information system is the system identification profile (SIP). This relatively simple document contains the information gathered about the information system during the pre-registration and registration process. The SIP, which is one part of the DIACAP C&A package, is maintained throughout the system’s life cycle.
Much of the information contained in the SIP can be found in program documentation, system design documents, requirements specifications, and other documentation normally developed as part of a system acquisition or development.
System identification profile (SIP): The SIP is the first critical component of the DIACAP C&A package. You will use the SIP to provide information needed to clearly identify the information system, the C&A status and the life cycle status.
Several of the information items on the SIP are unique to the DOD C&A process; others are derived from external sources, such as the DITPR or the DOD component equivalent IT portfolio management tools.
So, let’s walk through completing the SIP. In order to keep it manageable, we’ll break it down into sections. NOTE: A SIP template is available on the CD accompanying the book. We’ll look at each entry in detail in the table below, which provides the guidance for entering information into that block.
Table 33: Completing the SIP
106 Conditional – information will be entered if applicable and available for the information system.
Assign the information assurance controls
Assigning the appropriate IA controls is arguably one of the most important activities in the DIACAP – as well as in any of the C&A processes. Determining the IA controls is a pre-requisite for execution of the follow-on step in the DIACAP activities, the development of the DIACAP implementation plan. The following diagram will take you through the IA controls assignment process.
Figure 26: IA controls assignment process
Source: Adapted from the DIACAP Knowledge Service
Here is a condensed overview of the process. Using DODI 8500.2, Information Assurance Implementation, as guidance, define the type of information system scheduled to undergo the C&A process. Frequently, the type of information system will influence the MAC and CL, inheritance factors, additional control sets, and ultimately, the selection of controls.
As discussed earlier, DODI 8500.2 defines three DOD mission assurance category levels with associated requirements for availability and integrity. DOD also provides guidelines for determining the confidentiality level.
Once the MAC and CL for the IS have been identified, the initial IA controls baseline can be easily determined. Basically, the initial IA controls baseline is an unrefined, combined list of all of the IA controls associated with the MAC and CL for that IS.
It is important to note that this baseline list of IA controls is not considered final. Further analysis is still required.
First, you will determine which controls are inherited from other information systems or from the environment.
Next, determine which IA controls are not applicable to this information system.
Identify any additional requirements, such as privacy or protections required to interconnect with other information systems.
Only after you have completed this analysis, will you have a final set of IA controls. But wait – you still are not done. Before starting on the implementation of the IA controls, be sure to obtain approval from the DAA and the system owner. Once this process has been completed, you can assemble the DIACAP team and develop the DIACAP implementation plan.
Assigning the DIACAP team
While this is the next “official” step in the DIACAP activities, we believe that your DIACAP team should be largely assembled long before reaching this stage. But if you have not yet determined the structure of your team, this is a good time to finalize this action.
At a minimum, the DIACAP C&A team should consist of:
Designated accrediting authority (DAA)
Senior information assurance officer (SIAO)
Certifying authority (CA)
Program manager/system manager (PM/SM)
Information assurance manager (IAM) or information assurance officer (IAO)
User representative (UR).
Descriptions of these roles and their associated responsibilities can be found in Chapter 5. The members of the DIACAP C&A team should be trained and certified according to the requirements of DODD 8570.01, Information Assurance Training, Certification, and Workforce Management, current as of April 2007.
When you are determining the members of the DIACAP C&A team, keep in mind that DOD has established some allowable and unallowable relationships between the team members. The table below shows these relationships:
Table 34: Allowable/unallowable relationships in C&A team
|
Relationship |
Allowed (YES or NO) |
|
PAA may be DAA |
YES |
|
DAA reports to the PM, SM or program executive officer (PEO) |
NO |
|
DAA and CA are the same individual |
YES |
|
CIO may be the DAA |
YES |
|
CA reports to the DAA |
YES |
|
CA reports to the PM, SM or PEO |
NO |
|
PM , SM, or CA report to the DAA |
YES |
|
PM, SM, or CA may be the same individual |
NO |
|
PM, SM or DAA may be the same individual |
NO |
|
PM, SM, or UR may be the same individual |
NO |
Develop the DIACAP implementation plan
The DIACAP implementation plan (DIP) illustrates the strategy for implementation, along with the current implementation/compliance status of the IA controls assigned to the IS. The DIP is the second element in the DIACAP C&A package. At a minimum, the DIP should contain the following information:
Assigned IA controls: This is the final list of all IA controls for that IS. The list can be organized by sub-entities of the DOD IS (e.g. site, subsystem, service, or set of services). NOTE: While only the IA control number is required in this column, it is often useful to include the name of the IA control.
Implementation status: Each listed IA control should also be designated as applicable, not-applicable, or inherited. If the IA control is inherited, specify HOW the inheritance occurs (e.g. enclave firewall, physical security measure, personnel security program, etc.).
Responsible entities: Identify the element or individual responsible for the implementation of the specific IA control. There should be a responsible entity for each control, although one entity may be responsible for more than one IA control.
Resources: This is where you would indicate the personnel, material, or financial resources needed to successfully and completely implement a particular IA control. You should have an entry for each control; however, it is useful to combine IA controls to minimize the resource requirements or to logically organize the implementation of the IA control.
Estimated completion date: You should enter an estimated completion date for each IA control. Again, you may be able to consolidate resources to more effectively implement the IA controls with a combined completion date.
Comments: Use this column to enter any comments relevant to the implementation of an IA control.
The following diagram is an example of a completed DIACAP implementation plan (DIP). Before proceeding to the next stage in the DIACAP, implement and validate IA controls, it is critical to obtain the approval/concurrence of the involved parties in the DIP. This includes the assigned DIACAP team, as well as any external entities or individuals participating in the IA control implementation and/or testing process.
Figure 27: DIACAP implementation plan
Implement and validate assigned IA controls
In the first DIACAP stage or activity, you should have established your C&A team, completed the initial version of the system identification profile (SIP), and assembled the list of required IA controls on the DIACAP implementation plan (DIP). Additionally, all of the required approvals for the SIP and DIP should have been obtained. If yes, then your information system is ready for the IA controls to be implemented and subsequently tested for compliance. Prior to starting the implementation process, determine which entity(-ies) will be responsible for an IA control, or perhaps even several IA controls. It is best to do this as early in the process as possible to ensure availability of required personnel, materiel support, or funding.
Figure 28: IA control components
Source: Adapted from the DIACAP Knowledge Service
It is also a good idea to make sure that arrangements have already been initiated for the validation testing. The CA is part of the DIACAP team and should already have been notified, but now is a good time to confirm their availability for the estimated completion date. This will help you to avoid delays – particularly since most CAs and their staff are extremely busy.
Finding implementation and validation test guidance
The DIACAP Technical Advisory Group (TAG) is responsible for maintaining standardized implementation and testing guidance for each of the IA controls. The anatomy of an IA control and its elements is shown in the diagram below.
Implementation guidance is supported by a high-level set of standards for executing the IA control. The guidance is supplemented with a list of resources, such as other related publications or tools, in the “system-specific resources” area.
The documentation on validation test criteria or procedures includes a statement regarding the objectives of the validation test, a series of steps to prepare for the test, the test procedures themselves, and DOD’s expected minimum results. There is a one-to-many relationship between the IA controls and the validation tests, e.g. one IA control may require several discrete tests to ensure that all elements of the IA control are adequately validated for compliance.
Just a note of caution: if you are seeking very specific implementation or validation test guidance – you won’t find it here. The standardization information has been developed intentionally at a very high level to ensure that it can be applied to multiple types of information systems and within multiple environments. It is the responsibility of the owning organization to tailor the guidance to fit their particular requirements.
There is an IA controls explorer on the DIACAP Knowledge Service: https://diacap.iaportal.navy.mil/ks/Site%20Pages/IA%20Controls/IA.4.0.aspx where the most current guidance for the IA controls can be found. We recommend checking the explorer prior to starting any implementation to make sure that you have the most current information. The DIACAP Knowledge Service maintains a change log, so you can always track any changes to an IA control.
Execute the DIACAP implementation plan
As mentioned above, the DIACAP Knowledge Service is your primary source for information about implementing IA controls. There are also other resources that can assist in the process. These include the Security Technical Implementation Guides (STIG) published by the Defense Information Systems Agency (DISA).
STIGs are essentially configuration guides for DOD information systems and associated IA and IA-related devices. DISA also publishes Security Checklists, which can serve either as an implementation guide or as a checklist to evaluate compliance with a baseline level of security.
The STIGs, Security Checklists and other valuable resources can be found at DISA’s Information Assurance Support Environment (IASE) website at http://iase.disa.mil/stigs/index.html .
As the IA controls are being implemented, evidence can be developed and retained. In DOD, evidence is referred to as artifacts. Artifacts can be the direct result of IA control implementation, such as the establishment of a password policy. They can also be generated as a part of normal system development, such as configuration management processes. Here are some examples of artifacts:
System policies, such as the IT contingency plan which includes processes established to meet the requirements of COAS-1, alternate site.
System documentation, such as the software inventory developed during the configuration management process, which meets the requirements of DCSW-1, software inventory.
Test results, such as those generated during a vulnerability scan and which meet the requirements of IA control VIVM-1, vulnerability management.
Artifacts provide the tangible evidence of an IA control’s implementation. As they are developed, they should be referenced in the DIACAP implementation plan. It is usually not necessary to create a separate document describing the evidence and to attach it to the DIP. But it is useful to reference the artifact, the date of the most current version, and where the artifact can be found in the comment section on the DIP.
Conduct validation activities
Validation testing, or IA controls compliance verification, is the next step in the DIACAP process. It includes all of the tasks related to the execution of the validation tests.
As mentioned above, one or more validation procedures have been developed for each IA control and the most recent procedures are posted on the DIACAP Knowledge Service. These procedures provide guidance on preparing for the validation test, executing the test with test steps, and the expected results. The descriptions may include background material, sample results, and links to automated testing tools.
Although DOD provides the basic guidelines for validation testing, variations in the test procedures may be needed based on system configuration, location, and environment. Some of the testing procedures are largely manual, requiring the direct participation of an individual to initiate the test and collect the results. Other tests may be highly automated and the results will be automatically generated. Regardless of the type of testing, the individuals conducting the test procedures should have security and information system knowledge, such as network security, firewalls, intrusion detection systems, and operating systems.
Using the DOD baseline validation tests – and only modifying as required – ensures that:
There is standardization of the minimum baseline test plans for all DOD information systems.
All of the IA controls for an information system are tested to a consistent standard.
There is a common expectation of test results.
There is a standard language for expressing the results and sharing them, as required.
While validation testing can be conducted once all of the IA controls have been implemented, we have found that testing each IA control internally as we implement it can save both time and money. First, we see immediately if the implementation has been sufficient – and if not, we can take immediate remediation actions. Also, we may generate artifacts and test results that will be considered sufficient by the responsible certifying authority and/or the CA representative.
This is important to note. In most of the DOD components, IA controls validation testing is conducted by an independent CA on a cost reimbursement basis. If you can reduce the time and scope of the CAs test presence, you can also potentially minimize the time to authorization and the cost of testing.
Prepare the plan of action & milestones (POA&M)
The validation testing will provide a determination if an IA control is compliant or non-compliant. If any of the IA controls is determined to be non-compliant (or not applicable), a system level POA&M must be prepared.
Although FISMA mandates the POA&M as a reporting requirement, it is also:
an organization’s primary tool for tracking the mitigation of any security weaknesses in the information system and in the security program itself;
a tool to assist an Inspector General (IG) in the evaluation of an organization’s overall security performance; and
assists OMB in its oversight activities.
Once developed, the POA&M is a permanent record. And once a weakness is posted, it can be updated, but not removed, once corrective actions are completed. It is a living document and should be updated as weaknesses are mitigated or as new weaknesses are identified.
The members of the DIACAP Team have certain responsibilities in relationship to the POA&M:
Table 35: POA&M responsibilities
|
DIACAP team member |
POA&M responsibility |
|
DOD component CIO |
Monitoring and tracking the overall execution of the component’s system level POA&Ms until security weaknesses have been mitigated and the C&A documentation adjusted to reflect the changes. |
|
DAA |
Monitoring and tracking the execution of the system-level POA&Ms. |
|
PM/SM |
Implementing or overseeing the implementation of the corrective measures identified in the POA&M. |
|
IAM/IAO |
Assists the PM/SM in providing the POA&M status to the DAA, SIAO, and CIO. |
DOD IT POA&Ms share several characteristics:
Linked to the organization’s budget submission and links security costs with security performance.
Intended to address all weaknesses associated with an information system, including, but not limited to, those found during validation testing, IG inspections, audits, security tests, and vulnerability assessments.
Shared as required with the responsible IG.
Required to follow the mandated format provided by OMB and DOD.
Submitted to the DOD SIAO when required.
There are three types of DOD POA&Ms:
System level POA&M, which is a living document designed to be a tool to assist organizations in closing gaps in their security performance. It addresses the IA controls weaknesses from an individual information system.
Component level POA&M. DOD components are required to prepare and submit a DOD component level POA&M, which compiles the information from system level POA&Ms and systemic weaknesses identified across the DOD component.
DOD enterprise POA&M. The enterprise POA&M is a roll-up of the component level POA&Ms and includes system weaknesses identified across the enterprise.
Table 36: Types of DOD POA&M
For the purposes of this book, we will only focus on the system level POA&M. The system level POA&M has a very specific, mandated format. This format is tied to the annual requirements published by OMB and reflects authorized modifications due to specific DOD requirements. The instructions for the DOD POA&M process are developed and issued through the DOD FISMA integrated process team (IPT). The following figure (provided by the DIACAP Knowledge Service as a sample) shows a completed system level POA&M.
Figure 29: System level IT security POA& M example
Let’s look at each column and the information required.
Table 37: POA&M information requirements
|
Column |
Required information |
|
1 |
Type of weakness: Use this column to describe the identified security weaknesses. DOD has provided a set of approved weakness statements, one for each IA control, on the DIACAP Knowledge Service. This input cannot be changed. |
|
2 |
CAT or severity code. This is the code assigned by the CA to a security weakness to indicate the risk level associated with the weakness and the urgency with which the weakness must be corrected. They are expressed as CAT I (greatest risk and urgency), CAT II (moderate risk and urgency), and CAT III (least risk and urgency). In most cases, POA&Ms with CAT I weakness must be protected and possibly classified. Additional detail on the severity codes is provided below. |
|
3 |
IA control and impact code. This is the number of the IA control associated with the identified weakness and the associated impact code assigned by DOD. |
|
4 |
Point of contact (POC). Identity of the entity that the DOD component will hold responsible for correcting the weakness. |
|
5 |
Resources required. Estimated funding and/or manpower required to correct the security weakness. Enter NA for a CAT III weakness that the DAA has accepted. |
|
6 |
Scheduled completion date. Estimated date for resolving the security weakness. This date cannot be altered. If a security weakness is corrected either before or after the scheduled completion date, the organization should enter the actual date of completion and the status in the status column (10). Enter NA for a CAT III weakness that the DAA has accepted. |
|
7 |
Milestones with completion dates. Identify the individual requirements essential to resolve a security weakness with estimated completion dates for each requirement. This input cannot be altered. Any changes to the milestones should be noted in column 8, milestone changes. Enter NA for a CAT III weakness that the DAA has accepted. |
|
8 |
Milestone changes. Include changes to the milestones with completion dates, including the new date and the reason for the change. Enter NA for a CAT III weakness that the DAA has accepted. |
|
9 |
Source identifying the weakness. The source could be the formal validation test, an IG inspection, audit, or any other means. This input cannot be changed. |
|
10 |
Status. This must be indicated in the following terms: ongoing, completed, or risk accepted (for a CAT II or CAT III weakness accepted by the DAA). Completed applies only when a weakness has been fully resolved, tested, and validated. Include the date of completion or the date risk accepted for a CAT III weakness, together with the statement “risk accepted by the DAA.” |
|
11 |
Comments. Use this column for any additional information needed to clarify the IA control status. For example, if an IA control is inherited, indicate the originating IS. If NA is used for an IA control, provide the justification here. Issues in the resolution of a weakness (e.g. lack of funding, lack of personnel expertise) can be entered here. |
Since the POA&M describes security weaknesses in some detail, the information contained on the document can be quite sensitive. Care should be taken to avoid any sensitive or classified descriptions, but the information provided should be sufficient to permit oversight and tracking. Where it is impossible to avoid sensitive or classified content, the POA&M should note the sensitivity and classified accordingly. In some cases, there may be an unclassified POA&M which provides only high-level data and a reference to the location of the more complete classified or sensitive POA&M.
Compile validation results in the DIACAP scorecard
The results of the validation testing and the review of the associated artifacts should be a matter of record and a permanent part of the C&A package. The detailed results are maintained on file along with the artifacts generated during the validation process, e.g. output from the automated test tools or screen shots depicting certain system configuration aspects.
There are four possible results of the validation testing process:
Compliant (C) – the control meets all of the requirements of the validation test and is fully compliant with the expected results. This means that each of the sub-validation tests has met all of the requirements of the IA control. If any of the tests related to an IA control in a one-to-many test relationship are not consistent with the requirements, then the entire control is not compliant.
Non-compliant (NC) – the control has been tested and has failed to meet the expected results, either fully or partially. NOTE: There is no category called partially compliant.
Not tested (NT) – the IA control was not tested at the time of the validation test due to life cycle status or for other operational or security reasons. A status of NT should be periodically reviewed to determine continued relevance.
Not applicable (NA) – the IA control was determined not to apply to this information system. A status of NA should be periodically reviewed to determine continued relevance.
The results of the validation testing are recorded on the DIACAP scorecard, one additional part of the DIACAP package. The scorecard is an executive-level summary of the validation test results used to convey the IA controls status of an information system.
An analogy can be made between the scorecard and a university transcript. Once a student has completed a course successfully (or unsuccessfully), the results are retained. If a student transfers to another university or wants to understand the compiled value of his/her studies, the transcript provides a medium by which the student’s university participation can be verified. The student does not have to provide copies of all tests taken, papers written, or books read to the other university in order for the transcript to be accepted.
The scorecard provides the medium by which IA controls compliance and weakness information can be shared, either with the authorizing official or with other organizations entertaining a possible connection to the information system.
The scorecard is a relatively simple document to prepare and maintain. The figure below shows a standard DIACAP scorecard. We will talk about each of the required entries in more detail.
Figure 30: DIACAP scorecard
Table 38: Instructions for completing the DIACAP scorecard
|
Scorecard reference |
Instructions for completion |
|
System name |
This is the name of the information system being certified and authorized for operation. |
|
System owner |
The organization/entity within the DOD component that owns, manages, or controls the IS. |
|
IS type |
This is the same as the entry on the SIP called IA record type. This will be enclave, AIS application, outsourced IT-based process, or platform IT interconnection. If it is an enclave, indicate whether it is a standalone network or a DMZ. |
|
DAA |
The name and signature of the designated accrediting authority. Manual or PKI-certified signatures are both acceptable. |
|
Accreditation status |
The authorization decision for the IS: ATO, IATO, IATT, DATO. |
|
Period covered |
Date of the authorization (unless the entry is unaccredited) and the authorization termination date (ATD). |
|
Last update |
This is the date of the most current change on the scorecard and is primarily driven by the IA controls and their updates. |
|
CA |
The certifying authority for the IS. |
|
MAC |
The determined mission assurance category for the IS. |
|
CL |
The confidentiality level applied to the IS. |
|
IA control subject area |
The subject area associated with the specific IA control. |
|
IA control number |
The reference number associated with the IA control. |
|
IA control name |
The specific name of the IA control. |
|
Inherited |
YES or NO indication of the inheritance status of the IA control. |
|
C/NC/NA (NT) |
Compliance status of the IA control (compliant, non-compliant, not applicable). Note: DOD does not specify the use of not tested, but this is a viable control status. |
Make certification determination & accreditation decision
At this point in the DIACAP stages or activities, you have probably completed most of the hard work necessary for obtaining the desired authorization to operate. The following DIACAP package elements have been developed:
System identification profile (SIP)
DIACAP implementation plan (DIP)
DIACAP scorecard
POA&M.
The next action in the DIACAP is for the certifying authority (CA) to review the validation test results, the associated artifacts, the scorecard, and make a certification determination.
Make certification determination
A certification determination is a pre-requisite to making an accreditation decision, so it is a very important part of the process. It represents the CA’s validation that the system is compliant with all of its security requirements, or IA controls.
In making the certification determination, the CA considers a number of factors:
The IA posture of the information system; the overall reliability and viability of the information system, as well as the acceptability of the implementation and performance of the security safeguards applied or inherent to the information system.
The behavior of the IS within the larger information environment, including whether or not the IS introduces vulnerabilities into the environment, interacts securely with the information environment and its services, is visible to situational awareness and network defense services.
An important part of the certification determination is based on an assessment of the risk of operating the information system. This assessment is expressed via impact codes and severity categories.
Impact codes are assigned to the IA controls by DOD and maintained by the DIACAP TAG. They represent DOD’s enterprise level assessment of the consequences of a failed IA control to the overall information environment, as well as the urgency of remediation. There are three impact code levels: HIGH, MEDIUM, and LOW. The impact codes are available on the DIACAP Knowledge Service.
Severity category assignments are made by the CA and also indicate the severity of the weakness and the urgency of remediation. There are three severity categories: CAT I, CAT II, and CAT III, as shown in the following table. Once defined by the CA for each weakness, the severity categories are included in the POA&M.
Table 39: Severity category assignments
|
Category |
Criteria |
|
CAT I |
Assigned to findings that allow primary security protections to be bypassed, allowing immediate access by unauthorized personnel or the unauthorized assumption of privileges within the IS. An ATO will not be granted if CAT I weaknesses are present in an IS. |
|
CAT II |
Assigned to findings that have the potential to allow unauthorized IS access or activity within the IS. CAT II findings that can be or have been successfully mitigated will not preclude the issue of an ATO. |
|
CAT III |
Assigned to findings that might impact the security posture of an IS, but must not necessarily be mitigated in order for an ATO to be issued. |
The certification determination is actually a recommendation to the DAA. The CA can determine that the information system meets the requirements for an ATO; should be issued an IATO until certain weaknesses can be resolved; has a valid requirement for an IATT and its operation will likely not compromise the enterprise; or the IS has sufficient weakness to justify a DATO.
Even if there is a compelling mission or business need for the rapid introduction of an information system into the DOD information environment, a certification determination is still required.
Once all the information has been received and analyzed, the CA’s certification recommendation is provided by the program manager or system owner to the DAA together with the DIACAP package. The certification determination is frequently a primary factor in the DAA’s decision.
Issue accreditation decision
The ultimate responsibility for making the final accreditation decision, or authorizing the information system to operate, rests with the DAA. No one else can assume this responsibility.
The final decision to authorize operation of an IS must reflect a balance of the mission or business need for the IS and the risk of operation to the environment. The protections offered by the IS for privacy of information, protection of information, and protection of business functions are included in the consideration.
In those cases where the validation testing is abbreviated in the interests of time and mission, the DAA will not issue an accreditation decision beyond an IATO. If the requirement for the information system is anticipated to extend beyond the immediate need, the validation testing should continue with the goal of obtaining an ATO. The DAA’s accreditation decision always applies only to a specific information system. There are four possible accreditation decisions that can be made by a DOD DAA:
ATO – Authorization to operate: An ATO indicates that an IS has met all or most of the criteria necessary to operate securely and the risk is acceptable to the DAA. An ATO may be issued for a period up to 3 years before re-accreditation is required.
Conditions:
An ATD within 3 years of the authorization date must be specified.
There are no CAT I weaknesses. (A system can operate with a CAT I weakness only when it is critical to a military mission and only the DOD component CIO can make this decision.)
Any CAT II weakness can be corrected or mitigated within 180 days of the accreditation decision.
An ATO can be granted with CAT III weaknesses; however, the DAA must indicate that the risk has been accepted.
IATO – Interim authorization to operate: An IATO is a conditional, temporary authorization contingent upon the information system meeting stated conditions or constraints.
Conditions:
The ATD is within 180 days of the authorization date.
The request is accompanied by a system-level POA&M.
CAT II weaknesses must either be corrected within 360 days of the original IATO or the DAA will issue a DATO, unless continued operation is specifically authorized by the DOD component CIO.
IATT – Interim authorization to test: The IATT is unique to DOD and represents the DAA’s authorization to operate the IS in a specified environment for a limited time frame in order to conduct an operational test of the IS.
Conditions:
The IATT is issued only for a special case requiring IS testing in a live environment for a specified time period.
Applicable IA controls have been tested and validated prior to operation of the IS. The IA controls requiring testing will be approved by the DAA together with the PM/SM.
The IATT is not being used to bypass the requirements of an ATO or IATO.
DATO – Denial of authorization to operate: A DATO is issued when the DAA determines that the risk of operating the IS may be greater than the mission requirement. A DATO can be issued to prevent an IS from starting operation or to remove an existing system from operational status.
The accreditation decision is indicated on the DIACAP scorecard and the DIACAP implementation plan should also be updated to reflect the current authorization status. Once the accreditation decision has been issued, the IS enters into the DIACAP stage or activity where it will maintain the authorization to operate.
Maintain authorization to operate & conduct reviews
Obtaining the authorization to operate is not the end of the story by any means. In fact, in many cases it is only the beginning of the secure operation of the information system. Initial evaluation of the security controls is a necessity, but is not sufficient to demonstrate due diligence – or meet DOD requirements.
Continued authorization to operate is contingent on the sustainment of an acceptable security posture, which can only be accomplished by ensuring continuous compliance with the security controls.
This is accomplished through continuous monitoring and maintenance of the security controls. Continuous monitoring is one means of obtaining and maintaining situational awareness. The information assurance manager (IAM) usually has the primary responsibility for maintaining situational awareness of an operational information system’s security status and for taking actions to maintain or restore its security compliance.
Maintain situational awareness
The term situational awareness is used – at least in the context of C&A – almost exclusively in the DOD. Simply defined it is “an awareness of what is happening around you to understand the impact of information, events, and your own actions.” The US military started using the term extensively during the Korean and Vietnam wars. Returning pilots stressed the importance of situational awareness as a decisive factor in the success of their engagements. Survival in any situation, but particularly in war, is typically a matter of observing the opponent’s actions and anticipating the next move a fraction of a second before the enemy can observe and anticipate one’s own.
Based on the nature of information systems, emerging new technologies and changes in the threat environment, security controls are subject to security volatility. Maintaining situational awareness to address security volatility includes:
Continuous monitoring of the information system and its environment for security relevant events.
Assessing configuration changes for impacts to the security of the information system.
Conducting periodic, at least annual, quality assessments of the security control compliance.
Maintain IA posture
DOD has included security controls that assist the IAM in maintaining situational awareness, such as configuration and vulnerability management, performance monitoring, and periodic independent evaluations (e.g. penetration testing).
Other security performance indicators, such as security incidents, the results of external audits and inspections, exercises, and operational evaluations, can also provide information critical to maintaining the system’s security posture. As a result of reviewing the security performance indicators, the IAM may recommend changes or improvements to the implementation of the assigned security controls, additional security controls, or improvements to the design of the information system.
One very important thing to remember: always document any actual or proposed changes to the information system. Information systems are usually in a constant state of migration with upgrades to hardware, software, or firmware or changes to the environment in which the information system operates. If you maintain your documentation, it will be much easier to report the results of your continuous monitoring and your IA status to the stakeholders in the information system and to make sure your system security plan (SSP) and the POA&M are current.
Conduct reviews
FISMA section 3544(b)(5), as well as DODI 8510.01 (DIACAP), require “periodic testing and evaluation of the effectiveness of information security policies, procedures and practices, to be performed with a frequency depending on risk, but no less than annually” as a minimum requirement for maintaining the authorization to operate. You can conduct these reviews in a number of ways:
Execute compliance testing for all IA controls.
Execute periodic, at least annual, testing for volatile IA controls and review the others as part of a self-assessment.
Execute an annual compliance test for a selected number of IA controls and use a table-top self-assessment for the others.
Regardless of the method you choose for the annual reviews, you must have executed compliance testing for each of the assigned IA controls by the end of the 3-year authorization to operate period.
You should assign greater resources for reviewing security controls with higher volatility, such as vulnerability scans or configurations for firewalls and intrusion detection systems (IDS). Any IA controls identified in the system’s POA&M should also receive top priority in the continuous monitoring and review process. Bottom line: you should make informed decisions about how best to apply limited resources to your monitoring and review activities to ensure that expenditures are consistent with your mission requirements, federal mandates, and DOD and component-level policies, directives, and regulations.
For example, if your system was recently accredited and all of the security controls underwent a complete certification test within the past year, then the annual review may consist of a simple update or maintenance review – provided the initial tests and the review are sufficiently documented.
The following factors will influence the depth and breadth of the annual review:
Potential risk and magnitude of possible harm to the system or its information.
Comprehensiveness of the most recent past review.
Adequacy and success of the corrective measures for weaknesses identified in the POA&M.
This review process will ensure that security-relevant events and the appropriate responses are promptly identified. We are often asked what exactly is a security-relevant event? Some examples include:
Expiration of the revalidation period for an assigned security control. Some of the IA control implementation standards mandate a specific revalidation period or the organization may establish its own revalidation requirements.
Specific events defined by the IA control. Examples of security controls that may include specific events are configuration and vulnerability management, performance monitoring, and penetration testing.
A breach of security or violation of system integrity that reveals a significant flaw in security design, information system security management, policy, and/or security procedures.
Significant changes to the information and/or its environment. Examples include, but are not limited to:
• Installation of a new or upgraded operating system, for example, moving the information system from Windows® XP to Windows® Vista.
• Installation or migration of a significant back-end application, for example, changing the database from Microsoft® Sequel to Oracle.
• Modifications to system ports, protocols, and services, for example, allowing access to a previously denied port to meet a new operational requirement.
• Modifications to cryptographic modules or services, for example, transitioning to the use of common access cards (CAC) or from the CAC to biometric access.
• Changes in laws, directives, policies, or regulations, for example, a new threat may drive a change in system configuration requirements.
• System patch alerts, often issued by DOD in the form of information assurance vulnerability alerts (IAVA).
Not less than annually, the IAM or the PM/SM must provide a written statement to the DAA and the certifying authority (CA) that either confirms the continued effectiveness of the assigned security controls or recommends changes to ensure their continued compliance.
The CA and the DAA will review this statement in light of the mission and the organization’s information environment and determine a course of action. Any course of action changing the C&A status will be recorded in the system identification profile (SIP) and reported during the annual FISMA reporting period.
Courses of action can include a decision to downgrade or revoke an accreditation decision if the risk conditions warrant it. The following table shows the possible determinations as a result of the annual review or other events, such as an incident, audit, or inspection.
Table 40: Annual review results
|
Decision |
Description |
|
No change |
All of the IA controls remain at a risk-based acceptable level of compliance; there is no change in accreditation status; no corrective action is required, and there is no change in the current authorization termination date (ATD). |
|
Corrective action required |
There are continued or new weaknesses in the assigned IA controls; however, a risk-based decision allows the accreditation status to continue with no change; the PM/SM is directed to initiate the required corrective measures; and there is no change in the current ATD. |
|
ATO downgraded to IATO |
There are continued or new significant weaknesses in the assigned IA controls; the DAA makes a risk-based decision to downgrade the accreditation status to an IATO; the PM/SM is required to prepare or amend a POA&M; the ATD is set to 180 days or less during which corrective actions must be completed or initiated. In order to upgrade the status, the affected IA controls must undergo compliance testing upon completion of the corrective measures. |
|
DATO |
There are continued or new critical weaknesses in the assigned IA controls or there is critical risk to mission and/or environment from the operation of the information system; the accreditation status is downgraded to DATO and operation is halted pending corrective action. In order to re-initiate operation of the information system, the affected IA controls must undergo compliance testing upon completion of the corrective measures. |
Initiate re-accreditation
In ordinary circumstances, the DIACAP requires that an information system be recertified and re-accredited upon expiration of the ATO at the three-year mark. Important note: if you have been doing your annual reviews and testing of your IA controls throughout the 3-year accreditation period, you may use these results to meet part – if not most – of your re-accreditation requirements.
In addition to the requirement for re-accreditation at the end of the three-year ATO, the DAA may make a risk-based decision to require re-accreditation based on changes to the information system and/or its operating environment. Here are some of the events that could trigger re-accreditation:
Change in the criticality or sensitivity level of the information processed by the information system, for example, the system was accredited for sensitive information, but now has a requirement to process classified information. This would result in a change to the MAC and/or confidentiality level of the system.
A breach of security or a successful violation of the system’s integrity reveals a significant flaw in system design, security management practices, or security procedures.
A change in the system’s operational environment that could impact system security, for example, the system is deployed into a war zone or other area of operations with a higher threat environment.
Significant changes to the operating system, security applications, or hardware that would affect the current security controls, for example, a transition of the information system from a Unix to a Windows® operating system
Decommission the information system
When a DOD information system is removed from operation, there are a number of IA-related activities that must be considered. Here are some of the actions you should consider as you retire an information system containing DOD information.
Retiring the information system
When a DOD information system is retired from operation, a number of DIACAP related actions are required. There are several authorized and appropriate ways to retire your DOD information system. Giving it away, throwing it in the trash, or selling it to your neighbor are not suitable ways to remove your system from operation.
You should consider how you will decommission or retire your information system as you put it into operation. Early planning will allow you to adjust for the potential high costs, slow process times, and the uncertainty involved with each of the authorized decommissioning strategies. Below are some of the actions you will need to take at the time of retirement:
Any inheritance relationships should be reviewed and assessed for impact.
The SIP should be updated to reflect the system’s decommissioned status.
Concurrently, the DIACAP scorecard and any POA&M should also be removed from all of the component and DOD tracking systems. Other artifacts and supporting documentation should be disposed of according to its sensitivity or classification, unless these are also relevant to other information systems, in which case they will be retained in association with the other IS.
Data or objects in IA infrastructures that support the global information grid, such as key management, identity management, vulnerability management, and privilege management, should be reviewed for impact.
The difficulties with retiring your information system are seldom associated with the hardware - in this case, it is all about the information. And this is one area that is often misunderstood – or completely overlooked. Prior to disposing of or recycling your information system, all DOD data must be completely removed from the system storage.
Data does not just die! This was proven in a 2003 study conducted by two MIT graduate students, Simson Garfinkle and Abhi Shelat. They purchased 158 disk drives from various sources, including eBay, computer stores, salvage companies and swap meets.
When they analyzed the hard drives, the students found that 117 (74%) of the purchased drives still contained data that could be recovered and read. 17% of the drives (28) still had fully installed and functional operating systems with easily accessible user data.
The students also proved that formatting the drives is not sufficient for the removal of the data: 36% of the drives (57) had been re-formatted, but contained data that still could be recovered. Of the 158 drives, only 9% – or 12 drives – had been properly sanitized before being purchased by the students.
So, what type of information did they find on the drives? Information retrieved from the disk drives included corporate financial records, personal medical records, credit card numbers, bank account numbers, dates of transactions, and account balances.
The classification level of the information will influence the processes required to ensure that all sensitive and/or classified information, programs, or data files on any storage media associated with the system are completely erased or otherwise made unreadable.
Here are some requirements regarding the disposition of the information and the information system:
Information preservation – ensure that information is retained, as necessary, to conform to the DOD sensitive information protection requirements or if the information is required for other activities or for historical purposes.
Media sanitization – ensure that hardware and software are disposed of in accordance with current DOD policy and any applicable DOD component policy or guidance. This procedure also applies to contractor-supplied IT equipment and electronic storage media. Before a computer system is sold, transferred, or otherwise disposed of, all sensitive and/or confidential program or data files on storage media must be completely erased or otherwise made unreadable in accordance with DOD 5220.22-M, National Industry Security Program Operating Manual (NISPOM), February 28, 2006. DOD is also using NIST SP 800-88, Guidelines for Media Sanitization, September 2006.
The information system and any data storage peripherals must be relocated to a designated, continuous physically secure storage area in accordance with DOD 5200.1-R, Information Security Program, January 14, 1997 until sanitization is completed.
Once the sanitization is complete, the success of the process must be certified and the record maintained for a period of six years.
DIACAP support tools
As the DOD was considering the requirements for a new and improved method of executing C&A, it focused on the concept of dynamic policy. DOD defined this as policy that took advantage of the tools in the information environment in order to remain current and relevant to the user.
In order to create this dynamic policy together with the release of the DODI 8510.01, DOD Information Assurance C&A Process (DIACAP), DOD also developed and fielded two supporting tools:
DIACAP Knowledge Service (KS)
Enterprise Mission Assurance Support System (eMASS).
Figure 31: Interrelated DIACAP elements
DIACAP Knowledge Service
The DIACAP Knowledge Service is an online repository of information specifically designed to support the execution of the DIACAP. It is available at https://diacap.iaportal.navy.mil/.
In order to access the DIACAP Knowledge Service, all users must comply with the following requirements:
the user must have a valid DOD PKI certificate, such as a common access card (CAC); or
the user must have a valid ECA PKI certificate107 AND the user must be sponsored by a DOD employee (this is generally for those users who are not authorized with a DOD CAC).
107 DOD has established the External Certification Authority (ECA) program to support the issuance of DOD-approved certificates to industry partners and other external entities and organizations. The ECA program is designed to provide the mechanism for these entities to securely communicate with the DOD and authenticate to DOD information systems. Additional information about ECA certificates can be obtained from http://iase.disa.mil/pki/eca/index.html .
First-time users must go through a series of steps to gain access to the Knowledge Service, including registering an account with the Navy Enterprise Single Sign-On (NESSO) service. Those users holding an ECA certificate must also request and obtain sponsorship from an authorized DOD government employee.
The figure below shows the initial landing page from the DIACAP Knowledge Service and highlights some of the more useful content areas.
Figure 32: DIACAP Knowledge Service
According to the DOD, the DIACAP Knowledge Service is:
A web-based portal to DIACAP resources.
A library of tools, diagrams, process maps, documents, and templates, to support the execution of the DIACAP.
An online repository of the authorized IA control set, including rules for implementation, validation testing, and reporting.
A collaboration workspace for the DIACAP user community to develop, share, and post lessons learned and best practices.
A source of IA-related news and links to other information resources.
One important note: The content on the DIACAP Knowledge Service is constantly evolving to keep step with changes in emerging technologies, the DOD threat environment, federal legislative mandates, and DOD policy and regulatory requirements. You should check back regularly to ensure that you are using the most current versions of the IA controls and the supporting guidance.
Enterprise Mission Assurance Support Service (eMASS)
The Enterprise Mission Assurance Support Service (eMASS) is essentially a suite of integrated services that facilitate the workflow management of key activities in the DIACAP process. Using eMASS, a DOD component can automatically initiate the C&A process, manage the requirements for system registration, monitor the implementation and testing of the IA controls, and assign the roles and responsibilities for each of these actions.
The target deployment level for eMASS is the DOD component CIO and the system was designed to be able to exchange information between other web-based services. eMASS provides the capability for information input and exchange through its unique architecture. It is composed of an integrated suite of government-owned, relational-database management systems, based on commercial-off-the-shelf (COTS) components and all functions are accessed through a web interface. The intent of eMASS is to provide a standardized, automated approach for describing and collecting required data for C&A and other core IA functions.
As the required C&A actions are accomplished, they are electronically “moved” along in the workflow and into the “inbox” of the assigned DIACAP team member. Completed actions are digitally signed, allowing for non-repudiation and authentication.
All of the information generated during the C&A process becomes part of the permanent data file for the information system, which enables security to be tracked across the entire system life cycle. eMASS contains a number of standard reports, but also has the ability for the owning organization to develop tailored reports and output.
At the end of the C&A process, eMASS also automatically generates the elements of the C&A package for the information system using the input from the C&A process and then submits the package digitally to the CA and the DAA.
eMASS also correlates the information needed by DOD to meet FISMA reporting requirements and to automatically generate several of the FISMA reports, such as the plan of actions and milestones (POA&M) and self-assessment checklists.
The government-owned component of eMASS software is available free of licensing fees to DOD constituents. Since eMASS does use some COTS, such as the report generation software, there may be some costs for licensing these applications.
However, eMASS currently does not require a large organizational investment in hardware, software licenses, application installation and configuration, or training. Determination of the cost of acquiring and using eMASS will depend on factors such as availability of supporting COTS software/hardware, need for system configuration and database engineering support, and the amount and type of system training required.
The office of DOD Information Systems Agency (DISA) is currently the eMASS sponsor and the final authorizing authority for any eMASS deployment. The DISA office, PEO-IAN, is responsible for reviewing and approving eMASS application deployments and installation. An agreement between DISA and the DOD component installation site is necessary to ensure centralized configuration management needed to maintain the integrity of the system.
C&A and the DOD components
Although the DIACAP was designed to standardize the C&A process and provide consistency and repeatability of results, each of the DOD components has decided to personalize the DIACAP to meet their unique requirements.
In order to discuss each of the DOD component-unique DIACAP implementations, we would need another book. Instead, we will provide the service-specific references here:
Department of the Army: Army Regulation (AR) 25-2, Information Assurance, 24 October 2007.
Department of the Air Force: Air Force Instruction (AFI) 33-210, Air Force Certification & Accreditation Program (AFCAP), 23 December 2008.
Department of the Navy: Office of the Chief of Naval Operations Instruction (OPNAVINST) 5239.1C, Navy Information Assurance (IA) Program, 20 August 2008, and Department of the Navy (DON) DOD Information Assurance C&A Process (DIACAP) Handbook, 15 July 2008.
References
DIACAP Knowledge Service website, available at https://diacap.iaportal.navy.mil/ks/Site%20Pages/Home/HO.0.0.aspx .
DOD Directive 8115.01, Information Technology Portfolio Management, October 2005.
DOD Directive 8500.01E, Information Assurance, current as of April 2007.
DOD Instruction 8500.0, Information Assurance Implementation, February 2003.
DOD Instruction 8510.01, DOD Information Assurance Certification & Accreditation Process (DIACAP), November 2007.
National Institute of Standards and Technology (NIST) Special Publication 800-88, Guidelines for Media Sanitization, September 2006.