3.2.3. Network Auditing (CloudTrail, VPC Flow Logs)

Network auditing tools (CloudTrail, VPC Flow Logs) provide comprehensive and immutable records of network activity and configurations, enabling security analysis, compliance validation, and operational troubleshooting.

Scenario: You need to monitor all changes made to your VPC Security Groups and route tables, including who made the changes. You also need to analyze IP traffic flowing through your VPC for network diagnostics and security investigations.

For network specialists, auditing network activity is crucial for security, compliance, and troubleshooting. It provides a historical record of "who did what," "what happened on the network," and "when."

Key AWS Services for Network Auditing:

• AWS CloudTrail: A service that provides a record of API calls and resource changes within an AWS account.
  • Purpose: Audits network-related API calls (e.g., CreateSecurityGroup, AssociateRouteTable, CreateVpcPeeringConnection).
  • Information Recorded: Who made the call, when, from where, and what resources were affected.
  • Benefits: Crucial for security investigations (detecting unauthorized network changes), compliance auditing, and troubleshooting unexpected network behavior.
  • Alerting on changes: CloudTrail records the API call (e.g., AuthorizeSecurityGroupIngress), an Amazon EventBridge rule matches it, and an Amazon SNS topic emails the subscribers. VPC Flow Logs record traffic, not configuration changes.
• VPC Flow Logs: Captures detailed IP traffic information for network interfaces in your Amazon VPC.
  • Purpose: Logs IP traffic flowing to and from network interfaces (e.g., EC2 instances).
  • Information Recorded: Source/destination IP address, port, protocol, packets, bytes, and action (ACCEPT or REJECT).
  • Benefits: Essential for network diagnostics (debugging connectivity issues), security analysis (identifying suspicious traffic patterns, DDoS attacks), and compliance auditing.
  • Cross-account delivery to S3: CloudTrail trails and VPC flow logs from every member account can write straight to one S3 bucket in a dedicated Log Archive account. The bucket policy authorizes each service's principal (cloudtrail.amazonaws.com for a trail; the flow-log principal is covered in 4.1.2), so no IAM role or streaming pipeline is needed.
  • Destinations: Logs can be published to Amazon CloudWatch Logs or Amazon S3 for storage and analysis.
• Which Log Answers Which Question:

• Organization-wide and Tamper-evident: An organization trail delivers every member account's events to one S3 bucket; query it with Athena for periodic audit reports (e.g., all AuthorizeSecurityGroupIngress calls). CloudTrail log file validation writes signed digest files that prove a log file was not modified or deleted, and S3 Object Lock on the bucket prevents deletion or overwrite during the retention period. PCI-style audits typically need both CloudTrail (changes) and VPC Flow Logs (traffic).

Practical Implementation: Enabling VPC Flow Logs to CloudWatch Logs

# Assuming VPC_ID and a CloudWatch Log Group ARN are defined
# 1. Create a CloudWatch Log Group for Flow Logs
LOG_GROUP_NAME="VPCFlowLogs"
aws logs create-log-group --log-group-name $LOG_GROUP_NAME

# 2. Get the ARN of the Log Group
LOG_GROUP_ARN=$(aws logs describe-log-groups --log-group-name $LOG_GROUP_NAME --query "logGroups[0].arn" --output text)

# 3. Create an IAM Role for Flow Logs to publish to CloudWatch Logs
FLOW_LOG_ROLE_ARN=$(aws iam create-role \
  --role-name FlowLogRole \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "vpc-flow-logs.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
      }
    ]
  }' \
  --query Role.Arn --output text)
echo "Flow Log Role ARN: $FLOW_LOG_ROLE_ARN"

# 4. Attach a policy to the role allowing it to write to CloudWatch Logs
aws iam put-role-policy \
  --role-name FlowLogRole \
  --policy-name FlowLogPolicy \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Action": [
          "logs:CreateLogGroup",
          "logs:CreateLogStream",
          "logs:PutLogEvents",
          "logs:DescribeLogGroups",
          "logs:DescribeLogStreams"
        ],
        "Effect": "Allow",
        "Resource": "*"
      }
    ]
  }'

# 5. Create the Flow Log for the VPC
FLOW_LOG_ID=$(aws ec2 create-flow-logs \
  --resource-ids $VPC_ID \
  --resource-type VPC \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-destination $LOG_GROUP_ARN \
  --deliver-logs-permission-arn $FLOW_LOG_ROLE_ARN \
  --query FlowLogs[0].FlowLogId --output text)
echo "Flow Log ID: $FLOW_LOG_ID"

⚠️ Common Pitfall: Not centralizing CloudTrail logs or VPC Flow Logs. In a multi-account environment, logs scattered across individual accounts make security analysis and auditing extremely difficult.

Key Trade-Offs:

• Granularity of Logs vs. Cost: More detailed logging (e.g., all traffic vs. rejected only) provides richer data for analysis but incurs higher costs for log ingestion and storage.

Reflection Question: How do network auditing tools (AWS CloudTrail for API activity and VPC Flow Logs for IP traffic) fundamentally provide comprehensive and immutable records of network activity and configurations, enabling security analysis, compliance validation, and operational troubleshooting?