April 21, 2010, 2:57 PM — As a manager, I love seeing employees show initiative. So it isn't easy to say no when someone does that. But as a security manager, I am rigidly opposed to anything that would make us vulnerable. This week, initiative and security clashed.
At issue: An initiative to solve a latency problem involves opening the HTTPS port to the Internet.
Action plan: Put the brakes on this idea until all security risks have been mitigated.
The conflict arose from a new program we call Innovation. It's sort of like the old suggestion box, allowing folks in IT to put forward ideas for improving processes and systems. If the proposal is approved, the person who thought of it can go ahead. I usually attend the meetings where ideas are reviewed, as a way to ensure that no new initiatives pose a security risk. I can't make it to all of the meetings, though, and a couple of weeks ago, I missed one at which the Innovation team gave the green light to a suggestion that we use Akamai to enhance the speed of one of our core applications.
The idea was to address the availability and latency issues that we've been having with one of our product life-cycle management programs. Our facility in Israel has been complaining that it takes too long to render data from the application. Because it is our largest manufacturing site, their complaints echo loudly, and they usually get what they want.
I knew nothing about the Akamai plan until earlier this week, when I received an e-mail from the network operations manager in charge of the change control process. He was concerned about a planned network change to our core firewalls and wanted to be sure that I approved of it. Innovation initiatives aren't supposed to involve any major changes to the infrastructure. That's what "projects" are for.
I stopped by our lead security engineer's cube and asked him what network changes were in store for the Akamai initiative. He told me that the plan was to add a single rule in our externally facing firewall allowing Port 443 (better known as HTTPS) access to an internal application living on a Web server. It would be OK, he said, because the traffic was encrypted and we were masking the real identity of the Web server. No, I said, opening the firewall to internal infrastructure would be unacceptable; encrypting the traffic gives you encrypted traffic but does nothing to prevent attacks.
One Sorry Server
On a hunch, I did a quick assessment of the Web server, and sure enough, it wasn't patched properly. In fact, the server was in really bad shape. Security patches and the antivirus engine were not up to date, a lot of unneeded services were running, and the application was susceptible to cross-site scripting and SQL injection.