False Positives and Vulnerability Scanning on Cloud.gov
Explanation: Why False Positives Occur
Automated scanners may flag findings on Cloud.gov systems that aren't exploitable in practice.
This occurs because:
- Automated tools can't evaluate compensating controls.
- Cipher naming differences (IANA vs OpenSSL) create mismatches in reports.
- Deprecated cipher modes may be partially supported for compatibility but mitigated by platform-level protections.
Cloud.gov provides this page to support system owners, ISSOs, and compliance teams when interpreting findings and documenting them in System Security Plans (SSPs).
Reference: Common False Positives
TLS Cipher Suites
Scanners may flag the following as “weak”:
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003C)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xC027)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xC028)
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003D)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009C)
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009D)
Disposition: False Positive.
- Cloud.gov relies on AWS
s2n-tls, which mitigates CBC padding oracle attacks (for example, LUCKY13). - Ciphers remain compliant with NIST SP 800-52r2, Appendix D.
- TLS 1.3 is supported via AWS policies.
NIST 800-53 Control Mappings:
- SC-8 (Transmission Confidentiality and Integrity): TLS enforces confidentiality/integrity for all transmitted data.
- SC-12 (Cryptographic Key Establishment and Management): AWS manages validated key exchange and negotiation.
- SC-13 (Cryptographic Protection): AWS FIPS-validated modules ensure cryptographic protection.
- SC-20 (Secure Name/Address Resolution): TLS protections reinforce authenticity of endpoints.
BREACH (CVE-2013-3587)
Scanners may flag HTTP compression as a BREACH vulnerability.
Disposition: False Positive if application mitigations are in place.
- BREACH mitigations include CSRF token masking, secret randomization, and length hiding.
- Disabling HTTP compression isn't required and would degrade platform performance.
- Modern web frameworks already include CSRF masking, which satisfies mitigations.
NIST 800-53 Control Mappings:
- SC-23 (Session Authenticity): CSRF tokens protect session integrity.
- SC-28 (Protection of Information at Rest): Ensures secrets are randomized or masked.
- SC-34 (Non-Modifiable Executable Programs): Application frameworks enforce protections in code execution.
- SI-10 (Information Input Validation): Randomization/masking of secrets prevents exploitable input conditions.
How-to Guide: Documenting False Positives in Your SSP
When documenting scanner findings:
- Identify the finding (cipher, BREACH, etc.).
- Reference Cloud.gov guidance (this page, SSP, or CIS/CRM mappings).
- Describe mitigation:
- TLS mitigated via AWS FIPS-validated cryptographic modules.
- BREACH mitigated via CSRF and application-level protections.
- Mark as False Positive in SSP/POA&M with citation.
Customer Responsibility
- Ensure CSRF protections are implemented in applications.
- Document compensating controls clearly in SSP narratives.
Tutorial: Example SSP Write-Ups
TLS Cipher Finding (SC-8, SC-12, SC-13, SC-20)
Finding: Scanner flagged TLSRSA_WITH_AES_128_CBC_SHA256 as weak.
_Assessment: AWSs2n-tlsmitigates CBC attacks; cipher remains NIST SP 800-52r2 compliant.
Disposition: False positive, no remediation required.
Controls: SC-8, SC-12, SC-13, SC-20.
BREACH Finding (SC-23, SC-28, SC-34, SI-10)
Finding: Scanner flagged HTTP compression as vulnerable to BREACH (CVE-2013-3587).
Assessment: Application uses CSRF masking; BREACH mitigated at application level.
Disposition: False positive. No remediation required.
Controls: SC-23, SC-28, SC-34, SI-10.