Category Archives: C&A

What needs an ATO? (Update)

In 2013, I wrote a post that traced the definitions in DoD policy on what things need an ATO (then Approval-To-Operate, now known as Authorization-to-Operate).  Since that time, much policy has been reissued, so here’s an update:

DoD Instruction 8510.01 (Change 2, July 28, 2017) “Risk Management Framework (RMF) for DoD Information Technology (IT)”, says “Each DoD IS, DoD partnered system, and PIT system must have an authorizing official (AO) responsible for authorizing the system’s operation based on achieving and maintaining an acceptable risk posture.”

“DoD IS”, above, is a DoD “Information System”.  The glossary section of 8510.01 says “Information System” is defined in CNSS Instruction 4009, “Committee on National Security Systems (CNSS) Glossary”:  “Set of information resources organized for the collection, storage, processing, maintenance, use, sharing, dissemination, disposition, display, or transmission of information.”

This doesn’t help, in terms of determining what doesn’t need an ATO.  However, DoD Instruction 8500.01, “Cybersecurity”, says this:

(a) DoD ISs are typically organized in one of two forms:

1. Enclave
2. Major Application (Formerly Automated Information System Application)

a. Certain applications, because of the information in them, require special management oversight due to the risk and magnitude of the harm resulting from the loss, misuse, or unauthorized access to or modification of the information in the application and should be treated as major applications. A major application may be a single software application (e.g., integrated consumable items support); 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, Defense Enrollment Eligibility Reporting System). 

b. Major applications include any application that is a product or deliverable of an Acquisition Category I through III program as defined in Enclosure 3 of Reference (av). When operationally feasible all new major applications will be hosted in a Defense Enterprise Computing Center. c. All applications, regardless of whether they rise to the level of major application or not, require an appropriate level of protection. Adequate security for other than major applications may be provided by security of the environment in which they operate. d. When possible, capabilities should be developed as applications hosted in existing authorized computing environments (i.e., enclaves) rather than designated as major applications requiring new and separate authorizations. e. DoD Component CIOs will resolve disputes regarding whether an application rises to the level of a major application. 

c. All applications, regardless of whether they rise to the level of major application or not, require an appropriate level of protection. Adequate security for other than major applications may be provided by security of the environment in which they operate.

d. When possible, capabilities should be developed as applications hosted in existing authorized computing environments (i.e., enclaves) rather than designated as major applications requiring new and separate authorizations.

e. DoD Component CIOs will resolve disputes regarding whether an application rises to the level of a major application.

The ’90s called, they want their C&A process back

michael-douglas-wall-street[This is mirrored on Intelink-U]

In a previous post, I traced through the various policy documents that describe the certification and accreditation processes for the Department of Defense, ultimately tracing back to OMB Circular A-130.  In summary, “systems” need accreditation, while “applications” do not, and the distinction (per A-130) turns on the highly subjective decision of whether it is a “major” application.

In tracing this definitional tangle, I unwittingly provided a roadmap for how to get your system “application” on a DoD network without a full-blown Approval To Operate (ATO).  I was not trying to  provide an easy-out for getting operational without being accredited … although the method is a well-trodden path with a lot of history.  I’m was trying to show that our C&A policy is at-least-slightly broken, and we generally don’t even understand it ourselves.

Again, to summarize, this is what not to do:  Continue reading

System vs. Application: when is C&A required in DoD?

[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?