Why Federal IT Will Never Be Secure

Few stories have depressed me as much as this report from earlier this month in the Washington Post. It looks to be normal fare -- a news report about an IG report that finds some aspects of a Federal agency lacking. And yet ... what I see in this news article is a turgid Federal bureaucracy that will never understand the IT sector. And that's depressing. To understand why requires some exposition, so bear with me.

Our story begins with 18F. Put simply, 18F is a Federal digital consultancy that is an attempt to bring the software development methods of Silicon Valley to Washington. It had its start back in 2014, when the Healthcare.gov website roll out was such a dismal disaster. Desperate to recover, and fix the problem, the Obama Administration brought in experts from the West Coast to revamp the program -- and in doing so, they also re-wrote how IT projects are managed in Washington.

Traditional project management in Washington operates by a method known, colloquially, as Waterfall Project management. To simplify somewhat, the system runs as a top-down cascade (kind of like a waterfall) with requirements being set at the top and then leading sequentially to design; coding and development; quality assurances and, finally, implementation. Each step in the process is well-documented and no step is started until the prior step is finished. It's long, slow, and highly auditable.

By contrast, most software development these days in the private sector proceeds by a method known as "Agile" methodology. Agile development is iterative, with many small steps going forward, and then back and then forward again in a flexible process. Agile methods are usually preferred because the waterfall method is unable to adapt to changes in projects, so a project’s success depends on an adequate initial brief. It leaves no room for testing prototypes or making design alterations based on behavior or user experience. But, software is the quintessential project that needs to adapt based on user experience. And so, 18F (and its companion, the US Digital Service) sought to try to use these new development methods. A good pictorial depiction of the difference looks something like this:

These methods have had some real success. Besides Healthcare.gov, the 18F group has also helped with the Veterans Administration, US Citizenship and Immigration Services and the FEC. But, as GovTech puts it 18F's biggest success has been in IT procurement. It has made government IT become more affordable by shrinking the size of contracts, heightening competition, and opening up federal work to startups and small businesses. "18F’s micro-purchase initiative created a Web platform for agencies to freelance low-cost coding jobs to technologists and businesses. Its Agile Delivery Services Blanket Purchase Agreement (Agile BPA) built a program for startups and companies to provide open source technology at competitive pricing, and 18F’s state and local IT consulting program — which provide services to federally funded state projects — may save California and other states millions with a new child welfare system upgrade. Through 18F’s influence, California officials broke down what would have been a costly contract into more smaller, more manageable, competitively priced contracts that ask for open source code — code that can be freely reused by other states."

All of which sounds wonderful, right -- few, if any, could doubt that the nimble development, procurement and provisioning methods of Silicon Valley would greatly benefit Federal IT systems. And that, in the end, is why the GSA IG report is so disappointing. Applying its static, old-school model of assessment, the IG reviewed 18F and found it wanting. Among its findings:

• 18F “routinely disregarded and circumvented fundamental security policies and guidelines”
• “none of the 18 information systems operated by 18F had proper authorizations to operate during the entire time period of June 1, 2015, to July 15, 2016”
• “18F created its own security assessment and authorization process, which circumvented GSA IT”
• “the 18F Director of Infrastructure improperly appointed himself as the Information Systems Security Officer for 18F”
• “18F disregarded GSA IT security policies for operating and obtaining information technology, and for using nonofficial email.”

But note that almost all of these (save perhaps the first) involved not actual security failures, but rather failures to comply with process that define security in the Federal IT space -- things like authorizations and assessments. This approach is at the core of FISMA (the Federal Information Security Modernization Act) which is widely derided as a paper exercise that produces no security. As one observer put it: "FISMA is about compliance, not security. Whether an agency gets an A or a D on its FISMA report card doesn’t tell us whether its systems are vulnerable to attack. It tells us only how well it has met FISMA reporting requirements." Or as Aaron Snow (one of the founders of 18F) said: "As a taxpayer, I take a somewhat different view: as far as I know, those policies have added cost, added delays, and not made any of our services any more secure than they were before. . . .But often in government, no good deed goes unpunished. Checking compliance boxes is often conflated with actual security.”

More fundamentally, the GSA IG report reflects the zero-defect mentality in Washington. No project can ever risk failure. Every step needs to be completely documented and approved by 37 higher authorities. If Congress can't review and audit the project, it is "out of control." Emblematic of this approach is the response to the IG report from Rep. Robin L. Kelly (Ill.), ranking Democrat on the House Oversight and Government Reform subcommittee on information technology: “Today’s Inspector General report is deeply troubling,” he said . “Our information technology security must always be a priority. … This report makes it clear that 18F needs to be reevaluated and vetted from the ground up to ensure compliance and accountability.”

And there you have it. 18F is an innovative program designed to improve security and IT performance by using modern methods of program management for our Federal systems. But it is too innovative. The prospect of focussing on actual results (does the code work; is it actually secure) instead of process measurements (have we checked all of our boxes on the checklist) is too daunting for Congress. It needs to be reevaluated and vetted from the ground up (read destroyed) so that it doesn't innovate again.

To be fair, the rules are the rules. So the IG report is accurate -- but what this says to me is that the rules are out of date. They should be changed -- and until they are changed there should be exemptions for innovative programs like 18F.

The winners in this process: Process-definitions of security; large IT providers who use the waterfall method; Congressional overseers who have only a limited ability to actually understand nimble methodology.

The losers: Federal IT users, stuck with old systems that haven't been upgraded; small businesses that can provide novel solutions but not invest in compliance metrics; Federal IT security and utility, writ large; and, ultimately, the American taxpayer.

It's a crying shame.