The term "cloud" gives the impression that it is an abstract entity with its own set of rules. In fact, a "cloud" is ultimately just someone else's computer/server. Accordingly, the possible attack vectors do not differ strikingly from on-prem environments. The division of responsibilities between provider and user in relation to IT security are an aspect that must be given special attention in cloud pentesting. In this article, we therefore explain how the circumstances of cloud settings affect the responsibilities and framework conditions of a cloud security assessment.
Since the introduction of the first cloud-based systems in 2006, the range of dedicated providers of these services has continued to grow. These range from the complete transfer of one's own infrastructure to the cloud (where the responsibilities remain within one's own company) to the complete, native integration of services (where one "no longer has to worry about anything" other than the underlying system maintenance regards).
The cloud has simplified many things for daily operations, but at the same time increased the complexity. This also applies to the area of pentesting, because the cloud does not exist “off the peg”. The areas of application are always just as individual as the company itself and place enormous demands and tight framework conditions on a cloud security assessment.
For a cloud security assessment, it makes a difference whether the cloud infrastructure in question on own servers is hosted or whether it is about Public cloud environments concerns.
Because in public cloud environments like Microsoft Azure, Amazon Web Services or the Google Cloud the test options within a penetration test are limited. Only what is within the scope of the cloud provider may be tested here. Another factor that influences the approach of a cloud pentest is the area of application of the cloud. We'll go into that in the following section.
When scoping, there are a few things to consider in the area of cloud security assessment: While with infrastructure as a service (IaaS) everything can be included in the pentest except for physical servers and network infrastructure, the test scope with software as a service (SaaS) is limited on how the users deal with the software. In the following, we explain why a security assessment generally makes sense for all three variants.
Infrastructure as a Service, or "IaaS" for short, is commonly understood to mean the transfer and migration of one's own IT infrastructure to the cloud. This can be either full or hybrid. For this is the connection of your own Active Directory domain to a cloud-based component such as Azure AD Connect a case in point.
The main responsibility for operation, patch management of the virtualized infrastructure (with the exception of the hypervisor) and hosted content remains within the company. Only the Responsibility for the availability of the services and the underlying hardware is transferred to the cloud service provider.
What does this mean for scoping a pentest? In the case of an IaaS, this is where the smallest differences to the "classic" pentest arise. Typically from the scope tests of the physical server and network infrastructure are excluded. Otherwise it could not be ensured that other participants on the same platform or in the same cluster are not affected by the test.
With Platform as a Service (PaaS), only part of the infrastructure is moved to the cloud. Usually this is about Services that you want to make available to external users, but for which dedicated resources would be over-proportioned or have potential security risks. This includes, for example Web presences such as blogs, company websites or online shops.
In the area of cloud security assessment, you are already approaching difficult terrain here because of the scope of the pen test limited to the application itself is. All underlying infrastructure (including the container on which the application runs) is already the responsibility of the cloud provider.
Software as a Service (SaaS) includes all services that are already provided by the manufacturer as a finished application. Which includes Microsoft Teams, Slack, Google Cloud Storage.
The decisive factor for a pentest here is that even the application itself is no longer the responsibility of the company. It is therefore not in the scope of a security assessment. Nevertheless, there are also aspects in this case that can be usefully integrated into a penetration test. Which includes obtaining access or extending privileges within the application as well the capture of sensitive information.
Especially in cloud environments and resources, the overview of user rights can quickly get lost. A cloud security assessment shows which permissions can be exploited in the worst case to increase privileges as a normal user (Privilege Escalation). So attackers could Access resources that a normal user should not have access to.
Regardless of the extent to which cloud services are used: the users and their devices are on site and are sensibly passed through Social Engineering and Physical Access Scenarios included in a cloud security assessment.
Because if a phishing attack is successful, the attacker may already be in the cloud environment. There he can obtain sensitive information or exploit misconfigurations to cause further damage.
In addition, external assets can often only be reached via the company's public IP addresses. That makes them corporate building definitely a worthwhile goal, even if your servers are no longer operated on premise.
