There are many good reasons to protect the sensitive data that is in your database: government regulation, corporate policy, managing legal liability and simply being a good steward of the information that has been entrusted to you. There are also industry standards defined and enforced by non-governmental agencies that dictate the management of sensitive data. The Payment Card Industry Security Standards Council (PCI) is an example of such an organization.

PCI is an organization that is comprised of representatives from American Express, Discover Financial Services, Master Card, Visa and JCB International for the purpose of establishment and enforcement of data security standards in regard to payment card data. It is through their data security standard (DSS) that they provide guidelines that aid in the consistent protection of this type of sensitive data.

In the PCI DSS there are twelve requirements that must be adhered to for any business that handles or stores data that is in relation to payment card data. Details of each of these twelve requirements can be found in their document titled: "Navigating PCI DSS".

For our interest as a DBA, the third requirement titled "Protect stored cardholder data" addresses the concerns of how the sensitive data that is involved in a transaction is stored. The PCI DSS specifically defines the following pieces of information as sensitive:

• Cardholder's name: This is located on the face of the card and identifies the owner of the credit account.
• Primary account number (PAN): This is located on the face of the card and identifies the account in which a payment is processed.
• Expiration date: This is located on the face of the card. This value indicates when the card expires.
• Service code: Found within the magnetic strip. Defines acceptance requirements for the card. This is a three or four digit number.
• Authentication data: This includes the full contents of the magnetic strip and the verification code which is located on the back of the card. The personal identification number (PIN) which is keyed by the card holder and contained within the magnetic strip is also considered in this category.

The development of a system in which payment cards are used requires careful consideration of the data that is to be stored within various means of storage be it a database, cookies, or cache. For PCI DSS compliance the items defined as "authentication data" cannot not be stored beyond the duration of a payment card transaction. This includes the full content of the magnetic strip, the verification code and the personal identification number (PIN).

The primary account number (PAN) can be stored after the payment card transaction; but it must be obfuscated through the use of encryption, truncation or other hashing methods. PCI DSS presents their requirements in a product agnostic manner, as they should. As Microsoft SQL Server DBAs one approach might be to encrypt the PAN by implementing the Transparent Data Encryption (TDE) feature of SQL Server 2008 rather than implementing encryption at the cell-level. If TDE is used then the access to the PAN must be through an account other than a local user account.

If the cardholder's name, service code and expiration date is stored with the PAN additional protection efforts are required for this data. Storage of these pieces of data independently from the PAN require no additional protection for PCI DSS purposes. Therefore, careful consideration of the storage schema of these elements can reduce the complexity of the storage of this information.

With the implementation of encryption comes the responsibility of key management. The importance of limiting the access to the keys that are used to decrypt the cipher text maintains the effectiveness of the encryption effort. Limiting the locations in which the key backups are stored not only ensures that when the need arises to restore a key that you have the most recent backup, it also is a way to limit who can obtain and restore the backup files.

Encryption keys are not a "set it and forget it" feature. PCI DSS requires that the keys used for encryption be changed at least once a year. SQL Server does not offer native functionality of key lifecycle management; although, in SQL Server 2008 the introduction of Extensible Key Management (EKM) does provide a means to integrate a third party product that provides this function.

On the surface an industry standard may not have as much teeth behind them as a government regulation. In some cases this may be true depending upon the goals of establishing the standard. In the case of PCI DSS the consequences to non-compliance is considerable. In addition to a $500K fine per incident of non-compliance, the business could be denied the ability to process payment card transactions which is a competitive vulnerability.

This was a cursory overview of requirement 3 of PCI DSS. To get more specifics on what can be done through SQL Server in regard to all of the PCI DSS requirements check out the one hour "SQL Server 2008 Capabilities for Meeting PCI Compliance Needs" webcast on TechNet.