Compliant on Paper, Compromised in Practice" slug: case-study-target-pci-breach chapter: 40 type: case-study

Case Study 1: Target's PCI DSS Breach --- Compliant on Paper, Compromised in Practice

Background

The 2013 Target Corporation data breach is the single most instructive case study in the gap between compliance and security. Target was PCI DSS compliant at the time of the breach, having passed its most recent assessment conducted by a Qualified Security Assessor (QSA). Yet three months after receiving a clean bill of health, attackers stole 40 million credit card numbers and 70 million customer personal records. The breach cost Target over $300 million and resulted in the resignation of both the CEO and CIO.

This case study examines the breach in detail through the lens of compliance and governance, analyzing exactly how an organization can satisfy compliance requirements on paper while remaining fundamentally vulnerable.

The Attack Timeline

Phase 1: Initial Compromise (November 15, 2013)

The attack began not at Target but at Fazio Mechanical Services, a small HVAC and refrigeration contractor based in Pennsylvania. Fazio had a remote access relationship with Target for electronic billing and contract management.

Attackers compromised Fazio through a phishing email that delivered the Citadel banking trojan. The trojan captured Fazio's credentials for Target's vendor portal. This initial compromise vector was entirely outside Target's PCI DSS scope --- it occurred at a third-party vendor's office using a general-purpose malware variant.

Phase 2: Network Penetration (November 15-27, 2013)

Using Fazio's stolen credentials, the attackers logged into Target's Ariba external billing system and BMC performance monitoring portal. These systems were in Target's general corporate network, not the Cardholder Data Environment. From this foothold, the attackers began lateral movement through Target's internal network.

The lateral movement path traversed multiple network segments. The attackers exploited the fact that Target's network segmentation between the corporate environment and the POS environment was insufficient. While firewall rules existed, they were not restrictive enough to prevent the attackers from reaching systems that could deploy software to POS terminals.

Phase 3: POS System Compromise (November 27 - December 15, 2013)

The attackers deployed a custom RAM-scraping malware variant dubbed "BlackPOS" (also called "Kaptoxa") to Target's POS terminals. The malware was deployed using Target's own centralized POS management system --- a system designed to push software updates to all store terminals.

The malware captured cardholder data from the POS terminal's RAM as cards were swiped. It stored the data on compromised internal servers, then exfiltrated it in batches to external drop servers. The exfiltration used standard network protocols to blend with normal traffic.

Phase 4: Data Exfiltration (December 2-15, 2013)

Over approximately two weeks, the attackers exfiltrated approximately 11 GB of data containing: - 40 million credit and debit card numbers with expiration dates and CVVs - 70 million customer records with names, addresses, phone numbers, and email addresses

Phase 5: Detection and Response (December 12-19, 2013)

Target had deployed FireEye network security monitoring tools in its environment. These tools detected the malware activity and generated alerts. Target's security operations center in Bangalore, India, reviewed the alerts and escalated them to the Minneapolis headquarters team. However, the Minneapolis team did not act on the alerts.

The breach was ultimately discovered not by Target but by the US Secret Service, which notified Target on December 12 after investigating the appearance of large batches of stolen cards on underground markets. Target confirmed the breach on December 15 and began containment.

The Compliance Disconnect

What PCI DSS Required

At the time of the breach, Target was subject to PCI DSS version 2.0 (version 3.0 had been published but was not yet enforced). The relevant requirements included:

Requirement 1: Install and maintain a firewall configuration - Target had firewalls between network segments - The requirement was met on paper - However, the firewall rules were insufficiently restrictive, allowing the attack path from the vendor portal to the POS management system

Requirement 5: Protect all systems against malware - Target had antivirus software deployed - The requirement was met on paper - However, the BlackPOS malware was custom-made and evaded signature-based detection

Requirement 6: Develop and maintain secure systems - Target maintained patch management processes - The requirement was met on paper - However, the specific exploitation path used by the attackers did not rely on unpatched software --- it relied on credential theft and network architecture weaknesses

Requirement 10: Track and monitor all access - Target had logging and monitoring in place (including the FireEye deployment) - The requirement was met on paper - However, the alerts generated by the monitoring systems were not investigated and acted upon

Requirement 11: Regularly test security systems and processes - Target conducted regular vulnerability scans and penetration tests - The requirement was met on paper - However, the penetration testing scope did not include the vendor access path that the attackers used, and the testing did not evaluate detection/response capabilities

Why Compliance Did Not Equal Security

The Target breach illustrates several fundamental limitations of compliance frameworks:

1. Scope Minimization

Target defined its PCI DSS scope to include the POS terminals, the payment processing servers, and the network segments directly connecting them. This is a legally defensible scope definition --- these are the systems that store, process, and transmit cardholder data.

However, the attackers did not attack the CDE directly. They attacked the vendor portal (out of scope), moved through the corporate network (connected-to scope, but tested less rigorously), and used the POS management system (a borderline scope decision) to reach the CDE.

The lesson: attackers do not respect scope boundaries. They will find the path of least resistance, which often runs through systems that are technically "out of scope" for compliance purposes.

2. Point-in-Time Assessment

Target's PCI DSS assessment was conducted months before the breach. In the intervening time, the security posture could change (new systems deployed, configurations modified, new vendor access provisioned). The assessment captured a snapshot of security, not a continuous state.

The lesson: compliance assessments are inherently backward-looking. They confirm that controls existed at the time of the audit, not that they exist at the time of the attack.

3. Control Existence vs. Control Effectiveness

PCI DSS version 2.0 required that controls exist --- that firewalls are installed, that monitoring is deployed, that patches are applied. It was less prescriptive about whether those controls actually work against realistic attack scenarios.

Target had firewalls. But the firewall rules allowed the attack path. Target had monitoring. But the monitoring alerts were not investigated. Target had antivirus. But the custom malware evaded it.

The lesson: compliance tests whether controls exist, not whether they are effective. Penetration testing should test effectiveness, but only if the testing methodology is realistic and the scope is comprehensive.

4. Vendor Risk as a Blind Spot

Fazio Mechanical was a small HVAC contractor with 52 employees. They had remote access to Target's network for billing purposes. PCI DSS Requirement 12.8 addresses third-party service provider management, but the practical implementation often focuses on payment service providers rather than every third-party vendor with network access.

The lesson: any entity with network access to the organization is a potential attack vector. Vendor risk management must include all vendors with connectivity, not just those in the payment chain.

Governance Failures

Beyond the technical compliance gaps, the Target breach revealed governance failures:

Board Oversight

Target's board had a Risk Committee that reviewed cybersecurity matters. However, the committee received high-level summaries rather than detailed security assessments. The board was not informed about specific security architectural risks (like the vendor access architecture) or about the limitations of the PCI DSS assessment scope.

After the breach, Target reconstituted its board oversight, adding a dedicated technology committee and requiring direct reporting from the CISO to the board.

Detection-Response Gap

Perhaps the most damning failure was the detection-response gap. Target spent approximately $1.6 million on FireEye monitoring tools. The tools worked --- they detected the malware and generated alerts. But the organizational processes for responding to those alerts failed. The Bangalore SOC escalated the alerts, but the Minneapolis team did not act.

This failure was not a compliance gap (Target met the monitoring requirement) but a governance failure. The organization had invested in detection technology without investing in the operational processes to respond to detection.

Incident Response

Target's incident response was widely criticized for its slow pace. It took six days from the Secret Service notification (December 12) to confirm and begin containment (December 18). The public disclosure (December 19) came only after investigative journalist Brian Krebs was about to publish the story.

Aftermath and Industry Impact

Financial Impact

  • $18.5 million: Settlement with 47 states and the District of Columbia
  • $10 million: Settlement in a class-action lawsuit by consumers
  • $39 million: Settlement with payment card issuers
  • $202 million: Total corporate costs (through 2016), including breach investigation, customer notification, credit monitoring, and legal fees
  • Unknown: Lost revenue from customer trust erosion

Industry Changes

The Target breach catalyzed several industry changes:

  1. PCI DSS 3.0 and beyond: Subsequent PCI DSS versions increased requirements for penetration testing scope (including segmentation validation), vendor management, and detection capabilities.

  2. Chip-and-PIN adoption: The breach accelerated US adoption of EMV chip cards, which are resistant to the RAM-scraping attack used at Target. The October 2015 liability shift deadline was partly driven by Target's breach.

  3. Board-level cybersecurity: The resignation of Target's CEO and CIO demonstrated that cybersecurity failures have C-suite consequences, driving increased board-level attention to security across industries.

  4. Third-party risk management: The breach elevated vendor risk management from a compliance checkbox to a genuine security priority. Organizations began scrutinizing vendor access with greater rigor.

  5. Detection and response investment: The breach demonstrated that having monitoring tools is insufficient without effective response processes. This drove investment in SOC capabilities and incident response planning.

Implications for Penetration Testers

Scoping Lessons

When scoping a PCI DSS penetration test, explicitly address: - All third-party vendor access points (not just payment-related vendors) - The path from each vendor connection to the CDE - Management systems that can deploy software to CDE systems (POS management, patch deployment) - Monitoring systems and their alert-response pipeline

Testing Methodology Lessons

Design testing to evaluate: - Realistic attack paths (including multi-stage attacks through connected systems) - Detection capabilities (can the client detect your testing activities?) - Response effectiveness (if alerts fire, are they investigated?) - Segmentation from non-obvious network segments

Reporting Lessons

Report findings in terms of: - Attack paths, not just individual vulnerabilities - Business impact tied to the specific data at risk - Compliance gap analysis that connects findings to specific PCI DSS requirements - Recommendations for continuous monitoring, not just point-in-time fixes

Discussion Questions

  1. If you had been the penetration tester conducting Target's PCI DSS assessment, what additional scope items would you have insisted on including?

  2. Target's FireEye tools generated alerts that were not investigated. How would you test whether an organization's SOC actually responds to alerts? What methodology would you use?

  3. The Target breach originated at a small third-party vendor. What practical steps can organizations take to manage vendor risk when they have hundreds or thousands of vendor relationships?

  4. After the breach, Target's CEO and CIO resigned. Does executive accountability for security failures create better security outcomes, or does it create a culture of blame that discourages honest risk reporting?

  5. PCI DSS has been significantly updated since 2013 (now at version 4.0). Research the specific changes and assess whether the current version would have prevented the Target breach. What gaps remain?