Security in SaaS: When Applause Turns to Head-Scratching

Blogger: Trent Henry

We just completed research and writing on a piece entitled, "Considerations for Risk Management When Choosing Software as a Service." It should be publishing in the near future. Our Service Director Eric Maiwald wrote this report in the midst of Salesforce.com's reported breach and subsequent security enhancements, so it was timely. In fact, as users of Salesforce.com, we were pleased to see the company offer improved protection against certain forms of identity fraud--especially phishing.

But soon after the security enhancement was implemented, we realized it wasn't quite working right for us.

See, Burton Group Analysts are a distributed, traveling bunch. We tend not to cling to the same IP address for very long. Unfortunately, part of the Salesforce.com fix was to authenticate users based on inbound IP address.
(Back in the day we might have balked at this due to its low surety--but with so few routers/firewalls honoring source-routing flags and weird ICMP redirects, it tends to be reasonably effective.) Of course, Salesforce.com realized that lots of its users are mobile, so they also implemented a browser cookie that anchors to a given host in the event of changing IP address. More details are at https://trust.Salesforce.com/security.html.

However, the cookie part of the solution didn't seem to be working for many of us. This meant that we had to repeat the system enrollment process each time we DHCPed (is that a verb?) with a new IP block. The end result? -- some significant inconvenience and delay in using our presumably available-everywhere SaaS application.

What a conundrum. I abhor phishing. And I don't mean to pick on Salesforce.com. On the contrary, enhancing security is a noble and applauded decision. But as a security practitioner, I know first hand that if information protection gets in the way of an application's usefulness, it causes all manner of consternation and often a total retreat from better protection. The good news is that this hasn't happened to Salesforce.com; glitches are getting worked out and improved security remains. The bad news is that it is likely to happen to other SaaS vendors.

In essence, attackers create an environment for potentially poor decisions that can directly impact the original benefit of a system. Although insiders continue to cause harm in organizations, Internet-facing systems are particularly open to a wide array of damaging bad guys. Mobility adds to the complexity of protection. The possibility for hastily implemented SaaS security, especially after the latest successful attack, is quite high. And haste will cause applications to fail. At best, the result is temporarily inconvenienced users. At worst, it's (also hasty) dismantling of protection and reluctance to try for better.

Where does that leave us? SaaS is in our future; make no mistake. And attacks will continue to evolve and succeed. The goal in this ever-connected mobile world is to raise the bar for protection with thought and care. Like independent software vendors and in-house developers, SaaS solutions must consider security requirements and threats, design protection as best they can (nothing is perfect), use multiple mechanisms where appropriate (defense-in-depth), and include strong response capabilities (well-trained, adequately staffed support teams). When problems are found, a vendor should think through how the application is used when deploying fixes or additional mechanisms. An overly quick, troublesome response will likely fail, lead to head-scratching, and--perhaps worst of all--ultimately be circumvented by the very users that need better protection.