Performing a Cloud Audit

Introduction

In my last article, we understood the various risks involved in Cloud Audit. We discussed on Data Security Risks, Regulatory Risks, Backup Risks, Disaster Recovery Risks, Technology risks, Accountability Risks amongst others. One should also look at these risks from the angle of how they are deployed and serviced. For instance, back up risk in case of an Infrastructure as a Service (IaaS) would be different from that of Software as a Service (SaaS) or Platform as a Service (PaaS). But the bigger question is, how does one audit the Cloud and how do you ensure the risk is within the organization’s appetite? This article explores a few of these aspects.

Auditing the Cloud

Given the fact that cloud can be deployed in multiple ways (Public, Private, Hybrid, community etc.) and serviced in different models (IaaS, PaaS or SaaS), auditors need to understand the risks in each scenario. A general one size fits all approach may not be of much relevance as each organization has adopted to the cloud in a unique manner.

The first step would be to check the deployment and service model of the Cloud and understand the SLAs in place between the customer and the Cloud Service Provider (CSP). The following are a few pertinent questions:

a. What is the deployment model chosen by the customer and is that in line with the organization / regulatory expectations?

To recollect the popular deployment models are Public, Private, Community or Hybrid.

A company in the BFSI or Healthcare space may prefer a Private Cloud (On Premise or Third Party managed) in contrast to a Public Cloud. On the contrary a company in the hospitality space, may be open to Public Cloud, but with an additional layer of encryption if necessary.

b.What is the Cloud service model used by the organization?

As discussed in the previous articles, the popular cloud Service models are Infrastructure as a Service (IaaS), Platform as a Service (PaaS) or Software as a Service (SaaS).

A company having a dedicated tech team, might prefer going for an Infrastructure as a Service (IaaS), where only the infrastructure (i.e., Physical network, data center) is shared by CSP, and Operating system, network, applications, is designed and developed by the company. In this case as auditors, all the traditional domains are to be looked into, except for physical security and environmental controls. The below are a few areas to be examined:

Compatibility of applications once they have migrated from On-premises to IaaS
How have the Infrastructure and Virtualization Security been enabled?
How is the network, VPN set up? How is the firewall configured to permit the incoming and outgoing traffic?
How are the change management practices followed for the infrastructure?
How are the root accounts (super use account in cloud) protected?
Whether the vulnerability and penetration testing (ethical hacking) of the infrastructure was performed to identify technical weaknesses?
How is encryption enabled?
How are access to make Infrastructure changes managed?
How are logs configured and retained?
Is there a centralized Cloud infra team who manages the overall infrastructure? Does it include how it is designed and operated?
Are there standard ways in which software development takes place on the Cloud?

On the contrary, a company may alternatively be using a SaaS solution developed by a CSP. In this case most of the technical controls are the responsibility of the SaaS solution provider and the auditor must focus on the customers responsibilities which include the following:

How was the data migrated into the SaaS solution? Is there means to ensure integrity and completeness?
Who has access to the data from the CSP’s team and from the client’s end? How are those managed?
Is the access subject to periodical review and revocation?
How are users identified and authorized into the SaaS solution? Are there multi-factor authentications in place?
Who is responsible for periodical backing up data? Is the data back up in line with the organization needs? For instance, organization has a backup requirement for four times a day, whereas the SaaS solution could be backing up the data only once a day!
How is Disaster Recovery System enforced? How can it impact the clients’ business?
Whether super user has access to delete production data and backup data?
How is the data classified within the SaaS Application? Does it have Personally Identifiable data, Sensitive Data, highly confidential data etc.?
How is each category of data treated and secured? Are there mandatory encryptions in place?
Where is the data hosted? Are there geographical barriers?
Who and how is the process of access grant, revocation and modification monitored?

Therefore, as auditors, each Cloud deployment model has unique questions to answer. The below Figure is another reminder to understand the unique responsibilities in different service models.

c. Other common audit questions in all the Cloud Models

The following are few of the common area’s auditors should focus in addition to above:

Understanding the SLAs in place and how they are monitored?
What is the extent of customization performed by CSP for the customer? Often, the CSP does not customize as it makes it difficult for the CSP to manage those customizations.
What are the security frameworks the CSP is adhering to? ISO 27001, ENISA Cloud governance framework, Cloud Control Matrix (CCM) by Cloud Security Alliance (CSA), SOC 2 Type 2 are few standard reports which are worthy for CSPs.
Ensuring back up policy is consistent between customer requirement and what the CSP offers?
How are changes to application and infrastructure performed? What is the extent of sharing of the roles and responsibilities between the CSP and customer?
Has the CSP mandated encryption for all customers or is it only based on request?
Does CSP have access to the customers data and how is that monitored?
How is multi-tenancy of cloud customers managed?
Is there a Cloud Escrow agreement in place? An Escrow Agreement is a simple tri-party arrangement with mutually agreed terms between the CSP, customer and trustee. Under the terms of the Agreement, the CSP deposits the materials required to access, restore or rebuild the Cloud with the trustee and in the event CSP failing to operate or closing down the business, the customer can make use of the information with the trustee and suffer minimal losses
Are the backups subject to same level of protection as the production environments?
Whether the data is hosted within the geographical boundaries of the customer? Are there any regulatory requirements in storing the data locally?
Is the Disaster Recovery / back up stored in the same geographical location or stored in different location? (A different location is preferred as it reduces the risk in case the primary center is not accessible.)
Who invokes the Disaster recovery and under what circumstances are these invoked? Is it only when all the CSP or majority of the CSP customers have an outage or when even when one customer is having a challenge?
Are there additional methods of access restrictions such as IP based restrictions, browser-based restrictions, device-based restrictions, geography / country / region-based restrictions, time-based restrictions etc.

In General

Lack of awareness of responsibilities towards key risk (e.g., Who must take backup, who will test it) / Shared Responsibility
SLA Compliance and tracking (for CSP and Third Party)
Understanding of Backup, Restoration, BCP and Disaster Recovery requirements and responsibilities

In case of IaaS / PaaS audits

Network Security, VLAN, subnets, firewall rules (Ingress and egress) having incorrect configuration, open firewall ports,
Incorrect parameters configured for Virtualization Layer, permitting unapproved ports, Web Application Firewall WAF not configured, IDS / IPS not configured.
Ownership of deployment between centrally controlled cloud architects versus platform / department autonomy, creating conflicting rules.
Failure in DR / Backup restoration, lack of segregation of duties at Customer set up (e.g., User having access to delete production data and cloud backup)

In case of SaaS Audits

Absence of SOC 2 Report Type 2 – No visibility of CSP operations
Incorrect data classification principles followed by Customer (PII, Health, SPDI hosted in Cloud) without assessing the risk
SOC 2 report covers different locations, Customer data hosted in different location
Absence of User access review performed by Customer / CSP for the services provided
Lack of Change Management review by Customer in a highly customized environment.
Extent of access to CSP and their team

Concluding Thoughts

Auditing the cloud requires comprehensive understanding of the customer, the CSP practices and how the integration between them. One should also be clear on the shared responsibilities and to what extent these overlap or override. As auditors, it is important that cloud is assessed independently from the angle of how it is deployed, serviced and more importantly to the extent it is used by the organization.

Author

The author CA Narasimhan Elangovan, is a practising CA and partner KEN & Co. He is a GRC Professional, a Digital transformation catalyst and an author. He believes in the power of technology to solve everyday problems. He can be reached at narasimhan@ken-co.in