In essence, the information security/assurance certification and accreditation process -- in both civilian and military realms -- represents a command and control view of decision making.

On the battlefield, the commander gathers information from advisors who are qualified to attest to the accuracy (or limitations) of the information they provide. Because no one ever operates without a degree of uncertainty, the commander makes decisions using available information but with the full realization that other factors are unknown and perhaps unknowable. The commander also recognizes that a bad decision will reflect on him or her directly.

But in today’s federal information security/information assurance world, the model is turned upside down. The accrediting official seldom knows enough about the information provided by the certifying official to know if it (or even the certifying official) is trustworthy. Furthermore, the accrediting decision -- at least on the civilian side -- never really involves personal responsibility. For example, it is a virtual certainty that neither the National Institutes of Health official who accredited the system that included the recently stolen laptop nor the State Department official who accredited the system that protects passport information will lose his or her job.

So I hereby offer the beginnings of a realistic set of assumptions for every accrediting official to consider before signing that document:

• I accept the risk that the boundaries of this system have been incorrectly defined;
• I accept the risk that one or more supporting or interconnected systems have vulnerabilities which are either unidentified or have been accepted as risks by the accrediting official for those systems (even though I would never accept such risks);
• I accept the risk that one or more of the security controls supposed to protect this system have not been tested properly;
• I accept the risk that one or more of the security controls supposed to protect this system have changed in a material way since the control was tested;
• I accept the risk that the hardware and software underlying this system may have weaknesses and vulnerabilities that have not yet been identified or corrected;
• I accept the risk that the custom software code, hardware settings and other changes to out-of-the-box configurations used in this system may introduce vulnerabilities not covered by standard control tests;
• I accept the risk that employees, contractors and others who develop, maintain, repair and use this system may be able to bypass security controls without detection;
• I accept the risk that five-year background screening may not identify privileged employees or contractors who have a motive to bypass security controls;
• I accept the risk that reliable operation of this system depends on weather, the power grid, the national and international telecommunications network, and other matters outside the control of my agency;
• I accept the risk that users of this system may not do what they have been trained to do or may choose to do what they have been trained not to do; and
• I accept the risk that I could lose my job if anything bad happens.

Surely, there are many others. Readers, any suggestions?