So, Agile Security? How does it fit into the new age of rapid iteration, continuous integration and continuous development? It’s an interesting discussion and personally very on point for me as I operate in an agile organisation and just today took (and passed yay me) my Scrum Master certification.
The traditional silo approach of security is already breaking down as in smaller organisations it was typically part of the ops team, and with the whole DevOps movement, infrastructure as code and CI/CD – that silo is already getting busted up.
And I have to agree, the next silo to combust will be security – it has to adapt, become more agile and more integrated into the development flow from the beginning.
Continuous delivery of software and applications is one of the most significant advancements that has taken place in the computing industry in the past 25 years. It is catching on so fast that you can now hear the death rattle of the 18-month software delivery cycle. The rise of cloud computing infrastructures — both in corporate data centers and infrastructure-as-as-service providers (IaaS) such as Amazon Web Services (AWS) — is powered by agile software development teams using orchestration tools like Puppet and Chef to decouple application development from the infrastructure, adding speed and agility to the enterprise.
Just as enterprise computing is having its DevOps moment, though, much of the security profession has woken up to the fact they are mired in the traditional infrastructure and silo approach. When everything in computing is dynamic, distributed, heterogeneous, and hybrid (i.e., alive), security that is bonded to static infrastructures like the network — an architecture based on hierarchies and chokepoints — appears out of sync with the new reality. If you are a security professional, continuous delivery and agile development is your future.
Consider the traditional approach to securing applications. Development creates a new app and then passes it over to the infrastructure team, which then onboards it to server, storage, and networking platforms. When that is complete, the security team comes in to protect it so employees, partners, suppliers, and customers can use it securely.
Waterfall is dying off, I mean it’s still ok for simple projects with few changes (low complexity) but for the real world, agile is SO much better at adapting to change and building relevant, high quality software which delivers maximum value to the business.
So security needs to get out of the oldskool models of being an after-thought, or an entire separate “ops” stage like architecture, infrastructure and deployment used to be.
For security to flourish in the age of continuous delivery, it must meet the following requirements:
1. Security policy must be embedded into the application development cycle at inception. This means developers must co-join with infrastructure and security teams to create and instrument policy when they are creating new apps. Just as continuous delivery dissolves the barriers between developers and infrastructure, security will be the next silo to go.
2. Enforcement of security policies must move and adapt with the continuous delivery approach. If new applications are moved between private clouds and IaaS environments, security must move with the applications.
3. Thus, security must be decoupled from infrastructure to support the distributed and fluid nature of continuous, on-demand applications and supporting infrastructures. This provides an added benefit of being able to dynamically add resources on-demand, including security
4. Finally, as Gartner notes, security must offer detective, preventive, responsive, and predictive capabilities that adapt with changes in the threat environment and provide transparency to the various IT constituencies involved.
So what do we do? What’s the way forwards? I’m personally a huge fan of tools like Code Climate which perform static analysis on every commit to your Github repo, it actually uses Brakeman for Ruby security for example and it’s all integrated so it works brilliantly in an agile development flow.
This pushes basic security responsibility to the developers and couples it with code quality, style and test coverage.
There’s much more than this we can do, but it’s a whole new movement I guess – exciting times ahead.
Source: Security Week
Stephen de Vries says
In my opinion, part of the answer lies in not treating security as a special and unique flower that is somehow completely different to other software domains such as Quality, Performance and Usability.
We’ve been pretty successful in adapting those domains to Agile, and in the case of software quality, one could argue that we’ve improved it through agile practices! I think a quick win for security teams is to look at how quality has been integrated into agile processes and simply copy it.
My domain of expertise is security testing, so naturally I’ve looked at how software testing is done in agile processes and copied it for security testing by creating the BDD-Security project. Essentially a set of pre-written acceptance tests applicable to web application security.
I completely agree that security as a silo must go- and that means equipping the dev and ops teams with the tools and knowledge to take full responsibility for security. A dedicated security team still has an advisory role to play, but in a CI/CD process it can’t be the primary security function because limited resources means they’ll inevitably slow down the process.