Identify web application vulnerabilities and prioritize fixes with Netsparker

In this Help Net Security podcast, Ferruh Mavituna, CEO at Netsparker, talks about web application security and how Netsparker is helping businesses of any size keep their web applications secure.

Here’s a transcript of the podcast for your convenience.

Hello. Thank you for tuning in. Today we’ll be talking about web application security because hacked web sites and security breaches are no longer news. They have become a daily occurrence, even though professionals know how they are happening and even though we have all the right tools. We’d like to find out how come these are still happening. Maybe businesses are not aware of the available solutions or maybe they do not have enough resources. Let’s find out.

Today we are interviewing Netsparker CEO and founder Ferruh Mavituna, and we will talk about web application security and how Netsparker is helping businesses of any size keep their web applications secure with their exclusive and cutting-edge technology. Thank you for joining us Ferruh.

Thank you for having me.

Let’s start with the first question. As I was just saying, hacking is no longer new. What is the problem with web application security and why are we seeing so many hacks?

When we look at web application security, I think we kind of undermine the problem. When you have one developer, when you have one web site, it’s kind of straightforward and you say “oh, it’s kind of easy to secure your web sites”. But it’s not that easy. We got two major problems in the industry. One of them is that businesses have too many web applications.

If Google was securing only one web application, I am pretty sure you wouldn’t find many vulnerabilities on that one application. But when organizations in that size, whether governments, education, tech, space, when they have hundreds if not thousands applications, then it’s a very challenging task.

The fact that majority of the companies don’t even know how many web sites they have, because organizations are so well distributed, and got so many different departments, and there is no centralization, it’s like everyone is popping up websites and microservices and APIs all over the place, and there is no single process to make them secure. On top of that, the problems become even worse when they don’t have big enough security teams to support these large number of web applications.

These two key problems are the core of the problem that we are seeing today, and the challenge with the older companies – they are moving to very Agile models and are very decentralized. That means the challenges are constantly being pushed in these web applications and also new websites keep popping up, new services keep popping up in these organizations. With small security teams, it’s virtually impossible for them to catch up with most of today’s solutions.

Fair points. However nowadays, like Netsparker, there are many automated tools, automated scanners, that teams can use to find security issues, yet we are sensing these issues. Any idea why?

The key problem in here is, when you have so many websites, automation is supposed to solve the problem. But what we see, people talk about scalability. The simplest way to understand scalability: “Hey, can I run 2000 web application security scans?” The answer is yes, pretty much anything in tech world today you can scale on the cloud and everyone does it. That’s a good thing.

But it doesn’t really solve the problem because, while the scanning itself is scalable, solving or the whole process of web application security is not scalable today. The core reason of that is false positives. What happens is, we talk about secure development lifecycle and with this scalable web security program we expect to have web security results, like vulnerabilities, identified in a scalable manner and reported back to developers and individuals.

But imagine you have 1000 web sites and imagine you ran a scan, and on average you got 5 to 10 issues per website, now you’re looking at 10,000 issues and any one of them can be a false positive. Even if you were to distribute them to individual responsible parties, you expect every single one of them to review and understand false positives. If these are developers, if you keep sending these results, they will stop taking you seriously because signal/noise ratio becomes a problem. The false positives are one of the biggest problems of today. That explains why we cannot scale well.

Wouldn’t a bigger security team solve this problem?

Not really. In theory maybe, in practice never. Part of the problem is, the process itself is very not scalable and very bottleneck driven. You cannot tell a developer “Hey, don’t push features for two days because I’m still catching up with your previous features that you pushed, and I’m still testing them.” On top of that, realistically, even if you want to tie all these people, even if you have all the money in the world, the talent is not there. There’s just not enough security talent in the world that we can hire and address this problem. So, you definitely need, we need, as an industry, as a whole organization who relies on web applications heavily, a scalable solution independent of human resources mostly, because it doesn’t scale.

As you said, many companies nowadays are distributed a lot, they depend heavily on web applications. What is the solution? I know Netsparker is doing something differently. Can you explain how Netsparker is doing web security differently and how it’s helping in such situations?

We actually have two key pieces to address the scalable problem and we have been working on this for the last four or five years. As I said, the core of the problem of scalability is not how many scans you can run, but it is about “can you scale the whole process?”, which is not just finding vulnerabilities. It is finding vulnerabilities, ensuring those vulnerabilities are not false positives and actually vulnerabilities that you want to address and fix, so actionable. Then sending these vulnerabilities to the right people, so you don’t create a bottleneck of a security group who takes these vulnerabilities and then assignes individuals. Then ensure that the vulnerabilities are addressed.

In Netsparker, to address the false positive problem, we have a technology called Proof-Based Scanning. The way it works, when Netsparker identifies a vulnerability, it actually approves whether it’s a real vulnerability or not. Let’s say it’s a SQL injection, it doesn’t just say “hey, there’s a SQL injection, it might be exploitable”. Instead it says “hey, I found this SQL injection and here is the data from your database”. It’s all automated so automatically you know the vulnerabilities are not false positives and these are very real vulnerabilities.

When it comes to the second part of this challenge, this is how we solve the false positive problem. Whenever we have a vulnerability, we know whether it’s real or not, and we prove it to anyone with a proof, like data from the database or file form your server, because there is a local file inclusion. The advantage of this, it’s not just the security team can simply say “hey, I don’t have to double checked this, that’s definitely correct”, but now you can send this data to anyone, developers or whomever is responsible for addressing these, and you will never get an objection because they know this is real because they can see the proof.

Historically, this is one of the key problems why a lot of web security programs cannot scale. One security group needs to review every single result to avoid sending false positive to developers. Even after that, developers will come back and say: “Is this real? Can you reproduce? Can you prove that this is real?” Especially in a very large organization. That’s the solution to a false positive problem.

There is another problem that I mentioned: what happens after that? How do you send to the right person? How to ensure they fix it? How do you rate it? We got the whole workflow and integration to address that problem. When Netsparker finds a vulnerability, it triggers the whole workflow of rules, and workflow rules are like “hey, send this vulnerability to the person who introduced it in the first place”. It actually matches up to user names from the developers’ source code repository user like a Git User, SVN User, and then create a ticket for the same user by mapping it to the bug tracking user, like a JIRA. When a developer introduces a vulnerability, they get a ticket, not one generic person, not the security team, but that particular individual developer gets the ticket.

This is very decentralized, there is no bottleneck in the middle and stuff can just work, even when the security team is sleeping and wakes up at the other side of the world only to see “oh, a developer in Europe introduced a vulnerability, creator gets a ticket in half an hour fixed that problem, then marks it as resolved in their bug tracking system Jira and then that problem retested the confirmed deployment and the fix was successful by Netsparker. By the time security team wakes up and looks at these, vulnerabilities are introduced, identified, reported, fixed, retested and closed. And this is why we can scale that web security process, whereas any other solution is just going to fail to do that, or any other approach to this problem is just not going to scale.

The way you are doing it, if you integrate Netsparker as the SDLC development workflow or any other type of development environment, you are basically automating everything, post scanning. You just need a little bit of supervision from the security team to ensure that things are going correctly, right?

Exactly. That’s what makes this a very bottleneck for your kind of scalable process, and on top of that, now your security team is free to tackle bigger problems. Now they got visibility into the whole process and they can even say something like “oh, okay now developers are introducing these vulnerabilities and, yes, Netsparker catches them, our program catches them, and it addresses them” but they keep introducing. Maybe they can take some strategical action like “oh, okay, let’s get them this particular group of developers, let’s get them secure code training”.

They kind of elevate themselves from these individual problems like SQL injection, XSS scripting, etc., and they can make strategical decisions based on the data that they have accumulated in thousands of these scans and in their websites, and they can tackle all these big chunks in a systematical manner. That’s the key piece, they get visibility into the whole thing in a way it was impossible before.

Thank you very much for the insights. Before we close, what does the future look like for Netsparker?

We will be focusing on addressing big problem of how do you gain control of your web security when you have hundreds and thousands of web applications. The future is very relevant to that. We are adding new pieces like discovery, identify all of your assets, even if you didn’t know it existed and it belongs to you. We are moving towards that, just keep adding features that help organizations to scale their web security program with the minimum amount of resources they might have in their security departments.