Fundamental Cloud Security Part 20 – Security testing of cloud environments

As part of managing the risk of working with public clouds, we need to conduct on-going tests in-order to measure the security controls we have embedded in our IaaS (Infrastructure as a Service) environments or the security controls configured to protect our PaaS (Platform as a Service) or SaaS (Software as a Service) environments.

The tests should begin before deploying our first cloud environment and continue for as long as the environment or the service we consume provides us with services.

It is highly recommended to conduct security testing on a regular basis (for example every 12-24 months) to make sure our environments and the managed services we consume are as secure as possible.

The relevant tests will depend on the specific solution and the cloud deployment models, according to the shared responsibility model.

In the IaaS model, we control the operating system, which means we can install penetration testing tools (such as Kali Linux on AWS or Kali Linux on Azure), however with PaaS or SaaS environments we are limited in the type and depth of tests we can conduct.

Before performing any security test on a cloud environment, we must understand that we are consuming services from a cloud provider, and we must proceed according to the cloud provider’s terms of use. Before before conducting penetration testing or even vulnerability scanning, we must notify the cloud vendor (usually via email by filling out a form on the cloud vendor website).

We need to remember that we are working in a shared environment, and cloud providers must make sure that one customer, in their own tenant, cannot harm or impact another customer in the same multi-tenant environment (such as conducting distributed denial of service, brute-force against a managed service, etc.)

Examples of permitted security testing activities on an Azure platform:

Create a small number of test accounts and/or trial tenants for demonstrating and proving cross-account or cross-tenant data access
Fuzz, port scan, or run vulnerability assessment tools against your own Azure Virtual Machines
Load testing your application by generating traffic which is expected to be seen during the normal course of business
Testing security monitoring and detections (e.g. generating anomalous security logs, dropping EICAR, etc.)
Attempt to break out of a shared service container such as Azure Websites or Azure Functions

Examples of prohibited activities on an Azure platform:

Scanning or testing assets belonging to any other Microsoft Cloud customers
Gaining access to any data that is not wholly your own
Performing any kind of denial of service testing
Performing network intensive fuzzing against any asset except your Azure Virtual Machine
Performing automated testing of services that generates significant amounts of traffic
Deliberately accessing any other customer’s data
Moving beyond “proof of concept” repro steps for infrastructure execution issues

Examples of prohibited activities on an AWS platform:

DNS zone walking via Amazon Route 53 Hosted Zones
Denial of Service (DoS), Distributed Denial of Service (DDoS), Simulated DoS, Simulated DDoS
Port flooding
Protocol flooding
Request flooding (login request flooding, API request flooding

Additional references: