In discussions with customers and interested parties, we are repeatedly confronted with the statement that security investigations (penetration tests and vulnerability scans) are not necessary in cloud scenarios because the cloud provider (e.g. Amazon Web Services, Microsoft Azure, Google Cloud, Hetzner Cloud) ensures the security of the environments. This is a widespread misconception, which we would like to explain in more detail in this article.

Let’s first take a look at what the provider of a cloud, in which application operators can develop and run their applications, actually does in terms of security. The target group of typical Infrastructure as a Service (Iaas) and Platform as a Service (PaaS) offerings are application operators (e.g. start-ups, medium-sized companies or even corporations) who can create their own applications with the help of cloud resources and operate them in the cloud. The advantage for the application operators is obvious: there is no need to invest in their own server landscapes, the cloud provider makes the necessary computing capacity available for operation.

Cloud providers only secure their own systems and services

The tasks of the cloud provider in such Iaas and PaaS offerings include securing all services provided to the cloud application operators. This means, for example, that APIs, automation mechanisms and platforms and services are provided in such a way that they do not contain any serious security vulnerabilities. If they do, the respective cloud provider will do everything in its own interest to provide a remedy and patching as quickly as possible. Only in the special case of Software as a Service (SaaS) can the user rely on the fact that the software provided by the respective SaaS provider will also be checked and corrected accordingly by the respective provider if security gaps are identified. However, SaaS offers are mostly aimed at end users and not at application operators.

Let’s leave Software as a Service (SaaS) aside for a moment and focus on IaaS and PaaS scenarios. The following results from the tasks of the cloud provider described above in such environments:

Cloud providers secure their own systems and services – but the applications of cloud application providers do not inherently inherit security from the cloud provider!
Patching is the sole responsibility of the cloud application operators; Azure, AWS and any other cloud provider will not automatically patch the infrastructure and applications residing in their clouds and used by application operators!
Any data that application operators store in the cloud is only as secure as the permissions set by the application operators. The cloud provider explicitly does not care about this either!

Play it safe with TEN IM

At TEN Information Management, we also see our mission in explaining again and again what the cloud providers do in terms of security for application operators – and what is and remains the application operators’ own responsibility. And of course we help to fulfil this responsibility – with vulnerability scans, penetration tests and our Watchdog by TEN IM, a managed SIEM (Security Incident & Event Management) solution that also and especially in IaaS scenarios provides valuable insights into the IT security situation of one’s own organisation. All true to our claim: Business Driven Security Expertise – tailored to our customers’ business.

More articles

Risk precautions are supposedly just as unwelcome as health precautions. But they are just as important! Various studies prove: Attacks on IT systems and applications are increasing significantly. The consequences are financially devastating. At the...
Conversion to the latest version of the standard Companies that are certified according to the international standard ISO 27001 will have to think about converting their ISMS to the latest version of the standard in...
A serious vulnerability exists in the popular Samba server, which provides Windows file and print services in Linux environments. Linux systems should be updated as soon as possible, because the vulnerability with the identifier CVE-2020-27840...