Current Certification and Accreditation Regimes Have Become a Hindrance to the Rapid Fielding of Effective Software Solutions
According to the Center for Strategic and Budgetary Assessments, between 2001 and 2011 the Department of Defense (DoD) spent some $46 billion on a dozen or more programs that never achieved operational capability.
With Ashton Carter’s nomination to become the next Secretary of Defense, the Department may finally have leadership willing to address its acquisitions woes.
Among Dr. Carter’s accomplishments is a 2010 memo, written when he was Undersecretary of Defense for Acquisition, Technology and Logistics (AT&L), entitled “Better Buying Power: Guidance for Obtaining Greater Efficiency and Productivity in Defense Spending.” It seems that he’ll now have the opportunity to implement the plan he outlined four years ago.
Meaningful acquisitions reform must also address the DoD’s problems (and, for that matter, those of the Government as a whole) with developing and procuring software. Everything that the DoD buys, it seems, has an electronic information component (with the possible exceptions of boots and bayonets).
“. . . persistent software problems have slowed progress in mission systems flight testing, which is critical to delivering the warfighting capabilities expected by the military services. These persistent delays put the program’s development cost and schedule at risk.”
Security drives many of these software issues. Security requirements for information assurance, risk management, and certification and accreditation constrain Government organizations with respect to software allowed on Government networks. On one level, this is nothing more than managing the supply chain to prudently mitigate security risks to systems and networks. Unfortunately, these security measures often become procedural impediments and disablers, preventing Government programs from implementing optimal solutions.
The intent of these requirements is uniformly good, but problems arise as they are distilled into a myriad of risk management policies and directives. This results in a security environment where many excellent, and often cost effective, software components are unavailable for Government use. In many cases these components are proven commercial products (both proprietary and open source) that simply lack the right certification or accreditation pedigree. A brief look at one of the most important security certification standards, the “Common Criteria for Information Technology Security Evaluation” (Common Criteria), helps to illustrate the point.
The Common Criteria is an international standard (ISO/IEC 15408) for computer security certification. It provides mechanisms by which security requirements can be specified and assertions made about a product’s level of compliance with those requirements. Importantly, the Common Criteria also provides guidance for laboratory testing that evaluates the degree to which claims of compliance are valid. This flow is intended to provide confidence that the product has been evaluated in a standardized manner at a level of rigor relative to the degree of sensitivity of the environment in which it is intended to operate.
The National Information Assurance Partnership (NIAP) is closely associated with Common Criteria implementation in the US. NIAP is a US Government initiative intended to meet the security testing needs of both information technology consumers and producers. Its Common Criteria variant, the Common Criteria Evaluation and Validation Scheme for IT Security (CCEVS) is designed to help public and private sector consumers select software products that meet their security requirements and, at the same time, help manufacturers of those products gain acceptance in the global marketplace. In effect, CCEVS enables architects and developers to select from a catalogue of pre-vetted, trusted products.
As a concept, it’s difficult to argue with CCEVS. Implementation, however, is another thing. A GAO investigation (PDF) indicated that across the span of eight laboratories, evaluation costs range from $150,000 to $350,000 while testing timelines range from nine to 25 months. As a result, reliance on CCEVS effectively prevents Government acquisitions programs from taking advantage of innovative software developed by small businesses that might not have the funding to invest a quarter of a million dollars in certification testing. Moreover, by the time a software product has been certified, an average of a year and a half has elapsed and the solution is no longer cutting edge or innovative.
Instead of providing useful security, assurance programs often stifle innovation, retard the economy and entrench monopolies. Clearly, these are unintended outcomes. A proactive certification regime’s goals should be to create a broad catalogue of approved software and, at the same time, ensure security through a rapid and cost effective vetting process. Achieving these would go a long way toward addressing the acquisitions dilemmas that continue to plague the Government.
VB2’s benefits to the Government are significant. Having a broad catalogue of pre-approved components from which to choose allows program managers and engineers to tailor a product stack to a program’s timeline and budget. Additionally, the distinction between proprietary and open source products is removed, enabling programs to reap the benefits associated with open source development.
Recent developments lend the necessary infrastructure to implement something like VB2. On September 24, 2014, the National Institute of Standards and Technology (NIST) awarded a contract to the MITRE Corporation to operate a new Federally Funded Research and Development Center (FFRDC) supporting the National Cybersecurity Center of Excellence (NCCoE).
FFRDC’s are public-private partnerships which conduct research for the US Government. The NCCoE’s mission is to help secure information systems by bringing together experts from industry, government and academia to provide cybersecurity solutions based on commercially available technologies. Senate Appropriations Committee Chairwoman Barbara Mikulski described the NCCoE as “the best of government working with world-class IT companies to make our country safer and our economy more secure.”
The existence of the NCCoE and the establishment of its supporting FFRDC begs the question. If a publicly funded organization with the objective of securing American information systems already exists, why isn’t it responsible for a VB2-like software security certification regime? In part, this is due to the newness of the organizations in question. The NCCoE was established in 2012 and its FFRDC is less than four months old. That being said, age neither explains nor excuses the fact that the cyber FFRDC’s initial tasking speaks only to expanding the NCCoE’s efforts in developing cybersecurity use cases and building blocks, operations management and facilities planning and not to laying the groundwork for an efficient software certification and accreditation program.
To be effective, security must both protect an organization’s information assets and enable its business processes and activities. When security is perceived as a hindrance to the core mission, it will be at best ignored and often deliberately thwarted by those it seeks to protect. Current certification and accreditation regimes have become a hindrance to the rapid fielding of effective software solutions and a key cause of poorly performing acquisitions programs. A “Validated Best of Breed” certification paradigm, when administered by a publicly funded entity agnostic to everything but software quality and security standards, offers a solution addressing both technical and programmatic problem sets.