These days there’s no shortage of approved cloud services used by a typical Canadian organization – and the number will likely only increase in the future.
Cloud services can offer convenience in lower operating costs and improved security: The provider looks after patching and code development with more resources than most enterprises to hire top talent.
But they also create a problem for CISOs: How to track and ensure cloud providers and their products are complaint with corporate security controls and with compliance demands of business partners.
It isn’t easy, security consultant James Arlen told a recent meeting of the Toronto Area Security Klatch (TASK), a community of infosec pros and students, because few organizations have the leverage to get providers to divulge the secrets of their security processes.
However, he said, by gathering information and asking incisive questions infosec pros may be able to create a risk model that will meet the needs of management.
Arlen is the Hamilton, Ont.-based director of risk and advisory Services at Leviathan Security Group, a North American consulting firm. He’s also one of the lead authors for governance and risk management and compliance for the Cloud Security Alliance’s guidance manual. The Alliance promotes best practices for cloud providers.
Ironically, in this digital age, security compliance with a cloud provider comes down to paper.
“The contract [with the provider] is the whole damn thing,” Arlen told the meeting. However, unless the customer is a government or a global corporation, the provider usually holds the whip hand.
On top of that CISOs may have a raft of security standards to comply with, including the federal PIPEDA, the EU privacy directive, PCI for credit cards, NIST and various ISO/IEC rules. How does that relate to what a provider follows?
One answer is using the Cloud Security Alliance’s free cloud controls matrix, which cross-indexes major compliance regimes and discover how they map to another. This will partly help CISOs determine how provider security statements (like “we comply with ISO 27001) relates to other standards.
But, Arlen said, the real work of tracking compliance is creating a tracking list for every cloud provider and service staff are entitled to use – or, if the CISO decides, services staff are known to use even without permission. It will list key information including the business owner, the technology owner, who uses it, the service level agreement and the CISO’s security risk assessment.(see chart below)
It’s not as easy as it sounds. For example, he noted, it can be hard to nail down the product name. “There are about 30 variations of ZenDesk,” he noted. So the product has to have a name, including options and add-ons.
They type of cloud service will expand/limit compliance risk assessments: Software-as-a-service offerings usually can’t be touched, so the customer has to rely on what the provider says. Infrastructure-as-a-service, on the other hand, allows the customer to provide the operating system.
The list should also include an evaluation of data criticality (what happens if the data is lost, stolen or made unavailable by the provider).
While the list includes mentioning if there is a service level agreement, Arlen notes these are becoming rare.
As for the contract, the CISO may not be able to see the entire version held by the finance department, but sections related to security are vital. “You need that in order to understand what your capabilities are when an audit hits the fan,” Arlen said – who do you call, what did they promise/warrant?
Arlen admits to frustration with third party security attestations in contracts (“We attest to following ISO 27001”), which says nothing about the provider’s actual security capability.
“I was reading one two days ago where they had scope exclusions on page 17. Not on page three, where it would be useful to know they have excluded all but one of their products.”
Unless an organization’s infosec framework requirements are “truly bizarre,” Arlen added, the provider’s security standards will line up with ISO 27002 or NIST 800-53. The CISO will have to pay attention to where they don’t coincide, but it isn’t real to ask a provider to comply to your requirements.
He also cautioned about trusting a provider’s promise that it follows the SSAE16 SOC2 (system and organization controls) auditing standard. While there is a certification path, Arlen said, many providers rely on self-assessments. [As of May 1 this standard was replaced by SSAE 18, which requires companies to take more control and ownership of their own internal controls around the identification and classification of risk and appropriate management of third party vendor relationships.]
As for documenting the provider’s security compliance, Arlen urges CISOs to follow these seven steps:
- Review contract documents/exhibits
- Request vendor compliance documentation
- Review the Cloud Security Alliance Star registry for vendor compliance statements (see below)
- If neither exist, submit your own vendor security risk assessment
- Consider the provider and product stance relative to your requirements using the CSA cloud controls matrix
- Document deviations and your recommendations to the business/technology owner
- Revise this regularly
This is where things get tricky and may involve a lot of hunting.
Members of the Cloud Security Alliance’s can upload proof documents to its Star Registry. The registry consists of three levels of assurance (self-assessed, third-party assessed and certified, and continuous monitoring based certification). See here for Microsoft’s Azure compliance statement.
Be wary, Arlen suggested, of providers whose contracts mention exhibits, policies or standards but don’t include them. The reverse is also true: Providers who are transparent about their failures – Arlen cites Amazon’s explanation of a recent S3 outage – may be more trustworthy.
Look at the provider and its product separately for compliance, he added, because after an acquisition some companies don’t warrant the new products follow its standards.
Small questions may get valuable responses, (“Do you have a comfort level from your last pen test?” – and if the answer is “Yes, we got four criticals and we’re working on resolving them,” that may be satisfactory.)
He also stressed that in writing the risk assessment the recommendations have to be stated in plain English so business owners understand.
Finally the assessment need to be revised quarterly, Arlen said, because it’s not uncommon for a provider to make changes to their products daily (let alone acquisitions).
“Be careful when you’re relying on other people’s statements,” he warned. “Transiting scope is always going to be tricky, because their scope [for compliance with a standard] and your scope may not match,” but at least there will be enough information for a risk assessment.
Which brings us to the assessment. Arlen suggests creating a score (1 to 5, or red/yellow/green) for each provider and product. The list may have to be subdivided by business units or criticality. A business unit may be scored differently because of their demands. The result is the CISO may have to tell a business unit “ask staff not to use this, instead use this because it’s safer.”
The result won’t be scientific, Arlen admits, but it will be a “simple way to get a largely subjective but valid and useful summary of your compliance stance” with your cloud providers.
“Only you and your organization can decide what’s an acceptable risk,” Arlen told the audience
In an interview he expanded on that. “In a lot of cases it comes down to a financial decision,” he admitted. But he cautioned that CISOs must thoroughly investigate a provider’s claims.
“You’ll get the cloud service provider’s sales guy talking to a non-technical person [from the customer] convincing them they have to buy this cloud service. without ever meaningfully exposing the potential risks associated with using that provider because they took a short cut on a bunch of security compliance things they don’t want you to know.”
“An astounding proportion” of infosec pros still think cloud computing is a security risk, he added. “It went from being kind of funny to now being dangerously bad.” CISOs who think their security is better than the likes of Microsoft, Amazon, Google or Salesforce are wrong. “Your ability to attract, train, maintain talent is sharply limited compared to theirs.”
Small providers may not have been audited, but may have done a vendor security risk assessment. They may be willing to answer questions, which the CISO can treat as an unpublished attestation.
But it’s important, Arlen said, for the CISO to get a handle on what cloud services employees are using.
