OWASP AppSec Day 2018 – Melbourne

29 Oct 2018 OWASP AppSec Day 2018 – Melbourne

I was lucky enough to have the opportunity via Shine recently to attend the inaugural OWASP AppSec Day 2018 (Melbourne) at RMIT. Security professionals from around the globe gave some insightful talks into the state of secure application development in 2018. In this post I’ll share you some of the key insights I gained from these talks.

We Broke the Build: How Security Failed the DevOps Movement – Keith Hoodlet

Starting the day we had the keynote from Keith Hoodlet. This talk really set the tone and presented one of the main recurring themes I heard throughout the day: security teams and professionals within organisations have failed to keep pace with the shift in recent years to a DevOps mindset. This has not only led to security professionals being seen as blockers to progress, but has also reduced the benefits gained from the “small batch, release often” cycle that comes with modern agile practices.

The prescription for this? DevSecOps. As numerous speakers pointed out, the term has often had a bad rap as the latest buzzword (quite often due to companies looking to make a quick buck out of it). Nonetheless, the principles are sound and align with how the development world is shifting when it comes to software creation.

Keith’s talk focused around the above DevSecOps manifesto. The manifesto itself is too big a topic for one blog post, but you can find more about the general ethos at http://www.devsecops.org/

It was a great start to the day and a call to arms for security professionals to become enablers of secure development practises.

Why ‘Positive Security’ is the next security game changer – Pieter Danhieux

Despite claiming to hate public speaking, Pieter Danhieux (CEO of Secure Code Warrior) showed no sign of this during his talk.

Pieter started off with an interesting thought: in which other engineering disciplines do students have to opt-in to security and safety electives? Are mechanical engineers given the option to opt-in to electives on providing infrastructure that doesn’t collapse and hurt people? Yet for software engineering, this is the norm.

One of the key points I got from Pieter’s talk was that we are presented with a scale problem that can’t be solved by our current toolsets. That is on top of a real shortage of well trained security professionals (as per slide below, it’s not uncommon to have 1 security professional per 200 developers in an organisation), and a general lack of security training for developers.

One of Pieter’s key prescriptive measures for this was to distribute security knowledge amongst developers. All too often breaches caused by bugs in code are not down to complex 0-day attacks, but decade-old vulnerabilities that have been written into software; this being due to developers not having adequate methods for sharing secure code practises with other developers they work with.

Part of this can be addressed by creating common shared libraries. When a developer fixes a SQL injection bug, they can put that into a common library, and other developers can use it from that point onwards.

Domo Arigato, Mr. Roboto: Security Robots a la Unit-Testing – Seth Law

Seth Law started with the question: what are exploits? Essentially they are just bugs in code. What is one of the primary tools in a developers toolbox for preventing bugs? Writing unit-tests.

From this Seth delved into the idea of writing security unit-tests as part of your normal TDD process.

Much of Seth’s talk focused around a unit testing tool he has developed called sputr

One of the primary drawbacks of dynamic security testing tools like Burp suite is the time it takes to scan your sites for vulnerabilities. This is due to the brute force nature of these tools. The mathematics looks something like (number of endpoints * vulnerability type * payload for each vulnerability). As you can imagine, for large-scale software the time taken to run these scans scales dramatically with the number of endpoints in your software.

Rather than being this all-encompassing vulnerability scanner, sputr aims to take some common patterns which indicate that an endpoint will definitely be vulnerable to a certain kind of attack, and executes appropriate tests. The beauty of this approach is the speed of execution. You can run these tests as part of your CI/CD process and fail your build if you find a vulnerable endpoint. This is much faster than running a brute force scan that tries to execute an exploit against your site.

You want CVE with that? Using components and staying secure – Nina Juliadotter

The vast majority of code in applications we write is not our own code, but components we pull in as dependencies to our code. As Nina Juliadotter pointed out at the start of her talk, on average this is around 90% components to 10% our own code.

For a long time, developers have mostly just trusted that the components we use are secure.

As Nina pointed out via the widely publicised Equifax breach, this is most definitely not the case.

As per Nina’s slide above, the Apache Struts vulnerability at the heart of the breach was patched over two months before the first attacks at Equifax started.

So what to do about this problem? Automated vulnerability scanning of course! You can put these tools into your build pipeline and fail builds if you find vulnerabilities that match certain vulnerability criteria that you deem unacceptable. Some more sophisticated options like Snyk even allow for continuous scanning for new vulnerabilities even if you aren’t building your software regularly.

Below are a list of tools that Nina mentioned:

https://snyk.io/

https://www.whitesourcesoftware.com/

https://www.blackducksoftware.com/

https://www.owasp.org/index.php/OWASP_Dependency_Check

Let’s breakout!!! – Scott Coulton

Scott Coulton from Puppet started his talk with a simple question:  “Is it that easy to break out of a container?”. It turns out if you follow a number of best practises for creating and running containers it is really hard to break out of the container into the host operating system.

Let’s look at a couple of suggestions

Don’t use the –privileged flag when starting a container

By and large, this is just bad. Doing this effectively gives your container root access to the host as the docker daemon runs as root. There is rarely a reason to use this flag.

Don’t use –pid and –net flags

These flags allow you to break the process isolation model of docker and allow you to view/kill host PIDs and connect to privileged network ports.

Be careful with your volume mounts

Be very careful with folders you mount from the host into a container. Mounting something like /etc into your container is, at best, going to give someone read permissions to your host configuration, and worse allow someone to have root write permissions in your host configuration files.

How about some pro-active measures to make sure we don’t put containers into the wild with these problems in them? Two that Scott mentioned are Clair and Docker Bench for Security. Both these tools can be included as test steps in your build pipeline so you can scan for misconfigurations and vulnerabilities in your containers.

One of Scott’s strong recommendations was to start signing your containers, and to use something like Notary to ensure you are only using signed pre-approved containers.

Gamifying Developer Education with CTFs – Max Feldman

Finally we had a talk from Max Feldman of Slack. Max presented an overview of Slack’s October Capture The Flag event; something it runs internally to encourage an organisation-wide security mindset.

For the last two years, Slack has run a company-wide capture the flag security training event internally. Employees from all areas of the business (including non-technical) are encouraged to participate and solve an increasingly difficult number of security problems.

To me, this seemed like a really great addendum to traditional security training. What better way to get insight into security than a hands-on exercise like this?

Slack used fbctf which is a capture the flag platform written by Facebook.

A couple of takeaways from Max’s presentation:

• CTF is a great way to encourage all employees to think about security
• Don’t underestimate people! A number of individuals completed all the initial challenges in a couple of days
• There can be a productivity decrease (employees doing CTF instead of work), so you need to think about how to best manage this before starting the event.

Wrapping up

For someone like myself in the DevOps area, this event was a great opportunity to gain insight into an area that is at times isolated from me.

Overall there are a few key items I took away from this event:

• Put your security tools into your build process. Bugs and breaches become much more expensive to fix the further along your development process that you put security.
• Don’t make silos. Encourage security practises and understanding at all levels of your organisation.
• Encourage the creation of secure shared libraries so developers don’t have to re-solve the same problems repeatedly (or worse, not solve them).
• Don’t implicitly trust third-party components. Scan and verify everything you put in your code base.