By David Baker
With the growing movement of enterprises to the cloud, it’s more important than ever that service providers demonstrate and prove good security practices to their customers, in good times and in bad. During an incident, how a cloud provider communicates to its customers says a lot about its commitment to security.
Sounds obvious, right? Well, three different times during the past seven months – and once while I was on a panel at the 2012 CSA Congress in Orlando – I’ve learned that it isn’t clear after all. As CSO at Okta, I work closely with our customers and they always ask, “What will you guys do if a breach occurs?”
When I tell customers that we’ll proactively reach out to them with written communication within hours of any important incident, they are surprised … which surprises me. We include transparent communication into every service level agreement (SLA), alongside availability guarantees and recovery point and time objectives.
SLAs exist so that customers have a means to measure the basic service performance of their providers. SLAs can sometimes be very complex and involve many components. But it’s the communication aspect that I see most commonly omitted. It’s important for cloud providers to incorporate communication protocols into their SLAs to ensure trust and transparency with their customers.
Proactive Communication
The most basic question that customers have for their cloud providers is finding out if there’s been a breach in service. During last year’s CSA conference in Orlando, the same question came up again and again: “How would I even know if the service is breached?”
Typically, when a large consumer-facing provider goes down, the company posts a “We’re sorry” or a fail message on its homepage. This works for a service such as Google, which expects users will visit the site, see the service interruption and then wait for the site to come back online. Users might tweet about how annoyed they are that Google’s down, but they wouldn’t expect a phone call from a Google rep explaining the problem and detailing the company’s plans to resolve it. Large consumer services, such as Google, simply have too many millions of users.
But for enterprises that rely on cloud services to run their businesses, an impersonal “sorry” on the provider’s website is little consolation during an interruption or breach. They should expect, as part of the signed SLA, a proactive message alerting them to the problem and detailing the response. Maintaining a high-touch customer interaction is essential to building and maintaining trust with customers. Cloud providers may think this seems futile or silly if they have several thousand enterprise customers and need to alert an administrator point of contact for each customer during a service-wide incident. Welcome to the big leagues of enterprise SaaS IT!
Transparent Expectations
As important, communication shouldn’t stop after the initial notification. It’s important for the vendor to update customers throughout the disruption, whether an outage, a breach or a service interruption. Transparency is essential from an enterprise standpoint in order to educate customers about the details of what’s going on, and to build trust that the problem is being addressed, what the target resolution steps are, and what work-around steps can be implemented..
Typically, recovery point objectives (RPOs) and recovery time objectives (RTOs) are standard SLA elements that set customer expectations for when the service will be recovered. What these elements don’t do is dictate how –and how frequently – the provider communicates to its customers during the recovery process. Okta provides identity management (IAM) in the cloud and is an extension of our customers’ IT team, so we maintain high-touch communication with them as frequently as possible. Companies should expect the same when they extend their mail, system log facilities or HR services into the cloud, all of which are important extensions of the enterprise.
By setting customer expectations from the outset with a detailed SLA, cloud vendors can assuage their customers’ anxieties – and develop trust for when, or if, breaches or service down time occur.
Continuity
Earlier this year, I wrote about how enterprise cloud IT services allow companies to enhance their business continuity plans. Geographic redundancy and layering across multiple AWS availability zones signifies a service’s investment in disaster avoidance and translates into a customer’s disaster recovery and business continuity plans. But lets face it, every disaster recovery and business continuity plan document assumes a worst-case scenario, so responsible service providers should work with their customers to develop continuity plans that account for specific worst-case disasters, whether a serious extended service degradation or a significant outage.
Though not necessarily baked into SLAs, customers should be able to leverage their providers to help assemble a continuity plan tailored to their needs. Objective plans between a cloud service provider and its customers about outage protocols in advance can save a lot of time, frustration and anxiety when a service misses a beat. It can be appropriate to have global or customer-wide SLAs spell out precisely the measures that will be taken in different scenarios to ensure a speedy recovery.
The businesses that thrive in the cloud are highly available, disaster resilient and prepared for anything. And they clearly communicate these guarantees to customers through SLAs. These agreements are intended to build trust by guaranteeing open communication when a problem arises and clear explanation about how (and when) the problem will be fixed. The detail in the SLA, and how a cloud provider follows through on those details, says a lot about its commitment to security – during the good times and, most importantly, during the bad times.
David Baker, is the chief security officer of Okta, an enterprise-grade identity management service that addresses the challenges of a cloud, mobile and interconnected business world. Follow him on Twitter @bazaker.