Friday, March 09, 2007

PCI Compliance Part 3 - Don't lose that credit card data!

Two weeks ago, I discussed what PCI Compliance is and where it came from. Last week, we reviewed the first 6 requirements of the PCI Data Security Standards (DSS). Today we'll finish this series with an explanation of what requirements 7-12 do to protect your clients' cardholder information.

Implement Strong Access Control Measures

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

This sounds like a page out of a classic spy novel, but the principle of "need-to-know" is a foundation of good security. Only users who specifically need access to credit card data should have access to the system that contains that data. If a user has access to other parts of the system, then by default they should not have access to unencrypted, sensitive credit card data. Lastly, administrators should grant access to cardholder information only to the minimum number of users who specifically need to see that information for a legitimate business reason that has no alternative.

In Certain Registration, for example, some meeting planners still collect credit card numbers from their attendees in order to "guarantee" their room reservation. These planners need to deliver the unencrypted credit card number to the hotel if the registrant is a "no-show" for the room, thus they have a legitimate business reason to view the full credit card number and their User access can be granted permission to see those numbers. However, all other users will only see the last four digits of the credit card number if they attempt to view the same reports.

In the near future, as more companies adopt PCI compliance, I suspect that no hotels will be willing to receive a list of unencrypted credit card numbers and will thus require room blocks to be guaranteed against the master account. Then the current "legitimate business need" to view these numbers will disappear, and such access can be ended. In this case, the planner can still store the credit card information in encrypted, unreadable format, and they can charge the registrant's card if they are a no-show without any human being able to read the cardholder data.

Requirement 8: Assign a unique ID to each person with computer access

If you are going to restrict access to data via an authentication scheme (such as username/password), then each individual person must have their own authentication. If multiple people share a single username, for example, then the system cannot audit which person made specific actions, only which username made those actions.

In order to make sure that only the intended user has access to a given username / password combination, PCI places multiple restrictions on systems:

  • Passwords must be at least 7 characters long, with a combination of alphabetical and numeric characters
  • Every 90 days, passwords must be changed and inactive user accounts must be removed
  • The user must be authenticated prior to changing or resetting passwords, e.g. by sending a temporary password to the User's email address
  • User sessions without activity for 15 minutes must be automatically timed out and require login to re-start

Some of these security requirements, such as the 15-minute timeout rule, can be annoying for users who don't need access to credit card information. Thus our system gives those users the options to adhere to a less restrictive security policy - but they cannot view credit card data. Any user who can view cardholder data must adhere to the PCI guidelines and live with its inconveniences.

Requirement 9: Restrict physical access to cardholder data

PCI requires companies to control physical access to cardholder data; this includes access to the database servers, backup media files (which are often stored offsite), paper hardcopies, etc. Modern Network Operations Centers (NOC), such as ours at NTT Verio, provide this control through 24/7 security, photo-badges with biometric hand scans, individual cages and cabinets, and constant video monitoring.

Regularly Monitor and Test Networks

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

PCI requires us to log all activities related to accessing cardholder data, plus all activity related to controlling access to that data. So everytime an Administrator creates a new user with access to cardholder information, we record the action in a log. If a user runs a report with cardholder data, the action (and content of the report) is logged. These logs cannot be deleted by Administrators, and are available online for a year after the action occurred.

Requirement 11: Regularly test security systems and processes

Periodically, security vulnerabilities appear due to new techniques discovered by hackers or researchers or software updates. PCI requires adherants to monitor critical files for changes, scan internal and external network vulnerability quarterly, and perform annual detailed security tests on all systems.

In addition, networks need to have an "Intrusion Detection System" (IDS), which is basically an observation post that watches the data traffic flowing through your network and looks for patterns that indicate malicious data attacks or a security compromise.

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security

Companies that collect cardholder information must publish written security policies that adhere to PCI compliance. The policy should be known by all employees and contractors, and any outside vendors who receive cardholder information must also be PCI compliant.

Since most data security breeches are caused by internal behavior, all employees who have access to credit card information in bulk format must be screened prior to hiring. For example, we perform credit checks and criminal checks on employees as part of the hiring process.

No comments: