Where organizations rely on application-aware security policies for their network security devices, or rely on Data Loss Prevention (DLP) products to prevent leakage of sensitive corporate material outside the network perimeter, the use of encrypted traffic means that those devices are suddenly blinded to the content, rendering deep packet inspection to the application level impossible. Cybercriminals are aware of this, and often make use of encrypted channels for covert command and control communications for botnets, as well as data exfiltration from the corporate network.
Given the risk that encrypted channels may be used by malicious entities for botnet command and control or data exfiltration mechanisms, enterprises are faced with an unpalatable choice – leave traffic in the clear or lose visibility into the encrypted data stream. Of course, there are solutions to the problem – there always are! – such as ensuring that network monitoring and security products can handle decryption, inspection and re-encryption of traffic on the fly.
The only issue is, how much of your already straining-at-the-seams security budget can you allocate to add SSL inspection capabilities to your infrastructure?
And while this may seem the obvious solution, on-the-fly SSL inspection can have a number of issues that need to be considered, not least of which privacy and performance. Vendor data sheets usually do not reflect accurately real-world impact on performance, forcing organizations to perform their own testing to ensure network security devices are fit for their intended purpose.
NSS Labs has a group test report in the pipeline covering SSL inspection capabilities of network security devices, and in the mean time, we have published a useful piece of research on What CIOs Need to Know About SSL and its Effect on Network Traffic Inspection Capabilities (subscription required).
Follow me on Twitter (@bwalder) to keep informed as new research is released.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment