Preparing for a Cloud Pentest – SecAdvent Day 10

As the fourth quarter of 2020 draws to a close many security teams are planning their next year of initiatives. Weighing the pros and cons of how to spend the most valuable resource we have available; staff time.  In industries regulated by compliance, one of the activities you must do in order to verify that you are secure is to perform a penetration test.  In a traditional penetration test, hackers hired by your company attempt to thwart existing security controls to go after a prize.

CISOs the world over would generally agree that contracting that activity out to a third party  pays dividends.  Those dividends come in the form of time saved, speed to deliver, and often quality of work.  It can be a challenge for teams working on a piece of cloud software to consistently think of new and interesting ways to pivot through the architecture.

Why prepare?

Before you go signing those contracts and scheduling your cloud pentest for Q1 2021 you may want to take a few proactive steps in order to help focus your penetration testers’ time. The goal of a preparatory effort is to ensure that the individual performing your assessment can focus on vulnerabilities that are unique to your use case. Leverage their expert skills to the fullest without becoming mired in top 10 type findings.

Prepare your team

An often overlooked key factor in penetration testing is the psychological impact of testing the system on your team.  Even the most grizzled engineers take pride in their work and may feel uneasy about bringing in a third party to determine if the cloud platform infrastructure can be breached.  Of course, this does become easier over time.  Engagements tend to fall into two sets of scenarios that require different levels of handling:

• Full knowledge scenario: The entire team knows that the test is occurring and when to expect it.  The team actively may participate in developing the requirements and process.

• Scopeless scenario: Only key players on the team have knowledge that a pentest is occurring. Generally there are a set of assets commonly referred to as crown-jewels that the test is designed to acquire.  If your pentest is scopeless, decide well ahead of time what the criteria will be in order to ready team members as needed.  (Example: They catch the test in progress using detection.)  Nothing is more demoralizing than missing out on personal life due to a paid exercise.

If possible, have the team create a roadmap for a “Security Sprint” or “Technical Debt Paydown” to share with your testing team.  After all, you don’t need to waste cycles on finding out things you already know to be problems.

Your cloud provider is part of your team as well.  Each cloud provider has their own process for sending a notification that a pentest will take place.  This is especially important if testing the provider’s underlying APIs is in scope.  Customers that fail to notify are often taken offline while the provider determines if it is a legitimate attack.  Avoid this at all costs by communicating early and often with your friendly cloud support team.

Focus on excellent onboarding

Regardless of the type of scenario and size of the team you should onboard the folks as if they were a member of your internal team.  This should include things like how they will get access to your application and cloud, invoice, and communicate with you.  Who are the emergency contacts and “get out of jail free” contacts in your Security organization?  An additional consideration in a scopeless scenario is also leveraging contact channels outside of your corporate control for things like invoicing and billing meetings.  Using corporate owned messaging mediums may very well leak the red team’s identity to your internal security team.

Have an inventory of assets

You can not decide what to test if you don’t know what you own.  Cloud is more flexible than on premise infrastructure.  The environment changes minute to minute.  Having an event aggregator or inventory tool like AWS Config, Google Cloud Asset Inventory, and Azure Security: Inventory and Asset Control are all Cloud Native methods to gather a list.

A number of open and free inventory and asset tools exist in the AWS Ecosystem as well like CloudMapper, Prowler, Scout2, and Capital One’s Cloud Custodian if you prefer to use tooling from the open ecosystem.

These tools are only as good as the tagging system driving them.  These are the key/value combinations like, “env:production, cost_center:1440, product_line:donut”. The historical driver for tagging has been accounting but tags are advantageous for detection and response, compliance, and security as well.  Almost every major cloud now has a way to enforce a minimum level of tagging.  When they do not you can address that with a tool like Cloud Custodian.

Be sure to define out of scope assets as well—after all you don’t want to disrupt the business if you know that can be avoided by scoping out or scheduling.

The goal of a preparatory effort is to ensure that the individual performing your assessment can focus on vulnerabilities that are unique to your use case.