Relaxed on the road in the data cloud: security tests for cloud infrastructures

Using cloud services often starts with a misunderstanding: “I don't have to worry about anything, systems are managed, and capacity is unlimited.” The idea of managed services is widespread, where all underlying layers (hardware, operating system, software, applications, virtual machines, etc.) are abstracted and invisible. This idea is equally tempting for home users and IT administrators. The difference is how many layers there are: The user enjoys a fully managed application, such as Microsoft Office, while the administrator enjoys a limitless scalable infrastructure.

The SySS cloud team often encounters this idea when preparing tests and can explain its background: As a last consequence, there is no cloud, but only “other people's computers”.

THE UNDERSTANDING OF CLOUD

What is defined as cloud depends on how high or low the user is located in the stack, i.e. the network of components used. A possible example of a stack would be LAMP, the federation of Linux, Apache, MySQL, PHP.

Whether a technology is classified as cloud also depends on the point of view. For an OpenStack user, OpenStack is cloud, for an administrator it is a very complex application. However, a clear distinction is necessary for technical categorization — for the sole reason to enable a professionally differentiated specialization. SySS draws this line, on the one hand, by means of products. “Product” also explicitly refers to the big cloud platforms, i.e. Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP) — not least because these providers have significantly coined the term “cloud”. In addition, testing hybrid infrastructures as well as containers and container orchestration, but also services such as OpenStack and Kubernetes are part of the cloud team’s work at SySS.

THE TEST PERSPECTIVE

Based on this understanding of cloud, certain test methods emerge. In general, an open test approach (white box approach) for cloud products has proven to be more useful than a grey box approach that one would choose, for example, for a web application. In case of an web application, the complexity lies in the web application itself. The systems behind it, such as databases, are well understood and offer relatively small attack surfaces which is reflected in the OWASP Top 10, for example. Almost all of the weaknesses listed here stem from the complexity or development errors of the application itself. An audit from a user's perspective sharpens the test perspective because the directly exposed weaknesses are automatically the focus.

With a technology platform such as Azure, test coverage is significantly less productive in this way. This is primarily due to the fact that the complexity here is spread across the entire platform. Among the OWASP Cloud Top 10 risks, many topics that are partially or completely in the organizational area, such as compliance issues, can be found.

The fact that the grey box approach for a cloud test is less productive than for a classic penetration test also attributes to numerous functions not existing at all in the pre-cloud technology age and them being very difficult to test manually.

This can be illustrated using the Microsoft Azure AD conditional access feature as an example. Conditional access allows user access restrictions and conditions depending on group memberships, locations, and devices. Exceptions and conditions can be defined for this purpose. For example, a possible configuration would be that administrators could only log in with a second factor unless they were within their own company's IP range.

Such rules are difficult to test because the different test perspectives are very laborious to produce. It is conceivable, for example, that access would only be allowed from a specific country. It is relatively easy to bypass such a restriction using VPN while experimental testing is very time-consuming, because a corresponding VPN connection would have to be maintained for each possible country. It is also almost impossible to check combinations of prerequisites, such as clarifying whether iOS access from Portugal may be allowed.

The insight into the defined rules provides this information much faster and more complete. This type of testing means both a saving of time as well as better test coverage compared to manual testing. The homogeneity of the platform brings some benefits for both the tester and the customer, as both test time and money can be saved.

THE COMPONENTS CONSIDERED

Differences between cloud and 'classic' penetration tests also exist in the test item. In the penetration test of a web application, back-end components are usually not considered at all, only indirectly or partially. Elements that are not directly part of the application are left unconsidered whether they are technical aspects or process topics.

The situation is different with an AWS infrastructure. In the minimum case, such an infrastructure consists of an account (usually more). An account, in turn, integrates various resources such as instances, databases, identity pools, serverless functions and other services. Each of these components are completely visible, usually even in formats that can also be read by machines.

Another good example to illustrate the differences between classic penetration testing and cloud testing is firewall rules. For web applications, the firewall configuration is usually not exposed on the internet, i.e. accessing firewall rules is an additional organizational effort for the tester. In the case of AWS, the SySS consultant can easily read these rules and even process them automatically due to the fact that they are even readable by machines. All access, of course, fits into the test process. Since access to AWS accounts acts as single sign-on, so to speak, there is no need to provide additional access for every function. Thus, expanding the scope of the test is possible in an easy and spontaneous way. And the time saved can then be sensibly invested in analyzing organizational topics.

At the same time, the risk posed by an audit is very low. Both AWS and Azure have read-only permissions where potential damage to the systems, which can never be completely ruled out otherwise, is impossible. For the tester, this reduces the burden of constantly worrying about the potential fallout of an error and allows testing on productive systems without compromising their availability.

THE ARCHITECTURE

Many new possibilities of cloud technology also lie in the area of architecture. Relatively young concepts such as serverless ones and containers make it possible to build completely new types of infrastructures and to make them secure. At the same time, the variety of options also opens up new security gaps that can be overlooked. According to the experience of the SySS cloud team, the most important new element here is Kubernetes.

Kubernetes is a container orchestration solution and brings container technology, i.e. Docker and the like, into an infrastructure-ready form. Besides it manages the additional administrative effort that the microservice philosophy creates. At the same time, the higher technical complexity also favors potential weaknesses.

In a test, this means that not only technical but also organizational topics are increasingly in the focus. This, in turn, results in the need for closer cooperation between the SySS consultant and the client. Process and architecture topics in particular are best clarified in direct discussions.

For example, with Kubernetes, it would be typical to ask about image security. The following is to be determined:

Can every user provision any image?

If yes:

• What security implications does this assignment of rights have?

If not:

• Who is responsible?
• Who has the technical know-how?
• How do actual and target states relate to each other?

OUR CONCLUSION

Anyone who commissions SySS to perform a cloud security test can expect a very open test procedure. Numerous detailed questions about the overall structure of all components are discussed in a cloud test, both technical and organizational aspects will be considered. The findings of a cloud test then address more organizational topics and the overall safety level of the test item mostly (though not always!) is relatively high at the time of testing.

Are you already using cloud services or are you planning to do so in the future? As a reliable partner, SySS can help you meet the highest security standards when working in and with the cloud. Whether as a test for the last acceptance before the go-live or for a security check of an existing structure: Our team of experts for cloud security will be happy to support you!

Feel free to contact us at:

anfrage (at) syss.de

+49 (0) 7071 - 40 78 56-50

Our team is looking forward to hearing from you!