Meetup @FT: Testing Security as Part of Continuous Delivery

by Martin Roddam

At the end of May the FT was excited to host the London Continuous Delivery meetup with the topic ‘Testing Security as Part of CD (Continuous Delivery)’. The focus was on trying to build security into software from the start.

There were two excellent presentations. One from Phil Parker, a partner at Equal Experts, and another from Ian T Price who is an independent consultant. Both presentations and a link to the meetup can be found at the end of this post.

Here are some of the most interesting takeaways from the two presentations.

DevSecOps

This essentially builds on DevOps by stating that security should be core to a software development team’s thought process and indeed the code itself. It didn’t feel particularly ground-breaking, but it’s certain to be a growing trend.

The Attack Window

Clue: it’s not this.

The attack window is the time taken from the initial deployment of vulnerable software to production, past the time at which that vulnerability is recognised, past the time it takes to implement (and test) a fix, to the time of eventual deployment of said fix. This is the window where hackers look to exploit that vulnerability.

Bug Bounty Programme

[caption id=”attachment_8827" align=”alignnone” width=”840"]

“Responsible organisations should operate a bug bounty programme”[/caption]

This recognises and rewards individuals for reporting vulnerabilities in a responsible manner. People often end up tweeting about a vulnerability when there were no formal channels of communication open for reporting these kinds of issues.

The OWASP Top 10

Phil did acknowledge that this list was by no means comprehensive and that hackers have high levels of creativity, but points out that it’s a good place to start (due to be updated this year).

He tweeted a handy poster to illustrate common vulnerabilities and a typical defence. Click the following to download.

[caption id=”attachment_8828" align=”alignnone” width=”150"]

OWASP Top 10 Poster from EE[/caption]

The Agile Security Manifesto

Much like the Agile Manifesto it contains a set of core principles (rather than a process) to guide proactive, security-conscious organisations:

Rely on developers and testers more than security specialists.

Secure while we work more than after we’re done.

Implement features securely more than adding on security features.

Mitigate risks more than fix bugs.

More detail available here.

Security “Theatre”

This is the process of investing in practices designed to make your users feel more secure without actually doing anything to improve security. This should be recognised and flagged as such in organisations.

Security Techniques and Terminology

Part of the Phil’s presentation was aimed at ensuring everyone had an understanding of common terms and techniques. It’s a common mistake to confuse encoding with encryption. He talked about one-way cryptographic hashing and salting as good ways of securing your data.

Phil also mentioned that it was a common perception that encrypted data guaranteed integrity. Attackers may not be able to steal the data, but they could change it in situ. The data may decrypt, but may then be meaningless.

Cloud Security Alliance ‘Treacherous 12’

Similar to the OWASP Top Ten but, at present, more up to date having been updated in February 2016. Find it here.

Zed Attack Proxy (ZAP) security test tool

This open-source tool is essentially an automated vulnerability finder and reporter. It works with web applications and APIs alike. There are Jenkins plugins that can trigger the tool in order to incorporate it into continuous integration pipelines. It has a REST API and can be run in headless mode.

There are examples of integrating ZAP with Selenium — ZAP follows user sessions created during Selenium’s interaction with an application and identifies vulnerabilities during the course of test execution.

Ian Price’s slides that mention ZAP can be found here.

This tool makes it very easy for anyone even vaguely tech-savvy to find common vulnerabilities. It struck me that as well as being a useful tool for software development teams, it’s also an extremely powerful tool in the hands of a skilful, dedicated, time-rich and creative hacker. Tools such as these are probably the absolute minimum an organisation should be using for anything public-facing.

Download here and handle with caution!

The BodgeIT Store

For anyone looking to practice their skills in penetration testing / hacking. This sample web application is built with deliberate vulnerabilities to be found.

Security Front and Centre

Security is no longer the exclusive domain of external consultants. Highly-motivated, highly-skilled and creative individuals are at work around the clock seeking out the vulnerabilities in your software. There is no excuse for not spending some time learning about common exploits and getting hands-on with tooling that is free, easy to use, and powerful. We must assume that those with malicious intent have access to at least the same tooling.

When assessing risk we can no longer accept statements like “who on Earth is going to find that?” because we know exactly who.

You can find more information on this meetup here: http://www.meetup.com/London-Continuous-Delivery/events/228002697/

Phil Parker’s slides can be found here: http://www.slideshare.net/EqualExperts/continuous-security (note that they are deliberately in reverse order!)

Ian T Price’s slides can be found here: http://londoncd.centreline.biz/