Compliance Complexities Challenge Cloud Adoption
Cloud and infrastructure compliance expert, Shawn R. Chaput, lends his understanding of the range of regulatory and other constraints that affect a number of users of high-performance computing. This week he took a look at the challenges of compliance burdens and what to consider when weighing cloud computing options based on lessons learned during his compliance consulting experiences. Although not intended to provide a comprehensive listing of considerations, it should provide some guidance as to some of the more commonplace examples of items warranting specific attention.
In recent experiences helping decision makers evaluate infrastructure options, we’ve encountered several clients who have decided that, given the specific sensitivity of data, the related systems should be hosted by professional hosting organizations well versed in the security of systems.
As it turns out, these data centers offer private cloud infrastructure as a service, which seemed particularly desirable to them. One of the clients in particular was looking for a provider who could guarantee the data would continue to reside within Canada as prescribed by provincial legislation as the data in question was health-related. In this specific example, this requirement became so difficult to accomplish that all other requirements seemingly fell by the wayside.
Ultimately, they found a private cloud provider but the level of security (and ultimately the compliance associated with those systems) may be insufficient for their desires.
Requirements & Obligations
The first things to understand are your regulatory and legislative obligations. Depending on your industry or geographic location, you may be subject to a variety of different laws and agreements governing the way you do business. From a security perspective, some of the more obvious ones include Sarbanes Oxley, PCI DSS, NERC CIP, and a variety of privacy regulations. Don’t expect your cloud provider to explain to you which are applicable and which they adhere to by default. For the most part, the providers are competing on price and security is not typically something organizations are really willing to pay for (although nearly all organizations expect it).
Just because the provider is a massive organization with a good track record for security and has good reference clients doesn’t mean that they’re giving you the same service at the price you’ve been quoted. You need to formalize your requirements and ensure the quotes you solicit capture them all. This likely means you need to talk to your legal counsel to understand and document these obligations. If the price is remarkably lower than the others, you need to look critically at the differences in service and specifically security.
As I alluded, it is entirely possible that cloud services can be compliant with the obligations your organization has set forth but, by default, it’s probably good to assume the initial proposal provided by them will not be sufficient. It’s also realistic to assume that the more burdensome your requirements are, the more the solution will cost to implement and maintain.
If we refer back to that example of the Canadian health care provider looking to use cloud services, the foremost requirement they had pertained to the physical location of the data and how it must reside within the province of British Columbia. This requirement alone immediately eliminates most of the very large cloud service providers and brings it down to a handful of local providers to choose from. It’s safe to assume that the price of the niche market players would typically be higher that the massive internationals but that requirement precludes the use of the cheaper providers. Similarly, if you’re looking for a PCI DSS compliant service provider, the list is relatively short and the prices not easily comparable to non-compliant service providers.
If you combine the two requirements (PCI DSS compliant and local BC company), it’s unlikely that list would be very large at all. In some cases, you may have to choose a local provider and help them to become PCI compliant, in the event that none of the companies fit both requirements. Clearly, the cost of that endeavour is not immediately comparable to posted monthly service charges from Microsoft or Amazon, as examples. Clearly, the organizational strategy of outsourcing to the cloud is not one to be taken lightly.
Information Security Organization
Ultimately, the success of your cloud compliance project hinges on your organization’s existing IT security and compliance maturity as well as how your organization manages third parties. Although it could be argued that there is significant overlap between the two concepts, we’ll treat them as relatively mutually exclusive for the purposes of this discussion.
With respect to the individual security elements pertaining to outsourcing to the cloud, there are a few basic principles which need specific consideration.
If you’re outsourcing anything, your organization needs to have a solid understanding of the type of data you’re sending outside of your organization’s physical premises. For example, in the event your organization is allowed to safeguard government classified documents at the level of Secret, you would not be able to have that data hosted anywhere that isn’t appropriate certified by the government for those purposes (and verified as such). This means you need to understand the sensitivity of the data to be hosted and the related obligations.
The exercise of data classification, system classification and labeling is intrinsic to the success and efficient use of resources for all information security programs and should be conducted long before you consider trusting a third party to host your data.
Ultimately, as data custodians, the cloud provider will do exactly whatever you tell them to do with the data and only that. They will not have the insight or capability to examine your data for sensitive information like credit card numbers then decide that that specific file or database should have an additional level of protection (unless, of course, you pay them to classify your data and systems for you as part of a consulting project). You need to identify the specific systems of concern and consider whether the costs associated with the protection of those systems in cloud are ultimately less than that you’re already spending.
Access Control & Connectivity
Authentication and authorization are another two areas you need to understand with respect to outsourcing to the cloud. Specifically you need to understand who owns and manages the authentication mechanism (such as LDAP, Active Directory, etc.) and who assigns the appropriate permissions to the individuals accessing the data or otherwise using the systems.
We’ve seen cloud deployments use a variety of different methods from standalone servers which don’t have any central management, to an extension of your corporate Active Directory environment to a fully managed authentication LDAP directory. Each of these options has different concerns pertaining to how they’re secured (and who is responsible for that security). This all needs to be documented and formalized. From a documentation perspective, there are many procedures which would need to be reviewed including user provisioning and deprovisioning to fully ensure you understand what you’re getting.
Another specific area to ensure is considered is the accounting and auditing of users as required by specific compliance regulation. From a security perspective, logging and monitoring does not apply to just the service logs which are generated by default by the operating system. The way we view logging and monitoring is that it is a means to forensically recreate events which have occurred to understand where they came from, what happened and hopefully why. This means that your provider should have some sort of Security Information and Event Management System (SIEM) in place to consider the security events which may occur and not just whether a service has stopped running. This, again, is likely not a standard offering by the less expensive cloud providers but needs to be considered if you’re looking to sufficiently secure your hosted environment to meet compliance obligations.
Additional considerations should include how the data stored in the cloud are secured as well as how that data is transmitted. Encryption tends to be the “easy answer” for questions about how the data gets from your office to the cloud using SSL or IPSEC. Data stored on hard disks may use full disk encryption or BitLocker or some other comparable technology but how often does the process by which the encryption keys are managed get mentioned? Rarely. You need to understand if the keys used are unique? Does key rotation occur? Ultimately, without a solid understanding of cryptography principles as part of a mature security and compliance program, it’s unlikely you’ll capture the requirements sufficiently within the contract with the cloud provider. Its further doubtful that the cloud provider will volunteer this level of detail without you asking the question.
Segmentation and Separation
Considering the nature of cloud infrastructure, to maintain specific compliance obligations you may seek to validate how the logical Virtual Machines (VM) in your environment are separated and secured from other customer’s VMs. Even if the hosted environment is a “Private Cloud” or perhaps using “dedicated hardware”, it’s in your best interest to understand the methods and mechanism in place separating the provider’s customer systems (and data, if stored on shared storage) and evaluate whether those controls are sufficient to your needs.
Ask for diagrams and evidence and don’t trust informal communications describing the environment. Further investigation into how the systems are managed (i.e. what access their staff has?) and what happens if the management consoles are compromised should also be considered. Additionally, from that perspective, the provisioning process of hypervisor users should be reviewed. Furthermore, how the hypervisor is secured or hardened should be considered and whether it is consistent with best practices such as NIST SP 800-125 Guide to Security for Full Virtualization Technologies.
Roles and Responsibilities
From a less technological perspective, another area warranting through review and formalization is a comprehensive responsibility matrix outlining who is responsible for what under each circumstance. This document needs to exist to ensure all parties are aware of their responsibilities under the contract and ensure aligned expectations. This goes for initial provisioning of virtual machines, patching and updating, log management, all the way through user management and incident response plan execution. Incident response is of specific importance for most organizations and, if you’re in one of the many jurisdictions subject to breach notification laws, you need to ensure that it’s well understood who is responsible for contacting your customers in the event your provider suffers a breach, as an example.
As with any new endeavor or outsourcing effort, a variety of evaluations and assessments should be conducted to ensure the concept makes business sense. This means ensuring a capable individual or company conducts a business impact assessment and perhaps a privacy impact assessment, depending on the nature of the systems and data you’re considering sending to the cloud. Threat and risk assessments are also commonplace for evaluating whether a technical solution meets the business requirements stipulated and addresses all the non-negligible concerns.
Due Diligence & Provider Contract Requirements
Really, when it comes down to any outsourcing deal, be it cloud computing related or not, contracts are the most important part of the arrangement and just like any other contract, due diligence should be conducted to ensure you are getting what you want.
As part of the diligence process, many organizations may mandate things like ISO/IEC 27001 compliance or PCI DSS service provider compliance. One must pay particular attention to the scope of the environments being assessed within each of these types of attestations to ensure the applicability to your potential environment. Just because an organization is ISO 27001 certified doesn’t mean the systems they intend to host for you will be within that certified environment.
Similarly, a lot of organizations use SAS70 type 2 audits to show they’re secure. SAS70 is in the process of being replaced by SSAE No. 16 with the intention of showing similar details about a service provider organization. These reports ultimately verify whether an organization follows the documented procedures they have, not whether they adhere to best practices or are inherently secure. When provided with one of these types of audits as evidence of security controls in place, review them carefully to ensure they cover the desired areas and procedures.
With respect to specific contract terms you should insist upon, clauses covering portability & interoperability should exist to ensure, in the event you want to retrieve your data and transfer it to a different provider or bring it back in house, it will be technically possible. Similarly, you should insist on the Right to Audit clause, which hopefully you’ll never use but should things go badly, you can exercise. And lastly, ensure you have a strong collection of metrics within the Service Level Agreement against which performance can be measured and tracked.
As you’ve probably discovered by now, cloud computing technology can easily extend your organization but many of the components security conscious organization consider “Standard” or expect may not be initially included in the contract and treated as a la carte. With that in mind, pricing associated with outsourcing data and systems subject to compliance obligations can considerably increase to the point that these specific costs should be thoroughly investigated prior to trying to outsource the responsibility of managing those systems. Furthermore, placing those items in the cloud do not necessarily allow you to abdicate all responsibility associated with those systems and, in fact, can make things more difficult to manage if appropriate roles and responsibilities haven’t been formalized. At any point, you’ll likely be obligated to validate that your service providers are compliant as part of your compliancy initiatives.
Privity Systems Inc. (Privity) is a boutique-style Western Canada based Information security consulting practice with a focus on compliance matters and strategic planning. As a Payment Card Industry Qualified Security Assessor (PCI QSA) company, Privity provides guidance and assurance to its Canadian clients dealing with these complicated regulations. Privity is a Microsoft Silver Partner with a competency in Identity & Security as well as Mid-Market Solutions. Privity is also a Symantec Silver Partner, Cisco Select Partner and VMWare Professional Service Provider.
About the Author
Shawn R. Chaput, CISA, CISM, CGEIT, CRISC, CISSP, ISSAP, ISSMP, CIPP/C, CFE, CIA, PMP, ITIL, ABCP, MCITP, MCTS, CCDA, STS, QSA; Chief Architect & Executive Consultant, Privity Systems Inc.
Shawn R. Chaput is an Executive Security Consultant and Chief Architect for Privity Systems Inc., an information security services company in Vancouver, Canada. With a past of working for large consulting firms like IBM, EDS and Accenture, he has over 16 year’s tenure in IT and more specifically within the information security and compliance professions.
As a trusted business advisor to many large and well known organizations, Mr. Chaput tends to fill the role of a chief security strategist helping organizations overcome tremendous roadblocks affecting their IT compliance initiatives such as PCI DSS, FISMA, NERC and SOX.
His role has lead him to advise executive management of some very large and well known organizations on how to effectively govern and manage IT risk; design enterprise security architectures, strategies and plans; develop cost-effective and sustainable security management policies and practices for governance frameworks.
An accomplished author, patent holder and public speaker, he has contributed to several articles and books as well as other formal academic publications. He participates in the Canadian Advisory Committee for the ISO SC27, which develops the ISO/IEC 27000 series Security Standards and is also a contributing member of many special interest groups within the PCI Community responsible for shaping the related official guidance and future versions of PCI DSS. A foremost expert on IT and security compliance, he was asked to author the inaugural “compliance” section of the Cloud Security Alliance’s “guidance” document and has managed all revisions since. Since his participation in the founding of the CSA, he has been published several times and spoken at several large conferences on the topic.
Shawn holds a Masters of Business Administration, Management of Technology from the Beedie School of Business at Simon Fraser University and an Honours Baccalaureate in Economics and Political Science from the University of Winnipeg. He also holds more than twenty industry certifications across multiple technical and best practices disciplines and is continually adding more.