Visa has always been on the forefront of the payment card industry, often being the first out of the gate to provide sage wisdom to the payment community at large. Some of my favorite people at Visa, Tia Ilori and Ingrid Beierly, have put together a great presentation to address the most recent security trends and breaches. The presentation will soon be posted at www.visa.com/cisp. We are all aware of some of the grocery store breaches from this year which were soon after addressed by Visa who provided some guidance. In this well thought out presentation, Visa connected a few dots pertaining to the latest breaches and presented practical actionable items for merchants to follow to help minimize their exposure as well as some long-term strategies. In short, the hackers are finding ways to get onto companies’ non-payment card networks (i.e. corporate network) and they are circumventing poor network controls (poorly configured firewalls, weak access controls, etc.) to install malware on POS systems where they are capturing cardholder data in memory “where the fastball hits the catcher’s glove,” and then sending the captured information back to the attacker, oftentimes back through the initial compromised boxes.
Several of the suggestions were to simply do the right things to be PCI compliant. This echoes Visa’s April guidelines and my corresponding blog post. Most of this post will cover the tactical elements that are “beyond doing the stuff you’re supposed to be doing away.”
Is you is or is you ain’t PCI compliant?
OK – one paragraph about this. One – if you are self-assessing, don’t just check the “in place” box and say “close enough.” Feel confident that the applicable item really is in place and that if for some reason you had to testify in front of a jury, you feel good about your position. Secondly, if you are using a QSA, make sure they are pragmatically thorough. This is where you can (and ultimately will) get burned by a QSA who is not thorough in his/her approach to assessing your environment. It is possible for a “fly-by” QSA to deem you to be PCI compliant, but that doesn’t mean that you’re REALLY compliant or that you’re really secure. Third and final point here – and this SHOULD be a no-brainer anyway – PLEASE make sure you have tight firewall rule sets and access control lists in place to protect your cardholder data environment. Don’t allow excessive hosts/ports/protocols to communicate in or out of this environment just because it’s easier.
The Things to Noodle Over
The following actionable items are things you should consider to improve your security posture and to be in a better position to address the most recent threats and attack vectors. Again, these suggestions are not explicitly called out in the PCI DSS, but really are Good Ideas (and as always, I’ve added my color commentary):
- Treat your admin boxes right: Make sure administrative boxes are secure – this includes jump servers, authentication servers, and web consoles. Many folks consider these types of devices to be quasi-out of scope because they don’t “store, process, or transmit cardholder data.” However, this is not true. These devices are often ATTACHED to the cardholder data environment which renders them in scope. Oftentimes they are either the keys to the kingdom or they at least provide an easy avenue to access the cardholder data environment. Take proper care to secure these devices by hardening them and monitoring them, and treating them the way they deserve to be treated. Since we are mentioning authentication here, you also need to make sure that your centralized authentication mechanisms (i.e. AD domain controllers) are secure and treated as in-scope systems since they are, after all, most likely attached to the cardholder data environment.
- POS – just because they’re remote means you should forget them: On POS systems, make sure that you are monitoring them closely. In addition to PCI compliance and PA-DSS compliance, consider performing binary or checksum comparisons. Also consider monitoring running processes and if possible whitelisting.
- Don’t skimp on pen testing: For web applications, remember there is a PCI DSS requirement to perform pen testing annually and after any “significant” changes. Do not rely solely on automated pen testing or you run the risk of NOT finding things that a real attacker would be able to find. The pen testing should be both DETAILED and MANUAL (and sure, it can contain elements of automation!)
- 2FA is your friend: Wherever possible, try to implement two-factor authentication for access to the cardholder data environment. This helps circumvent any potential attacks there if the attacker is able to obtain credentials (from password cracking or keystroke logging). And given the fact that there are many low cost providers out there these days, this is not too difficult/painful to implement.
- Deny RDP logons: To the extent possible, minimize or do away with using RDP to remotely administer machines. Attackers have gotten good at performing man-in-the-middle attacks to hijack sessions. Of course, this may be challenging for many of the companies who use this protocol to remotely manage POS systems. Some things to consider (I’d love to hear more ideas…):
- If you MUST use RDP, then try to do it as securely as possible – refer to hardening documentation and tips, such as https://security.berkeley.edu/node/94?destination=node/94.
- Use access control lists to restrict which devices are allowed to RDP to remote boxes.
- Change the default port to something besides 3389. That port is akin to wearing a “hijack me” sign on your back.
- Cold hash and porridge: Do not use weak encryption algorithm for passwords (i.e. no NTLM). It has gotten much easier over the years to crack passwords. Even strong passwords will succumb to attackers if a weak hashing algorithm is used. Check your system settings to understand what mechanisms are used to encrypt/protect your passwords.
- The three-finger salute: Consider periodically rebooting systems to clear caches/keys/etc. The longer a system is up and running, the more potential information can be found in temp files, etc. Obviously this would apply more to POS systems and possibly store servers than to back-end systems!
- The application is not as important as it thinks it is: Limit administrative privileges on applications. Grant only the privileges that the application, service account, or process ID needs. You may need to engage in discussion with application vendors to get a clear understanding of the privileges/access that the application requires to do its thing.
Once again, thanks to Visa for paving the path for this blog post. While no particular action will prevent a breach from taking place, it will help reduce the probability and the attackers will turn their focus on those who don’t take action.
Do you have any pearls of wisdom to add to this list?