Re-perimeterization: Regaining app-centric visibility and control

Enterprises need a better way to control software-as-a-service, cloud computing, Web 2.0 and other applications that are hosted outside the enterprise because the traditional port-based approach has ceased to be effective.

Read the second part of this series.

Moving beyond port-based traffic classification isn't easy, but because the "threat industry" now has application-level exploits and applications are at the heart of many data leaks, enterprises must rise to the challenge. Here are the key techniques necessary to achieve application traffic classification, how that classification can be implemented as a set of useful controls, and the production requirements for such an infrastructure component.

To continue reading, register here to become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

Enterprises need a better way to control software-as-a-service, cloud computing, Web 2.0 and other applications that are hosted outside the enterprise because the traditional port-based approach has ceased to be effective.

Read the second part of this series.

Moving beyond port-based traffic classification isn't easy, but because the "threat industry" now has application-level exploits and applications are at the heart of many data leaks, enterprises must rise to the challenge. Here are the key techniques necessary to achieve application traffic classification, how that classification can be implemented as a set of useful controls, and the production requirements for such an infrastructure component.

Application-centric traffic classification first has to deconstruct traffic (detect and decrypt, decode and de-tunnel) to be able to deduce the application.

The first step is to detect the application protocol being used. Please note this is not just capturing TCP and port and then assuming the application protocol, but detecting the actual application protocol in use (for example, HTTP, SMTP).

This may require decryption. If it's SSL, decrypt it. Given that forward proxy decryption of SSL is well understood, this isn't a technical challenge. It is, however, a sensitive issue, so it must be handled with care. Once decrypted, detect the application protocol within. The process of decryption and detection slightly narrows the list of potential applications, but more importantly, enables application protocol decoding.

The second step is to decode the application protocol. This enables several different services (described later), but most important for understanding the application, you need to come to grips with the type of tunneling used.

Tunneling, in its broadest definition, can include three flavors: encryption, protocol-in-protocol, and application mode switching. We've already discussed the importance of SSL decryption followed by further detection. Protocol-in-protocol, however, involves decoding the application protocol, and detecting/decoding again to "de-tunnel" the application traffic (which addresses a common practice – instant messaging or peer-to-peer filesharing tunneling through HTTP).

Detecting mode-switching is harder still. This is where one application substantially shifts functions -- such as when IM users initiate a file transfer, or when WebEx participants initiate desktop sharing. But it is important to understand this: organizations may want to enable IM for close customer contact, but have a different perspective on file transfers. The same could be said for WebEx – enable for salespeople, but have concerns about desktop sharing – where critical information could be inadvertently shared as well.

Deduce the application

Now that we've deconstructed the application traffic -- that is, done the decryption, detection, decoding and de-tunneling -- we must deduce the specific application. More specifically, we need to turn to pattern matching and behavioral analysis.