Re-Thinking Application Security

Applications and users are the weakest links in enterprise security. It’s time to change how we think about securing them, says Tala VP of Engineering, Sanjay Sawhney.

Most businesses have invested significant time and money into innovating new applications to enrich customer experience and engagement. 

Unfortunately, these client-heavy applications and architecture introduce critical vulnerabilities that enable client-side website attacks such as data exfiltration Magecart and formjacking, cross-site scripting (XSS), clickjacking, and other supply chain attacks. 

Sponsorships Available

Sponsorships Available

Sponsorships Available

To make matters worse, most security products fail to protect businesses from application-layer attacks – It’s time for a re-think.

You Can’t Protect What You Don’t Understand

One of the fundamental principles that should guide all security professionals is that, to protect an asset, you’d better know something about that asset. If the asset you need to protect is an application, it makes sense to ask how well the protection technology you’re using understands that application. The truth is, the level of app awareness in many so-called “intelligent” or “app aware” products is no match for the sophistication of today’s application-layer attacks. That’s because they’re built around using a flawed approach that doesn’t involve an understanding of the asset at a fine-grained level.

Twenty-five years ago, data path networking products made their forwarding decisions primarily by filtering on Layer 2 and Layer 3 packet headers. The first generation of network firewalls made their allow/block decisions on TCP/UDP port numbers – and called themselves “app aware.” To support more complicated applications using multiple TCP/UDP connections (think FTP, audio/video conferencing), these devices extracted port numbers from control connections in order to detect dynamic ports being used for bulk data transfers. Vendors like Checkpoint evangelized the concept of stateful inspection and even invented scripting languages to rapidly support new applications using multiple control and data channels. 

But did allowing/disallowing TCP/UDP connections make these products truly app aware? 

Soon, all applications started getting around this level of “app awareness” by tunneling over the two ports no enterprise could afford to shut down: Port 80 and Port 25. 

Spot the Difference

To differentiate between legitimate and unauthorized web/mail traffic, vendors developed application-specific proxies, such as forward/reverse web proxies and incoming/outgoing SMTP gateways. These application-layer proxies partially emulated the client and server-side http and SMTP protocol state machines. This definitely made them more “app aware” than traditional network firewalls, which couldn’t inspect beyond 2-3 packets “glued together.” 

These products were able to validate connections within the constraints of http/SMTP protocol syntax, or filter a file payload through an AV or anti-spam engine. They also offered more fine-grained control over apps and users than network-level firewalls. These evolved into next-gen firewalls providing fine-grained control with more efficient implementations (functionality pushed down the stack), were developed. 

Network WAF Isn’t Always The Answer

On the server side, where most applications use some kind of http interface and everything tunnels over http, traditional network IDS/IPS solutions morphed into Web Application Firewalls (WAFs). Almost all network WAFs are deployed in tap mode, rather than inline mode. The reason for this? They lead to excessive false positives and essentially just look for known bad patterns (i.e. blacklists) or some level of http protocol conformity.

How app aware are WAFs? How much do they know about your web app, compared to a generic web server? The answer is not much. They simply look for known bad patterns, meaning they can’t protect against new variants of bad patterns or zero-day threats. For example, SQL injections were supposed to be solved by network WAFs but they’re still very much around. 

So how come hackers are still finding new ways to launch SQL injections? 

Recognizing that both app awareness and whitelisting approaches are superior to blacklisting, some network WAF vendors started talking about a positive mode, a kind of learning mode in which a WAF would learn about a web app’s normal behavior by inspecting network traffic. The challenge with this approach is that 50% of traffic to any website is malicious probing, making it difficult to train your positive model. 

To address some of the weakness of network WAFs, server RASPs (runtime application self-protection) were developed. RASPs are more app-aware than traditional network-based WAFs – they actually instrument the behavior of your server-side apps and have more context than the traditional WAF when it comes to apps. And that’s a good thing – as this article keeps repeating, app awareness is important. 

WAF is a network-based solution, whereas RASP is a server-based solution. They both largely adopt a blacklisting approach. But they operate on the server side, and today’s web is all about execution on the client side. All the action is happening in the browser on the client side, and your app awareness has to follow it there. 

Know What You Know

It makes sense to question how anyone can protect an asset – an app or its data – without understanding the asset at a fine-grained level. 

Identifying port numbers, TCP/UDP flows or checking for http/SMTP protocol level violations/exploits doesn’t make a defense truly app aware. Today’s sophisticated threats exploiting user psychology or flaws in complex application logic are impossible to stop with this patchwork of “app awareness.” If you’re not taking into account that all the action on today’s web is taking place on the client-side, you’re missing a critical aspect of that app awareness.

Many experienced security professionals recognize that whitelist-based security is far more resilient in the face of zero-day and unknown threats than purely signature-based blacklists. This approach strongly requires that one must understand the application.