Over a million developers have joined DZone.

Application Security-as-a-Service Changing Landscape for SMEs and Enterprises Alike

DZone 's Guide to

Application Security-as-a-Service Changing Landscape for SMEs and Enterprises Alike

Real-time protection software democratizes AppSec and challenges the “safe bets.”

· Performance Zone ·
Free Resource

I had the opportunity to talk to Zaid Al Hamami, CEO of IMMUNIO, about the state of application security today.

IMMUNIO provides automatic detection and protection against web application vulnerabilities with patented runtime application self-protection technology (RASP).

How have you seen the cybersecurity threat landscape changing recently?

The threat landscape for web applications has certainly changed as more and more organizations become cloud-based and adopt agile development. The DevOps movement is built on the desire to be fast for that reason, but this is where traditional security shows its age. Old-school SAST is not capable of effectively supporting popular dynamic languages like Javascript (Node.js), Python and Ruby (Rails), and moreover, even commercial-grade static analysis tools require five days or so to produce reports ridden with false positives. Tuning such tools takes another 15 days or so, per application, requiring highly specialized expertise that is not always available. Without this heavy lifting, such tooling is generally ineffective. This approach isn't viable in a DevOps environment, which is why we're seeing the move to DevSecOps. Organizations need agile and scalable solutions that don't require heavy manual operation.

With the complex threats facing organizations today, security teams are less concerned with checking boxes and doing security for compliance’s sake. They want to find solutions that actually work. Five years ago, it was only the giants HP, and IBM for example who offered the high quality forms of application security technology, but that's not the case anymore. With so much innovation happening in the space, organizations have new options to evaluate, and they're moving away from the “safe bets.”  

IMMUNIO's runtime application self-protection (RASP) technology is one example of a solution that's attacking application security in a new way – and we are attracting the attention of a lot of Fortune 1000 companies, which traditionally have been very conservative, to solve today's complex security problems.

What “real world” problems are being solved with your solution?

1) DevSecOps wants manageable security that works against advanced attacks and languages like Node.js, Ruby on Rails and Python. The modern developer's toolbox demands workflows with agility and continuous security, and IMMUNIO fits with that.

2) Application security is no longer something only seen at big banks and large organizations; AppSec as a domain is becoming democratized as smaller companies adopt it, too. Many organizations are hiring their first AppSec engineers and are working to implement different pieces of the AppSec programs. For most companies, it's extremely difficult to achieve full application protection with the traditional AppSec approach, even with secure programming and security reviews. There are legacy code vulnerabilities, and hackers are developing new approaches all the time. IMMUNIO helps by filling in the gaps, leveraging RASP to protect against vulnerabilities in the fastest possible manner and helping the DevOps team ensure the application is secure.

3) Bug bounty programs are a trend today in AppSec programs; however, there’s a lot of noise and manual work required to vet the entries. IMMUNIO can help clarify what needs to be addressed and eliminates much of the manual work that comes with an effective bug bounty program because we sit inside the app to detect vulnerabilities while attackers are attacking. Once a bug bounty hunter has found the outside vulnerability, an organization already has the internal information they need through the platform.  

What are the most common issues you see affecting data security?

The usual suspects of SQL injection, cross-site scripting and remote code execution are still   common issues today. What we’re seeing more of now, however, is attacks where hackers use millions of stolen credentials to execute full account takeovers through what is called “credential stuffing.” A half million machines doing credential stuffing can typically steal 4,000 to 5,000 accounts. Pen testing and static analysis tools don't detect this kind of malicious activity, and most applications on the web today are vulnerable to this kind of dangerous attack. We must protect against this new class of hacking by looking at new approaches to protection.

What do developers need to keep in mind when working to secure their data?

Common wisdom was to train developers on security. This has been done for 10 years or more, but there has been no correlation between companies that train developers in secure coding methods and fewer vulnerabilities in the applications these developers write. We cannot expect developers to be experts in security when they are being tasked with rapid delivery of applications. Applications are the number one place where attacks happen, and very small changes can put data or the customer at risk in very subtle ways. Developers need to demand AppSec-as-a-service that can work at the same speed they are. Innovative security technology today, like RASP, is designed to be lightweight and reduce risk drastically by fitting into the development cycle instead of hindering it.   

What else do we need to consider with regards to data security?

We’re at an interesting time right now with new threats facing organizations both small and large. The market has shifted with an emphasis on cloud and DevOps, and as a result, small companies with different ways of solving what the established players have been providing are being given an opportunity to show how they can improve web application security.

security as a service ,RASP ,devsecops ,appsec ,application security ,AppSec as a Service

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}