12 Questions To Ask About PCI

Organizations either breeze through or struggle with PCI certification. The struggle parallels to a fight against zombies. You must stay on your toes. Once they start coming towards you they don’t stop and as your team deals with their own zombies, you realize you can’t keep up. The challenge does not stop there. This poem by Sam Kassoumeh sums PCI up in a nutshell. You must manage tech debt, legacy access control rules, and getting attention from developers or operations. How does anyone get through this?

Never stray from your main goal. Certification is the immediate point of the program. It is supposed to comfort customers and partners because due diligence keeps their financial data safe. Remember PCI is a means to an end and not a goal itself. The PCI process is supposed to make you think of ways to handle sensitive data in a general way. Nobody would argue that a single certification, piece of paper, or audit is enough to protect the organization. Build a process and worldview to work with.

The PCI Level 3 document is 112 pages long with 4 appendices and 12 sections. It sounds daunting and can be if your approach to security is ad-hoc. You will scramble to figure out what is covered, where covered assets are, who has access to those assets, and maybe even what the term asset really means. In the middle of an assessment you find yourself questioning the meaning of just about everything including:

  • Security strategy  – Do I really have a coherent strategy?
  • Tools used
  • How to store data

So what can you do to make PCI compliance achievable on that big day? Start today and think about:

  1. What customer data do we need to hold onto? For how long?
  2. How do I dispose of storage and printouts that have this data?
  3. Does everyone who needs to access this information have 2-factor authentication?
  4. Is the pathway to this data secured by encrypted connections (e.g. HTTPS)?
  5. Is it possible for an insider or intruder to see sensitive data through some other segment of our network?
  6. Is sensitive data only available to people and apps that really need it?
  7. If someone’s access level changes, would I know about it?
  8. If a related network rule changes, would I know about it?
  9. Am I keeping up with patches on high priority servers?
  10. Am I monitoring for and/or alerting on suspicious traffic?
  11. Do I know what ciphers we use?
  12. What’s our process for offboarding employees with access to sensitive data?

If you store data about customer transactions unrelated to credit cards (which is the domain of PCI) is it really a stretch to treat that data with same care? Why encrypt credit card information but not bank account numbers? Why mask part of the credit number and not a customer’s address? An address can be used for identity theft, too.

It’s not to say you should encrypt or mask everything everywhere. The point is to consider it. Maybe you don’t need to store so much data. Maybe you can build your network and application access rules earlier when paying attention to areas of the network with personal information.

This is just the beginning but if you can ask yourself these questions early, you can construct a strong strategy which is the true end goal of the PCI compliance process.

Once you know what you’re looking for use any resource you find helpful. For example, IBM has posted a guide on the importance of complying with PCI DSS 3.0 Requirement 6. You can view the guide here.

What are your thoughts on PCI? Be sure to comment below.