Automation In Application Security

First of all, thank you everyone for coming. I appreciate that you are here, that’s the last talk of the day. Today we’re going to talk about application security and how to automate security in pipelines. I’ll start introducing myself, my name is Javier Dominguez, I am an application security engineer. I don’t do Facebook, I don’t do Instagram, and yeah I’m a human being so you can talk to me if you see me around, if you have any question talk to me. So what we’re going to be talking today is about security in applications, in fact, about the lack of security in applications in the SDLC. We will see which controls we can apply in the software development lifecycle to prevent vulnerabilities.

How to automate those controls, and we will support this with a practical example. It’s a demo application I’ve built called Vulnerbank, it’s an online banking system that has several vulnerabilities. When a company is breached, we usually hear what happened, what was the impact, sometimes we hear how it happened and what was the impact. And we always hear the typical ‘we take your security very seriously’ which translates that we just realized that our firewall is not enough. But we don’t usually hear: why did that attack happen? Which controls have failed in the SDLC and what else could have been done to prevent those attacks? I mentioned before I have a vulnerable application and to support this presentation, we are going to use this as a template.

This is an online banking system where you have to enter your details, which is user and password and then it displays your accounts. In general, the lifecycle of an application is something like this, everything starts with a set of requirements with an idea. This is supported with an architecture and a design, then developers start building the code, this is tested. If testing goes well, the code is released and the application gets into operation mode, it’s running in production. Security is usually done here, just a requirement before releasing, that’s too late. It’s all about shifting left, which means doing security at the earliest possible stage and in all the stages in the SDLC. With the requirements, you define what you want your application to do, the typical as a user when I do this, this should happen.

But do you also define what you don’t want your application to do? That’s something that is not typically done and we should start creating user stories applied to our Vulnerbank application. Moving to the design stage, we should create a threat model. Threat model is the exercise of based on our architecture identifying which threats our application is exposed to. Back to our Vulnerbank application, we have a very simple design, we have a front end with an HTTPS connection to the backend. At this point we have identified two threats, a weak HTTPS connection and a potential SQL injection. Before writing any line of code, we have to have some good practices on hand, we can use frameworks like NIST 5, SKF, proactive controls from OWASP.

Even if we’re following that, we may make mistakes, so we have to analyze our code statically with a SAST tool to make sure there are no vulnerabilities in the code. Equifax was breached not because of a problem in their code, they were breached because they were using a vulnerable version of Apache Struts. All the controls that we have designed are working as expected. You remember that before we created some automated tests for the logical flows. What happens tomorrow? Can you guarantee that tomorrow your application is still going to be in that good shape? Probably not. We need to be continuously testing our application, we need to attack our application automatically to make sure when there is a new vulnerability, we can detect that.

What we’re going to do is run a pipeline using Jenkins where we are going to be checking out the code, we’re going to run the static analysis and analyze the libraries. Our slack connection that is linked to that Jenkins build is starting to report things, SAST step failed, there is a potential SQL injection detected. The idea of this talk is shifting left, don’t leave security for the last minute, automate everything, attack your application thoroughly and build a strong monitoring and alerting system.