SIMULATION The developers recently deployed new code to three web servers. A daily automated external device scan report shows server vulnerabilities that are failing items according to PCI DSS. If…

Question

Exhibits

Explanation

PCI DSS Web Server Vulnerability Remediation - Exam Explanation

Overall Goal

This simulation tests your ability to triage and remediate web server vulnerabilities found by an external PCI DSS compliance scan. PCI DSS (Payment Card Industry Data Security Standard) requires that cardholder data environments protect data in transit and use trusted certificates. The two-step workflow - validate first, then remediate - mirrors real analyst work: you must confirm a finding is real (not a scanner false positive) before acting on it.

Step-by-Step Reasoning

Steps 1-2: Review the Network Diagram and Scan Report

You cannot remediate what you don't understand. The network diagram tells you the server IPs, their role, and their network segment. The scan report tells you the specific CVE or vulnerability class flagged. Without this context, you'd be guessing at remediation actions.

What goes wrong if skipped: You might apply the wrong fix (e.g., rotating a certificate when the real problem is unencrypted HTTP traffic), wasting time and leaving the vulnerability open.

Steps 3-4: Web_Server01 (172.30.0.15) - Cleartext Transmission of Sensitive Information

Vulnerability: The server transmits sensitive data (likely HTTP instead of HTTPS, or HTTPS only partially applied).

Validation: True Positive. The scanner detected actual unencrypted traffic carrying sensitive data. Nothing in the network diagram suggests this is a false positive (e.g., it's not an internal-only test server exempt from PCI scope).

Remediation: Encrypt Entire Session. A partial fix (encrypting only the login page, for example) would still fail PCI DSS. The entire session - every request and response - must use TLS. This typically means enforcing HTTPS site-wide, implementing HSTS (HTTP Strict Transport Security), and redirecting all HTTP traffic to HTTPS.

What goes wrong if you only encrypt part of the session: Session tokens can still be intercepted over the unencrypted portions, defeating the purpose entirely. PCI DSS Requirement 4.2.1 is explicit: all PAN (Primary Account Number) and sensitive authentication data transmitted over open/public networks must be encrypted.

Steps 5-6: Web_Server02 (172.30.0.152) - Sensitive Cookie Without Secure Attribute

Vulnerability: Session cookies are being set without the Secure flag. Even though the page uses HTTPS, the browser will also send these cookies over plain HTTP if a request is ever made that way - exposing session tokens.

Validation: True Positive. This is a real misconfiguration in the application code or server config. The Secure attribute is simply missing from the Set-Cookie header.

Remediation: Encrypt All Session Cookies (i.e., add the Secure attribute to all sensitive cookies). This is a code-level or server-config fix that ensures cookies are only transmitted over HTTPS connections.

Important discrepancy: The "Answer" block in your question says "Submit as a non-issue," but this contradicts the True Positive validation result and PCI DSS requirements. "Submit as a non-issue" is the correct action only for a False Positive - when the scanner flags something that isn't actually a risk in your specific environment. Since this is confirmed True Positive, "Encrypt All Session Cookies" (from the Procedure) is the correct remediation. The Procedure section is the authoritative answer here.

What goes wrong if skipped: An attacker performing a mixed-content or HTTP downgrade attack can steal the session cookie, leading to session hijacking even on an otherwise HTTPS-only site.

Steps 7-8: Web_Server03 (172.30.0.153) - Untrusted SSL/TLS Certificate

Vulnerability: The server uses a self-signed or privately-issued certificate that public clients cannot validate against a trusted root CA.

Validation: True Positive. External scanners (simulating a customer's browser or PCI scanning tool) cannot verify the certificate chain. This is a genuine compliance failure, not a false positive.

Remediation: Request Certificate from a Public CA. PCI DSS requires that certificates used on systems handling cardholder data be issued by a trusted, publicly-recognized Certificate Authority (e.g., DigiCert, Let's Encrypt). A self-signed cert provides encryption but zero authentication - a client cannot distinguish it from a man-in-the-middle attack.

What goes wrong if you use a private CA instead: Internal machines that trust your private CA would pass, but external scanners and customer browsers would still flag it. The PCI scan would remain non-compliant.

Memory Tips

Use this mapping:

A useful mnemonic: "Session, Cookie, Certificate" - the three layers of HTTPS trust, each with its own failure mode and fix.

Key Takeaway

All three are True Positives - the scanner is correct in all cases. The remediation actions address three distinct layers: transport-layer encryption, cookie security flags, and certificate chain trust. PCI DSS compliance requires all three to be correct simultaneously.

No community discussion yet for this question.