The 2021 Guide to Multi-Cloud Security and Compliance

If you work as a CISO, Enterprise Architect, Cloud (Security) Architect, in DevOps or you are just interested in cloud security and compliance - this guide is just right for you.

Photo by Nathy dog on Unsplash

In this post I’ll cover what’s important when thinking about cloud security:

• What cloud security and compliance is
• Who the stakeholders are — inside and outside of your organization
• What threats jeopardize your cloud environment
• How to address security challenges on an organizational and technical level
• How to create a security concept that combines organizational and technical security aspects
• How to improve the interface between central IT and compliance, governance, and regulatory departments

If you want to dive deeper, this guide will go into more detail on:

• The concept of shared responsibility
• IAM and tenant isolation
• Shadow IT
• Best practices on landing zone configuration
• Security specifics of AWS, GCP, and Azure
• Certifications like ISO 27001 or CSA

Chapter 1: Cloud Security and Compliance Fundamentals

Let’s get started with a chapter on the basics of cloud security and compliance.

Specifically, in this chapter, I’m going to cover why cloud security and compliance are extremely important!

This first chapter will also show what cloud security and compliance are.

Let’s dive right in!

What is Cloud Security?

Cloud security is a strategy and concept to protect cloud computing environments, applications, and data. Important elements of cloud security are organizational and technical security, as well as an overarching strategy. Although it might never be possible to prevent every variety of attacks — a well-designed cloud security strategy vastly reduces the risks to data, infrastructure and applications.

The CIA and Zero Trust in Information Security

In our case CIA has nothing to do with THE CIA — it stands for the three key components of information security: Confidentiality, availability, and integrity.

Cloud security is no exemption — every security strategy should aim to achieve these goals.

Arguably the most relevant goal in current security considerations is integrity.

Today’s enterprise IT architectures have become so complex, that traditional perimeter security thinking won’t get you very far anymore. Your organization probably has no clear picture of who is doing what within their enterprise IT.

That is a great threat to the integrity of data, applications, and resources.

The modern approach to information and cloud security is the zero-trust approach: Assume that your firewalls have been breached, assume that the enterprise network is just as hostile as the internet — and construct your security strategy around that.

Here are the three guiding principles to the zero-trust approach:

1. Verify explicitly
2. Use least privileged access
3. Assume breach

Why is cloud security so important?

You can have the best applications and the most satisfied customers.

But what if sensitive data is exposed — due to misconfiguration?

Exposing sensitive customer data greatly reduces your customers' trust and may result in churn.

What if an attacker gains access to your infrastructure? Imagine an airline that loses control of the airline app backend. Resulting downtime leaves customers unable to book flights and passengers unable to check-in.

Competitors that have access to your company secrets can pose an existential threat!

Those scenarios will cost reputation and in the end a lot of money:

According to a report from IBM and the Ponemon Institute, the average cost of a data breach is just short of 4 million dollars.

High profile cases of cloud security incidents include Facebook, Capital One, and Docker Hub.

What are the main cloud security risks?

Most cloud security incidents can be mapped to one of these 4 categories:

• Data is exposed or leaked due to a lack of protection
• An unauthorized user from outside the organization has access to internal data
• An internal, authorized user has too much access to internal data
• A malicious attack incapacitates cloud infrastructure

Cloud security measures aim at reducing the risks posed by these threats by protecting data, managing user authentication and access, and keeping resources and services running.

Cloud computing vs. on-premise computing

“We wish for the same security measures and capabilities on-prem as they are available in the public clouds”

I hear this a lot when talking to our customers.

Cloud security risks can seem daunting. But they overlap a lot with traditional IT security risks. Cloud computing is often more secure than on-premises computing. Most cloud providers have more resources to implement comprehensive security concepts than individual businesses do, which lets cloud providers like Amazon, Microsoft, or Google keep infrastructure up to date and patch vulnerabilities as soon as possible. For example, 3,500 security experts work on keeping Microsoft’s Azure Service secure. Even the CIA decided to go all-in on the Cloud with a private AWS account.

How can you improve the security of your clouds?

Achieving a higher level of security in your clouds is done by a combination of organizational and technical measures.

To get an overview of the current state of your cloud governance capabilities, have a look at our cloud governance assessment.

Let’s have a look at what that means and what you need to take into account:

• Shared responsibility
• Stakeholders in your organization
• Internal regulations
• Identity and Access Management
• Tenant Isolation
• Shadow IT
• Encryption at rest and in transit
• Credential management
• Network architecture
• Monitoring
• Audit logging
• Regional restrictions
• Landing zones
• Transparency
• Certification
• Exit Strategy

And this is likely not an exhaustive list.

Luckily this guide covers all of these aspects and a few more!

Chapter 2: Shared responsibility and stakeholders

First of all: It is important to know who is responsible for what aspect of cloud security:

The cloud provider, cloud foundation, or DevOps team in your company or — most importantly — yourself? To clarify ownership throughout your organization and enable the departments and teams concerned with aspects of cloud security is a vital process for implementing a cloud security concept and strategy.

This chapter will shed light on responsibilities and relevant shareholders.

Let’s get to know the people concerned with your cloud security!

What is behind the concept of shared responsibility?

A very basic concern in cloud security is preventing unauthorized physical access to the servers. Does that mean you have to lock server room doors at Amazon, Microsoft, or Google? Of course not: The responsibility for all the different aspects of security is shared. You don’t have to worry about locked doors or even patching the underlying software of the clouds you use.

Example: Pooled Audit

However, there is another side of the coin. A lot of companies, especially in regulated environments, e.g. the financial services industry are required to ensure unrestricted audit rights when they outsource material IT workloads. This means that they would have to provide access to the service provider’s premises when conducting an audit. This had been a showstopper for a lot of organizations within the European Union. In 2017, pioneering companies like the “Deutsche Börse” initiated a new concept, called the “Collaborative Cloud Audit Group” that enables financial institutions to group together to perform such audits to reduce the effort on both sides, the cloud providers and the financial institutions.

In turn, that means that there are other areas, for which the cloud providers don’t take responsibility. For example:

• How you set up your organizational structure, e.g. IAM processes
• How you configure and secure your infrastructure, e.g. network setup, firewalls, load balancers
• How you secure your applications

A general rule is that the cloud provider is responsible for the security of the cloud, while you as their customer are responsible for the security in the cloud. However, other aspects affect the shared responsibility model, e.g. the service model you are using (Iaas/PaaS/SaaS).

Here is an example: If you use a SaaS service like Google Docs, you don’t have to take care of the VM images or databases this application is running on. If you deploy your own MySQL cluster to AWS EC2 instances, however, you are responsible to encrypt the connection via SSL or TLS.

Who are the stakeholders in the cloud security business?

Put simply, the providers are responsible for the security “of” the cloud- whereas you and your organization — as their customer — are responsible for the security “in” the cloud.

Let’s have a look at what that means in a little more detail as you’ll have to figure out how to distribute responsibilities within your organization as well.:

Provider: The provider usually makes sure that your infrastructure built within its platform is secure and reliable. This responsibility includes the physical security of hosts, networks, and datacenter as well as the software security of storage, databases, and networking.

CISO: The CISO cares about the information and data security of a whole organization. That includes — but is not limited to — the cloud. The CISO takes executive responsibility for security operations, data loss and fraud prevention, identity and access management, and the overall security architecture.

SOCs: A SOC (Security Operations Center) is a central organizational unit that is responsible to protect IT infrastructure across the organization. Monitoring IT systems, identifying security risks, and responding to security incidents when they occur are part of the team’s core responsibilities.

DevOps: DevOps teams are responsible for secure engineering, secure deployment, and operations, availability management, backups, separation of duties, and security evaluations.

Cloud Foundation: Most large organizations aim to transform their IT environment towards cloud-native technologies to achieve more agility in their software delivery. They often set up a dedicated team to manage cloud infrastructure and provide secure cloud environments to DevOps teams across the organization. These teams are often called “Cloud Center of Excellence” or “Cloud Foundation” as they lay the foundation for the use of cloud infrastructure. This foundation may cover security and compliance aspects and relieves DevOps teams from security or compliance requirements that are independent of the application, e.g. the geographic restriction of cloud data centers.

Chapter 3: Cloud Compliance

This guide has been talking about cloud security a lot without touching on the important topic of cloud compliance so far. The second your organization decides to move data and applications to the cloud compliance becomes a huge issue!

Time to take a look at what you need to know about compliance and regulations when it comes to the cloud.

What is cloud compliance?

The term cloud compliance refers to the need that cloud-delivered systems must be in line with internal and external regulations. A common example is the European General Data Protection Regulation (GDPR), which concerns virtually every organization. But there are also very specific regulations for example in the financial or healthcare sector that companies need to comply with. This compliance must be transparent and auditable for regulators.

Which rules are there for cloud compliance?

The first step towards achieving cloud compliance is to be aware of the standards and regulations that apply within your industry and specifically within your organization. Standards and regulations may apply to certain

• Industries
• Geographies

Depending on the relevance of your industry there may be different regulations in place. Here are some (exclusively german) examples, however this list is not exhaustive:

• KRITIS for critical infrastructure (national)
• BAIT and VAIT (Supervisory Requirements for IT in Financial Institutions/Insurance Undertakings) (national by the BaFin)
• ISO/IEEC 2700x (international by the International Organization for Standardization and the International Electrotechnical Commission)

What happens if you fail to be compliant?

Organizations are made responsible to meet a large variety of regulations. Failing to meet these can result in fines and a negative impact on your trustworthiness and reputation.

A widely discussed example is the GDPR, which focuses on data protection and privacy.

Even if your organization is based outside the EU — as long as you have a business in the EU, GDPR compliance is required. The possible fines are enormous. According to enforcementtracker.com, the highest fines were due to insufficient technical and organizational measures to ensure information security. Marriott International was fined more than 110 million euros and British Airways almost twice that amount because of information security violations.

Cloud security and cloud compliance is a shared responsibility between cloud providers and organizations. In the past years, cloud providers have invested a lot in providing better transparency and better tools to be an eligible infrastructure provider, even for very sensitive industries or governments.

How do you stay compliant when working with the cloud?

A great challenge to staying compliant is the ever-changing environment and requirements of internal and external regulations. That brings us to our list of 4 aspects you need to take into account:

1. Be aware of regulations and guidelines
2. Control access
3. Classify the data and document, where it’s at
4. Encrypt the data you are entrusted with

But there is a lot more to ensuring continuous compliance — especially across multiple environments and vendors: With a declarative approach, you can fully utilize the advantages the cloud offers by automating the efforts of enforcing your compliance policies across your multi-cloud environments.

Chapter 4: Organizational Security in Cloud Computing

Let’s talk about organizational security.

This chapter will tell you what organizational security is. It will also show why it is an important part of any cloud security strategy. And if you want to learn about what aspects you should definitely consider for your organization — you came to the right place!

Let’s go!

What is organizational security?

Organizational security is everything you do on an organizational (as opposed to technical) level to improve the security of your cloud.

How can you improve the organizational security level?

In this case, you don’t have to evaluate whose responsibility the measures for organizational security are depending on the cloud operating model: Organizational security is for everyone!

(Sidenote: Clear responsibilities are important! In that way an organization stays responsive during a security incident.)

• Implementing principle of least privilege
• Isolating tenants in a multi-tenant environment
• Practicing the 4-eye-principle
• Fighting shadow IT
• Preventing accidental misconfiguration
• Classification of data

What is the principle of least privilege

The principle of least privilege (PoLP) is the concept of granting access to only the resources that are necessary to do the assigned tasks. It is pretty similar to what you might know from movies about secret agents: They only know what is necessary to accomplish the mission: In that way, they can’t endanger the whole operation in case of failure.

But we’re not the CIA or MI5 so let’s see what the principle of least privilege means in terms of cloud security!

4 Tips to implement the principle of least privilege

From developer onboarding to long-term management of user and permission lifecycles, managing access to cloud infrastructure is complex and security-critical. Authorizations should be granted as sparingly as possible (principle of least privilege) to reduce security risks. At the same time, the productivity of developers should not be restricted by lacking access rights or tedious approval processes. A simple and transparent process for assigning access rights is therefore essential.

1. Avoid excessive use of broad primitive roles
2. Assign roles to groups, not individuals
3. Reduce risk and control access to your project by using networking features
4. Consider using managed platforms and services

Quarantine your applications and environments

A relatively easy but very important step in securing your cloud workloads is tenant isolation.

By that I mean 2 things:

1. Every application needs to run in its own tenant.
2. Different development environments, e.g. development, staging, and production environments of each of your applications should run within their own tenant.

A common setup with our customers is three cloud tenants for every application you move to the cloud: Development, staging, and production. The number of stages ranges from 2 up to 6, depending on the use case.

Let’s have a look at a company that did not follow this principle — Tesla:

In 2018 security experts discovered that hackers gained access to Tesla’s cloud resources. Not to steal company secrets but use them to mine cryptocurrencies. All of that happened on a tenant that was used for several applications and environments. That made it relatively easy for the attackers to hide their malware in the general activity on this tenant. It’s much harder to identify deviations of regular activity within a shared environment. One team responsible for a single app would probably have identified high expenses or unknown resources much earlier.

The dark truth about Shadow IT

According to a survey by the Cloud Security Alliance, only 8% of the CIOs believe they know about the secret digital infrastructure in their company. This shadow IT, or Stealth IT as it is more aptly referred to, hides from the radar of IT managers. Eco, the Association for the Internet Economy, asked 580 experts from German medium-sized companies for its IT security report — the result is clear and worrying: three-quarters of those surveyed assume that a shadow IT exists in their company. Nearly 25% fear a “considerable extent”.

Even without an actual security breach, shadow IT costs your organization money, right now. It is uncontrolled and may contain unnecessary workload, organization-wide discounts by the cloud providers, e.g. for reserved instances are not taken into account. There are examples of cloud costs being billed as travel expenses on company credit cards, making the controlling of cloud costs hardly possible.

Chapter 5: Technical Security in Cloud Computing

Now that we have covered the ins and outs of organizational security, let’s turn to its even more powerful brother: Technical security!

This chapter will cover what technical security is when it comes to keeping your cloud secure.

You will learn about important aspects of technical security, like encryption at rest, credential management, and audit logging.

What is technical security?

In the realm of IT — or our case more specifically — cloud security, the term technical security refers to technical actions that can be taken to implement and enforce security measures.

How can you improve your technical security level?

Here’s a list of aspects and concepts you definitely have to take into account when thinking about technical cloud security:

Once again, make sure you understand who is responsible for each aspect. The cloud service provider? If not, who in your organization is it?

• Encryption
• Credential management
• Network architecture
• Monitoring
• Audit logging
• Regional restrictions

Even if you make use of cloud-native service offers, you have to evaluate whether the service is compliant with your internal and external regulations. To give you an example: With AWS Key Management Service (KMS), AWS offers a managed service to generate encryption keys. Some organizations however have the requirement to have an exclusive control on their HSM (hardware security module, the device that manages digital keys and performs encryption and decryption functions), which isn’t fulfilled by the KMS service. To address this need AWS launched additional services for this specific use case.

Encryption at rest: Protecting data, even if it has been stolen

Simply put, data encryption is the process of translating one form of data into another form of data that unauthorized users can’t decrypt. For example, you saved a copy of a paid invoice on your server with a customer’s credit card information. You definitely don’t want that to fall into the wrong hands. By encrypting data at rest, you’re essentially converting your customer’s sensitive data into another form of data. This usually happens through an algorithm that makes it practically impossible for somebody without the encryption key to decode it. Only authorized personnel will have access to these files, thus ensuring that your data stays secure.

Encryption in transit: Get the armored vehicle for your data

Data that is being moved from one place to the other is vulnerable to attackers. Unencrypted data transfer puts this data at risk. To protect it against eavesdropping or a Man-in-the-Middle you need to enforce your defined encryption requirements. It’s also a good idea to authenticate the network communications using Transport Layer Security (TLS) or IPSec.

Credential management

Credential management is key to securing any kind of system: From the traffic on our roads to the traffic in our data centers. The management of drivers' licenses and IT credentials have a lot in common. They both are:

1. Generated,
2. stored,
3. backuped,
4. used,
5. audited,
6. changed,
7. and eventually revoked and deleted.

Those 7 aspects need to be taken into account when managing credentials. That’s about how far our little metaphor will get us here. Let’s dive into multi-cloud credential management:

When we say credentials, we mean passwords, tokens, or keys that grant access to your workload. Manage credentials and authentication mechanisms in a way that reduces the risk of accidental or malicious use.

Here are a few tips, tricks, and best practices:

• Define IAM configurations to meet your organizational, legal, and compliance requirements.
• Integrate with the centralized federation provider of your organization to reduce complexity. In that way, all users are authenticated in a centralized place.
• Enforce password requirements to protect against password attacks like rainbow tables or brute force.
• Enforce multi-factor authentication (MFA) to provide an additional layer of access control.
• Lock physical credentials away That includes hardware MFA tokens.
• Rotate credentials regularly to avoid unauthorized use of old credentials.
• Audit credentials from time to time.

Network architecture

Most organizations have a hybrid infrastructure, with parts in the cloud and parts on-premises. Sensitive data is often kept on-prem, for security reasons, but also because large amounts of data in the cloud lead to an immense lock-in effect, as it is very easy to get the data in there, but costly to take it out again. That’s why a lot of applications running in the cloud need access to on-prem infrastructure.

All 3 public cloud providers offer Virtual Private Clouds (VPCs) that enable you to build virtual network topologies that you can fully control.

Here are some VPC Best-Practices to improve network security:

• Use multiple availability zones for high availability
• Use public subnets for external-facing resources and
• Private subnets for internal resources
• Use ACLs → Access Control Lists to limit the traffic between components to the minimum

It can make sense to hand out new cloud tenants with standard network components already deployed (via Landing Zones) to relieve DevOps teams and avoid insecure configurations.

4 Tips for monitoring cloud security

Cloud Monitoring is another critical aspect of keeping your workloads secure. Correct monitoring will tell you if your cloud infrastructure functions as intended while minimizing the risk of data breaches.

To do that there are a few guidelines to follow:

• Your monitoring tools need to be scalable to your growing cloud infrastructure and data volumes
• Aim for constant and instant monitoring of new or modified components
• Don’t rely on what you get from your cloud service provider alone — you need transparency in every layer of your cloud infrastructure
• Make sure you get enough context with your monitoring alerts to help you understand what is going on

You can and should monitor on different layers (e.g. network, application performance) and there are different tools for doing this. SIEM (Security Information and Event Management) tools collect data from various sources. They process this data to identify and report on security-related incidents and send out alerts whenever a potential risk has been identified.

Audit Logging

With audit logging, you document changes applied to your cloud tenants: Has a new user been added to your AWS account? Were access rights granted in your Azure subscription? Or who logged in when and for how long into your Google Cloud Project?

Audit logs are an absolute necessity when it comes to cloud security and compliance! And there are three main reasons why:

1. Compliance auditing: Audit logs are official records that can be used to prove compliance to an auditor.
2. Security analysis: Audit logs let you trace malicious behavior and potential attacks.
3. Operational troubleshooting: Audit logs help you find what is wrong with your tenants.

Closing remarks to this topic: Disk space is cheap, there is absolutely no reason to not keep audit logs.

The most common audit logging services

At AWS user activity and API, usage can be tracked with AWS CloudTrail. CloudTrail stores event logs in the CloudTrail console, Amazon S3 buckets, and (optionally) in Amazon CloudWatch logs.

Azure provides a whole barrage of logging, auditing and monitoring tools. Audit logs can be retrieved from the Azure Active Directory portal.

Google Cloud Platform offers Cloud Audit Logs, that maintain three audit logs for each project, folder, and organization.

Regional Restrictions

Regional restrictions in the context of this guide are mainly a compliance concern that can be addressed technically. Many European companies want to or need to, make sure that their data is stored on servers within EU jurisdiction. Same with managed services: They often need to be delivered from a certain geography.

With AWS for example you can disable entire regions (that’s not possible with all of them) and set up IAM policies that restrict access to certain geographies.

Chapter 6: The combined approach to cloud security

Achieving security in all aspects of cloud computing is a multilayered quest for every organization. Single measures of organizational and technical security are important but not enough.

This chapter will discuss the overarching organizational and technical security measures you need to know about and implement within your organization.

Learn about metadata for applications, the danger of configuration drift, and how landing zones greatly improve the security and compliance of your tenants.

Metadata

Maintaining organizational metadata — or context information — for applications, such as Application IDs, cost centers or security contacts is a way to establish a connection between the organization and the actual implementation of the application and integrate cloud infrastructure to the surrounding IT landscape, including CMDBs (Configuration Management Databases), SIEMs or Accounting systems like SAP.

Let’s have a look at two examples:

• Providing a cost center when creating a new cloud tenant enables cloud foundation teams or management systems like meshcloud to map the occurring cost of an application to the corresponding department.
• SOCs scan infrastructure for vulnerabilities. If a vulnerability is detected, it is essential to know within which application the affected infrastructure is used and who is responsible for its security and therefore fixing the breach.

Declarative model vs. Workflow-centric approaches

We’ve almost reached the end. And by now it’s pretty clear that cloud security and compliance are a complex endeavor with many different technical and organizational aspects to take into account. The complexity increases, if you consider that all these aspects do not only have to be set up and implemented once but for a heterogeneous application landscape throughout the application lifecycle. Looking at a longer-term perspective this leads to a risk for a phenomenon called configuration drift.

What is configuration drift?

Configuration drift describes a deviation of configurations from their initial setup due to frequent changes in hardware and software.
Within a complex cloud landscape, you’ll have to think about how to treat configuration drift, from detecting it, to managing and correcting it.

Declarative model vs. Workflow-centric approach

A common way to speed up slow manual processes is to automate the workflow. So for example, instead of having an Azure Admin manually create and configure a subscription for a DevOps team, there will be a script automating the workflow to reduce the time needed.

But what happens if the DevOps team lead goes ahead and changes the configuration to better suit the application’s needs? Right, configuration drift and no one will be aware of it.

A superior approach is to define the desired state. To stick with the Azure example, this could be an Azure subscription with access permissions for a DevOps team lead and one of his team members. This desired state definition can be continuously compared to the actual state. If no subscription or permissions exist yet, they will be initially set up. If the DevOps team lead changes the configuration, this will be detected. If it is intended the desired state can be updated, if not the action can be undone to get back to the desired configuration.

How vs. What

Workflow-centric approaches focus on “how” to achieve the desired outcome, while declarative approaches provide a clear definition of “what” is to be achieved. A declarative approach has the benefit that it enables a continuous validation of the actual state against the defined desired state (re-certification) and provides a single source of truth to avoid configuration drift.

Cloud Landing Zones

Configuring a new tenant to be secure and compliant can be quite a hassle — especially if you have to do a basic set of tasks over and over again. This is where landing zones come in. Landing zones allow to quickly set up a multi-tenant environment with a baseline of identity and access management, data security, governance, and logging already in place.

The basic purpose of a landing zone is to build and secure the airport before an application lands in the cloud.

But landing zones are not “fire and forget”: A proper landing zone lifecycle management is an important part to keep your environments secure and compliant.

The big cloud service providers have the concept of landing zones implemented in some way.

Cloud Exit Strategy

Moving your workloads to the cloud brings many advantages — like on-demand infrastructure and elastically scalable services. While most cloud users love the feel of innovation and progress to it, many don’t think too much about how to get out again — why would they? But having a solid exit strategy in place is essential! In some industries, like banking, it is a regulatory requirement, as stated in the EBA Guidelines on outsourcing arrangements. The goal of an exit strategy is to ensure business continuity under changing circumstances. What if the service provider terminates the contract? What if the services do not meet the defined quality standards? Being able to handle these scenarios without interrupting critical business functionality is part of a comprehensive cloud transformation strategy.

So here are 4 aspects you will have to have an eye on when building your cloud exit strategy:

• Most importantly: Take inventory! Knowing your assets is essential. Exit strategies often apply to critical business functions only. So it’s important to know what you have running in which cloud — an up-to-date cloud inventory is of great help.
• Open-source infrastructure is key. Open-source infrastructure components like Kubernetes clusters or open-source databases can make a move between clouds much easier. The more proprietary services you use, the harder it will be to adapt your application to run in a new cloud environment.
• Go multi-cloud from the beginning. Contract negotiations between enterprises and cloud providers can take a while. It’s too late to start the process when it’s actually time to move
• Watch out for organizational lock-in. Even if from a technical perspective your application can easily be moved to a different cloud provider, there’s more to it. If you are running cloud applications at scale, setting up the corresponding cloud environments transferring permissions and configurations comes with massive complexity. Use a centralized governance system like meshcloud to keep your organizational structures independent from specific providers.