Detoured by Shellshock and Poodle
- 28 October, 2014 03:00
As I moved into the information security position at my new company a few weeks ago, I was anxious to do a full assessment of our security defenses. But I was immediately sidetracked by, not one, but two major vulnerabilities that couldn't be ignored. Those were fires that had to be put out before I could do anything else.
Of course, at my previous company, I had just spent months managing the cleanup effort and response to the Heartbleed vulnerability. It felt like I barely had time to breathe a sigh of relief when the Shellshock vulnerability was revealed, followed rather quickly by Poodle.
Handling Shellshock was pretty straightforward for us. Shellshock takes advantage of a vulnerability in the Bash utility that's present on virtually every Linux distribution, and my company was fairly safe, since our applications don't provide a mechanism for commands or malicious code to be executed on the Web servers. Nonetheless, we needed to manage the perception that we were vulnerable, and so we had to close this hole. Simple enough, though, since we use a central orchestration infrastructure; all we had to do was to test the upgrade in our development environment, upgrade the master images and run a job to update all of our hundreds of Linux servers to match it.
The Poodle exploit takes advantage of a weakness in the Secure Sockets Layer (SSL) Version 3.0 protocol, allowing for the decryption of intercepted traffic. It's not that easy to exploit, since the hacker has to be positioned between the user and the Internet (man in the middle), but once again, we can't afford to give customers the impression that we're not addressing security vulnerabilities. Ironically, though, it was our customers who made remediating the Poodle vulnerability a challenge. During our business impact analysis, we discovered legitimate SSL 3.0 connection from dozens of customers using older browsers. The recommended approach for remediating Poodle was to disable support for SSL 3.0, but that would have made it impossible for those customers to use our product. We've decided to contact them and try to persuade them to modernize their systems.
Back on track
Once I felt that Shellshock and Poodle were under control, I was able to return to prioritizing the risks I've discovered at the new company.
One thing I've uncovered isn't terribly surprising, but it worries me all the same. More than half of our employees are using cloud-based file storage and backup sites -- 15 of them, in fact, including Box, Dropbox, Google Drive and iCloud. Clearly, we need to standardize on a file-collaboration tool. And we need to make it clear to everyone that cloud storage that's been set up independently with a personal email account is inappropriate for storing company data.
Another practice that has to be circumscribed is the widespread use of remote-control software, such as LogMeIn, Team Viewer and VNC. Currently, the company has no remote-access policy, so establishing one will be a priority, as will be educating users about the need to gain remote access only through our approved VPN client with multifactor authentication.
I also was able to determine that employees are using peer-to-peer applications, which are frequently associated with risks of copyright violation and introduction of malware onto networks. To deal with that, I'm going to want to get approval for a URL filtering service, which would also help protect against users visiting sites that are known to host malware. It might be even better to invest in a threat-prevention technology such as FireEye.
And so I'm on my way to establishing a security strategy and road map. I'll present my recommendations soon to the executive staff, assuming no more crises arrive unexpectedly over the Internet.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at firstname.lastname@example.org.
Click here for more security articles.