The hacking community continues to go after the small and midsized merchants who often lack the security maturity to adequately protect their systems and data – which makes them easier targets. In the wake of the recent breach at Schnuck’s, a 100-store grocery store chain in the Midwest, where the hacker’s purportedly walked away with a couple million credit cards, Visa released a security alert to provide guidance to grocers to help fight off these attacks: http://usa.visa.com/download/merchants/alert-prevent-grocer-malware-attacks-04112013.pdf.
First, the bulletin discusses the issue – that hackers find a way to get onto the merchant’s network and then they install memory-parsing malware on Windows-based POS (point-of-sale) 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 them from the computer using customized memory parsers.
Visa’s guidelines provide several common sense strategies to abide by to help reduce the probability of these threats. This post will provide 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.
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 the most specific locations (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 prevent 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 gobbledegook (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 that 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. Remember: 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 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 basis. 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) system to monitor your critical systems, provide correlation analysis, provide alerting to anomalous events, and 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.
Bag Your Own
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.
These recommendations are all quite useful. Reading between the lines, since Visa made so many recommendations pertaining to the basic blocking and tackling of PCI compliance, I’m going out on a limb to say that these grocers who recently suffered breaches were not PCI compliant at the time of the breach, but would love to hear any additional thoughts.
A closing note – Visa will be presenting much of this material on Wednesday 24 April 2013 at 10:00 AM PDT. Register for this event at: https://visa.adobeconnect.com/e4z1rb8vc0h/event/event_info.html.