The sales team is using Salesforce to access sensitive data from any device, anywhere. Action plan: Rein in accessibility by requiring VPN connectivity for SaaS apps.
The access police have struck again.
That would be me, of course. I am forever seeking to control accessibility to the company's sensitive data. Naturally, when I tighten things up, some people get unhappy. Our salespeople, among others, always want access to be as easy as possible, and they want to be able to get to the data they need anywhere and from any device. For me, though, that sort of ease of access just sounds like a disaster waiting to happen.
My latest candidate for more restrictive access is our Salesforce.com deployment. We've been using this software-as-a-service customer relationship management and sales application for more than six months with pretty wide-open accessibility.
I have a policy regulating remote access to our internal infrastructure or sensitive data. It requires encryption (i.e., VPN ) and two-factor authentication (i.e., RSA SecurID tokens ). The problem with SaaS applications like Salesforce is that their use does not really involve our internal infrastructure, but it does involve our sensitive data, though it doesn't reside in our data center. After discussing things with our legal counsel, we decided that the policy should more clearly define sensitive data to include source code and financial, human resources, healthcare, customer and sales data. Salesforce contains quite a bit of this sort of information, especially customer data, sales data and sales forecasting reports. As a publicly traded company, we can't risk unauthorized access to such data, which could be used to make illegal stock trades based on insider information.
With this tighter policy in hand, I decided to take advantage of a Salesforce configuration option that allows companies to restrict access by IP address. That would essentially force all users to be connected to one of the following: a port in one of our offices, a corporate wireless access point or the network via VPN.
Cue grumbling from the sales department. They were used to logging in to Salesforce from anywhere on any device. Of course, that convenience is exactly the risk we are concerned about, since we can't vouch for the integrity of "anywhere" or "any device." Some employees have even accessed corporate SaaS applications from Internet cafes and hotel-lobby kiosks. Such "unknown" devices are often infected with malware, and when connected to our network, they have compromised the login credentials of our employees. OK, said sales, no more public machines, but at least grant us the convenience of accessing Salesforce from our iPads .
That we did, by deploying the Cisco AnyConnect VPN client and RSA SecureID token for the iPad. We had been planning to deploy these applications for the iPad later in the year anyway, in conjunction with our mobile device management rollout.
A Lot of Work
Restricting Salesforce by IP address is a big job. We had to obtain all the IP addresses that Salesforce uses, as well as those of third parties. Then we had to modify our firewalls to allow access to each of those destinations. We also had to modify our VPN client profiles to recognize when a connected VPN user is accessing Salesforce. Finally, we had to let Salesforce know all of our company's IP address ranges. Gathering this data took time, and more time will be needed for monitoring, so that when a change occurs -- the addition of a new office, for example --we can modify the configuration.
This latest change hasn't been pain-free, but the grumbling has subsided. The sales team seems to understand our reasoning and agrees that, given recent security events in the news, this change makes sense.
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.
Join in the discussions about security !
Read more about security in Computerworld's Security Topic Center.
This story, "Plugging a SaaS access hole" was originally published by Computerworld.