Let’s suppose that you need to handle credit card data in your computing environment.  Let’s suppose further than you can’t use something like Point-To-Point encryption to vastly reduce your PCI scope.  The PCI DSS standard defines twelve high level requirements that you need to meet.  We will summarize these below.  But be careful with the overview.  When it comes time to actually implement these requirements, you’ll find that each one actually has many subrequirements that you’ll need to meet.  You’ll have to read the standard to find these.

In the blog below, the Requirement headings are taken directly from the PCI DSS v3.0 spec.  The descriptions below the headings are mine.  Please note that the descriptions just include highlights, and are not comprehensive.

Requirement 1: Install and maintain a firewall configuration to protect cardholder data.

This section regulates your firewalls, routers, and networking configuration in general.  Firewalls must be stateful, and protect card holder data.  Firewall and router configurations can’t be changed without a formal approval process.  You’ll also need network diagrams showing the flow of cardholder data through your systems and networks.

You’ll need to formally define who is responsible for network components, and what their role is.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Don’t use any default passwords or vendor supplied passwords anywhere in your cardholder environment.   Make sure that your systems are hardened.  Disable unneeded services on each machine.  Each system should have only 1 primary purpose.  Get rid of insecure services, like ftp, or use a secure alternative like s-ftp.  Remove unneeded software from the system.  Use strong encryption when logging in as an administrator.  Create an inventory of each system’s components that are in scope for PCI.

Requirement 3: Protect stored cardholder data

Never store full track data from the card.  Never store the card verification number or the card’s PIN.  The credit card number is called the Personal Account Number (PAN).  PAN data, if stored, must be protected by strong encryption or something similar.  Define a retention period for the data, and make sure that it is securely destroyed after the retention period ends.  For cryptographic keys, have secure key storage and secure key distribution.  Limit the number of people who have access to the keys.  Have policies and procedures to protect the keys.  Key custodians must “formally acknowledge” that they understand their responsibility.  Mask the PAN data when it is displayed, showing no more than the first 6 digits and the last 4.

Requirement 4: Encrypt transmission of cardholder data across open, public networks.

Use strong cryptography to protect data going across a public network, e.g. the Internet, a wireless network, or a cell phone network.  Your wireless network can’t use WEP, but must use a secure protocol.  Don’t send PAN data in email or instant messaging technologies unless it is protected by strong encryption.

Requirement 5: Protect all systems against malware and regularly update anit-virus software or programs

This requirement pretty much boils down to running anti-virus software on all of your systems, and keeping it running well with things like regular updates.

(Please note that anti-virus software alone is not enough to make a system secure.  Custom malware and other attacks can get through.  But it is a good starting place, and does filter out many low level threats.)

(Note that whitelisting products, like the ones from Bit9 can be particularly effective at stopping malware.  Anti-virus software allow unknown programs to run unless they are on a blacklist.  In contrast,  products like Bit9 prevent unknown programs from running unless they are known to be safe, i.e. on the whitelist.  When the Stuxnet virus came out, it was undetected by all the anti-virus programs for over a year.  However, Bit9 blocked it since it was not on the whitelist.)

Requirement 6: Develop and maintain secure systems and applications

If you don’t have security-oriented coding practices and IT processes, then this requirement is going to dramatically change the way you work.  You’ll need to train your developers in secure coding practices.   Your programmers will also need to do code reviews for security before releasing the code.  You’ll need to become familiar with coding security pitfalls and avoid them.  Lists like the OWASP Top Ten or the CWE/SANS Top 25 Most Dangerous Software Errors, can be very helpful as starting places.  However, they don’t cover everything.  You’ll almost certainly certainly want to have your developers take training classes from SANS and other organizations that specialize in teaching secure coding practices.

About 90% of the code in today’s applications is assembled from other sources.  You’ll need to monitor those sources, and when security patches come out, you’ll need to rate is severity, and apply it.  IT will need to do the same for the system software on the servers.  You’ll need a formal change control process.

Never use live PAN data for testing.  Remove test accounts before production.  Have separate development and production environments.

Requirement 7: Restrict access to cardholder data by business need to know

This requirement basically says to strongly limit access to card holder data.  Give users the least amount of privilege to get their jobs done.  By default, deny access unnless someone has a business need to access the data.  Document the roles of the people who access the data, and define access for each role.

Requirement 8: Identify and authenticate access to system components

This requirement has mostly to do with password and credential management.  Users need to have individual accounts; shared accounts are forbidden.   Passwords must be strong, and passwords must be changed every 90 days.  Strong cryptography must protect stored passwords.  Two factor authentication is required for remote access.  Third party accounts for support must be disabled when not in use.  Access to a database with card holder data should be restricted programs and database admins.

Requirement 9: Restrict physical access to cardholder data

PCI requires you to physically secure your facility.  You have to restrict physical access to your computers and network equipment.  You’ll need to have badges (or something similar) so you can quickly identify who is a visitor and who is an authorized employee.  When someone leaves, you’ll need to revoke their access immediately.

You’ll need special protocols for visitors.  They will have to be escorted at all time.  They will need to wear a badge (or something similar).  A visitor log will tell when they entered and left.

If backups and other media are stored offsite, then a secure location must be used.  A secure courier must be used to transport the media.  You’ll need an inventory log of all media.  When media is no longer needed, securely destroy it.

If you have a POS device that reads the cards, you’ll need to protect it from tampering or from being switched out.  You’ll also need to maintain a list of devices.  Inspect them periodically to look for skimmers or tampering.  Train your people to also look for problems.

Requirement 10: Track and monitor all access to network resources and cardholder data

PCI requires that you log access to card holder data and many security events, e.g. logins, creating new accounts, deleting accounts, elevating privilege, any action by privileged accounts, and so on.  All logs need to be sent to a central logger, and retained for one year.  Time must be synchronized on all systems to an industry standard source so the dates in the log files are reliable.  You’ll need to review these logs.

Requirement 11: Regularly test security systems and processes

You need to scan for unauthorized wireless access points, and have a plan to deal with them.  You’ll need to maintain an inventory of legitimate access points.

Run external and internal vulnerability scans at least once a quarter.  The external scan requires a PCI Approved Scanning Vendor (ASV).  Fix high risk problems, and rescan until there aren’t any more.

Penetration, external and internal, must also be done at least annually, and problems remediated.

If you make a significant change to your network or environment, do new scans and penetration testing.

Have an Intrusion Detection and/or Intrusion Prevention system.

Critical files on servers should have file integrity monitoring, so changes can be detected and personnel alerted.

Requirement 12: Maintain a policy that addresses information security for all personnel.

Write up your security policy, and review it annually  This has many details that are given in the PCI spec.  Give it to everyone involved in the cardholder environment.

Have a risk assessment plan, and perform a formal risk assessment at least once per year.

Have an Incident Response plan to respond to breaches.  Test it at least annually.  You’ll also need designated personnel to be available to respond 24×7.