Agile. Devops. SDN.
Development. Operations. Network.
Notice anything missing? How about security? On the one hand, that could be because we’ve finally managed to realize that security is an integral part of every aspect of IT and it’s by default embraced by the other three groups already.
I’ll pause while you stop laughing and catch your breath.
On the other hand, it could be because it’s like every other technological movement and advancement and we’ve simply plowed ahead without considering security until, as is always the case, someone remembers that security is important too. If development, operations and the network teams are going to have an answer to improving the speed with which applications get from the IDE to the end-user’s iPhone, then shouldn’t security have a seat at that table, too?
Absolutely.
It can be argued, in fact, that some areas of security already have a seat at the service velocity table. Consider automated pen testing, virtual patching and continuous vulnerability assessment services. These are often continuous processes that integrate (sometimes) with existing systems or, at a minimum, with some process through which aberrations can be noted and addressed.
It’s important to note that this – and devops – isn’t a plea for automation. Automation and orchestration are tools in a toolbox that may or may not be a fit for a particular tasks or process. Most enterprise organizations, for example, refuse to automate changes to data center firewall rules. Not because it can’t be done – it can – but because the ramifications of a change going wrong is too great to take even the small risk that might be incurred.
But in the interests of speeding up the deployment process (in which security is – or should be – a significant player) there are likely adjustments that can be made to align security with other groups already adopting more agile methodologies.
For example, consider that along with agile development often comes a “nightly build” of the software, designed to ensure that changes don’t break the complete package. It might be beneficial for application security-focused assessments to be inserted into that process, to test early and often the security profile of the software being developed. This helps in two ways: first, it ensures that developers can be made aware of potential vulnerabilities while they’re actively developing the software. That’s important because one of the precepts of agile is move quickly and by the time you’ve found a vulnerability in the released software the developers are already half way through the next spring and not thinking about what they just tossed over the wall.
Second, if there are vulnerabilities that turn up that developers can’t, for some reason, address you have a head start in figuring out how to mitigate them. If that requires a security service of some kind, you’ve got time to get the right policies into place before the application hits the Internet and becomes a target.
There are plenty of ways in which agile methodologies can be adopted by security professionals. One of the precepts of devops is getting outside the silos that exist within the organization and communicating with the other folks seated at the “get the application to the user” table. Being more involved with development and operations and even the network will enable security to integrate more fluidly with the increasingly agile processes that drive the application lifecycle.
