Get started Bring yourself up to speed with our introductory content.

PCI DSS Requirement 3: Protecting stored data

One of the biggest problems with PCI DSS requirement 3 is that merchants must accurately know where credit card data flows from its inception, where it traverses the network and resides, and what its "state" is along the way. Craig Norris explains how to follow your data and leap over a common PCI hurdle.

From the very instant that a merchant receives a customer's credit card information, all of the card data must...

be encrypted. In a National Federation of Independent Business/Visa survey that was presented at Visa's March 2007 conference, small business owners said that they believe they are doing a good job of securing customer data, despite frequent evidence to the contrary. Among the respondents that said they retained their customers' data, more than 25% kept customer records in unsecured files, and 36% of those surveyed accepted credit card numbers at their stores.

One of the biggest problems with this requirement is that merchants must accurately know where credit card data flows from its inception, where it traverses the network and resides, and what its "state" is along the way. This is why it is critical to identify and examine all desktops, laptops, servers and databases that handle any type of cardholder information. This includes all of the database files and/or SQL tables that contain credit card numbers, not to mention all of the application systems that create or access credit card numbers. No matter what type of system touches the credit card information, it must be protected by encryption.

How to pass PCI requirement 3:

As mentioned above, start identifying all of the systems that touch cardholder data because these systems will be included in the scope of an eventual PCI DSS audit or compliance validation. It is also important to understand the compartmentalization of the cardholder systems and how they are using firewalls and network filter controls. Such an arrangement may dictate if nearby systems would also be within the scope of a PCI DSS compliance validation. You may be surprised to find out that the total number of systems retaining cardholder data -- including data warehouses, development servers, middleware and backup systems -- is quite large.

If you are not confident in your IT department's ability to accurately identify sensitive data, there are very good data loss prevention tools that can assist in this effort. These tools are designed to sift through data across the enterprise and accurately report on which systems house it, where it is on the system and who has access to it. Once known, review the organization's access controls to enforce "need to know" policies. Also, see if it is possible to minimize how many and which systems have this sensitive information.


  Requirement 3: Protecting stored data
  Requirement 11: Regularly test security systems and processes
  Requirement 8: Assign a unique ID to users
  Requirement 10: Monitor access to network resources and data
  Requirement 1: Install and maintain a firewall configuration

Craig Norris, CISSP, CISA, G7799, MCSE, Security+, CAPM, TICSA, is a Regional Engagement Manager at an IT consulting firm in Dallas. He has been involved with information technology and security for over 12 years. He can be contacted via [email protected].
Next, document the flow of credit card data throughout your organization and identify the business functions. The marketing department, for example, may need customer data, but not the associated credit card information. Track data from the point of acquisition -- even from customers or 3rd parties -- to the point where the data is disposed of or leaves the corporate network. Also be sure to identify all of the computers and networks that connect to the organization's infrastructure and applications. These can include network connections from business units, vendors, partners and the systems of remote employees. All fluid credit card data should be encrypted using methods such as SSH, VPN, or SSL/TLS for encryption.
This was last published in September 2007

Dig Deeper on IT security audits and audit frameworks