Cloud Security Assessment: Pen Testing vs Breach-and-Attack Simulation

bySafeBreach

Thought Leadership

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.

Pen-Testing In the Data Center World

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.

Pen-Testing in the Cloud Security World

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:

  • Applications: All applications and workloads an enterprise is running in the cloud. This must include first-party and third-party (Saa) managed applications.
  • PaaS Platforms and Serverless: Newer ways of handling workloads can also present security risks and must be treated as
  • Databases and storage: All cloud storage platforms, including traditional transactional databases as well as the many flavors of newer data structures including MapReduce and NoSQL storage.
  • Networking and Application Delivery: Includes load balancers, application delivery controllers, reverse proxies, and more. All networking and application appliances, either inside or outside of larger orchestration technologies. In the cloud, it is very common for each application to have its own cluster of load balancers.
  • API Gateways: Often considered another form of networking control, API gateways are specifically designed to manage API traffic and are increasingly becoming a critical security checkpoint and policy enforcement mechanism for cloud deployments
  • Containers / Virtual Machines: The cloud equivalent of servers, containers are quickly overtaking VMs as the form factor of choice, driven in part by the rise of Docker and other standards container systems as well as container orchestration. Containers may also contain networking components included.
  • Virtualization Substrate / Hypervisors: This layer is maintained by the cloud computing providers and can be hard to test without upsetting the cloud security teams at these providers.

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.

Why BAS Improves on Pen-Testing for Cloud Security

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.

  • Continuous: BAS is designed to test against cloud applications in a sandboxed environment and to probe on a continuous basis. This continual testing addresses security drift by constantly validating the configuration of all security controls and enforcement of security policies.
  • Safe: Running in a sandboxed environment, BAS poses no risk to running applications and does not negatively impact the performance of public clouds or that of other customers on a cloud who are not involved in the pen-testing. This safe approach allows BAS to cover a broader cloud attack surface.
  • Comprehensive and Programmatic: More advanced BAS solutions can draw from compounded collections of nearly all known cyberattacks from multiple databases and the MITRE Framework. This enables cloud security teams to keep up with the rapid growth in reported vulnerabilities and resulting massive security debt imposed on CISOs and their teams.
  • Simulates Sophisticated Attacks: Legacy automated pen-testing solutions can scan for one or two layers of vulnerabilities. Modern BAS can generate more sophisticated attacks that can horizontally traverse a cloud infrastructure or otherwise test out multi-step attack playbooks, just like real attackers.

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.

Headquarters

  • 111 W Evelyn Ave
  • Sunnyvale, CA94086
  • USA
  • 408-743-5279

R&D Center

  • Yosef Karo St 18
  • Tel Aviv-Yafo,
  • Israel
  • +972-77-434-4506
© SafeBreach Inc. 2022
|