WAFs and SAST/DAST don’t provide adequate security for enterprise applications. There, I said it. Let’s dig into this assertion and see how we can improve the state of enterprise application security.

Before we begin, let’s look at an example enterprise webserver using NGINX, Node.js, and Redis.

Users access the application via NGINX, which acts as a reverse proxy sending traffic to the enterprise application running on Node.js. This example application uses redis to store its data. For now, we’ll abstract away deployment methods (K8s, OpenShift, Docker, VMs, etc.) and load balancing and scaling technologies.

Now that we’ve laid out our enterprise application, let’s talk about the Sec portion of DevSecOps. While there are many different threats to our shiny new enterprise application, some of the more common threats are:

1. Web app attacks (SQL injection, cross-site scripting, command injection, etc.)
2. Compromised credentials
3. Supply chain attacks (dependency confusion, SolarWinds)

Disrupting Hackers with WAF and RASP Tools

Web Application Firewalls (WAF) and Runtime Application Self-Protection (RASP) tools cover an important layer of enterprise applications: web applications and their associated databases. They can help disrupt attackers that try to access data they aren’t authorized to view or to modify data they aren’t authorized to modify. In some cases, WAF and RASP tools can mitigate against command injection attacks, rendering attacks that try to run arbitrary software on the server ineffective. In fact, WAF and RASP solutions are all but “table stakes” when it comes to securing enterprise applications. For our application, WAFs and RASP tools will provide protection to our NGINX, Node.js, and redis software.

Applying SAST/DAST to Seek Vulnerabilities Early

Another toolset that can help protect against web application attacks are SAST/DAST tools that scan web application code to find vulnerabilities before they ship to production. While SAST and DAST tools do find and help fix vulnerabilities, they aren’t perfect. Reddit’s r/pwned subreddit shows a plethora of data breaches, often by vulnerabilities not detected by SAST/DAST tools.

Secure Password Storage and Verification

Compromised credentials can be harder to protect against, with most of the tools in this space choosing instead to alert when breaches are found, either online or when an incident response team finds invalid logins. The best protection we can implement for this threat is a strong and secure implementation of password storage and verification. See OWASP’s Password Storage Cheat Sheet for best practices.

The Attackers are Still Getting Through

Recently, supply chain attacks have been gaining lots of media and researcher attention. In the web application space, the most notorious incident was when the author of LeftPad, a Node.js module used all across the internet, unpublished his module and subsequently broke an untold number of applications.

More recently, a researcher used a technique known as dependency confusion to hack into Apple, Microsoft, and many more companies. Auditing your software’s dependencies for compromise is a big task, but companies such as Phylum are building products to confirm the software bill of materials (SBOM) for open source software so that we understand the integrity and provenance of the software we use.

Now that we’ve discussed common threats to enterprise applications, let’s revisit the first sentence:

WAFs and SAST/DAST don’t provide adequate security for enterprise applications.

It sounds like, with all of the protections listed above, that we’ve built a rock-solid security plan for our web application. However, we’ve really only looked at the web application code we’ve written. What about all the other code executing?

Hidden below our enterprise application is a bunch of compiled code that does everything from routing network traffic to our application and database, to reading and writing files, to parsing HTTP requests and generating responses. What’s securing that code? The answer, unfortunately, is not much is securing that code.

In fact, while code analysis tools have existed for compiled code for decades, recent research from NCSU found that only 2.5% of vulnerabilities in Linux were possibly discovered by scanning tools over the last decade. That’s not a typo, scanning tools missed 97.5% of all vulnerabilities in Linux.

 

The Long-Term Effects of Memory Exploits

Exploiting memory corruption bugs in web servers and databases can lead to many different problems, including:

1. Arbitrary code execution
2. Lateral movement through a network
3. Data corruption
4. Data exfiltration
5. SSL certificate leaks

Finally: Reliable Defense. Meet Alkemist:Repo

What can we do about this problem? RunSafe Security’s Alkemist:Repo offering is designed to protect these open source applications by applying our Alkemist:Code protection capabilities to popular open source packages. Every day we build and ship the latest Docker images, DEBs, and RPMs for some of the leading and most commonly used open source software packages, such as:

1. Apache HTTPD
2. memcached
3. NGINX
4. Node.js
5. PHP
6. PostgreSQL
7. python
8. redis

Implementation is as simple as installing our version of the software you need and you are set. It’s really that simple. Get a free trial of the technology today and learn more about how to deploy Alkemist:Repo versions of the open source code you use.