Friday, September 13, 2013

Agile Development and Security in Government

All IT domains continue to make broad use of incremental system and software development methodologies to improve the efficiency of deploying projects small and large. Those methodologies are even extending beyond traditional development to include system integration and program management. When it comes to the U.S. Government, though, there is one aspect of oversight that is preventing managers from making effective use of incremental methodologies: Security. While project teams share some blame by often actively and explicitly discounting security objectives (in my direct experience), I submit that the lion's share of the blame should fall on Information System Security Officers (ISSOs) and Managers (ISSMs).

The National Institute of Standards and Technology (NIST) has also failed to execute its mission to be "responsible for developing information standards and guidelines" in what I would consider a timely and effective manner in relation to incremental development methodologies. But, agency Chief Information Officers (CIOs) can meet legacy NIST guidelines, certify systems developed under those methodologies, and even improve security of their agency system, without running afoul of NIST guidelines, if only they were willing (and able) to make some strategic changes in how they manage system security compliance activities.

For its part, NIST only addresses incremental development methodologies in one line of the document that serves as the basis for all U.S. Government civilian security programs, Special Publication 800-37 Revision 1 (NIST SP 800-37rev1): Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Lifecycle Approach.

Organizations may employ a variety of system development life cycle processes including, for example, waterfall, spiral, or agile development. [Page 9 in Footnote 26]

Despite that brief statement that seems to support incremental development (those familiar with the sheer volume of NIST publications can attest to how insignificant those statements are within the breadth of all NIST guidelines), I am not aware of anything NIST has done to support nascent agency efforts to define sufficient processes to secure incremental releases. What's worse is that the current guidance essentially forces security managers to subject projects to waterfall, big-bang development methodologies that have long been the root cause for large-scale program failures and spending inefficiency. (See also: FBI Sentinel - finally succeeded after going agile, DHS eMerge/Financial Management, VA/DoD integrated Electronic Health Records) The result is a cultural clash between project and security managers that has projects leveraging internal agency politics to undermine security certification efforts through illegitimate waivers and security groups suspicious that projects are doing everything to bypass security requirements.

At the heart of the problem is how NIST defines the Risk Management Framework in NIST SP 800-37rev1 and how it defines a "system" that is subject to that framework.

NIST bases the Risk Management Framework on a single comprehensive "release" when an information system is made available to some user population to process real agency information. To release a system, the project must facilitate a lengthy (>90 days in my experience) security document development and assessment process (Step 4 of the NIST Risk Management Framework) that should ultimately lead to a final "Authority to Operate" (ATO) in Step 5. Once a system receives ATO (a very significant milestone), it may continue to operate under that authority for as long as three years, assuming that no "major change" has occurred in the interim.

NIST defines an "information system" based on the abstract process of defining "system boundaries."

Information system boundaries are established in coordination with the security categorization process and before the development of security plans. [NIST SP 800-37rev1, Page 10]

In Step 4, the ISSM subjects the system to an assessment that covers everything deemed to be within the system boundary. For large systems (those most likely to leverage incremental development methodologies), that assessment often includes an independent, sometimes adversarial, examination of an exhaustive list of "security controls" that apply to the information system. If the independent examination team identifies any problems with the controls that the ISSO determines are significant, then the project manager must either fix them as a condition of receiving ATO, or must submit a plan to fix them. As too many weaknesses will bring added scrutiny (e.g. from the agency Inspector General (IG) or Congress if the system is large enough), CIOs will generally only authorize systems with limited assessment findings.

Project managers face a significant process dilemma when considering an incremental development methodology. The typical timeframe to just support the independent assessment and authorization processes (3-6 months total in my experience) is simply infeasible when pursuing development sprints of 4-8 weeks to complete an incremental release. In response, project managers could define a broad system boundary to limit their exposure to the process, but then they would be unable to rapidly release system functions to their user populations since the system would have to meet most of the security requirements associated with the boundary. That effectively nullifies the efficiency gained through incremental development. Essentially, this would approach would drive the project manager to accept a big-bang release schedule (one release after developing all of the functionality) that perpetuates the lengthy transition periods at the heart of large-scale system integration failures.

Alternatively, project managers could constrain the boundary definition to promote more rapid delivery. But, as each boundary shift would represent a major change warranting reassessment and reauthorization, the ISSM or CIO would likely disapprove the plan because the higher assessment frequency would simply cost too much. I also doubt that the broad control definitions (usually agency defined based tightly on NIST SP 800-53, currently in revision 4) would even allow a system to pass the security assessment as boundary constraints would only result in a limited reduction in control requirements.

Basically, if a project manager chooses an incremental system development methodology to more quickly meet user needs and promote greater acceptance, then it will actually result in government inefficiency that's comparable to a big-bang failure. So, the best managers I've seen that apply an incremental approach do the only thing that's left in their toolbox: hide the system for as long as possible to thwart oversight. They put Billy Flynn's tap dancing to shame, all in the pursuit of more efficient government.

Short of NIST issuing new guidance on how agencies can adjust the Risk Management Framework, I believe that the responsibility must fall to the agency CIOs to develop a new authorization process. Balancing compliance with NIST guidance against supporting incremental development methodologies will require significant change on both sides. In the next part, I present what I believe is a plausible solution and explain how implementing it may even empower agencies to improve overall security posture.

For much of my career, I served as an enterprise security consultant for the U.S. government. I derived much of the basis for this post from my experiences on the inside. My experience includes a stint as a trusted advisor to a Treasury Department Chief Information Security Officer (CISO) whom I assisted in developing a broad agency-wide security program, a couple years as a security program manager for a major infrastructure consolidation effort at the Department of Homeland Security (DHS), and as a security program manager for a large-scale project at the Department of Veterans Affairs (VA) where we applied an Agile incremental development methodology modified to support system integration management. I currently manage an applied research development project where I developed another modified Agile methodology, this time focused on incremental development to support short-term research objectives within a multi-year strategic research vision. Whereas my current work requires no interaction with security certification authorities (yet), I worked closely with ISSOs/ISSMs in my past work and the current project resides in a domain with strong security requirements. I speak from my general experiences and nothing that I discuss in this post should be attributed to any specific project or other engagement.