Security Manager's Journal: On the lookout for rogue IT

Computerworld - In the age of software as a service, when just about anyone in a company can spin up an enterprise application with just a credit card and an email address, it can be tough for the security manager to keep on top of things.

How do you know, in a globe-spanning enterprise, that no one has instituted some cloud-based service in a way that threatens the company's intellectual property? Last week, luck led me to one such application, but that has me thinking that there has to be a more comprehensive way to uncover these things.

I have the authority to sign off on changes to the IT infrastructure. Because I like to have a life outside of that activity, I have established criteria for what sorts of changes need my approval. For example, I don't need to OK adding memory or a CPU to a server, but I don't want any publicly facing Web servers installed in our DMZ without my knowledge. Some of the changes that I retain oversight on might seem trivial, but last week's incident illustrated why they aren't.

What happened was that I received a request to white-list a particular domain so that it wouldn't be identified as spam. On the rare occasions when we receive such a request, we evaluate the domain, running it through some Web-based validity checkers. If it's not identified as hosting malware or other risky content, and if there's a business justification for releasing the domain from the spam filter, we allow such email to be delivered to the employee making the request.

The domain in question didn't set off any alarms and didn't appear to be malicious. OK, so what's the business justification? The request was from our customer service operations center in Hyderabad, India. The folks there told us they were deploying a new Web-based tool to give our customers access to certain knowledge-base data held on our internal servers. But our IT enterprise applications team knew nothing about this application. In other words, we had stumbled upon the deployment of a customer-facing application that was bypassing our strict review process.

What more could India tell us? Plenty, and none of it good. The SaaS vendor has eight employees and is run out of a small apartment. It has one Web server, hosted at Amazon. It has no U.S. presence. As for the application architecture, authentication requires a username and password, but there are no requirements for password complexity, and users aren't forced to change their password on first log-on. Passwords are stored in clear text, and sessions aren't encrypted. But this vendor is security-conscious, we were assured: It offers two-factor authentication. Um, yes, but the second factor is the user's date of birth.

We immediately put a halt to work with this vendor. It could have been a very embarrassing situation. After all, we are a publicly traded company, and many of our customers are banks, healthcare providers, utility companies and government organizations with complex compliance requirements.

This was an embarrassment that we barely avoided, and only by chance. Now I'm wondering how many other rogue enterprise applications have been implemented. What to do?

Luckily, all outbound network traffic must pass through our new Palo Alto Networks application-layer firewalls. A nice feature of these firewalls is that they can capture the destination of all network traffic as well as the actual Web addresses that are being accessed. I plan to filter out all the valid applications that we have approved or know are not risky. Whatever falls out will be evaluated in hopes of identifying other rogue SaaS applications being used in the enterprise.

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 mathias_thurman@yahoo.com.

Join in the discussions about security! computerworld.com/blogs/security

Read more about Security in Computerworld's Security Topic Center.