LAS VEGAS -- There are plenty of reasons that a company might want to try and decrypt SSL sessions -- to stop outbound malware botnet connections that are decrypted, or to stop a rogue insider from sending out sensitive corporate information -- but be prepared to hear employees whose data traffic is decrypted complain loudly about their privacy being invaded.
"Your users will freak out," says David Guretz, security director at a financial services firm that preferred not to be named.
Speaking at the Palo Alto Networks user conference here yesterday, Guretz said his company's management decided SSL decryption needed to be done in order to watch for any signs that the company's valuable intellectual property might be exiting via the network. The company's Palo Alto next-generation firewall (NGFW) is able to do SSL decryption by opening up SSL traffic through an inspection process.
But that didn't mean that company employees went along with SSL decryption process without complaining about loss of privacy. Guretz said he found the process of bringing in SSL decryption required explaining what was going on to employees, as well as garnering all the support possible from legal and human resources divisions.
"Be prepared to answer questions. If you didn't involve your legal, your SSL decryption will fail," he said. Because his company had a mandate from the executive level to undertake SSL decryption in order to protect intellectual property, it wasn't a hard transition, he added.
But it was necessary to make clear to employees in the U.S. they shouldn't have an expectation of privacy when using the corporate network, and across Europe where privacy regulations are tougher, it was only slightly different.
Signed policy statements have been the norm so that employees officially acknowledge the reality of SSL decryption. But Guretz's company has no interest in decrypting employee use of certain online services, such as banking, because there's no security rationale that pertains, he explained. By being as clear as possible to employees why certain SSL-encrypted streams are being decrypted to protect the business, it's possible to go "from freak-out to fair" in terms of employee reactions, he said. "We discuss this with them."
The Palo Alto Networks NGFW uses a certificate-copying mechanism to open up TLS 1.1 sessions (TLS 1.2 for outbound is not yet supported but the process negotiates down to TLS 1.1) that basically works like a corporate-operated man-in-the-middle attack. Keyword-based detection based on source-code extensions, for example, can be on the alert for an escaping intellectual property, though the Palo Alto NGFW is not said to represent full-featured data-loss prevention.
Mike Jacobsen, director of product management at Palo Alto Networks, said SSL decryption can be done on both an outbound and outbound basis in terms of SSL-encrypted traffic, but there are a few things to be aware of.
SSL decryption adds significant processing overhead so there's a limit that needs to be measured for the environment in question about how much SSL decryption can be done at one time via specific Palo Alto firewalls. That underscores what will likely be the need to do SSL decryption selectively based on where the greatest risk is.
The Palo Alto certificate-copying process that is used in some instances of SSL decryption will present the user with the well-known screen warning that the certificate is not trusted but they can override that. However, Jacobsen acknowledged that encouraging employees to override fake certificates is not really something companies relish doing. In lieu of that, it's possible to dynamically present a splash page that tells the user that an SSL decryption process is occurring, Jacobsen pointed out.
According to recent Palo Alto research based on its customers' usage, about 20% of traffic in the enterprise network is SSL encrypted traffic.
(Note: This story has been changed.)
Ellen Messmer is senior editor at Network World, an IDG publication and website, where she covers news and technology trends related to information security. Twitter: @MessmerE. Email: firstname.lastname@example.org.