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.