Security Manager: First task is to tighten up SaaS security

After just a couple of weeks at my new post, I'm already finding plenty of things to do.

Trouble Ticket

At issue: Early tasks at the new job include evaluating the security of the company's many software-as-a-service relationships.

Action plan: Identify all the weak points and then write a remote-access policy that will address most of them.

First up is following up on a plan to implement a SIEM (security incident and event management) tool. While my new company was looking for a replacement for its security manager, it hired a consultant to fill in. This interim manager initiated a SIEM proof of concept. I'm not keen on inheriting this selection, the problem being that a SIEM tool is only as good as the logs that are fed into it, but I don't want to risk losing an opportunity to enhance the security posture of the organization. I need to make sure we get full value from this investment, which will probably exceed $300,000. I will also be contacting references and negotiating the price. I'll probably have more to tell you about this project as it progresses.

Another issue vying for my attention early on is the company's heavy use of software as a service (SaaS). At my last company, we used four SaaS vendors. This company far exceeds that number, because it tends to choose a SaaS option ahead of either building applications in-house or buying them. As a result, we currently use more than 30 SaaS offerings. It's a nightmare from a security perspective, for many reasons.

For example, each SaaS relationship requires connecting some aspect of our trusted network infrastructure with the vendor's network. In doing this, security has been an afterthought. We're using a VPN, but that only addresses encryption. The associated firewall rules are pathetically weak, and in some cases the connections are wide open.

I also have a problem with single sign-on (SSO), since many of the SaaS tools that we are using can be accessed freely from the public Internet. I want access to be restricted to the company's trusted network. As it is, employees can access many of our SaaS applications from, say, an Internet kiosk in Moscow. People from outside of the security realm think I'm being paranoid when I say that I want more restrictions on things like survey tools and corporate travel sites. But it's not all about the content of the sites. With SSO, credentials that are compromised while accessing some innocuous SaaS site can put a good deal of our infrastructure and data at risk. And employees often do things that make compromise all too easy, such as clicking "remember my username and password" on a public computer or simply neglecting to sign off.

Tools of Compromise

But even if employees are well trained about security risks and don't do those sorts of things, there are still keyloggers, sniffers, screen-capture tools, cameras and other methods of capturing domain credentials. For example, we currently, change passwords every 90 days. That means that if someone were to capture an employee's enterprise credentials, the hacker would have as long as three months to figure out what other SaaS applications he could access. He would only need to do a quick query of our external DNS to discover our Outlook Web Access site, which currently isn't protected with two-factor authentication. What's more, many people these days (including me) use e-mail as a complete data repository, leaving all of that data -- and their calendars, contact lists and personal notes -- wide open to hackers who have the proper credentials.

Over the course of the next few weeks, I will write a policy on remote access that will include two-factor authentication and other ways of safeguarding access to our SaaS-based applications. If you have some advice, I would love to hear from you.

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