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).