CISO in Residence Series: Security teachable moments

Blog Post created by boblord Employee on Jul 14, 2015

A CISO I know was recently asked by his parent company to log into a third party web portal to receive some important business plans and legal documents. The web portal is designed to securely upload documents by one person or team, and to be received by another.

The CISO noted a few things. There were questions about just how “secure” this web portal was. It didn’t seem to use end-to-end encryption. And it wasn’t clear how enrollment/authentication worked. But what really caught his eye is that to use the secure webmail portal, he had to install Java on his machine with a plugin for his browser.


I’m particularly sensitive to the security risks associated with having Java enabled on corporate laptops. In fact, I spend most of my time on a Chromebook Pixel, a laptop that does not support Java. Rather than try to secure a general purpose computer, I’ve chosen to reduce my attack surface by using a more secure OS. While it supports Flash, I have it enabled in “click to play” mode. That means Flash only executes when I manually activate it, which is almost never. Running Flash and Java on a desktop fleet dramatically reduces security for the organization. My personal take is that in a corporate environment there should be no Java running in browsers. And Flash should be disabled. (An earlier draft of this post included a recommendation to use a click-to-play model for Flash. The CISO in question pushed back hard. He’s right. Just disable Flash.)


As I was writing this post, I saw this report show up on my Twitter feed: “Java zero-day security flaw exploited in the wild”. Amazing timing!


The CISO had many options, including:

  1. Enable Java on a separate machine (bare metal or a VM) to get the job done for himself, while maintaining his personal security.
  2. Delicately have someone send him the documents via a different, yet secure, mechanism, avoiding the problem. This approach would solve the problem for himself, but not help the parent company. This solution could create the impression that the CISO was difficult to work with, but the problem would be short lived.
  3. Decline to use the webmail gateway, using this event as a security teachable moment for the parent company. Explain why having Java enabled on browsers reduces security for the entire enterprise, and get commitments to migrate to another secure email solution that does not erode the security of the enterprise. This is the most difficult option. It’s the one that takes a simple request (“please click here to download some docs”) and turns it into an unscoped, unfunded, and unstaffed project. It is a request to stop doing business as usual in the middle of doing business that is time sensitive. It’s also an approach that many security professionals would argue is doing the right thing when it matters most.
  4. Document the problem, and escalate to the CEO of the parent company. Then implement option 1. He might possibly repeat this approach on a regular basis, providing a steady stream of reports highlighting unmanaged and unaccepted risk and demonstrating a larger strategic problem.


Which option in 2015 is most appropriate for the CISO to take, given what we know of vulnerabilities and threats?


In the end, the CISO didn’t need to install Java on his machine or a VM. Some kind soul sent him the documents via normal email anyway.


I highlight this case not because it is unique in some way. I highlight it precisely because it is the sort of challenge security leaders face every day. A decision to roll out Java to browsers of key executives in 2015 is a perfect example of the challenges implementing a solid security strategy at companies. It’s a teachable moment.


What would you have done?


Have thoughts? Drop me a line on Twitter at @boblord.