Agile security has emerged as a core topic for us in two cutting edge consulting engagements over the past few months.
The first of these engagements is to help a very large client develop and mature an enterprise risk management framework. This client just so happens to be adopting the agile methodology, not just as a way to develop software, but also to execute every project and business initiative undertaken in the enterprise. Literally.
We’re in the process of reaching out and asking colleagues such as Jack Jones (CEO, RiskLens) about incorporating the Factor Analysis of Information Risk (FAIR) or other risk methodologies into an agile delivery paradigm. This post is also our message in a bottle to you; please comment below! Does the idea of “agile security” have you tearing your hair out? Have you seen or can you suggest some good practices?
In addition, we recently worked with a financial services company on developing a container security reference architecture. Strictly speaking, that’s not an agile project but we’ve found in practice that containers, agile development methodologies, and DevOps practices are inter-related trends.“Dev 2.0” anyone?
Is “Agile” Bad for Security?
Let’s take a step back to discuss the challenges enterprises face with agile security in general.
Agile project management is an iterative, incremental method of managing the design and build activities in software development and other endeavors. The Agile Manifesto centers on four values: frequent communication among project participants; focus on getting something working over rigorous processes or documentation; collaboration with clients; and openness to changes.
These sound like good things.
The problem is that agile projects can run into pitfalls. We’ve seen teams skimp on upfront discovery of requirements and/or shortchange any analysis of how the solution will integrate into the enterprise application portfolio, strategy, and architecture. All too often, agile solutions ship with inadequate documentation.
Is “Waterfall” Good for Security?
It’s only fair to look at the competition, right?
Security programs have traditionally been grounded in methodologies that have more in common with waterfall development than agile. The classic waterfall project includes formal requirements definition, well-documented designs, full verification/testing, and scheduled maintenance. If there were a Waterfall Manifesto it might read: “Get it right the first time!”
These also sound like good things.
The problem is that as organizations move towards “Dev 2.0,” efforts to engage developers through waterfall-based engineering and assurance processes can make the security department seem irrelevant. Last year, we had a long-running consulting engagement with a highly-decentralized multinational company with multiple business-driven custom applications and cloud services. As one staff member of the CISO’s engineering team put it, “Business developers come to central IT asking for solutions to a problem and are told it will take 6 months. Then its late. They won’t be back.”
Good Practices for Agile Security
Going through these scenarios, it’s clear agile is not intrinsically bad for security (though it can be). Also, security departments with rigid waterfall project management methodologies may be out of pace with business developers.
So what’s the answer? During our container security consultation with the financial services company (and previous investigations of DevSecOps), we’ve recommended adapting control framework and assurance processes to accommodate new trends such as microservices and automated continuous development / continuous integration pipelines. Then, Influencing the development organizations to standardize methodologies and tools so that security capabilities from risk assessment, to code reviews, to vulnerability scans can be embedded in the agile or DevOps processes.
Agile Risk Management?
How should these security capabilities be created and integrated? And where to start? These questions reside with security and risk management organization and governance – the subject of our risk framework engagement with the large, agile-minded client mentioned at the beginning of the post.
We’re early in the process of creating an agile risk management framework for the client, but I’ll share one teaser. We strongly disagree with the notion that “risk management is intrinsic to the agile process.” From what we’ve seen, the agile methodology only addresses project execution risk, not information security risk. Security risk is different from project risk. Security risk endures long after development projects are completed and for as long as applications remain in production! Risk can also increase as applications find new use cases (consider an internal system that is re purposed, exposed to the internet, and loaded with customer data).
Conclusion
Stay tuned for more information from us on agile risk management (or contact us with any questions). Also, don’t forget to leave a comment below on what you’ve seen in this emerging space.
The post Is Agile Security an Oxymoron? appeared first on Security Architects Partners.