Analysis of Target's multiple PCI DSS failures that resulted in breach

• by secboxadmin
• in News
• posted February 6, 2014

As new information continues to unfold surrounding the Target data breach, it is becoming evident that there were multiple security failures which ultimately lead to a major catastrophic data breach. The news surrounding the breach can not be linked to a single point of failure. In fact, there are multiple instances where enforcement of PCI DSS could (and should) have detected and stopped the breach before it reached this level of magnitude. Here is a look at the some of the events surrounding the Target data breach, and the PCI DSS regulation failures around each of those events.

Failure 1: Vendor Access

Brian Krebs recently reported that the Target Hackers Broke in Via HVAC Company credentials. The quoted spokesperson from Gartner stated, “… although the current PCI standard (PDF) does not require organizations to maintain separate networks for payment and non-payment operations (page 7), it does require merchants to incorporate two-factor authentication for remote network access originating from outside the network by personnel and all third parties — including vendor access for support or maintenance (see section 8.3).”
While correct about section 8.3, there are two specific PCI DSS regulations pertaining to vendor accounts which should not be ignored:

• 8.5.6.a: Verify that any accounts used by vendors to access, support and maintain system components are disabled, and enabled only when needed by the vendor.
• 8.5.6.b : Verify that vendor remote access accounts are monitored

Benefit of the doubt: Let’s assume that the accounts were regularly monitored, and left on 24/7 due to the nature of the HVAC maintenance needed across all national stores.

Failure 2: File Integrity Monitoring

Once the hackers gained access to the system, they were able to upload Malware to various cash registers and POS systems. File integrity monitoring should have detected changes to critical files when the Memory scraper attached itself to a running process.

• 11.5: Deploy file integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files or content files. Configure the software to perform critical file comparisons at least weekly.

Benefit of the doubt: Maybe it was not possible to employ file integrity monitoring to detect changes to the critical files that make up the point of sale terminals.

Failure 3: Active Malware Detection

Once the malware was in place, why wasn’t it detected by virus scanners?

• 5.1, 5.2: Virus Scanning to detect malware signatures.

Benefit of the doubt: Evading virus scanning is hacking 101. Anyone with this level of planning and sophistication would have been able to easily circumvent traditional virus scanning. It’s probably not fair to consider detection a plausible defense.

Failure 4: Intrusion Detection Systems

As the malware was working to send the stolen data to various drop sites, Network Intrusion Detection Systems (NIDS) should have detected the unauthorized traffic leaving the network.

• 11.4: Use network intrusion detection systems and/or intrusion prevention systems to monitor all traffic in the cardholder data environment and alert personnel to suspected compromises. IDS/IPS engines must be kept up to date

Benefit of the doubt: Maybe the hackers were smart enough to evade the IDS systems and mask their outgoing traffic.

Failure 5: Daily Log Review

According to PCI DSS regulations, logs should have been reviewed on a daily basis. This daily log could have caught suspicious network activity or changes to system files in lieu of proper file integrity monitoring.

• 10.6: Review logs for all system components related to security functions at least daily

Benefit of the doubt: None. All roads lead to log analysis, and with strict guidelines of daily log review, it was evident that this security control was being ignored.