In the not so distant past, you couldn’t complete a networking class without learning the OSI seven layers in which layer 7 was considered the application layer and physical media was at the bottom, or layer 1. Along came virtualization, and migrating workloads or services demanded a change in how these layers worked. This was a tipping point for the wave of “software defined” services (as in Software Defined Network) that we see burgeoning today. Software has become the new hardware. This raises the question: What has become of the other network features, especially those related to network and cloud app security, in this new paradigm?
From Virtual Private Network to Virtual Private Application
We once relied on a clearly defined corporate network perimeter to separate the risky and uncontrolled external network from the safe and controlled internal network. For a nomadic user, the standard way to access any “internal” business application was through a Virtual Private Network (VPN). In some sense, the security boundary is drawn at a network layer that can be cleanly mapped to a networking stack. The advance of mobile computing and SaaS changed all that. End users simply expect access to business application in the cloud at anytime and from anywhere. Multi-tenant cloud apps enforce access based on user identity and roles rather than the network used for access and the network finally finds its namesake — a transport.
This is not to say that network security isn’t important. It only means that one needs to adopt a new paradigm: it’s not the network boundary that matters; it’s the application boundary. And this has given way to the Virtual Private Application. A logical collection of all the business transactions, the Virtual Private Application can be initiated from any device by any user from anywhere at any time against all corporate own tenant resources/APIs hosted in the cloud. A Virtual Private Application security layer must evolve to be able to provide the same visibility, control, and security with the same kind of transparency and network “neutrality” (not to be confused for “Net Neutrality” legislation) that people come to expect from accessing cloud apps from mobile devices.
Proxy: Reverse? Forward? Or Just a Traffic Redirecting Gateway?
Many state-of-the-art cloud app security solutions employ a proxy to redirect traffic. Much has been talked about a reverse proxy vs. a forward one. From the client perspective, a reverse proxy is exposed as an application URL itself, albeit a special application that functions like an application portal: brokering transactions between the user and the target SaaS application. No change to the client device is necessary to take advantage of the portal if the application client directly uses the portal URL or the end-user uses the portal URL directly from a standard browser (sometimes the URL is made available via a Single-Sign-On Identity Provider). This traffic redirection mechanism is most suitable to the use case in which enterprise IT has complete control over the app to configure the redirection from within the app itself. A forward proxy, on the other hand, can transparently intercept and broker the user to cloud app network connections. No special app URL is used. Such transparent interception often requires control over the network (e.g. a web proxy for a private network) or some modification in the client (e.g. some form of tunneling or Proxy Access Control configuration). The tunneling to a forward proxy should not be confused with a VPN, however, as the purpose of two tunnels are completely different (traffic redirecting in a forward proxy case and access control in the case of VPN). A forward proxy is mostly useful to gain visibility and control over SaaS apps that are not under direct enterprise IT control.
Some may wonder what kind of proxy to use for cloud security. The answer is quite obvious: you need to be able to do both. Or more precisely, one sometimes need to deploy a cloud application gateway as a reverse proxy, while at some other times the use case calls for the deployment of a forward one. An ideal cloud security gateway, therefore, should make both mode of traffic redirection available.
From Deep Packet Inspection, to App ID, to Deep API Control
Network security implementers have tuned and refined the art of network protocol parsing in a DPI device only to find that HTTP (and HTTPS) won as the transport protocol of choice. As a result, Next Gen Firewalls implemented App ID, which was designed to make sense of the app running on top of HTTP. As the cloud moving to a world of web APIs, or as some would put it, a programmable web, a network security device should move from inspecting the packet or simply identifying and parsing the app, to acting as the gateway and controller of the Web APIs in use.
Unlike document-centric first generation web pages, modern cloud apps were implemented as web services with well-defined RESTful APIs. The adoption of web APIs were driven by necessity as web services must support a variety of clients ranging from AJAX running in browsers to full fledge native apps on mobile devices. This is both a challenge and an opportunity to network security. For a conventional device, the protocol (HTTP/HTTPS) and even the URL is becoming less and less relevant. In their places, effective security policy can only be enforced at the API level where actual transaction takes place.
It’s all about the App
In the new era of cloud and programmable web, many debates of old have become irrelevant: it is not about hardware vs. software, private network vs. public network, reverse vs. forward proxy, or the inside vs outside of a network perimeter. It is all about the app and how it’s being used. The ideal solution should be flexible, adaptive, and most importantly capable of inspecting and controlling the new “protocol”: web APIs. Deployment mechanisms are only useful when actual use case is considered. Policy and insights should be data driven. Any talk about a specific network implementation in a network security discussion today is, well, just so yesterday.
