Enterprises need a better way to control SaaS, 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.
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.
For the majority of applications, we can use a signature, examining the unique attributes of the deconstructed application and matching it to a known application pattern. Every application has unique properties. 99.9% of applications, if properly deconstructed, can be identified with a signature.
The signature has to be detailed enough to distinguish between the different modes of the application (as described in the decoding step). For those few applications that resist deconstruction, use proprietary encryption, or are in some other way “signature-resistant,” one can use a heuristic analysis and match that against known application behavior. In the graphic, there is an illustration of this process using Google Talk, from within Google Mail, across Secure-HTTP.
The result of all of this is visibility of specific applications. Which is extremely valuable for organizations when it comes to understanding their environment, their users and the level of risk being maintained. Obviously, however, now that we can see the actual application there is a lot more we can do.
Take control of your network
Now that we have established deconstruction and deduction as the correct way to understand applications (as opposed to the wholly ineffective approach used traditionally), it raises the question of where in the infrastructure to perform this task. As noted, ports are meaningless, so whatever is determining the application must “see” all of the network traffic in question. Typically this means all of the traffic crossing a relevant trust boundary (inside vs. outside, across segments), not just certain ports or protocols.
But most organizations want to go beyond “understanding” and start enforcing policies about what sorts of applications should be used. This is not to say that IT security groups should get draconian about application use – many applications are used for business purposes, and many are used for personal reasons – with the blessing of the enterprise. But organizations should be able to block undesirable applications and safely enable desirable applications (allow, don’t impede and scan to prevent undesirable content).
Not another appliance
Today, firewalls see all traffic crossing the trust boundary, and are in a unique position to enforce policy. The thing that most traditional network firewalls are missing is any sort of relevant traffic classification mechanism (deconstruction and deduction).
The typical response from security vendors is to sell enterprises yet another security appliance that sits next to the firewall. This approach has resulted in lots of complexity and additional cost for enterprises. It has, for many organizations, also proved unsustainable in a cost-constrained yet increasingly regulated environment.
The reality is that this level of classification and control needs to be done by a device that is capable of both seeing all of the traffic crossing the trust boundary, and capable of exerting control over that traffic – which, in most organizations, is the firewall.
This will obviously require some reengineering of the traditional network firewall – all of the techniques described above will heavily tax existing firewall software and hardware. Simply bolting this functionality on will result in poor performance. Some of this can be addressed by specialized hardware, but the classification engine on the firewall must get fundamentally more sophisticated.
Once you understand and begin to control the actual application, there are other benefits. By focusing on applications, users and content, network and security professionals can focus on enabling the business instead of trying to make the business understand obscure technical details.
King is director of product marketing for Palo Alto Networks. He can be reached at cking@paloaltonetworks.com.
