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.
Next, I wanted to know whether our intellectual property would reside on servers outside our company. The answer I got was that only the Web page portions of the application would be optimized and that our IP would not reside on the Akamai servers. Very strange, I thought, since the whole point of the Akamai service is to get data as close to the end users as possible.
Since the complaints from Israel involve the downloading of large files, it's only reasonable to assume that the large files must reside on the Akamai infrastructure. Some discussions with Akamai proved me right. Worse, the testing involved a mirror of our production application, including all our valuable IP. I need to see the nondisclosure agreement, I said. I wasn't encouraged when everyone avoided my gaze. Sure enough, there was no NDA.
This simple initiative was turning into a security nightmare, and I had no choice but to reject the change control until the risks are mitigated. We'll get there, just not as fast as some people would like.
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 email@example.com.
To join in the discussions about security, go to computerworld.com/blogs/security
This story, "An employee initiative crashes up against security concerns" was originally published by Computerworld.