September 2014 IT Business Consulting Newsletter

Take Credit Cards??    PCI DSS Challenges

By Tom K

If your staff or your systems touch credit card info, your company must be PCI DSS compliant (Payment Card Industry Data Security Standard).

Last month, I outlined the PCI organization and the PCI DSS requirement structure in layman’s terms and showed you how to greatly reduce your responsibility to large sections of the requirements.

In this month’s article, I continue the discussion and highlight some of the Merchant Requirements that we’ve found to be challenging, or are often missed.


Disclaimer

This discussion is not presented as complete information to attain PCI DSS Compliance. I highly recommend you work with someone who knows the process when you need to step your company through the PCI DSS Compliance process.


PCI DSS Certification vs Compliance

The PCI DSS is actually a tool, created to help Merchants shore up their security practices to protect Card Holder Data (CHD). The SAQ (Self Assessment Questionnaire) required for a particular Merchant is designed to cover the security components most relevant to how that Merchant processes or handles CHD.

Once the Merchant affirms that the organization complies with all the components within his SAQ, the SAQ is signed and submitted, and the Merchant becomes PCI DSS Certified for one year. But, since this is a "Self Assessment", a Merchant can be certified while not being truly compliant. The merchant may mis-interpret a question, not understand the technology, or just choose to provide a false answer.

A bad situation in any case, as the PCI DSS is designed to protect you, the Merchant, as well as the Card Holder. So it is in your best interest to use the PCI DSS as it was intended... to insure your security is solid. And if you do have a breach and CHD is compromised, you WILL be audited. If the auditors find that you were not in compliance with your SAQ, the fines can be severe.

With this in mind, the following sections discusses components I've often seen Merchants have problems with while attempting to comply with their SAQ.


PCI DSS in the Merchant Environment

I am going to touch on specific topics within your local environment that can provide challenges (or are often missed) that are relatively easy to address.

As discussed in my March 2014 article, "Security When in the Cloud", local security requirements don’t disappear just because your data system is in the cloud. Most of what follows is valid whether your data systems are on–site or in the cloud.


PCs on which Cardholder Data (CHD) is entered:

1. Make sure that the CHD is not saved in cache anywhere on the PC.

  • Disable System Restore
  • Encrypt System Page File
  • Set the Page File to clear on Shutdown

2. Ensure all system and application security updates are being applied.

3. Ensure Anti-Virus is properly installed and configured, and that it can’t be disabled by the user.

If you have a Domain environment, the items in #1 can be set globally via Group Policy. If you have a Windows server, #2 can be satisfied using Windows Server Update Services. #3 can be satisfied using an enterprise Anti-Virus (AV) product. I have discussed these in detail in the following articles:

"Use Group Policy to Centrally Tune YOUR Business Computing Environment"
"Centrally Manage Microsoft Updates Across Your Enterprise"
"Protect Your Company from Viruses and Malware with Enterprise Anti Virus Systems"

If you have a peer-to-peer network or non-enterprise AV, you’ll need to set/confirm these configurations on every PC individually.


Users accessing networks on which Cardholder Data is entered:

1. Every user must have a unique Network ID.

2. Every user must have a strong/complex network Password (PW).
    The standard requires 7 chars min, containing both alpha and numeric chars.
    I recommend stronger PWs as described in my Nov 2011 article "Secure Passwords - You need to get this right!"

3. User must change PW every 90 days, must not use last 4 PWs.

4. Account lock-out is enabled and set for no more than 6 incorrect log-ons.

5. Account Lock-Out duration is at least 30 mins.

6. Screen lock is turned ON if PC is idle for 15 mins, ID/PW required to resume.

7. Revoke user credentials immediately upon termination.

If you have a Domain environment, #1 - #6 can be set globally via Group Policy. If you have a peer-to-peer network, you’ll need to set/confirm these configurations on every PC individually.


Users accessing Payment Applications (PA) including Property Management (PM) systems on which Cardholder Data is entered:

1. Every user has a unique PA/PM system ID (can be the same as the network ID).

2. Every user has a strong/complex PA/PM system PW (should be different from the network PW).


Cardholder Data Primary Account Numbers and e-mail

1. Never send, or request the cardholder send, Primary Account Numbers via end-user messaging technologies (e-mail, instant messaging, chat, etc).

2. This should be explicitly noted in your security policy.


Wireless – Public Access

1. Must be completely isolated from the business network/ Cardholder Data Environment (CDE).


Wireless – Business network with access to the CDE

If the business network includes a CDE and you provide wireless access to the Business Network, there are specific PCI DSS wireless requirements with detailed sub-components in the Standard:

1. A firewall must isolate the wireless network from the CDE.

2. All vendor defaults must be changed.

3. The wireless network must be well secured and encrypted.

I don’t recommend providing wireless access to the Business Network, unless it is absolutely necessary. I believe this is one of the most dangerous holes in any enterprise’s security health. Review my March 2013 article, "Provide Wireless Access to Business Systems???", for details.

If you do believe this is absolutely necessary, review your requirements to determine if you can attain whatever you are attempting to achieve another way.


Remote Access to the Payment Processing Environment

If you allow remote access into your business network by employees or by vendor staff, you need to ensure that access is protected by the following:

1. Use Two Factor authentication.

2. Use a complex Remote Access PW different from network and PA passwords.

3. All communication utilizes at least 128 bit Encryption.

4. For Vendors, provide a unique account, enable the account only when needed, change PW regularly.

5. For Vendors, ensure access is via VPN or based on Vendor IP address.
    (I recommend this for all company users, as well as Vendors)

6. Vendors must use a unique password for each client accessed remotely.

I’ve found Remote Access (via the various desktop remote access applications) to be another of the most dangerous holes in any enterprise’s security health. I highly recommend you take steps to safeguard your enterprise from these holes. My May 2013 article, "Hacked via Remote Access!", highlights the dangers and outlines steps to protect your company.


Information Security Policies/Programs/Plans

The Standard requires that you have a number of formal, written information security policies and programs in place, and that they be reviewed and updated at least annually. These include:

1. Security Policy

2. Critical Technologies Usage Policy

  • What devices touch Cardholder Data
  • How are they used
  • Who is authorized to use them

3. Security Awareness Program

  • All staff must acknowledge they’ve read and understand the security policy annually, in writing

4. Risk Assessment Process

5. Security Incident Response and Escalation Plan

Like everything else in the PCI-DSS, creating these policies and programs can be a rather difficult task, but once completed they are relatively easy to maintain.


If you have any questions or concerns with any of the material presented in this article, or would like general or specific assistance with the PCI compliance process, I’ll be happy to discuss this with you at your convenience. Feel free to contact me at TomK@TomKConsulting.com, or via my cell 443.310.5110.


Within this article, I often point out that having a server and Domain environment can greatly simplify compliance with many PCI DSS requirements. If you utilize a peer-to-peer network (no server/Domain), adding a server and setting up a Domain will not only help manage PCI compliance, but will also simplify the management of your overall environment. Next month I’ll discuss the many benefits of adding a server, and how it will pay for itself (a 2-3 yr ROI).