[This is a repost of my 9 Nov 2011 post on Intelink-U]
[There is a follow-up post]
[There is an update]

Suppose you are responsible for developing a network-based application for the DoD. Your team has cobbled together (i.e “integrated”) off-the-shelf components into a cool tool that meets a mission need of your agency or component. You intend to host and operate this application out of a datacenter somewhere on the GIG. Do you need to go through full-blown Certification & Accreditation… having a DAA, IATT, IATO, ATO?

Let’s see what the policies are:

DoDI 8510.01, “DoD Information Assurance Certification and Accreditation Process (DIACAP)” establishes that it is DoD policy that we shall certify and accredit “ISs” (Information Systems) through … yadda yadda yadda. It goes on to define “Information System” as “See Reference (d)”.

Reference (d) of 8510 is DoDI 8500.2 “Information Assurance (IA) Implementation”. It defines “DoD Information System” as:

“Set of information resources organized for the collection, storage, processing, maintenance, use, sharing, dissemination, disposition, display, or transmission of information. Includes AIS applications, enclaves, outsourced IT-based processes, and platform IT interconnections (NSTISSI No. 4009, reference (c) modified to include the four DoD categories).”

DoDI 8500.2 defines “Automated Information System (AIS) Application” as:

“For DoD information assurance purposes, an AIS application is the product or deliverable of an acquisition program, such as those described in DoD Directive 5000.1. (reference (u)). An AIS application performs clearly defined functions for which there are readily identifiable security considerations and needs that are addressed as part of the acquisition. An AIS application may be a single software application (e.g., Integrated Consumable Items Support (ICIS)); multiple software applications that are related to a single mission (e.g., payroll or personnel); or a combination of software and hardware performing a specific support function across a range of missions (e.g., Global Command and Control System (GCCS), Defense Messaging System (DMS)). AIS applications are deployed to enclaves for operations, and have their operational security needs assumed by the enclave. Note: An AIS application is analogous to a “major application,” as defined in OMB A-130 (reference (v)); however, this term is not used in order to avoid confusion with the DoD acquisition category of Major Automated Information System (MAIS).”

OMB A-130, Appendix III, defines “major application” as:

“a use of information and information technology to satisfy a specific set of user requirements that requires special management attention to security due to the risk and magnitude of harm resulting from the loss, misuse or unauthorized access to or modification of the information in the application. All applications require some level of security, and adequate security for most of them should be provided by security of the general support systems in which they operate. However, certain applications, because of the nature of the information in them, require special management oversight and should be treated as major. Agencies are expected to exercise management judgement in determining which of their applications are major.”

So, pulling the thread:

Policy says you gotta C&A an Information System. Information System is one of 4 things: AIS applications, enclaves, outsourced IT-based processes, and platform IT interconnections. In the scenario I presented above, you obviously aren’t an enclave, an outsourced IT-based process, or a platform IT interconnection. So, are you an AIS application? Definition of an AIS application says that it’s the deliverable of an acquisition program… you’re not that… but it also references the OMB Circular A-130 definition for a “major application”, which it defines as “requiring special management attention to security due to risk…” It further notes that agencies are expected to exercise judgement in determining which of their applications are major.

So, reasonably, if your program is not the output of a 5000.2 acquisition program, nor does it require special management attention due to risk, then it isn’t a “major application”, (in A-130 speak) so it isn’t a “AIS Application” as defined by 8500, and therefore isn’t one of the four categories of “Information Systems”. If you aren’t an Information System, then C&A doesn’t apply to your thing-that-isn’t-an-IS, per the “APPLICABILITY AND SCOPE” section of DoDI 8510 (although it would apply to the enclave where your application is hosted.)

I had this conversation with Eustace King once, (at the time, the primary author of DoDI 8510), and he acknowledged the policy problem that the definition of an “application” ultimately turns on the definition of “major” as used in OMB Circular A-130, which is grossly subject to interpretation. When pressed, he said: “I know one when I see one.” As a fellow policy wonk, I found this completely unsatisfying. My experience is that the interpretation of this across DoD varies widely, leaving significant capabilities untenable based on the caprice of policy interpretation of the local IA person.

I contend that many folks are getting put through the DIACAP wringer who shouldn’t be, according to policy. Am I wrong? Does the policy need to be fixed, and if so, how?