As anyone involved in testing knows, all the challenges in this space have been solved long ago. If we still have bugs, it’s only because engineers are lazy: existing practices and technologies can surely catch all issues, if properly applied. Finally, security bugs are just bugs, ergo security testing is also a solved problem for non-lazy engineers.
In this talk I’ll try to debunk this blatant lie, looking at some of the lessons I’ve learnt dealing with security testing in an uncomfortably large infrastructure. After demonstrating that security testing is a full citizen of testing practices and not a weird alien, I’ll trace my journey in building security testing tools at Google.
Spoiler alert: There won’t be any Hollywood style root-shell-and-ride-off-into-the-sunset moment: security testing at scale is a trench war, not a walk in the park. In a surprising turn of events, I’ll also cover the things that did not quite work and those that did not work at all, because sometimes failures are even more interesting than victories.
If you care about in-the-trenches security, are curious about the tiny details that can derail an initiative, or need to worry about security testing web software or infrastructures, then you might find this talk interesting.
Claudio Criscione leads the Information Security Assurance Automation team at Google: a very long title for a group that scales security testing — a lot.
In a previous life he was a penetration tester with a keen interest in cloud and web security. He presented at the main security conferences and has released a few security tools and advisories. These days, he reviews design documents and worries a lot about security testing strategy, coffee quality and preventing facepalm security bugs.