Having moaned about the poor job vendors are doing in helping customers explain how they manage the potential pitfalls and barriers associated with SaaS it was refreshing to see sponsor Workbooks grab the nettle based on their own unfortunate experience. Don’t worry, this is a non-critical issue that doesn’t affect customers but which relates to the Content Management System they use. It also gives me an excuse to start tackling some of the problems that concern potential buyers.
First thing to say is that Workbooks should be admired for confessing their issue. 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:
- How is it handled?
- How is it communicated?
- Is it symptomatic of larger problems?
In explaining what happened, Workbooks lays out a bulleted list of things you should understand:
Infrastructure
- Where is their infrastructure located?
- How physically secure is the infrastructure?
- How is resilience achieved?
- What type of protection have they against theft, fire or flood?
- Power – what happens if there is a power cut, do they have UPS, Generator or Alternative Power Supply?
- What happens if there is a major disaster and the site is physically destroyed (Think Bunsfield or Plane Crash)?
- How quickly can they recover? How would they source new hardware, do they have a hot or cold standby site?
Procedures
- What is their back-up procedure?
- How often do they test their restore process?
- When was the last time they restored a customer’s data?
- How do they monitor their infrastructure?
Security
- What is their Information Security Policy?
- Are they working towards or have they achieved ISO27001?
- Do they have third-parties conduct penetration tests (white hacking) and if so how often?
It’s a good start but that’s all it is – a start. The devil is in the detail. Most of the questions are of necessity technical in nature. In order to understand the responses, I have concluded that you really need the services of security, data, SLA and contract legal specialists on hand. This may seem over the top but if you interpret the ramifications of what is happening between Eli Lilly and Amazon Web Services (AWS) then it becomes easy to see why this issue needs taking seriously. This from ComputerWorld:
According to one report from SearchCloudComputing, Eli Lilly, the pharmaceutical giant, is fighting with Amazon over just these kinds of issues. Amazon’s Werner Vogels denied the story’s contention that Eli Lilly had walked away from AWS. “Eli Lilly is still very much a customer and has not dropped their use of AWS,” wrote Vogels. Be that as it may, not everyone is content with Amazon’s contract policies. Burton Group analyst Drue Reeves said at the Burton Group’s Catalyst conference, “We don’t feel like there’s enough transparency in Amazon. We would like to trust you [but need more information].”
Trust is important. Eli Lilly was burned publicly once before by an accidental release of the e-mail addresses for nearly 700 subscribers to its Prozac.com e-mail alert. The company certainly doesn’t want a repeat performance of that, and no company wants to be left holding the bag in the event of a data breach because of the negligence of a cloud provider.
You might be thinking – but why should I care about AWS? They don’t supply anything to me. Many of the SaaS providers use AWS. That’s why an understanding of where your data is held is important.
On procedures, I don’t think it’s enough to get information on the processes. I want evidence of what those processes deliver. So for example:
- Will the provider show you test results?
- Will they provide details of methodologies used that you can in turn sense test (subject to non-disclosure for identity purposes)
- What evidence can they provide for uptime? (example: Salesforce.com shows service performance history along with a slew of information about security policies, Intacct provides system status data.)
- Can they show you details of the technical architecture (again under non-disclosure if necessary) covering their security methodology. Workday provides broad details of how they solve this problem.
- If they are claiming SAS 70 Type II assurance then what evidence do they have? When were the last control tests performed? Can you see the audit reports? When will another audit be performed? Is the audit methodology good enough to stand scrutiny?
- What is their outage history?
- What remedial steps have been taken to ensure that past outages are not repeated?
These are all questions that any provider should be able to confidently answer or provide a bullet proof reason why they cannot. Again, you might be thinking: “Why do I need all this when I’m a modest sized business?” The answer is easy to understand:
- SaaS/cloud providers are banking on the fact that many thousands of customers will use their services. As a system scales it becomes vulnerable to a broad range of potential problems. I have seen this many many times.
- The larger a customer base becomes, the more attractive it is to those with less than good intentions.
- As pressure to reduce or hold cost levels continues as the business scales, there is always the temptation to cut corners. If that’s the case then what is the potential impact?
- You don’t have direct control over how the provider operates their business so are entirely reliant on the extent to which they are adopting the best possible practices. This is inevitably a trade off where you weigh the risks against SaaS/cloud benefits. The best providers will behave in a responsible and transparent manner but you cannot take that for granted or simply accept public statements on their website.
None of this should frighten you. 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.
So – which would you prefer? Understand and assess risks or assume that SaaS is inherently a risky alternative to the point where it obliterates benefit? As someone who has exclusively used SaaS/cloud for more than 6 years I know which camp I fall into.
If you would like further information then please feel free to contact me. I have some but not all the answers. I know plenty of people who can fill in the gaps.
Related articles by Zemanta
- Overcoming Fear Of The Cloud (forbes.com)
- Hoff says SaaS Vendors Should Eat Their Own Dog Food. Is Security SaaS an Exception? (securecloudreview.com)
- The Service Provider of Tomorrow, part 7: Revenue-producing Infrastructure SaaS Fills the Void (securecloudreview.com)
- Is SaaS in its awkward adolescence? (securecloudreview.com)
Comments on this entry are closed.
Get into the conversation