Extract value wherever possible

Most companies that are mature enough to hire out a pentest also have systems that perform some type of detection and response.  Part of the scoping with your pentester(s) should be to determine if they will be exercising detection and response capabilities of these tools.  This could also mean giving a position of privilege in the infrastructure by adding them to bypass or allow lists.

When attacks or techniques are not detected and stopped ensure that your test will deliver a set of “observable artifacts”.  The internal team can then use that timeline and artifact list to write new detections after the test is over.

Observable artifacts might come from the application logs themselves. But in the case that you are testing the “Security of the Cloud” or control plane these artifacts will come from cloud native logs like AWS CloudTrail, GCP StackDriver Logging, or Azure Log Analytics.  Take advantage of features that exist in products like AWS Organizations.  Using Organizations enables you to enforce logging for 100% of API Calls at a global level, across 100% of your managed accounts.  Writing logs once and reading many for forensics has become the gold-standard for these types of logs.  If possible, sequester those API Call logs in an account that is separate from your cloud platform’s primary billing heirarchy.

Patch where practical and possible

A penetration test leverages vulnerabilities.  The purpose should not be to spend time aggregating lists of unpatched systems.  If you do not have a regular release, patch process, or patch procedure, now is a good time to develop one and practice it prior to the start of a red team exercise.  If you are using a platform like Amazon EC2, patching might take place by regularly rolling out new AMIs or patching using the Systems Manager Agent.  If you use containers or serverless services, user patching will consist of  regular rebuilds of lambda layers, dependencies, and containers (as appropriate).  Ensure that this becomes a part of your regular operations pipeline, otherwise one-time patch management could skew your results towards false positives.

Identity and access management

One of the most nuanced and overlooked services in cloud infrastructure is Identity and Access Management:

  • How do users access your cloud platform?
  • How do applications authenticate in the cloud platform?
  • How do you manage access across account boundaries and across clouds?

As an industry we know that cloud control plane access is most secure when users are authenticating using single sign-on.   Additionally, that authentication should take place with more than a single factor.  Machine-to-machine authentication should use strong cryptographic controls as proof of identity.  Despite their efficacy, these steps are often overlooked or under-resourced due to the fact they are not required in most compliance standards.

Taking basic steps to implement a single sign-on pattern pays huge dividends.  Most cloud data breaches start with a misconfiguration, access key leak, or phishing campaign.  Moving to a model that enforces a single way that developers and machines assert strong identity, benefits detection and defensive posture.


Parting advice

As you move forward towards pentests of the cloud becoming more normative this will get easier.  Don’t worry if this feels daunting at first.  You will get better with time!  Whether this is your first or fiftieth time performing a pentest now is a great time to level set with your team, schedule a security or tech debt paydown sprint, patch where possible, and evaluate your IAM perimeter to make your pentest as productive and fruitful as possible.

Andrew Krug @andrewkrug will speak on Pentest Preparation next week at the Wild West Hackin’ Fest Cloud Roundup December 10, 2020 2:00PM EST.  Bring your questions and your cowboy hats to this live presentation.  https://wildwesthackinfest.com/the-roundup/cloud-pentesting/