Balance innovation and agility with security and compliance
risks using a 3-step process across all cloud infrastructure.
Step up business agility without compromising
security or compliance
Everything you need to become a Kubernetes expert.
Always for free!
Everything you need to know about Magalix
culture and much more
“The root cause of many security incidents is an assumption that the cloud provider is handling something when it turns out nobody was handling it”
The Internet has become an essential part of our lives and more than 4.66 billion people use it regularly. The growth of the internet has created a monumental shift in business and software delivery models. Companies historically focused on creating and selling individual software packages. These packages were stored locally and didn't necessarily communicate with the Internet. This delivery model was called on-premise software.
The technology industry has now shifted towards on-demand software, where software is licensed for a recurring fee and is centrally hosted on cloud servers. Cloud computing is big business, with Amazon, Microsoft and Google’s cloud divisions all making up sizable portions of their annual revenue. Just about any business today will use cloud computing in some way: communicating with clients, hosting websites and apps, storing sensitive data, etc...
As this industry matures and more sensitive data and applications move to the cloud, security becomes an ever-growing priority. Cloud servers become the main target for hackers, breaches and leaks. Cloud companies need to find ways to provide safe access to their servers, transmit encrypted data over public networks and provide users with tools to protect their accounts. Consumers need to learn how to configure access protocols, install proper authentication and patch software vulnerabilities which may leave their data exposed.
Which raises the question: who is responsible for cloud security? As we'll see, it's both impractical and unsafe to have one party take all responsibility. This is where we introduce the Shared Cloud Security Model. This model shares responsibility between the provider and consumer in different layers.
This model ultimately dictates who shares responsibility for breaches and leaks. Awareness of this model will help to protect your business interests, improve your security to limit the risk of being hacked and allow you to evaluate the services your cloud provider is offering.
To understand the Shared Cloud Security Model, let's take a quick look at the different types of cloud services and why security is important for each one.
1. Infrastructure as a Service (IaaS): Cloud-based infrastructure like network, storage, computing and operating systems.
2. Platform as a Service (PaaS): Cloud-based platforms which help developers to build, deploy and manage applications.
3. Software as a Service (SaaS): Cloud-based software applications usually employed by end users in web browsers or through APIs.
Security matters on each level of the stack mainly to protect the data uploaded by end users, either from falling into the hands of malicious parties or losing data through mismanagement.
As you will see from the following diagram, whoever has more control over a stack of the software architecture will be more responsible for its security. Protecting low-level cloud computing services is the provider’s responsibility. In contrast, high-level cloud services are designed so consumers need to configure as little security measures as possible.
Let’s take a closer look at each player’s responsibilities:
Across IaaS, PaaS, and SaaS, the cloud provider has complete responsibility for physical and virtualized infrastructure security (the bottom of the diagram). This includes physical protection of data servers (cameras, fences, authorization access, encrypted internet access and more), but also on-chip security for server hard drives, building virtual machines and containerizing the software environment.
As a rule of thumb, if the customer has the ability to break something, they usually are responsible for securing it. In the IaaS model, it falls unto the customer to secure the operating system.
While the cloud provider is responsible for creating security tools and features, it’s the consumer who must properly install them. Consumers must install strong passwords, enable two-step verification, train employees, use email confirmation or use security access chips and any other measures which are available to protect their applications and databases.
In almost all cases, data access security is the customer's responsibility. The provider gives you the necessary tools and platform to configure data access (such as storage permission, middleware permission, and SaaS permission) and no one can fault the cloud provider for a customer mishap or misconfiguration.
Shared responsibility only happens with IaaS Network Security and PaaS Middleware Security. For example, the cloud provider may enable encryption tools to safely send data across the internet, while the consumer must install a firewall to protect network integrity. Likewise, cloud providers can patch vulnerabilities in middleware applications while consumers must take responsibility and install the patch updates as soon as possible.
There are multiple layers of networking with different parties owning their responsibility. For example, the cloud provider is responsible for its own network but the virtual network on top is the customer’s responsibility to carve into reasonable security zones. Furthermore, the customer is responsible for things such as overlay networks, firewalls, and transport encryption.
Let’s look at some famous cloud breaches stemming from the misunderstanding of the shared cloud security model and the underlying cause behind them.
Cloud data breaches are more frequently appearing among news headlines. According to one report from Risk Based Security, 36 billion data records had been exposed through breaches between January and September 2020. While breaching victims and the media tend to blame cloud providers, it is often the consumer’s lack of security implementation that caused the problem. In fact, Gartner estimates that by 2025, 99% of cloud data breaches will be the customer’s fault.
Capital One was the target of a recent cyber hack that exposed sensitive information of over 100 million Americans and 6 million Canadians who applied for credit cards. This breach was caused by Capital One’s failure to install security measures for Amazon S3 buckets.
Amazon S3 is an object storage service for storing and protecting data for cases including websites, mobile applications, backup and restore, archiving, big data analytics and more []. This service offers scalability, which makes it a popular choice for large companies and a target for hackers. Amazon S3 data breaches have already led to billions of exposed records.
The problem with Amazon S3 is that data is stored in buckets with permission settings. Access to buckets is private by default, but system administrators often change them to public without proper encryption or authentication. In this case, Capital One failed to take responsibility for configuring buckets with access settings and the data became exposed.
In this breach, Microsoft left an internal customer support database with anonymized user analytics exposed online without proper protections. Microsoft claimed they accidentally exposed the server because of misconfigured Azure security rules. In this case, Microsoft is both the consumer and provider as they create and own Azure Cloud Computing but failed to properly implement security configurations.
Note that this issue was related to an internal database rather than an exposure of commercial cloud services. This data was collected for Microsoft to perform analysis on their user base. While this particular data was anonymized, it still contained some sensitive information like unformatted email addresses.
The vulnerability was discovered by security experts and Microsoft quickly admitted and fixed the problem. Microsoft reported no malicious use of the data and contacted customers whose data may have been exposed.
This breach exposed personally identifiable information (PII) from 147 million Americans online. Since Equifax is a consumer credit reporting company, it collects and stores highly sensitive information, including credit card numbers, drivers license numbers, social security numbers, birth dates and addresses. When such data is leaked on the dark web, consumers become vulnerable to identity theft and account hacking.
Equifax claims that the breach occurred from an unpatched vulnerability in a commonly used web application server (Apache), and that the specific vulnerability was repaired in March 2017, but Equifax neglected to apply the patch for the system which would ultimately be compromised in September 2017.
Equifax failed to perform important security updates for an application which was foundational in their software architecture, leading to a massive data breach. A settlement was reached with the FTC and CFPB for up to $425 million in compensation to victims of fraud and identity theft. (This doesn’t even include the negative cost for Equifax’s reputation).
As demand for cloud computing grows and data increases exponentially, so does the need to prevent data breaches and hacks. These breaches come with an enormous financial and reputational cost if the data is leaked online or sold for malicious purposes.
The first step in mitigating risk for companies is understanding who is responsible for what and taking necessary precautions. One of the main findings from a survey done by Barracuda is that the Shared Cloud Security Model is still misunderstood by both parties. It shows that the majority of respondents and decision-makers believe they fully understand this model, yet also believe that the public cloud provider is responsible for all cloud data and applications. So companies must learn to identify what their cloud responsibilities are and act accordingly.
Seamlessly build a shared security model within your team with one unified platform to help security, developers, and operations streamline their security from code to cloud.
Find out how to avoid misconfigurations in Kubernetes that may lead to security breaches or sensitive data leaks.
In this episode of the SaC, we will discuss with Daniel Feldman, Zero Trust Architecture, the SPIFFE and SPIRE project, and what the future holds for zero-trust networks.