Cloud-Focused Red Teaming
Cloud-Focused Red Teaming

In my Red-Teaming Engagement article, I’ve mentioned about its methodology and difference between Red Team and Penetration Testing. In this article, I’ll be focusing only on the Cloud side of Red Teaming Engagement.

Photo by İsmail Enes Ayhan on Unsplash

Shared Responsibilities for Overall Cloud Security

The below chart shows a high-level view of Shared Responsibilities between Cloud Provider and Customer for the overall cloud security. As sometimes it gets trickier to understand what you can or cannot perform during a pentest or red teaming exercise.

Cloud Companie’s Red Teaming

A cloud provider company covers the following areas for their own red teaming exercise. These are:

On their Tenants, Applications and Data.

On their infrastructure and platforms.

Software as a System (SaaS).

Cloud Providers never targets the user-operated services during their Red Teaming Engagement.

Cloud Client’s Red Teaming

Before engaging into any pentest/red team activities, you must complete the required security assessment form of that particular cloud companies. i.e. AWS, MS Azure.

Customer can only perform Red Teaming Exercise against their own Tenant, applications and Data hosted in MS Azure or O365.

In AWS Services like some areas of Elastic Cloud Computing (EC2) Instance (IaaS), lambda, RDS, Cloudfront and the API Gateway configuration are permitted to pentest.

Anything IN SCOPE for your client is permitted.

Configuration and identity of those SaaS services can be tested.

Exclusions
['K O M A L']
['Security', 'Cloud Computing', 'Pentesting', 'Red Team', 'Vulnerability']