Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Partner Perspectives  Connecting marketers to our tech communities.
5/18/2016
10:52 AM
Jamie Tischart
Jamie Tischart
Partner Perspectives
50%
50%

Cloud SLAs: What Everyone Should Know

13 questions to ask your service providers to better understand their service offerings and your risks.

When you sign up with a cloud provider for computing, storage, or application functionality, you should get a service level agreement that describes what the provider promises to deliver. An SLA should be fully transparent to customers and published on the provider’s website for prospective customers to review.

Unfortunately, SLAs are often difficult to find and can be even more difficult to decipher. SLAs are not really there to protect you, the customer. While they may provide some customer protection as a byproduct, they are really a marketing tool and a method to limit service provider responsibility in the event of an outage. This should not be viewed as negative. Every cloud provider I have worked for, talked to, and evaluated wants to provide their customers with 100% uptime and great service. But the complexity of software, infrastructure, humans, and reliance on third-party technologies and infrastructures makes 100% attainment near impossible.

I believe in the benefits, security, and financial opportunities that cloud services provide, but there are also risks that you should fully understand. In my last blog, I wrote about data disclosure and what you needed to ask your providers. This article is focused on service level agreements and what general questions to ask your providers to better understand their service offerings and your risks. Here are some practical questions to ask:

  1. Do you publish SLAs, and how are these documents accessed?
  2. If you do not publish SLAs, do you publish service level objectives (SLOs)?
  3. How do your SLA targets differ from your competitors? You may be surprised that SLAs do no vary that much.
  4. Why were your SLA targets chosen? Targets are often defined competitively or based on the best or worst capability of the underlying products.
  5. How often have you violated your SLAs in the last three months, six months, 12 months?
  6. Do you publish your SLA results openly? How frequently?
  7. Which SLA metrics do you fail at most often, even if it has no impact on your customers?
  8. How often do you increase or decrease your SLA targets, and what has the trend been? Any reduction or removal of a target may mean scalability challenges.
  9. What SLA metrics have been removed in the last 12 months?
  10. How often do you test your own SLAs? You really want to hear that the metrics are continuously tested.
  11. How are SLA claims validated? How am I compensated for an SLA violation? Your provider should be doing the work here, not requiring you to prove a failure.
  12. Do I receive detailed incident response information? This is necessary to fully inform your organization or customers of the problem and the solution. Never waste a failure; make sure your provider is identifying the root cause and resolving it.
  13. Do you use any third parties to monitor your SLAs? This can provide additional validation of the seriousness of SLA measurement.

One final word on compensation for SLA violations: I believe that neither the customer nor the provider wants to focus on compensation. The customer wants the level of service they contracted for, not a lower level of service with some credits. The provider wants to deliver the contracted service, not disappoint and pay their customers. Compensation is currently seen as a stick to hold providers accountable, but it may be having the opposite effect and inadvertently causing providers to limit or withhold their SLAs. Having clear, accessible, and realistic SLAs published by the service provider and reviewed by the customer helps to reduce the focus on compensation.

In my next blog, I will explore questions to ask your provider about specific SLA measures.

Jamie Tischart is the CTO for Cloud/SaaS (Security as a Service) and is responsible for leading the creation of Intel Security's future generation cloud solutions and creating sustainable competitive advantage. He has been with Intel Security for more than 10 years in a wide ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
'BootHole' Vulnerability Exposes Secure Boot Devices to Attack
Kelly Sheridan, Staff Editor, Dark Reading,  7/29/2020
Average Cost of a Data Breach: $3.86 Million
Jai Vijayan, Contributing Writer,  7/29/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-18112
PUBLISHED: 2020-08-05
Affected versions of Atlassian Fisheye allow remote attackers to view the HTTP password of a repository via an Information Disclosure vulnerability in the logging feature. The affected versions are before version 4.8.3.
CVE-2020-15109
PUBLISHED: 2020-08-04
In solidus before versions 2.8.6, 2.9.6, and 2.10.2, there is an bility to change order address without triggering address validations. This vulnerability allows a malicious customer to craft request data with parameters that allow changing the address of the current order without changing the shipm...
CVE-2020-16847
PUBLISHED: 2020-08-04
Extreme Analytics in Extreme Management Center before 8.5.0.169 allows unauthenticated reflected XSS via a parameter in a GET request, aka CFD-4887.
CVE-2020-15135
PUBLISHED: 2020-08-04
save-server (npm package) before version 1.05 is affected by a CSRF vulnerability, as there is no CSRF mitigation (Tokens etc.). The fix introduced in version version 1.05 unintentionally breaks uploading so version v1.0.7 is the fixed version. This is patched by implementing Double submit. The CSRF...
CVE-2020-13522
PUBLISHED: 2020-08-04
An exploitable arbitrary file delete vulnerability exists in SoftPerfect RAM Disk 4.1 spvve.sys driver. A specially crafted I/O request packet (IRP) can allow an unprivileged user to delete any file on the filesystem. An attacker can send a malicious IRP to trigger this vulnerability.