This article offers an introduction to the security standards your customers must face including security best practices that will help protect them in the event of a breach:
- The importance of key management to protecting credit card numbers
- The importance of key management best practices to meeting compliance
- Important certifications including NIST and FIPS 140-2
Challenges and Best Practices of PCI DSS Payment Card Security
This article discusses PCI compliance and answers some of the common questions companies have about PCI audits. The PCI process can be confusing for companies preparing for their first audit. Our years of experience helping companies meet the encryption and key management requirements of PCI can help smooth your road to compliance.
What are PCI Data Security Standards?
The Payment Card Industry Data Security Standard (PCI DSS) is a set of rules established by The Council’s five founding global payment brands – American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. The Data Security Standard applies to organizations that store, process, or transmit cardholder data. These rules have been in place for several years and were originally required of large credit card processors, but were only recommendations for most merchants accepting credit cards. Now, both merchants and processors fall under the industry-wide PCI Data Security Standard. Additionally, the Council have incorporated PCI DSS as the technical requirements for their data security compliance programs.
Who is subject to PCI rules?
All merchants who store, process, or transmit cardholder data are subject to PCI compliance. Almost all card issuers reserve the right to require any merchant to meet the rules, which help prevent data loss and protect customer data. In the event of a data loss from failing to meet audit requirements, some merchants may be subject to financial penalties to acquirers who fail to meet PCI compliance. You should consult with your acquiring bank or processing vendor to determine your level of PCI compliance.
Even if you don’t accept and process credit card payments, there are good reasons to meet these rules. Complying with PCI will help in meeting other state and federal regulations for data security. These regulations include state privacy notification, HIPAA, Gramm Leach Bliley (GLBA), and others.
Where can I get information about the PCI Standard?
The PCI Data Security Standard is available from the PCI Security Standards Council web site at www.pcisecuritystandards.org. Each card issuer (Visa, Mastercard, etc.) can also provide you with information about the PCI data security standard. In addition to the PCI standard you can get information on how to start planning for the implementation, who can help you with compliance audits, and audit questionnaires that you conduct yourself.
Do I need to pass a PCI audit?
Level 1 merchants must pass an annual on site PCI audit from a Qualified Security Assessor (QSA). Level 2, 3, and 4 merchants must also report their compliance annually to their acquirer, but may do so by performing a self assessment and submitting their Self Assessment Questionnaire. It is recommended that you contact your acquirer for reporting responsibilities. To aid in this, the PCI SSC provides an Internal Security Assessor (ISA) certification that aims to train your internal staff on how to conduct a PCI audit. Any merchant, regardless of size, may be required to pass a PCI audit in the event of a data loss. The PCI Data Security Council publishes a list of companies who can perform a PCI assessment of your compliance with the data security rules.
I have credit card numbers in my database files. What next?
The first step is to become familiar with the PCI rules and guidelines. You can access these on the PCI web site or your acquirer or processor can provide you with a copy of the rules. If you are eligible to perform a self-assessment, there is a questionnaire on the PCI SSC website that is very helpful in identifying what SAQ and attestation requirements you are required to submit. These depend on how your organization processes cardholder data.
After you understand the requirements for PCI security, you should develop a plan for encrypting credit card numbers and other sensitive data. This means identifying which database files or SQL tables contain credit card numbers, what indexes use the credit card number, and what applications create or access the credit card number. You may need to remove indexes based on a credit card number, and develop an alternative method to access information. If your database does not support automated encryption, you may need to modify applications that insert credit card numbers into your database and which access credit card numbers for interactive and batch processing. Be sure to have a good map of your applications with all impacted programs identified.
Once you have a development plan you will engage in a normal application development and testing process to support encrypting and decrypting credit card numbers as needed. This should incorporate your company’s normal quality assurance process.
Our customer support applications do lookups by credit card number. How will these applications be impacted?
If your database does not support automatic encryption, you may need to create an alternative method for locating records in your database. If you are currently looking up records by credit card number, consider accessing records by customer name and date range (from date, to date). Or, you may be able to access records by customer name and zip code. By eliminating the credit card number from the access logic you can create a much smaller set of records, and then decrypt and display the credit card number as needed.
The PCI rules allow you to store the last four digits of a card number in the clear. One method of locating a credit card number in your database is to store the last four digits, select a record set based on these last digits, and then decrypt the credit card number for records of interest. This would be an alternative to using the name and date range.
What is tokenization and will it help me avoid a PCI audit?
Tokenization is the process of replacing a credit card number with a bogus replacement number. Usually there is a repository that contains the original credit card number allowing an association between the token and the original credit card number. Using tokens can help simplify the PCI compliance process, but does not relieve you of PCI requirements. If the token is stored on your systems (not at a payment network) you have the same PCI requirements for encryption and key management. For businesses with an IBM i, Townsend Security can help with tokenization.
Is there other information that I need to secure?
The PCI rules require that you protect cardholder data. This includes credit card PAN, cardholder name, expiration date, and service code. It should be noted that encrypting this data does not remove it from scope of the PCI audit. Sensitive Authorization Data (SAD), which encompasses the full magnetic stripe data (CAV2/CVC2/CID, PINs/Pinblocks) must also be protected. The SAD may not be stored after processing or transmission of the cardholder data. This includes incoming transaction data, all logs, trace files, database contents and schemes, etc.
Looking beyond the requirements of PCI, you should take steps to protect customer PII. This might include a zip code, home phone number, social security number, check number, birth place, birth date and other fields commonly used for identification and subject to identity theft. While PCI does not require that you secure these types of fields, you should consider securing them to insure the maximum privacy of customer information, and to reduce legal liability
What is AES encryption and why is it important?
AES is the acronym for the Advanced Encryption Standard. This is the encryption method adopted by the National Institute of Standards and Technology (www.nist.gov). It is now the federal standard for encryption (FIPS-197) and has replaced Triple DES encryption as the industry standard. Because AES is a federal standard, it has been accepted by HIPAA and other agencies for use in securing sensitive information. Just as PCI DSS is recommending AES for strong encryption, it is likely that further federal and state regulations will incorporate AES. By implementing AES now you can meet future security requirements. It is important to look beyond PCI. Federal and state regulations related to privacy notification and security practices also mandate the use of data encryption, and new regulations are being formulated now. By using AES as your encryption method you will probably avoid future re-work to meet these new regulations. By deploying AES encryption you will also help your corporate legal team mitigate future legal liability concerns. Basing your implementation on published federal standards is a smart decision.
Are there differences in AES Key Sizes?
Yes, AES encryption supports different key sizes including 128-bit, 192-bit, and 256-bit keys. The Alliance AES encryption products from Townsend Security implement all of the key sizes of AES encryption to insure the strongest encryption level.
Are there differences in how AES encryption is implemented?
The modes most commonly used to protect sensitive information in databases are Cipherblock Chaining (CBC), Counter (CTR), and Cipher Feedback (CFB). Most AES encryption applications use the CBC or CTR mode. The CBC mode requires that data be expanded to align on a 16-byte boundary. The CTR mode allows any length of data for encryption and returns the same length for encrypted data.
When you have small fields like credit card numbers in multiple records in a database file, it is important to use the proper mode to insure the strength of the encryption. By using AES CBC or CTR modes the data in each field you encrypt is secure even if you have the same values in different records. These modes introduce additional initialization vector information on each encryption request. This means that the same credit card number in different fields will encrypt to a different value.
Can I use other encryption algorithms such as RC2, RC4, or Twofish?
AES encryption is not the only encryption algorithm that provides strong encryption. There are other encryption algorithms that can be used to secure your data. However, AES encryption is the current federal standard, and likely to be the basis for future state and federal regulations. AES encryption is the only algorithm that has a federally supported certification process. When you consider all of the reasons you want to encrypt data (PCI compliance, Sarbanes-Oxley (SOX), state privacy notification, legal liability limitation, etc.) choosing an AES encryption solution that is based on NIST standards is the right decision.
What is key management and why is it important?
Encryption requires the use of keys as a part of the encryption process. It is very important to secure the key from loss just as you would secure your server passwords. You would want to avoid storing your encryption key in source code, storing it in the clear in a database file, or giving access to the key to unauthorized users. For users new to system security and encryption the importance of key management is often overlooked.
You should be sure that your keys are stored in a secure manner, and that access to these keys is restricted to appropriate users. The storage mechanism should provide a means of avoiding the display of the key in application code, or in the clear in database files. The PCI rules make several recommendations on how keys should be stored.
Do I have to store my keys in hardware?
No, this is not a requirement of the PCI DSS. The best way to store encryption keys is on a separate server with proper key protections. If a server is compromised you will not expose the encryption keys to loss. Townsend Security can provide you with server-based key management solutions.
What impact will encryption have on my existing applications and system resources?
Most modern database systems support automatic encryption and you won’t need to modify your applications. If your database does not support automatic encryption it is almost certain that you will need to modify some applications that access the credit card number. Any application that adds a record to a database file or table will need to secure the data before the record is inserted. Any application that uses the credit card number for display on a report, transmission to the processor during settlement, or other use, will need to be modified to decrypt the data as needed.
All encryption routines require additional CPU resources to secure data. You should avoid a large number of decryption tasks in interactive applications. You should also avoid decrypting all records in a file in batch processes when the credit card number is not required. These steps will minimize the impact on applications and system resources.
Can I use Stored Procedures to secure credit card numbers?
If you use triggers or stored procedures you should implement proper user access controls. A trigger will be activated when any application or utility is used to access the file. For example, if you use FTP to transfer a file to another platform, the trigger application will be activated to decrypt a field. This defeats the intent of the security and may result in little additional security of your data.
In addition to the security concerns, triggers and Stored Procedures may be activated when encryption services are not needed, resulting in overuse of system resources. Running a query on a secure database with triggers can be a very expensive process in terms of system resources! If you do decide to use triggers or Stored Procedures for encryption and decryption tasks, be sure to implement proper access controls.
What do I need to do about my Point of Sale systems?
Your POS systems should be reviewed for security in the same way as your server applications. Most POS systems do not store credit card numbers in the clear. You should discuss this with your POS vendor.
If you transfer data from your POS system to your server system on a daily basis, you should review the transfer process to verify that it is secure. If you use a public network for the transfer, consider implementing secure VPN, TLS (1.1 & 1.2), or other secure transfer mechanisms to secure the data.
The Alliance AES Encryption products by Townsend Security provide support for platforms including Microsoft Windows, UNIX, Linux, IBM i (AS400), and IBM z (mainframe). If your POS system is using Windows, Linux or UNIX for its operating system, the Alliance AES encryption software may be able to help you with this data security.
How can I secure my tape backups?
If you have properly secured sensitive data in your server database files, you will probably feel secure about your existing backup routines. However, if you have sensitive data in your server tables that is not encrypted, you should deploy a backup encryption solution. This will be either a hardware device or software solution designed to secure backups to tape.
What part do state privacy notification laws play in PCI?
Most states have passed privacy notification laws. These laws require the protection of credit card numbers as well as other non-payment related information such as social security numbers. There is no direct relationship between PCI rules and the state privacy notification laws. The PCI rules are payment card industry rules required for any entity that stores, processes or transmits cardholder data. You are obligated to follow these rules as a part of your merchant agreement. State notification laws apply to a much broader set of companies handling sensitive information. If sensitive information, such as credit card numbers or social security numbers, is lost or may have been lost, these laws require that you notify anyone who may be affected. There is quite a broad definition of sensitive information, and most companies will begin the notification process on any suspicion that an individual’s private information may have been compromised.
What part does Sarbanes-Oxley and Gramm Leach Bliley play in PCI?
There is no direct relationship between Sarbanes Oxley or GLBA, and PCI. However, there are many IT security requirements in the Sarbanes-Oxley Act. You can be sure that securing all sensitive information in your server database files will fall under the purview of a SOX audit.
What experience does Townsend Security have with PCI?
Townsend Security is a PCI Participating Organization and works with the council to evolve the PCI Data Security Standard (DSS) and other payment card data protection standards. Data security is an integral part of our solutions and the company has been helping its customers meet data security requirements from the very beginning.
I am an independent software vendor (ISV). How can I secure information in our applications?
Townsend Security has a dedicated partner program for ISVs. This program provides you with implementation support, development assistance, special pricing, and product distribution. You can request information through our website.
Source: Townsend Security
