Response
Introduction and Root Cause Analysis
This document serves as the formal response to the non-conformity raised regarding the verification of Software Requirement SRS-CCD by Test Run T228. Upon review, we identified that the initial test case documentation (C366) did not sufficiently detail the verification steps for Parts 4 (Alerting and Audit Logging) and 5 (Fail-Secure Behavior) of the requirement. Furthermore, the expected HTTP status code for blocked requests was incorrectly documented as HTTP 429, whereas the default and implemented behavior of the AWS Web Application Firewall (WAF) is to return an HTTP 403 Forbidden.
To resolve this, Test Case C366 has been formally updated to reflect the correct expected behaviors and explicit verification steps for Parts 4 and 5. The test was subsequently re-executed (Test Run T228), and the comprehensive evidence is enclosed in the attached ZIP file.
Artifact
Download evidence package for Test Run T228 (updated test case C366): Download T228 Evidence
Resolution of Findings
Finding 1: Actual results demonstrating expected HTTP return codes.
- Resolution: An automated test script was executed to simulate an anomalous high-frequency request burst against the API environment. The execution logs demonstrate that baseline requests within normal limits successfully returned an HTTP 200 OK status. Once the rate limit threshold was exceeded, the intrusion prevention system successfully intercepted the anomalous traffic, immediately returning an HTTP 403 Forbidden status.
- Evidence: EV_001.txt (Test Script Output), EV_003.jpg (WAF Summary Dashboard), EV_004.jpg (WAF Metrics Graph).
Finding 2: Verification of SRS-CCD Part 4 (Alerting and Audit Logging).
- Resolution: The system is configured to securely log all intrusion-related events and alert administrators of high-severity anomalies. The audit log generated during the test execution accurately recorded the anomaly event, including the exact timestamp, source IP, event classification (AWS-RateBasedRule-IP-300-CreatedByCloudFront), and the enforcement action (BLOCK). Additionally, an automated CloudWatch alarm successfully triggered a notification to the administrator upon detection of the blocked requests.
- Evidence: EV_002.json (Raw JSON Audit Log), EV_005.jpg (Administrator Alert Notification).
Finding 3: Verification of SRS-CCD Part 5 (Fail-Secure Behavior).
- Resolution: The fail-secure behavior is inherently satisfied by our cloud architecture design. The Web Application Firewall is deployed as an inline security boundary directly attached to our edge distribution network (AWS CloudFront). Because the edge network strictly enforces the WebACL prior to routing any traffic to the internal origin, a failure in client-side interaction or anomaly detection cannot bypass the security controls. The architecture natively fails closed, ensuring internal components remain protected. This architectural verification has been explicitly added to the preconditions and expected results of Test Case C366.
Enclosed Evidence Directory
Please find the following artifacts in the attached evidence package supporting the successful execution of T228:
- EV_001.txt: Terminal output log demonstrating the execution of the rate-limit test script, confirming the transition from HTTP 200 to HTTP 403 responses.
- EV_002.json: The specific CloudWatch audit log entry capturing the blocked request data.
- EV_003.jpg: AWS WAF traffic summary confirming the intercepted and blocked anomalous traffic
- EV_004.jpg: AWS WAF metric graph visualizing the specific intrusion detection events.
- EV_005.jpg: Email receipt demonstrating the successful delivery of the high-severity administrator alert.