The way organizations build web applications has changed dramatically over the last several years. As a result, many organizations are considering additional security strategies to augment the Web Application Firewall (WAF) on which they have relied to protect critical digital business operations from vulnerabilities. New technology has created a development environment where the web application threat landscape grows larger and more complex every day. Fortunately, there are solutions available to shore up your web application security and account for vulnerabilities you may not know you had. Implementing these solutions will require you to think differently about web application security. In this post, we’ll talk about what has changed in the web application development process that makes you vulnerable to different threats and why relying on patching alone to address them may no longer be sufficient. We’ll also explain how a “shift-left”, “inside out” approach with a unified security model will augment the protection you get from your WAF and create a more sustainable and scalable application security strategy.
Not your father’s web application development environment
Every year, we discover new vulnerabilities in commercial, off-the-shelf software, open source libraries or in dependencies introduced by other applications. The number of vulnerabilities has exploded over the last few years. As we wrote more code to create more applications, we used better tooling and better analysis to find them. Another cause of the vulnerability explosion lies in the way organizations compose applications. Developers are moving beyond traditional web application building methods and introducing elements such as APIs and micro services which bring their own vulnerabilities into the mix.
Legitimate web application developers are not the only people out there looking for vulnerabilities. Imperva Research Labs reported that in the first half of 2021, Imperva blocked 40% more web application incidents in the financial services industry than over the same time period in 2020. Given what we know, this is not a surprise. The COVID pandemic has left lots of prospective attackers sitting at home out of work, potentially looking for different avenues to get money. The tools required to affect attacks have been democratized over the years, making it easier and cheaper than ever to constantly take “pot shots” at applications and see what sticks. This generation of bad actors has the time and motivation to look for and exploit vulnerabilities to launch attacks on high value targets like financial services.
First-party applications and third-party applications
Applications may be categorized as first party applications and third party applications. First-party applications are those that your organization writes and develops themselves. Let’s say an eCommerce company has a website where people can add items to a shopping cart and buy them when they check out. The website is a first-party application. If this company doesn’t do the check out, but instead, employs another system, component, microservice, or API to do it, then they are using a third-party application working in conjunction with the first party application (website). Some organizations have zero development capabilities and use only third-party applications, something as simple as off-the-shelf software they deploy in their environment.
Historically, organizations have had control over first-party applications (there are blind spots that we’ll address later). You have control over your own code, you can audit some of the open-source code that’s coming into your environment, and so you have some level of observability. However, with most tools, you don’t really have visibility into the security of third-party applications, you find yourself virtually taking the vendor’s word that they are protected.
The key element that stretches between first and third-party applications is risk, and both types of applications can introduce risk back into the overall environment that you need to manage to protect your applications. One risk mitigation technique is to draw a firewall between first and third-party applications. As the threat landscape grows, this is unlikely to be sufficient. Even if your vendor patches a zero-day vulnerability, the response may be inexact, take too long, and fail to prevent the code vulnerability from showing up everywhere in your environment.
The “shift-left” approach to application security
In 2021, the non-profit organization Open Web Application Security Project (OWASP) which helps website owners and security experts protect web applications from cyber attacks introduced for the first time the concept of “insecure design” as the 4th most important security risk affecting web applications. This represents an overall realization that developers should consider a “shift left” approach to application security, putting a greater emphasis on more rigorous threat modeling or secure design upfront in the process. Going forward, application developers may need to consider compensating controls as part of their overall design to counter bringing in risky third party code that has unknown vulnerabilities.
Web application development and supply chain security
OWASP’s greater emphasis this year on the risks of using components with known vulnerabilities is really a sign of the times in terms of what’s going on with supply chain attacks. There are more bad actors than ever trying to compromise supply chain vulnerabilities. The most efficient way to wreak supply chain havoc is to compromise a library or component that many organizations use.
Traditional security methods are highly effective at stopping threats from the outside that are trying to break into an environment, but are ineffective at stopping supply chain attacks because you just don’t see what’s going on inside of the application. As the code base and the number of dependencies increase, developers need to understand exactly what’s going on in or around applications in the software supply chain, whether it’s bad dependencies or bad packages or solutions that are around the core application, in either first party or third party applications.
The positive security model for application security
In the positive security model, you allow the application to do what it does based on its current behavior and anything outside of that behavior or abnormal behavior is just not going to work. You don’t require any signatures or updates and you can protect the entire stack. You can easily deploy it by flipping a switch, no need to constantly update it with patches, and no risk of degrading the application’s performance. This is where runtime protection (RASP) comes in. RASP is a light-weight agent that attaches to your applications and, unlike a firewall, which protects from the outside, in this solution, RASP offers code-level protection from the inside out. RASP lives squarely in the realm of development and security,
RASP stops more attack vectors
A web application firewall is great at stopping attacks compromising known vulnerabilities. In instances where an attack targets unknown vulnerabilities in certain code in the applications themselves, a unified positive security model including RASP provides more targeted controls designed to automatically mitigate those types of attacks. The same thing applies to client side attacks, which target the users in their actual browser environments themselves. With visibility from inside the application, Imperva RASP is able to understand how the individual components are working with one another and offer automated mitigation in order for enterprises to focus on business logic without compromising on security.
Deficiencies in so many organizations’ ability to protect the overall supply chain have driven changes in today’s regulatory landscape, and RASP is now frequently identified in regulations as an effective control in delivering that protection.
This post was adapted from the webinar, Mitigate Vulnerabilities in Application Code Without Emergency Patching. Watch it on demand here.
See RASP in action yourself. Start a free trial today.
Try Imperva for Free
Protect your business for 30 days on Imperva.
