Apps Are Like Onions; They Have Layers

Ever wonder what security professionals see as their main barrier to achieving a strong application security posture? We wondered that, too, so we asked them. As part of F5 Labs’ first annual Application Protection Report, F5, in conjunction with Ponemon Institute, surveyed security professionals on a slew of security-related topics. In answer to this particular question, 57% of respondents cited “lack of visibility into the application layer.” 

We’ve heard this repeatedly from customers and the InfoSec community—this is not new for any of us. In fact, one of our first F5 Labs articles was about app visibility. But, it’s a tricky problem to solve for several reasons.

First, apps today can be hosted anywhere—in the cloud, on premises, in a hosting facility, or any combination of these, which makes them far more challenging to keep track of than in the past. On average, the organizations we surveyed run 765 applications, but it’s not unheard of for mega corporations to run many thousands of applications. When we asked survey respondents how confident they are in their ability to keep track of these apps, 24% said they were only somewhat confident, and more than a third (38%) said they were not confident at all.

What makes the app visibility challenge even more daunting is the level of complexity in today’s apps. Web-based apps are large and contain many moving parts—dynamic web page generators, content distribution servers, databases, password files, HTTP services, data entry forms, shells, scripting languages, state tracking mechanisms, files and directories, domain name entries, encryption services—all connected over Internet service provider links. Like the applications themselves, these components can live in many different places: on premises in your data centers, hosted at a third-party facility, or in the cloud.

It’s Time to Adjust Our Thinking about Apps

To steal a line from a favorite ogre, “Apps are like onions—they have layers.” In fact, the application itself is the layers. An onion layer by itself would not be called an onion, but rather a piece of onion. All the layers need to be stacked together to form a complete onion, and the same is true of the components of an app.

We wanted an easy way to conceptualize all the interacting parts of an app and, at the same time, avoid confusion with the 7-layer OSI model, so we describe them as five distinct app tiers:

• Services tier. Included here is the application source code, which consists of both internal code (the application itself) and external code (third-party code that is linked to the application such as libraries, plug-ins); server-side infrastructure, which includes app, web, and file servers, content delivery networks (CDNs), and data storage; and server-side frameworks like Django, Ruby on Rails, or ASP.NET.
• Access tier. For almost all modern applications, the user must pass through some kind of gateway for authentication and authorization. Applications can implement access controls in a variety of ways whether on premises such as with an LDAP server, or by using single sign-on (SSO), federation, or other authentication services.
• Transport Layer Security (TLS) tier. As network packets pass over untrusted networks like the Internet or WiFi services, it’s important that they be encrypted. TLS does this and ensures that data hasn’t been tampered with in transit. It also verifies the application with a proper domain certificate issued by a trusted certificate authority.
• Domain Name System (DNS) services tier. Every web-based app relies on DNS, the “address book” of the Internet, to convert human readable client requests (such as www.example.com) into the correct IP address. Without it, no one could connect to any web-based app.
• Network tier. The network tier provides the means by which clients connect to application servers, typically on the Internet. This includes any network over which packets pass, from local, to WiFi, to “last-mile” connections provided by Internet service providers. Common protocols here are HTTP and HTTPS.

The client is key in this model, too. Although we don’t characterize it as a tier, a client of some sort (a web browser or mobile app) is necessary for users to interact with any app.

For a web-based app to work, each tier depends on the others. Break a tier and you break the app.

Think of Security and Resilience in this Context

Without some kind of a model, the complexity of today’s apps can be overwhelming. When we think of security and resilience in the context of this model, it gives us a whole new perspective and visibility into the essential mechanisms of an app.

This is also the proper context in which to think of attacks and defenses. A key point to note in this model is that each of these tiers can be a target of attack and, increasingly, more than one tier is a target. If attackers are thwarted at hitting one tier, they can shift their attack to another, more vulnerable tier.

Figure 2 shows the app tiers and just a sampling of the most common attacks that can occur at each tier. This list is by no means comprehensive—there are many more attack types at each tier.

Figure 2. Common attacks mapped to each tier of an application

Let’s note a few examples:

• Injections at the app layer — Unpatched vulnerabilities and things like third-party CMS and forum software can leave systems wide open for attackers to inject malicious code. They do this for any number of nefarious purposes like stealing confidential information, redirecting HTTP requests to an attacker’s server, escalate user privileges in order to execute operating system commands.
• Credential stuffing at the access tier — When attackers get their hands on credentials stolen from one website (and there’s a glut of stolen credentials available on the Internet), they use automated tools to “stuff” those credentials into the login fields of other, targeted websites so they can, for example, take over a bank account for fraudulent purposes.
• TLS vulnerabilities — Heartbleed was one of the worst security bugs ever. It essentially enabled anyone on the Internet to access a secure web server running certain versions of OpenSSL and gain access to that site’s encryption keys, administrator passwords, and other information.
• DNS cache poisoning — If attackers are able to change an organization’s DNS records, they can redirect a user’s request for a specific website (like example.com) to a website designated by the attacker. A recent and blatant attack of this kind happened when attackers took over all of a Brazilian bank’s online operations for up to six hours.¹
• Client attacks — These attacks can take many forms, but they often begin with attackers downloading malware to a website, which then goes on to take advantage of client visitors to that website. This was the case with Drupalgeddon2, which downloaded executable JavaScript to target websites and, in turn, caused the site visitors’ computers to use up to 80% of their CPU resources to mine the crypto coin, Monero, on behalf of the attackers. In other cases, traditional banking trojans like TrickBot and Ramnit are now being used to target a much broader range of business types—primarily retail—to steal credit card data.

Visibility into Each App

So, how do you get your arms around all of this so you have the visibility you need?

There are tools you can use to monitor and secure each of these layers. These include web application firewalls (WAFs), TLS decryptors that decrypt packets for further analysis by DLP, and IDS/IPS systems; cloud access security brokers (CASBs) that monitor and report on traffic between your users and the Internet and, more importantly, tell you which third-party (often unauthorized) applications your employees are using; and network or packet analyzers like Wireshark, Zenmap, or tcpdump that show you what’s happening on your network. Ideally, you want to pull all of this data into a single pane of glass so you can combine and correlate disparate data sources for a singular, real-time picture of the current risk to your applications. This will not only give you visibility into your application but a reasonable risk overview so you can respond accordingly.