Information Assurance Revolution

The Department of Defense Information Assurance Certification
and Accreditation Process is the department’s new process
for the certification of all information systems.

  Leroy Lundgren, deputy director of the Army Office of Information Assurance and Compliance, recalls a rueful sense of déjà vu when the new Department of Defense Information Assurance Certification and Accreditation Process (DIACAP) was released last fall.

“When they first came out with DIACAP, I said, ‘Here we go again. They’re just adding things to DITSCAP,’” Lundgren said.

Since then, Lundgren and other information assurance professionals within DoD have learned that the replacement of the DoD Information Technology Security Certification and Accreditation Process (DITSCAP) with DIACAP involves much more than a battle of acronyms.

DIACAP, which became effective immediately upon its release in November 2007, is the department’s new process for the certification of all information systems and for determining whether these systems should be authorized to operate. DIACAP represents DoD’s attempt to comply with the information security mandates required of all federal departments under the Federal Information Systems Management Act (FISMA).

DIACAP’s release triggered a process of transition from DITSCAP throughout all DoD components. But it is a true transition only in a limited sense. Newly built or newly acquired information systems must immediately comply with DIACAP, while systems that had been certified and accredited under DITACSAP, usually for a three-year period, are allowed to run out the clock before having to be recertified under DIACAP.

But once that recertification trigger is pulled, DITSCAP is pretty much out the window. The two IA policies are so different that there will be little if anything salvageable from DITSCAP, in the form of data, documentation or processes, that will be applicable to DIACAP. In that sense, analysts suggest, the advent of DIACAP can be seen as more revolution than evolution.

“DITSCAP worked on a three-year fire-and-forget cycle,” said Waylon Krush, chief executive officer of Lunarline, a Washington-based firm that advises agencies on compliance with DIACAP. “System controls were often not touched in three years, and the controls were often not up to date.

“DITSCAP involved more documentation of system security, while DIACAP takes a system life cycle approach,” Krush added. “DIACAP requires annual assessments and continuous system monitoring.”

The two policies also take completely different perspectives to system controls. “DITSCAP focused on specific program security needs, and not necessarily from the perspective of the Global Information Grid (GIG),” explained Eustace King, chief of the technology and capabilities division in the Office of the Assistant Secretary of Defense for Networks and Information Integration (ASD NII).

“With DIACAP, we are attempting to understand the risks being accepted with respect to the GIG as a whole.”

Acceptable Risk

Under DITSCAP, individual program managers decided the level of acceptable risk for the specific systems they managed. DIACAP provides a central set of information assurance controls that represent a baseline for all DoD systems.

“If we implement a system in the European theater that requires a certain level of trust,” King explained, “and another system in the Pacific theater requires the same level, we now know that the security implementation for both systems will look exactly alike.”

Implementation of DIACAP will involve all DoD components at all levels of the hierarchy, according to Natalie Givans, a Booz Allen Hamilton vice president who leads the firm’s IA work. Booz Allen has advised ASD NII on DIACAP.

“CIOs will take an enterprise view of DIACAP,” she said. “They are responsible for taking a wide view of the security of systems throughout the enterprise and for creating and implementing DIACAP workflows. They are also in the best position to determine the level of funding they need to ask for to implement DIACAP and to roll out metrics to measure DIACAP’s effectiveness.”

Program managers, the next level down, will implement the DIACAP workflows and manage the implementation processes, Givans explained. At the deepest level are the IA practitioners, who are focused on implementing and testing specific controls on individual systems.

DIACAP includes 157 controls, grouped into eight categories. The level of controls required for a specific system depends on two factors: its mission assurance category (MAC) and its confidentiality level (CL).

The three mission-assurance categories are: information that is mission-vital, information that is important to the support of forces, and information that is used in the conduct of day-to-day business. There are also three confidentiality levels: classified, sensitive and public, in descending order of the required controls.

The nine combinations of mission assurance category and confidentiality level establish nine baseline IA levels for the GIG. The MAC controls focus on integrity and availability, while the CL controls focus on confidentiality.

A confidentiality control, for example, would require that network access be gained only with an individual authenticator based on the DoD public key infrastructure (PKI). Integrity controls include accomplishment of identification and authentication using a DoD PKI class 3 or 4 certificate and a hardware security token. An availability control would require an annual IA review that evaluates existing policies and processes to ensure procedural consistency and uninterrupted operations.

While DIACAP was developed at the highest levels of DoD, once it was promulgated, it was up to individual DoD entities to develop policies and workflows for its implementation. “Each department is implementing DIACAP in its own way,” said Lon Berman, principal consultant and training director at the DIACAP Resource Center, a consultancy based in Fairlawn, Va.

The Air Force has issued a DIACAP workflow process it calls SISSU, for security, interoperability, supportability, sustainability and usability, according to Kenneth Brodie, chief of the Air Force IA branch in the CIO’s office. “The SISSU process includes four phases that we have matched up with mandated DIACAP activities,” he explained. “As program managers and certification and accreditation personnel go through the SISSU, we are able to track their activities from start to finish.”

The Army has no similar document, Lundgren said. But what both services have in common is the notion of pushing up the acceptance of system risk higher up the chain of command. Under DITSCAP, the Air Force had 450 decision makers who could decide to allow a system to operate on its network. That number is now down to three people, one each in charge of air operations, space, and special programs and requirements.

Lieutenant General Robert J. Elder Jr., commander of the Eighth Air Force, is now ultimately responsible for accepting system enterprise risk on behalf of the Air Force.

In the Army, the number of deciders has moved from 121 to eight, with the director of the Army Office of Information Assurance and Compliance being the ultimate authority, according to Lundgren.

Top-Down Management

Placing the assessment and acceptance of risk at a higher organizational level changes the perspective of organizational risk, Brodie noted. “At a lower level, you are assessing risk based primarily on operational considerations and how it would impact the mission,” he said. “Risks that might be acceptable at the base level might not be acceptable when you start crossing system boundaries. A base commander is not in a position to assess risk across the entire enterprise. That is one big reason why DIACAP has to be managed from the top down and not the bottom up.”

At the same time, the goal of DIACAP is not to eliminate risk but to manage it. “The government likes to use the term acceptable risk,” said Berman. “They understand that everything has some inherent risk no matter how much safeguards you put around it. The point of DIACAP is that before a system receives accreditation, a senior government official needs to conclude that the risk is acceptable.”

But the comprehension of acceptable risk depends on the perspective of the person assessing that risk, according to Brodie. “If it is accepted by senior leaders, then when there is an incident on the network significant enough to make the newspapers or cause rumblings on Capitol Hill, then it is those same senior leaders who will be called to give answers,” he said.

“Under DITSCAP there really wasn’t much risk management, just paperwork,” added Lundgren. “Implementing DIACAP is like trying to turn a battleship in a bathtub. Our job is to figure out what the level of acceptable risk is at an enterprise level. If a given system isn’t up to that level, then it needs to get a get-well plan.”

For example, an Army legacy system that still uses a file transfer protocol, which is considered a security vulnerability to other systems it may be connected to, may still need to remain operational because of its mission criticality. “What we’re saying is that we need a plan to make that system secure within six months,” Lundgren said.

The services face a number of other challenges in implementing DIACAP, not least of which is what Lundgren called “significant cultural issue” in moving from the “paperwork drill” characteristic of DITSCAP, to DIACAP, “where you’re expected to actually go out and do the testing.”

Another drawback to DIACAP is that it removes a great deal of discretion from local commanders and requires them to go up the bureaucratic chain to get approval for systems. The centralization of network system approval basically trades a higher level of security for the increased flexibility that prevailed before.

“In the past, if a wing commander said he wanted a certain application on the network, and boom, it was on the network,” said Brodie. “But we have since learned that in a network-centric environment, a risk accepted by one is a risk accepted by all. A risk not visible locally could have a catastrophic impact on the entire enterprise. That is why everything now goes up to a senior Air Force risk manager.

“This creates a headache,” Brodie added, “because the central point for accreditation has created a bottleneck in getting systems accredited. We are staffed up, but we are going through some growing pains.”

Local Assessments

The Air Force also sees the value of trying to re-empower local commanders, according to Brodie, by allowing them to make some local system decisions. At the same time, it is mandating that the local authorities perform due diligence on the systems they wish to add, have a risk mitigation plan in place for those systems, and share information on the new systems with the Air Force so that it has situational awareness over its enterprise network.

That might be acceptable with DoD, according to King, provided that DIACAP baselines are adhered to. “We have not eliminated the authority of components to do local risk assessments,” he said. “They have that the authority to go ahead and do that and to augment baseline set of controls contained in DIACAP. They can strengthen their environment if they wish, but they cannot weaken it.”

King also recognizes that DoD components will face some challenges as they move away from DITSCAP and towards DIACAP. “They are concerned about whether they have the resources and the tools they need to support the transformation,” he said. “Planning for this information assurance transition needs to be done early on.”

Training and education of personnel is another concern faced by DoD components, according to King. “They must make sure they have a cadre of information assurance professionals who are in full understanding of what DIACAP is and how it differs from DITSCAP,” he said. “This includes the complete realm of IA professionals, including principle certification and accreditation personnel to program managers and IA managers. There is a significant training and education tail that need to be accomplished for DIACAP to be properly implemented.”

One undisputed advantage to the enterprise view taken under DIACAP is that it will facilitate the sharing of systems among DoD components. “Under DIACAP there is reciprocity,” said Brodie. “That means that if I show my DIACAP package to the Army, the Army will recognize that certification and accreditation and put that system on its network. They won’t have to undergo the same process for themselves.

“We never had that under DITSCAP,” he added. “This is going to save money and time because it allows capabilities to be put out to the field without having to be certified and accredited three or four times.”

King sees implications to reciprocity that go even beyond DoD. He noted that reciprocity applies to intelligence community systems as well as national security systems operated elsewhere by federal government entities.

“DIACAP is really a combined initiative between DoD and the intelligence community,” he said. “What we have done is to create a single certification and accreditation process with the strategic objective of meeting the needs of all of those communities.” ♦