CBOSS - Blog

Prioritizing PCI - Part 2: Protecting Yourself

Written by Mike Lendvay | Jun 11, 2020 4:30:00 PM

PCI Compliance can be daunting for new merchants or service providers. The PCI-DSS contains 12 requirements, with 412 sub-requirements and sub-sub-requirements covering over 115 pages. It begs the question, "Where do I start?"


Fortunately, the Security Standards Council offers a roadmap for navigating the road to PCI Compliance called the PCI Prioritized Approach. This approach lays out the DSS requirements as a set of 6 milestones to attaining compliance. In this series, we will take a look at the 6 milestones and how to apply them to your business operations.
 

Today we'll tackle Milestone 2: Protecting Systems and Networks.

 

Deploy Firewalls

Any system that is in scope for PCI DSS (if you don't know about scope, please see Part 1: Watching What You Store) needs to be isolated from systems that aren't, and especially from systems on the internet as a whole. To make this happen, you need to install firewalls. How many and what kind depend on the details of you network. You should definitely have one at the edge of your network between you and the internet. You also need one between your DMZ (we'll get to what a DMZ is in a minute), and any internal systems. If you are keeping some of your systems out of scope, you need a firewall between those systems and your in-scope systems.

What's a DMZ?

A DMZ, or De-Militarized Zone is a perimeter network separated from you internal network. Any system visible to the internet; web servers, FTP servers, mail gateways, should be placed on this network. Limiting inbound traffic to systems in the DMZ helps keep an outside hacking attempt from reaching into other parts of your infrastructure. For this reason, PCI DSS requires that all inbound connections from the internet be terminated inside the DMZ.

Once you have a firewall deployed, you need to configure it. Firewalls should be configured to deny traffic my default. Anything you need to allow should be explicitly added. When you do, be sure to document what you're allowing and why it was needed.

 

Don't Use Vendor Defaults

Most devices purchased today come ready to use, configured for the most common setup they would be used for. This can be convenient when you need to hit the ground running, but this simplicity can be a vulnerability. Devices like routers, firewalls, access points, and server remote access cards are often shipped with generic passwords, SNMP strings, and encryption keys that are shared across many devices from the manufacturer. Because all of these are readily available to anyone, they must be changed to ensure access to your new systems is protected. Default passwords should be changed, SNMP strings should be set to something unique to your organization, and default certificates should be regenerated or replaced, as anyone with access to the same hardware has copies of the private keys for those certificates as well.

 

Encrypt Transmissions Over Open Networks and Use Secure Protocols

When you're sending sensitive information (like say, cardholder data) over a network, it's important to make sure that data is only readable by its intended recipients. If the network your transmitting is the internet, or another shared network that are not exclusively under your control, the only way to ensure confidentiality is to encrypt the data before sending it. The PCI DSS requires encryption for the following data types:

  1. Cardholder Data, including PANs, names, and expiration dates

  2. Sensitive Authentication Data, including Track Data, PIN Block Data, and CVV codes

  3.  Authentication data like passwords, One Time Passwords, API keys, etc.

  4.  Any Remote Administrative protocol, like RDP, web management pages, and CLI console access.

The PCI DSS doesn't specify a single encryption method for this traffic, but the following ones are generally recommended:

  1. For HTTP, Transport Layer Security (TLS) should be used.

  2. For console access, options like SSH should replace telnet or rlogin

  3. For FTP, TLS (FTPS) should be used, or replaced by SFTP (not the same thing).

  4. For RDP , TLS should be used.

  5. IPSec VPN should be considered for any protocols that can't be secure independently.

This is far from an exhaustive list, but covers a lot of the most common protocols.

 

Use an Anti-Virus

Part of any defense in depth strategy is protecting servers and workstations from malicious software. Most people know they need Anti-Virus/Anti-Malware, but if you didn't the PCI DSS is here to tell you. You Do. At a minimum you need the following:

  1. Anti-Virus must be installed on all commonly affected systems (i.e. servers, workstations, etc. running OSes that have know viruses in the wild; or really any platform that could run arbitrary software by default.

  2. Anti-Virus must be capable of detecting and removing malicious software. This seems to be a no-brainer, but you should be looking for effective protection, not something to check a box.

  3. Anti-Virus should be actively running, so schedule-only scanning won't be enough. You need on-access scanning.

  4. Anti-Virus should be configured for regular system scans. So even with the on-access scanning, you need to configure regular scanning system wide.

  5. Anti-Virus should be configured to update regularly. Outdated AV is just as bad as no AV at all. AV should be updated as often as practical preferably daily if not more often.

  6. Anti-Virus settings should be protected from modifications by end users. Users should not be able to disable AV, or prevent scanning.

Everything above should be in place, and the details of where and how should be documented.

 

Use Individual Usernames and Strong Authentication

One of the most ubiquitous, but often misunderstood aspects of security is IAAA; that is Identification, Authentication, Authorization, and Accounting. Everyone knows you need a password to get into most computers, but IAAA is about more than just that. Every user should have their own username and password. No one should be logging in with a "shared" account or with an account meant for another user. This is because each users access should be only available to them, and any action taking with a user account should be traceable to a single responsible person.

 

Unique accounts also simplify the process of revoking access. If someone leaves your company, you need to revoke they access to your systems immediately. Do you know what to shut off, or what passwords to change? If they only had their account you do, otherwise...

 
Usernames and passwords are important, but they aren't all created equal. To meet PCI DSS requirements, you should be requiring strong complex passwords for all users. You should be requiring users change passwords at least every 90 days, and preventing them from reusing old passwords. Passwords should never be stored in plain text in files or databases. Instead they should be hashed or encrypted so they cannot be easily intercepted or stolen.
 
Passwords alone are not enough in this day and age to protect our most critical assets. For this reason, the PCI DSS requires that certain actions, like console access or remote administration of systems be protected with MFA.
 
What is MFA? MFA or Multi-Factor Authentication is the use of two or more methods to validating the identity of a user. These "factors" generally fall into one of 3 categories:

  1. Something you know; this is usually something like a password or PIN.

  2. Something you have; often this is something like a SmartCard, RSA token, OTP generator or personal device like a phone or tablet.
  3. Something you are; this can be a fingerprint, eye scan, or another form of biometrics.
Special note on MFA selection: Many organizations are attracted to options like SMS or text messaging to add MFA to their systems. The appeal comes from the ease of configuration, and low cost of implementation. A word of caution though, SMS is considered a weak form of authentication, due to the large number of exploitable vulnerabilities all throughout the SMS platform. For this reason, the PCI DSS does not consider SMS a viable option for adding MFA.
 

Payment Security Requires Physical Security

An important aspect of any security plan is controlling physical access. The only saying in IT is "There's no security without physical security" Even the strongest security controls can often be bypassed if you have physical access. For this reason, you need to implement physical access controls.

Scope for PCI DSS applies to physically as well as logically so any physical location or where people or systems store, process, or transmit need to have the following considerations:

  1. You need to restrict access to locations and equipment where CHD is processed to only employees that need access. This includes server rooms, call centers, AR departments,etc. Notably, it does not include retail locations where only POS systems are being used. (Thankfully, as it would make going to the store a complicated endeavor). You can do this with keyed locks, badge readers, security guards, or any number of other control methods.

  2. You need to monitor access to restricted areas. Any of the areas referenced above require surveillance via camera or some comparable method. evidence from this monitoring needs to be kept at least 3 months unless barred by law.
  3. You need to restrict access to network jacks and access points. Walking into your facility shouldn't be all someone needs to do to get around a firewall. So jacks in public areas should be physically locked away, disabled, or protected by a protocol such as 802.1X.
  4. You need a system for telling employees and visitors apart. You can do this with badges, or similar identification to employees, and different badges or tags for visitors. Note: any visitor badge must expire and needs to revoked when the visitor is done.
  5. One final thing: although not explicitly called out as such in the PCI DSS, you can reduce your scope by applying the concept of segmentation (see Part 1 for an overview of segmentation). In this case, you can avoid having to lock down your entire company by focusing on and isolating the areas that interact with CHD. For this to be successful, you must put the required controls in place between areas of your company that do have access to CHD from those that don't. (e.g. You can't consider you AR department "segmented" if anyone has access to it once they're in your building and you can't consider access your data centers segmented if there are wiring closets outside if it with open access.)

Know What You Have, Where it's Vulnerable, and How to Protect It

To protect your data and your infrastructure, you need to know what your protecting. What you need is an inventory. You need to track all systems and software in your infrastructure, from purchase to decommission. This inventory should reflect any systems that process CHD, and devices like card readers, encryption systems, etc. It should also include any system which these systems depend on (routers, switches, firewalls, authentication servers, storage systems).

You also need to know where your systems might have weaknesses. To that end, the PCI DSS requires that you run network vulnerability scans, both internally and externally at least quarterly. You also need to perform penetration testing internally and externally at least annually.
View full post