Blog | G5 Cyber Security

PCI DSS Penetration Testing: AWS Serverless Segmentation

G5 Cyber Security

TL;DR

This guide details how to segment your AWS serverless architecture for PCI DSS 11.3 penetration testing, focusing on isolating in-scope components from out-of-scope systems. We’ll use VPCs, security groups, IAM roles, and resource policies to create a secure environment that allows testers access only to the data and systems they need.

Understanding PCI DSS 11.3

PCI DSS requirement 11.3 mandates regular penetration testing of your network and systems. For serverless architectures, this means carefully defining what’s ‘in-scope’ for the test – typically components that store, process, or transmit cardholder data – and isolating them from other parts of your infrastructure.

Step 1: Define Your PCI DSS Scope

  1. Identify In-Scope Components: List all AWS services (Lambda functions, API Gateways, DynamoDB tables, S3 buckets, etc.) that directly handle cardholder data or are involved in its processing.
  2. Document Out-of-Scope Components: Clearly identify services and resources *not* subject to PCI DSS testing. This is crucial for testers.
  3. Create a Network Diagram: Visually map your serverless architecture, highlighting in-scope and out-of-scope components.

Step 2: VPC Segmentation

Using Virtual Private Clouds (VPCs) is the foundation of network isolation.

  1. Create a Dedicated PCI DSS VPC: Provision a separate VPC specifically for your in-scope serverless components.
  2. Subnet Configuration: Within the PCI DSS VPC, create private subnets for Lambda functions and database resources. Avoid public subnets unless absolutely necessary (and then heavily restrict access).
  3. Route Tables: Configure route tables to ensure traffic within the PCI DSS VPC stays contained and doesn’t directly connect to out-of-scope networks.

Step 3: Security Group Rules

Security groups act as virtual firewalls, controlling inbound and outbound traffic.

  1. Restrict Inbound Traffic: Allow only necessary traffic to in-scope resources (e.g., API Gateway access from specific IP addresses or other trusted services).
  2. Limit Outbound Traffic: Restrict outbound connections from in-scope resources to only essential services (e.g., logging, monitoring). Block all unnecessary external communication.
  3. Example Security Group Rule (Lambda): Allow inbound traffic from API Gateway security group on port 443. 
    # Example using AWS CLI
    aws ec2 authorize-security-group-ingress --group-id sg-xxxxxxxxxxxxxxxxx --protocol tcp --port 443 --cidr 10.0.0.0/16 #API Gateway VPC CIDR block

Step 4: IAM Role and Policy Control

IAM roles define permissions for your serverless functions.

  1. Least Privilege Principle: Grant each Lambda function only the minimum necessary permissions to access required resources. Avoid wildcard (*) permissions.
  2. Resource-Based Policies: Use resource policies on services like S3 buckets and DynamoDB tables to further restrict access based on IAM roles or specific conditions.
  3. Example IAM Policy (Lambda – DynamoDB): Allow read/write access only to a specific DynamoDB table. 
    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:PutItem" ], "Resource": "arn:aws:dynamodb:your-region:your-account-id:table/YourTableName" } ] }

Step 5: API Gateway Configuration

Control access to your APIs.

  1. Authorizers: Implement authorizers (e.g., Cognito, custom Lambda authorizers) to authenticate and authorize requests before they reach your backend functions.
  2. Throttling: Configure API Gateway throttling limits to prevent denial-of-service attacks during penetration testing.
  3. Private APIs: Consider using private APIs accessible only from within your VPC.

Step 6: Penetration Testing Access

Provide testers with controlled access.

  1. Dedicated IAM User/Role: Create a separate IAM user or role specifically for the penetration testing team.
  2. Limited Scope Policy: Attach a policy to the tester’s IAM entity granting only the permissions required for their test scope (e.g., read access to logs, execute specific Lambda functions).
  3. Temporary Credentials: Use temporary credentials with limited validity periods for enhanced security.

Step 7: Monitoring and Logging

Track activity during the test.

  1. CloudTrail: Enable CloudTrail logging to record all API calls made within your AWS account, including those by the penetration testing team.
  2. VPC Flow Logs: Capture network traffic flowing in and out of your PCI DSS VPC for analysis.
  3. Lambda Logging: Ensure Lambda functions log sufficient information for auditing purposes.

Step 8: Post-Test Review

After the test, review logs and findings.

  1. Analyze Logs: Examine CloudTrail, VPC Flow Logs, and Lambda logs to verify that testers only accessed authorized resources.
  2. Remediate Findings: Address any vulnerabilities identified during the penetration test promptly.
  3. Update Segmentation: Refine your segmentation rules based on lessons learned from the test.
Exit mobile version