Achieving compliance in the cloud

More and more organizations are moving toward cloud technologies for scalability, cost reduction, and new service offerings. Here's a look at cloud basics and auditing for compliance challenges.

cloud blueprint schematic
Credit: Thinkstock

More and more organizations are moving towards cloud technologies for scalability, cost reduction, and new service offerings. In this short article we will review cloud basics and look at auditing for compliance challenges in the cloud. 

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models.- The NIST 800-145 Definition of Cloud Computing

Let’s review the deployment models:

Public Cloud- Cloud computing services from vendors that can be accessed across the internet or a private network, using systems in one or more data centers, shared among multiple customers, with varying degrees of data privacy control.

Private Cloud - Computing architectures modeled after Public Clouds, yet built, managed, and used internally by an enterprise; uses a shared services model with variable usage of a common pool of virtualized computing resources. Data is controlled within the enterprise.

Hybrid Cloud - A mix of vendor cloud services, internal cloud computing architectures, and classic IT infrastructure, forming a hybrid model that uses the best-of-breed technologies to meet specific needs.

Community Cloud - The cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (for example, mission, objectives, security requirements, policy, and compliance considerations). It may be managed by the organizations or a third party, and may exist on-premise or off-premise.

Service Delivery Models:

Infrastructure as a Service (IaaS) - Delivers computer infrastructure, typically a platform virtualization environment as a service. Service is typically billed on a utility computing basis and amount of resources consumed.

Platform as a Service (PaaS) - Delivers a computing platform as a service. It facilitates deployment of applications while limiting or reducing the cost and complexity of buying and managing the underlying hardware and software layers.

Software as a Service (SaaS) - Delivers software as a service over the internet, avoiding the need to install and run the application on the customer's own computers and simplifying maintenance and support.

So now that we have reviewed the basics of deployment and service delivery, what does it all mean to be compliant in the cloud vs compliance on a traditional perimeter based corporate network? We also have to consider the business sector or compliance model and sometimes this is mixed. For example in healthcare it’s HIPAA compliance we are trying to achieve, In the credit card retail environment it's PCI DSS and in government it's FISMA or the NIST Cyber Security framework we must achieve. Of course healthcare uses credit cards to create a mixed compliance. 

It's important to know where the responsibility is when working in the cloud. As we move from IaaS to PaaS and finally to SaaS, we see that the cloud vendor is responsible for more. For example in SaaS they are delivering it all. In IaaS they deliver the least so the rest is all your responsibility. The more they provide the more you lose control.  

Some real challenges in working with a cloud environment are understanding the scope of the cloud environment, Can your current risk assessment work in the cloud? Audit trails in the cloud?

The key is to go with a risk-based approach and know that cloud-based risk is different. For example, the concept of a perimeter in a multi-tenant environment doesn’t make sense anymore. Some examples: in service delivery risk, we must evaluate virtualization risk, SaaS risk, PaaS, and IaaS risk.

Then we need to look at deployment risk, business model risk and security risk just to name a few.

What we really need now is a map, this is getting too confusing right? Deloittes Cloud Computing Risk Intelligence Map is very helpful.

Take a look at data management in the cloud risk map. Notice that for data usage we have a lack of clear ownership of cloud generated data, and unauthorized access or inappropriate use of sensitive data, personal data or intellectual property. These are real-world issues with cloud computing because you don’t have full control especially if you are in an SaaS environment. At the same time you must be able to apply the deployment and service delivery models to your actual compliance framework as in HIPAA, PCI DSS and FISMA for example.

SOC 1, 2 and 3

SOC 1 is for service organizations assessments that impact financials, therefore let's look at SOC 2 and 3. SOC 2 is geared towards technology companies and allows the incorporation of other frameworks into the SOC 2 report. SOC 2 assessment consists of the Trust Service Principles (TSP) framework from American Institute of Certified Public Accountants (AICPA) for evaluating a service organization's internal controls against the prescribed set of Common Criteria found in the TSPs.

SOC 2 assessments cover a wide range of controls such as operational, technical and information security controls. SOC 3 SysTrust/WebTrust also  known as Trust Services, which are broad based  and also from (AICPA). We are really talking about e-commerce compliance here! So SOC 3 covers e-commerce web servers and the systems that interconnect and support e-commerce business platforms. 

Trust Services are a set of professional attestation and advisory services based on a core set of principles and criteria that address the risks and opportunities of IT-enabled systems and privacy programs. The following principles and related criteria are used by practitioners in the performance of Trust Services engagements:

  • Security. The system is protected against unauthorized access, use, or modification to meet the entity’s commitments and system requirements.
  • Availability. The system is available for operation and use to meet the entity’s commitments and system requirements.
  • Processing integrity. System processing is complete, valid, accurate, timely, and authorized to meet the entity’s commitments and system requirements.
  • Confidentiality. Information designated as confidential is protected to meet the entity’s commitments and system requirements.
  • Privacy. Personal information is collected, used, retained, disclosed and disposed to meet the entity’s commitments and system requirements.

Who sees your data and how can you really know?

In cloud environments, multiple party’s data and services can exist on a single physical platform running virtual services for its customers. This creates several problems for security, compliance and audit, including:

 • Limited ability to control data and applications

• Limited knowledge and no visibility into the degree of segmentation and security controls between those collocated virtual resources

 • Audit and control of data in the public cloud with no visibility into the provider’s systems and controls even in a private cloud that is privately managed, multi-tenancy is enacted at many layers, including storage, application, database, operating platform and hypervisor-based infrastructure. In other words, shared hosts, data centers and networks can potentially exist between the same and different organizations or internal business units. As such, it is critical that network segmentation is created securely with the ability to monitor any anomalies that may occur across virtual network boundaries.

What tools are available?

The auditee – in this case the cloud provider or consumer – is required to produce compliance reports to prove that their security measures are protecting their assets from being compromised. Several open source and commercial tools, including security information and event management (SIEM) and GRC tools, that enable generation of compliance reports on a periodic and/or on-demand basis, exist in the market.

In cloud environments it’s important to know what is different in an onsite local computing environment vs cloud service providers. Who has responsibility and to capture this in an service-level agreement and system security plan. Nothing can be assumed. The fact that you are sharing a cloud environment to provide growth and on demand scalability means we must realize the issues related to sharing.

Just like renting a  room out in your house changes your security, and privacy so too does sharing cloud computing resources. The NIST and Cloud Security Alliance Standards are mandatory to manage the ever changing and complex cloud environment. In both local and cloud environments we are managing risk and in the cloud it’s more complex, shared and dynamic.

Some helpful publications

For further reading on cloud virtual machine issues I recommend a paper titled “TenantGuard: Scalable Runtime Verification of Cloud Wide VM level network isolation.”

NIST SP 800-53, NIST SP 800-144, SP 800-30, Deloitte cloud computing risk intelligence map, ZCloud, Security Alliance Cloud Controls Matrix, ISACA Cloud computing Audit program, FedRamp Federal Risk and Authorization management Program.

References SANS

Deloitte

This article is published as part of the IDG Contributor Network. Want to Join?

Cybersecurity market research: Top 15 statistics for 2017