Cloud Security Assessment: Pen Testing vs Breach-and-Attack Simulation
In the recent past, CISOs and enterprise security teams looking to validate their security posture have contracted with penetration (pen) testing teams. These teams used a combination of technology and guile to probe for weakness and attempt to break into the networks and applications of their clients. As the world of computing and applications has shifted into the cloud, pen-testing has followed along behind by running the same exercises against cloud targets.
Unfortunately, the old world of pen testing doesn’t translate very well to the new world of cloud security. Many cloud vulnerabilities are often missed because pen testers are focused on data center techniques and not cloud tactics. For example, in the data center world, data storage systems often had no connection to the outside world. In the cloud world, where many enterprises use services like Amazon Web Services S3 for storage, storage buckets are accessible via the public Internet and must be properly guarded.
Another example — in the old data center world and in the intermediate step of virtual machines, the physical server remained the primary element; teams could not add compute capacity in seconds, anywhere in the world. In contrast, in the cloud, compute is completely abstracted from physical servers at the business logic layer, allowing teams to spin up and down new servers easily, quickly, and anywhere in the world — either inside or outside of a security perimeter. These characteristics apply not only in IaaS but also often apply in PaaS and SaaS environments, where APIs are exposed to allow these systems to connect with other systems.
The broader, more diverse, and constantly morphing attack surface means that any pen-testing campaigns are only checking against a snapshot in time that will likely no longer apply within days, weeks, or months. Because it is programmatic, thorough, and continuous, Breach-and-Attack Simulation solutions are rapidly replacing pen testing in cloud security environments.
In the old model of physical servers residing in data centers, pen testers (often called Red Teams) seek to gain access to devices connected to an enterprise network by finding weak external connection points to the outside world or to other services. These connection points are supposed to all be firewalled or protected by security controls. Pen testing teams scanned all IP addresses on a network to look for weaknesses, checked for unsecured FTP servers, or performed other types of probing activities. The teams did search for vulnerabilities but they also looked for misconfigurations that might allow injections of scripts or ways to overload system memory to gain access. This may have involved automated scanning to identify opportunities for attacks such as outdated and unpatched software. Alternatively, pen-testing teams used social engineering tactics like spearphishing emails or even phone calls to trick insiders to share credentials or otherwise compromise the security perimeter.
In the cloud, pen testing is quite a bit more complicated. To start with, if anyone is pen-testing against applications and infrastructure running in a public cloud, they must seek permission from the cloud computing providers and abide by specific rules and limitations. Because cloud infrastructure is shared, public cloud companies are sensitive to anything that may look like anomalous behavior or may impact the performance of others using the shared infrastructure. This can mean that pen testing may not be able to easily address all attack surfaces or fully simulate a real attack.
A cloud pen test has to cover a lot of ground. Pen testing teams must select a number of tools for each test if they are working across multiple clouds. Each cloud, as well, has a different way of doing things, different API and control structures, and different types of networking technologies. Below is a partial list but keep in mind, for companies with a major cloud presence, this could range into the thousands of potential pen-testing targets. Area of particular attention for cloud pen testing teams include:
To be effective even for that point in time, pen-testing teams must methodically cover this entire landscape. It is highly likely they will uncover a vulnerability or a misconfiguration because of the ever-changing nature of cloud deployments but whatever is uncovered is likely to only represent a fraction of the real potential security risks. This is simply a matter of math; there are over 20,000 known vulnerabilities and attack types and pen testing tools are not able to test against this entire range of known vulns or multi-step playbooks deployed by sophisticated attackers and APTs. In addition, this constant state of change makes security configuration drift a simple reality that renders pen-testing reports obsolete very shortly after they are completed. In the world of cloud-native, ephemerality is an operating principle that makes applications and infrastructure more resilient but harder to test.
Designed for more modern ways of computing like cloud computing, BAS has several strengths that make it a more effective testing solution for validating cloud security postures.
For teams that adopt BAS to validate cloud security, the goal is to automate Red Team activity and generate frequent feedback for security teams seeking to better lock down their cloud resources. With the sheer and massive surface area of cloud computing becoming a tremendous canvas for attackers seeking to cause damage comes the need for newer, better approaches to security. Legacy human-powered pen-testing approaches augmented with one-dimensional scanning technologies simply cannot keep up with all the changes in the cloud.
Just as DevOps made infrastructure a form of code, BAS is making cloud security programmable, testable, and more reliable.
For best protection, proactively, continuously validate, and optimize the effectiveness of your cloud security controls with breach and attack simulation tools from SafeBreach.