Platform Security Protections

Overview

Cloud.gov implements defense-in-depth security protections against malicious traffic, including Web Application Firewall (WAF) rules, rate limiting, DDoS mitigation, and container threat detection. These platform-level protections operate transparently to defend all customer applications while maintaining legitimate traffic flow. Understanding these protections helps agencies properly configure security testing and respond to potential false positives.

Prerequisites

• Understanding of common web application attacks (OWASP Top 10)
• Space Developer role for testing application behavior
• Familiarity with AWS WAF and CloudFront concepts
• Contact information for reporting false positives: support@cloud.gov

Process / Steps

1. Understand Protection Layers

Cloud.gov implements multiple security layers:

Layer 1: Web Application Firewall (WAF)

• AWS Managed rule sets for XSS, SQLi, and known exploits
• Custom rules for Log4j, path traversal, and fuzzing tools
• Automatic blocking of malicious patterns

Layer 2: Rate Limiting

• Request throttling to prevent abuse
• CHALLENGE actions for suspicious traffic
• Token-based verification for legitimate users

Layer 3: DDoS Protection

• AWS Shield Standard on all endpoints
• CloudFront with Shield Advanced for enhanced protection
• Automatic traffic scrubbing and filtering

Layer 4: Container Threat Detection

• Falco threat detection deployed on all hosts
• Managed rule sets customized for cloud.gov
• Event logging in OpenSearch

2. Configure Application for WAF Compatibility

Customer Responsibility: Ensure your application:

• Handles CHALLENGE responses appropriately
• Implements proper error handling
• Logs security events for correlation

3. Handle CHALLENGE Responses

When rate limits trigger, legitimate users see:

• Interstitial challenge page

• Automatic redirect after verification

• aws-waf-token cookie for subsequent requests

If you suspect that your traffic is being improperly affected by these protections, please contact us at support@cloud.gov.

4. Enable CloudFront CDN (Optional)

For enhanced protection:

cf create-service external-domain cloudfront-cdn my-cdn
cf bind-service your-app my-cdn

Benefits:

• Additional rate limiting
• Shield Advanced DDoS protection
• Global edge caching

5. Monitor Security Events

Track potential security impacts:

# Check application logs for blocked requests
cf logs your-app --recent | grep "403"

# Monitor application availability
cf app your-app

6. Monitor Container Threat events

Logs are available in OpenSearch under the logs-app index pattern. Events will have the @type field set to falco.

Common Errors & Fixes

False Positive WAF Blocks

• Issue: Legitimate traffic blocked by WAF rules
• Fix: Contact support@cloud.gov with request details and timestamps

CHALLENGE Token Warnings

• Issue: Security scanner flags aws-waf-token as vulnerability
• Fix: Mark as false positive - this is expected platform behavior

Rate Limit During Testing

• Issue: Penetration tests trigger rate limits
• Fix: Notify support@cloud.gov before testing (see penetration test policy)

Missing Security Headers

• Issue: CHALLENGE responses lack application headers
• Fix: Expected behavior - AWS handles CHALLENGE before reaching your app

Mitigating Falco Findings

• Issue: You believe an application instance has been tainted

• Fix: If you are concerned something in your application instance has changed causing a finding (i.e. someone installed software in an ssh session), you can use cf restart or cf restart-app-instance. This will cause the platform to destroy your existing instance(s) and create new one(s) effectively resetting the instance.

  If the finding is related to your application code, you will need to provide a fix. If you believe the finding is related to platform provided components like the buildpack or stack, please contact Cloud.gov support.

  Note: cf restart will recreate all instances of your application and may cause downtime unless you use --strategy canary or --strategy rolling. See cf restart –help for more details.

FAQs

Q: Can I disable WAF rules for my application? A: No. WAF rules protect the entire platform. Report false positives to support@cloud.gov for rule tuning.

Q: How do I test my application's security? A: Follow the penetration test notification process. Never attempt to bypass platform protections.

Q: What should I tell my security scanner vendor? A: Inform them that aws-waf-token cookies and CHALLENGE responses are legitimate platform security features, not vulnerabilities.

Q: Does Cloud.gov protection replace my application security? A: No. Platform protections complement but don't replace secure coding, input validation, and application-level controls.

Q: What types of events does Falco look for? A: Falco contains an extensive default rule set. It looks for events including but not limited to:

• Privilege escalation using privileged containers
• Namespace changes using tools like setns
• Read/Writes to well-known directories such as /etc, /usr/bin, /usr/sbin, etc For more details, see the Falco docs: https://falco.org/docs/#what-does-falco-check-for.

Q: How does the Falco team identify necessary rules? A: Falco threat detections align with the MITRE ATT&CK Framework: https://attack.mitre.org. Falco's rule alignment with the MITRE ATT&CK matrix enables detection of Tactics, Techniques, and Procedures (TTPs) employed by adversaries, aiding rapid identification and response to potential security incidents.

Q: Can I manage Falco rules? A: No. Falco rules are customized for Cloud.gov Platform and managed by the platform team.

Q: Are all Falco findings cause for concern? A: No. Falco generates audit events in containerized platforms. Some findings may be expected and some may be false positives. If you are unsure, please contact Cloud.gov support to discuss your finding.

Q: What compliance controls are satisfied with Falco? A: The DISA Container Platform Security Requirements Guide (SRG) explicitly requires the runtime to generate audit records for all program initiations, object access, and anomalies (SRG-APP-000510-CTR-001310, -001295, -001180), and to enforce approved ports/protocols (-000325). This directly maps to NIST 800-53 SI-4 (System Monitoring) and AU-3/AU-12 (Audit Generation & Analysis). Additionally, 2025 Executive Order (14144) explicitly calls for agency-wide Enterprise Detection and Response (EDR) and runtime threat identification capabilities.