SaaS Security Is Still Sticking Point but Doesn’t Have to Be

Security concerns remain one of the biggest bugaboos for companies considering putting data of any sensitivity into the cloud. A Computerworld article I cited in yesterday’s post about SAP’s late entry into the SaaS market included results of a survey of the UK & Ireland SAP User Group in which compliance and data protection fears were named as the biggest barrier to software-as-a-service, cited by 34 percent of respondents, ahead of lack of control (26 percent), lack of customization (20 percent), and risk of network or server outages (20 percent).

Writing on Network Security Edge, Sue Marquette Poremba shared results of an IEEE and Cloud Security Alliance survey which indicates a seemingly pressing need for cloud security standards, with 93 percent of respondents saying the need for such standards is important and 82 percent saying it’s urgent.

Lacking such standards, current and potential cloud customers are forced to put their faith in vendors. And vendors aren’t doing a great job of overcoming SaaS security fears, writes Dennis Howlett on AccMan. (I love his tagline, "Never knowingly under opinionated.")

While his post is largely about vendors’ shortcomings, Howlett’s first point relates more to companies considering SaaS. The first hurdle they’ll have to overcome is their desire for bulletproof security because (gulp) there’s no such thing. As Howlett writes:

Any vendor who says: “Oh no, we never have problems,” is lying. That’s a strong word but everyone has problems related to topics around security and data going astray at some point. It is in the nature of software that things will go wrong or that some expectation will not be met. What matters is: 1)How is it handled? 2)How is it communicated? and 3) Is it symptomatic of larger problems?

Howlett goes on to offer a list of security-related questions potential SaaS customers should ask, breaking them out into three major categories: infrastructure, procedures and security. I especially like the procedures category, as I think that’s one both clients and vendors tend to gloss over. Two of Howlett’s four sample questions: How often do they test their restore process? When was the last time they restored a customer’s data? He goes even further, with a list of more specific questions that should ensure procedures are effective. For example, vendors should be able to tell you when the last control tests were performed and let you see audit reports.

Howlett also suggests enlisting the services of security, data, SLA and contract legal specialists on hand. (At least some of whom are hopefully already part of your IT staff.) They’ll be especially helpful when it comes to risk assessment, writes Howlett:

In an ideal world, providers will be able to tick all the boxes but there can be perfectly good reasons why one or another item has an incomplete response or presents a response you were not expecting. This is where the combination of your technical and legal teams will add value. They can best explain the relative weighted risks.

Sketchy SLAs are a potential weakness, even for big SaaS and cloud providers like Amazon and Salesforce.com, as IT Business Edge’s Mike Vizard wrote a while back. A lack of more solid and specific SLAs "raises questions about just how much better the IT folks running cloud computing services are than the internal IT department," said Vizard.

Of course, some SaaS users are quite happy with their providers’ security systems and procedures. In a TDWI webinar late last year during which Shaklee CIO Ken Harris discussed his company’s use of SaaS business intelligence software from PivotLink, he said security is "absolutely better" with PivotLink than with Shaklee’s previous system. He suggested simply treating a SaaS provider’s facility as your own and asking internal security experts to perform a review. It should be "no different than internal analysis." That meshes well with Howlett’s advice, I think.