Automated Testing: Remember Security

Source – devops.com

Between continuous integration (CI) and release automation (RA), we’ve come a long way in making testing both integral and automated. This testing has allowed QA staff and developers to spend more time adding value by looking at problem areas instead of running tests by hand. Shops that have CI well-integrated into their application processes and are using test driven development (TDD) claim they have improved both time to deployment and code quality.

But we’re still struggling to get security adequately integrated into the overall system. Part of this is that some testing—such as application-level penetration testing—is very custom to the application being developed. There are tools to help, and they do offer some amount of automation, but they’re not yet to the point of being the only route to test. The other reason is that even today security and compliance are seen as road bumps that slow deployment. It is sad but true that the V-Tech data breach was a simple SQL injection attack. No doubt security was not involved in the deployment of that dozen or so websites/databases, or if they were, their ability to influence the product was limited.

But automated testing can help in many of the standard attack vectors that SQL injection is just one example of. And for some reason, an automated tool informing DevOps teams that they have to fix a whole slew of vulnerabilities is taken much better than the security team doing the same thing.

The breadth of security concerns mean that security must be involved at some level in every phase of DevOps. But tools can lighten the load, and the tools are getting better all the time.

And the idea that a breach is a risk that should have a certain level of acceptance is no longer en vogue. Doing what you can to avoid them, and paying the price to do so, is increasingly the norm. Automation tools help to cover not just the employee time gap, but also the skills gap. If a tool can validate the entire deploy environment for your chosen cloud environment at the time of deployment, that relieves any shortage in knowledge about the security features of your given cloud environment. Of course, eventually security staff will need to know more, but just like a deployment tool can throw up an entire big data infrastructure in hours instead of weeks, leaving operations time to learn about configuration details as they need to, security automation can do the same for security teams.

I highly recommend looking at building standardized controls into both the test environment and the deployment environment. While you won’t get perfect automation yet, you will get automation. The overall result of that automation will be increased security posture for the business, and since compromises are a business risk, that is in line with the overall point of DevOps: better serving the business. There will likely still be more work than there are hands/eyes/brains at this point (which says a whole lot about our pre-automation security posture), but you’ll be better off.

As I and others have mentioned, a small security staff will likely have to be trainers/consultants to Dev/Test/Ops functions to properly support all of the needs of locking down an application. This is still true with a high degree of automation, simply because there is a large surface area, and we’ve traditionally gone with the “most urgent” issues first. But just as automating (with human controls/approval) updates where possible to get the newest protections has reduced workload, so can automation of other security goals. I chose the word “goals” on purpose. It’s not about today’s processes, it’s about achieving goals, so just as Dev was taken apart and re-assembled for agile, and Dev and Ops changed how they do things for DevOps, look for the best, most efficient way to achieve the goal. And like everyone else in IT, iterate on it.