Our Thinking

Don’t be a Target – Thoughts on How to Stay out of the Crosshairs

Posted by Steve Levinson on Jan 8, 2014 3:48:01 PM

As most of the world is aware by now, the recent credit card breach at Target netted the attackers over 40 million credit cards between November 27 and December 15. This is the largest reported breach of a merchant since the TJX breach in 2006. Thus far, Target and the forensic community have been pretty tight-lipped about this breach. We’ve reached out to dozens of our peers to try to cobble together how the breach occurred, but at this point, I’ve only collected a few remnants of rumors, anecdotes, musings, and ramblings. While I would typically wait to collect a few more facts prior to blogging about this, I wanted to share some preliminary thoughts about the various attack vectors.

Attack Vector – POS Malware

One rumor I’ve heard is that the breach occurred through malware (a variant of Dexter, which is the malware that afflicted Schnuck’s almost a year ago) that was installed on just about all of the POS (point-of-sale) systems. There was also chatter that this may have been an inside job.

How would that work? The hackers find a way to get onto the merchant’s network, and then they install memory-parsing malware on Windows-based POS systems or store servers to extract full magnetic-stripe data from the computer’s memory (RAM, or random access memory, to be exact). The malware is configured to look for certain payment applications and then to basically steal it from the computer using customized memory parsers.

Was Target PCI compliant at the time of the breach? In my opinion – possibly. But if so, then why did the following things happen?

  • Malware is stealthy, but it is possible to detect it, possibly through file integrity monitoring mechanisms, or possibly through reviewing running processes on a real-time basis. If this malware was similar to the malware that compromised Schnuck’s earlier in 2013, Target ought to have been on the lookout for it.
  • How did the malware make it onto almost ALL POS systems? Was a centralized configuration management box compromised? Was the centralized configuration management box omitted from the PCI assessment (mistakenly) because it does not “store, process, or transmit” cardholder data? (Aahhh – but it IS attached!) Was the centralized management box duped into thinking it was just passing along a legitimate version of POS software? If so, where were the checks and balances?
  • Even if the malware made it onto almost all POS systems, it would have had to collect the cardholder data and then send it out to an intermediary or some sort of collection point. Could Target have had stronger network controls in place to prevent these unauthorized outbound data flows?
  • On the bright side, this breach was discovered very quickly. I’m still not sure if it was discovered through awesome Card Brand heuristics or through Target’s internal logging and event management platform. Oftentimes, breaches take place many weeks on end. If it were discovered through Target’s platforms, then one would wonder why it was not caught sooner.

Attack Vector – Major Artery

While I’ve not heard much chatter about this attack vector, it holds a certain amount of logical validity. As with the Heartland breach, could it be possible that the attacker(s)were able to deploy some sort of packet sniffing software on the back-end near the aggregation points or payment switches so that all cardholder traffic passing through that connection could be captured, assuming that it was transmitted via an unencrypted protocol (which is allowed on internal trusted networks). If this were the case, could Target have implemented more robust controls to prevent or detect this type of activity?

I expect that we should have a few more pieces to the puzzle within a couple of weeks when Visa presents a webinar that talks to the most recent breaches of large merchants (more info below). I expect to write a follow-up post once there are a few more data points.

Additional Education and Info

  1. I recommend that merchants attend Visa’s upcoming webinar on Wednesday, January 22 at 10:00am PDT. Visa does a great job presenting facts and providing advice based on the preliminary forensics analyses. The URL to register for this event is: https://events-na3.adobeconnect.com/content/connect/c1/1003435137/en/events/event/shared/default_template/event_landing.html?sco-id=1281791642.
  2. While this blog post is written with a focus on our merchant clients in the PCI arena, here is a good article geared towards the consumer (for your reading pleasure): http://www.today.com/money/5-lessons-learned-target-security-breach-2D11803343.

*****************************************************************

Also for your reading pleasure, this is an excerpt from my blog post from last spring pertaining to the summarizing of Visa’s guidelines resulting from the Schnuck’s breach. Good refresher material and I’m guessing we will see/hear several of these elements in Visa’s upcoming webinar.

Visa’s guidelines provide several common sense strategies to abide by to help reduce the probability of these threats. The remainder of this post provides an overview of the recommendations along with my color commentary. One common theme that resonates throughout the document is that these are basic elements of the PCI DSS.

Network Security

Firewalls: Visa recommends that firewalls be configured to allow only network traffic necessary for business. That means that the rule sets should deny all traffic that is not explicitly allowed. The rule sets should be configured to allow only traffic to/from a specific location (i.e., an IP address and not an entire network), allowing specific protocols or ports (i.e., HTTPS). Many companies are decent at constructing inbound rule sets, but do a lousy job of preventing data from walking out the door via outbound traffic. Oh, by the way, this is a PCI DSS requirement – if you are not doing this, then you are NOT PCI compliant.

Network segregation: Visa recommends segregating payment processing and POS networks from other networks. This is not necessarily a PCI DSS requirement, but it certainly CAN help reduce your PCI scope and your risk. Many companies consider the systems that store, process, and transmit cardholder data to be in scope, but they often overlook the “attached systems” which reside on the same network. If it’s on the same network, it’s “guilty by association” and it’s in scope.

Visa also recommends creating strict ACLs (access control lists or firewall rule sets) that segment public-facing systems and backend database systems that house payment card data. Again, this is a PCI DSS requirement. If you’re not doing it, you’re not PCI compliant.

POS (Point of Sale) System Security

P2PE: Visa recommends that merchants implement hardware-based point-to-point encryption (P2PE). This is considered an industry best practice as it could dramatically reduce your PCI scope as the attacker would only be able to obtain gobble-dy-gook (that’s a technical term for useless, to them, encrypted data), but many merchants have not implemented this since it involves hardware refresh and possible software changes in most cases. If you are a new business or if you are replacing your POS system, this is something to seriously consider. Otherwise, it is worth putting on your strategic roadmap.

Use PCI PA-DSS approved payment applications: Again, this is considered a best practice, not a PCI requirement. If you use a PA-DSS approved payment application, you also need to ensure that you’ve installed it in a secure (PCI complaint) way. If you are using a home-grown payment application, it is your responsibility to ensure that the application adequately protects cardholder data (i.e., you should perform penetration tests and forensics to validate this).

Current patches: This is a PCI requirement. If you do not keep your systems up-to-date with the most recent patches, you are not PCI compliant. You may take a risk-based approach to vulnerability management, so there is some flexibility. Just because you have systems in dozens or hundreds of retail locations doesn’t mean that you can claim “it’s too hard to roll the patches out to all of these systems” as an excuse.

Current anti-virus: Again, this is a PCI requirement. All in-scope systems susceptible to malware (i.e., the very Microsoft boxes that are the targets here) must have anti-virus software deployed with current signatures. Don’t forget, you also need to regularly check your centralized console to see if any systems have fallen behind, or more importantly, if any systems are attached to the network but for some reason no longer have the antivirus agent running.

Host-based intrusion detection/prevention: This is considered a best practice. Given the fact that the anti-virus vendors are beginning to add this functionality to their product suites, you should consider a strategic roadmap to incorporate this into your defenses. These products are continuing to get stronger and provide features such as locking down USB ports, cardholder data discovery, file integrity monitoring, and whitelisting.

Strong passwords: Again, this is a PCI DSS requirement. Many small to midsized merchants continue to use weak passwords, or sometimes default passwords, which become easy attack vectors for miscreants.

Validate your POS updates: Visa recommends that you perform a checksum comparison on the updates prior to deploying them on POS systems and that you work with your POS vendors to obtain signatures and hash values to perform this checksum validation.

System hardening: Per the PCI DSS requirements, you must disable unnecessary ports and services, change default settings, including default users and guests. If you are not doing this, then you are not PCI compliant.

Administrative

Administrative privileges: Visa recommends that you limit administrative privileges for users and applications. This is a PCI requirement. Privileges should be granted on a business need to know. Don’t just grant someone or something full-blown admin-level privileges because it was the easier path to take. If you use service accounts or process accounts, create one account for each function or group of functions and grant it only the privileges it needs. Also, make sure that process accounts (those used by computers or applications, and not those used by users) have long and complex password strings.

Account review: Visa recommends that you periodically review systems for unknown and dormant users. This is a PCI requirement. If you’re not doing it, you’re not PCI compliant. It should be one of your calendared ongoing tasks.

Incident Response and Audit Trails

Logging and monitoring: Visa recommends that you deploy a centralized Security Information and Event Management (SIEM), a system to monitor your critical systems, provide correlation analysis, provide alerting to anomalous events, and to store logs in the event that a forensic analysis is needed. This is a PCI requirement; if you’re not doing it, you’re not PCI compliant.

Incident Response preparedness: Visa recommends that your incident response team (IRT) receive the training and certification to respond to a breach and to periodically test and update your IR plan. This is a PCI requirement. If you don’t have people who can fill this role, consider partnering with a company that has a forensics/IR practice.

Be Aware of Known Malware

Visa also provides a list of known malware signatures, including their file names and MD5 hash values. Make sure your systems are capable of detecting and removing this malware and keep in mind that this landscape is constantly evolving.

Topics: Security

Our Thinking - The Online Blog is a source for insights, resources, best practices, and other useful content from our multi-disciplinary team of Onliners.

Subscribe to Blog Updates

Recent Posts