Best Practices for Cybersecurity, Part I: Keeping Bad Guys, Malware Out

Posted originally on Wired, InnovationInsights blog

In my last blog, I elaborated upon five “truths / must do’s” for Payment Card Industry (PCI) Data Security Standard (DSS) compliance and cybersecurity protection. But those truths touch upon just some fundamentals. I’ve read numerous articles over the past several months which talk about going above and beyond the PCI standards and offer specific suggestions. Too often, I find the recommendations to be found in the requirements already. To implement a fully realized cybersecurity strategy that also meets PCI compliance standards, here are some best practices which have been proven over time and, as applicable, where you will find them in the PCI DSS.

In Educating Employees, Explain the Why Behind the What

Most of the recommendations in this section speak to employee awareness training (required by PCI), in addition to putting filters in place to block malware-laden e-mail and such. This can also be improved upon. But, by driving toward employee behaviors, you’ll significantly increase the effectiveness of your efforts. You need to teach them about the “bad things” they must avoid doing – not only “what” behaviors but the “why” behind them which elevates risk. In other words, don’t resort to “Don’t do it because we say so …” lectures. Try this instead: “You are a vital contributor to our business. But what you do – or don’t do – impacts our operations.” Don’t load up on FUD factor (fear, uncertainty and doubt). Break it down into simple terms.

Here are some suggestions and how they tie back to the PCI DSS:

• Point of sale (POS) devices should be single purpose – addressed by PCI DSS 2.2.1
• Train users on how to spot security threats – PCI DSS 9.9.3 (new), 12.6, 12.6.1
• Implement a patch management plan – PCI DSS 6.1, 6.2

Prevent Malware Installation and Operation

For this area, let’s focus on five specific tasks:

• Isolate the cardholder data environment through network segmentation – strongly recommended by PCI DSS. However, the emphasis should (and always) be on improved security posture – not merely compliance
• Restrict outbound connections from the POS and back-office systems – PCI DSS 1.3.5
• Outbound connections should be limited to specific IP addresses and ports on those addresses – PCI DSS 1.2.1, 1.3.5
• Outbound connectivity should be logged and reviewed – PCI DSS 1.2.1, 1.35, 10.2, 12.10, 12.10.3, 12.10.5
• Make sure local administrator passwords are unique across all systems on the retailer network, and sufficiently difficult to guess – PCI DSS 8.2, 8.2.1, 8.5

Detect Breaches That Get Through as Quickly as Possible

This is all about being diligent, as the PCI DSS requires the following protections to be in place:

• Implement centralized logging and monitoring with daily review – PCI DSS 10.1-10.6
  • All security events
  • Event logs of all system components that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of CHD and/or SAD
  • Event logs of all critical network components
  • Logs of all servers and system components which perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).
• Implement intrusion prevention system(s) – PCI DSS 11.4
• Implement processes for physical and logical detection of USB drives – PCI DSS 9.9 (new) Note: You can’t disable the USB ports on point of sale (POS) systems because that’s how the PIN Transaction Security (PTS)/Point of Interaction (POI) devices are typically connected (as well as monitor, keyboard, etc.). It is essential to include USB ports in the physical security review of point of sale operations.

Lastly, here are a few words about whitelisting solutions, which are in-vogue for many retailers as a compensating control for the following reasons:

• A lack of anti-virus/anti-malware solutions and the inability to keep signatures current
• An absence of patching
• A lack of file integrity-monitoring solutions. 

So now that Windows XP has gone out of support, whitelisting is proffered as the main compensating control for the lack of any more security patches to protect XP. In many cases, I suspect that many unsupported XP systems (particularly POS systems) are already woefully insecure because they aren’t current with the patches already available. What if the “trusted” applications were compromised at the supplier/vendor facility? What if the yet-to-be-discovered-and-exploited vulnerability can execute within the authorized parameters of the application?

In my next and final blog installment, I’ll spend some time talking about the merits and limitations of the latest “silver bullets” (really more like a “Holy Grail”) that vendors are claiming will greatly reduce or even eliminate merchants’ compliance responsibilities: point-to-point encryption and tokenization.