Governments must adopt an agile mind-set towards security
Fen Labalme and Robert L. Read of Agile Government Leadership, explain the role of an agile security process in highlighting and preventing security risks
Just as agile software development rapidly iterates on evolving user stories, agile security must rapidly iterate on an evolving threat environment as technology plays an increasingly important role in society. In order to protect against ever-changing vulnerabilities, we must rethink how we approach securing complex government systems.
Existing regulations, such as the Federal Information Security Management Act (FISMA), represent a static approach to security, requiring voluminous documentation of systems to achieve an official Authority to Operate (ATO) but having no real-time monitoring or verification that the system matches the documentation. This is the antithesis of an agile process, providing no incentive for continuous improvement.
Fortunately, government is working to improve this ineffective approach with the recent mandate for Continuous Diagnostics and Monitoring (CDM) by the Department of Homeland Security. CDM is an attempt to identify risks on an ongoing basis, but it doesn’t solve all security challenges for government (and in some ways, it adds new ones).
Ultimately, agencies themselves must adopt a more agile cultural mind-set when it comes to security. As agencies work to implement CDM requirements, they can also work to pivot away from slow-moving, risk-averse attitudes and embrace more agile, effective security. Here are some ways to start:
Have the courage to iterate
While CDM will enable better real-time review of systems and faster response to threats, agencies must start thinking beyond temporary fixes and demonstrate agility by iterating to new systems more frequently. Government tends to cling to old systems that have been deemed “secure”, applying security patches and nauseum instead of updating to new systems. This makes it difficult for innovative vendors (who are using the latest versions of everything) to safely provide beautiful solutions that work.
Agencies must understand that rapid iteration and fast response to problems is LESS risky than using an old system that was once deemed “secure” after a battery of tests, but is now 7 years out of date. Instead of fearing new systems, governments should embrace updates with an agile mind-set, realising that newer technology provides a more stable foundation that is far more secure (even with bugs) than an old system that is full of holes and patches.
Keep metrics flexible and responsive
One of the goals of CDM is to track metrics and standards of agency IT security (strong passwords, up-to- date patches, etc). But agility is lost when documentation of metrics takes priority over new learnings. For example, two-factor authentication might be shown to be more effective than a strong password, but agencies and vendors are still forced to comply with requirements based on outdated information.
Government should be open to changes in the way security is measured, just as an agile process demands changes in project direction when a better path is discovered. Adhering to outdated metrics because they are in the documentation is like traveling an old, rutty road even when a clear path is within sight, simply because the old road is the only one shown on your map.
Learn from failure
In an agile development process, there is intense focus on what can be learned from the customer or users. An agile security process applies that same intensity of focus to what can be learned from adversaries. Agencies should continually retrospect on any failings in security – not just applying patches, but embracing innovative ways to avoid the problem in the future. Being agile means having the courage to diverge from the status quo in an effort to achieve the highest performance possible.
Embrace open source
Agile technologists and vendors in the open source community are eager to provide solutions to government, but are hindered by the fact that the CDM requirements are behind closed source code. If the Department of Homeland Security would publish the APIs and data formats required for collecting and transmitting the required metrics, agencies could more easily benefit from the collective knowledge of open source innovators, gaining access to solutions that reflect the most recent learnings.
Security is never “done”
Agencies shouldn’t ask “Are our systems secure?” Security is not a destination to be reached or a project to be checked off a list. Rather, agencies should ask “How have we recently improved our security?” That is an agile question that will prompt a re-examination of static approaches and lead agencies on a journey of continuous improvement towards better, faster security.
Chief Information Security Officer
Robert L. Read, PhD
Presidential Innovation Fellow
Founder, Public Invention
Agile Government Leadership