08-30-10 | Blog Post
Online Tech brings you a new series on PCI Compliance by Adam Goslin, Co-Founder of High Bit Security, a full service security company specializing in Payment Card Industry Data Security Standards Compliance and Penetration Testing. PCI compliant hosting is important for all of our clients who hold and handle credit card information. The series will explain the six objectives of PCI DSS and how to maintain PCI compliance for your company. We hope that you find it useful and we welcome your feedback.
The next installment in this series covers the second principle of PCI DSS compliance – Protect Cardholder Data.
This principle literally sets the tone for your entire PCI DSS compliance effort scope. For those commencing with Payment Card Industry Data Security Standard compliance, your first objective should be to mitigate and preferably avoid the storage (in any form), receipt (in any form) and transmission (in any form) of cardholder data. Further, one should take steps to minimize the number of physical / logical devices within the cardholder data environment.
Of course, this begs the question “What is cardholder data?”. Cardholder data is comprised of the card number on the front of the card; the magnetic stripe data captured when the card is swiped and the security code (3-4 digit code also known as the card-verification code or value) imprinted on the reverse side of the physical card and the personal identification number (PIN).
Consultation with a firm experienced with the PCI DSS requirements is a critical step early in your compliance objective to minimize your scope and streamline your implementation. Minimization of both cardholder data stored, and the amount of time the data is stored (retention period) is key. The storage of sensitive authentication data after authorization is prohibited; this includes storage of: the magnetic stripe data, card-verification code or value (CVC / CVV), personal identification number (PIN).
Whenever the card number (also known as primary account number or PAN) is displayed, it must be masked. For ease, most organizations will display account numbers as XXXX-XXXX-XXXX-1234, and this requirement applies to any situation where the card number is displayed – physical or electronic.
Should the card number be stored, you’re required to render the card number unreadable (encrypted) when stored. There are several methods one can leverage to accomplish this goal, including encryption of each individual value, encryption of a column in the database, encryption of the file leveraged for storage or encryption of the entire disk. Selection of the encryption approach really depends on your particular situation, and should be considered carefully before making a snap decision as there may be ramifications that impact your application layer, middleware and encryption authentication requirements.
Any form of encryption that is needed as a result of having cardholder data stored will also require you to establish an encryption key management program that will be required to be included in your policies, limit number of locations of key storage, and limit the number of key custodians (people with access to any portion of the cryptographic keys). For the key management requirements of PCI DSS, there are several requirements from a process / policy perspective that need to be addressed and numerous possibilities for maintaining compliance.
Whenever transmission of cardholder data is required across an open, public network (the Internet) that transmission must leverage strong encryption and security protocols such as SSL / TLS or IPSEC. An example of SSL would be the electronic transmission of web based traffic, such as when you log into your web based banking interface and the URL is begins with HTTPS:// and the lock is showing on your web browser. An example of IPSEC could be a situation where your organization requires an encrypted tunnel from your firewall to the firewall of one of your customers.
There are numerous requirements for the deployment of wireless technology when that technology is transmitting cardholder data or connected to the cardholder data environment. Unless your implementation specifically requires wireless technology, there are numerous advantages to avoiding the implementation of wireless. However, if you do require wireless technology for your environment it would be strongly recommended to consult with an expert regarding your specific needs.
Lastly, your policies need to prohibit the unencrypted sending of cardholder data through end-user messaging technologies such as email, instant messaging, chat. Unless your business requires the encrypted transmission of cardholder data through such end-user messaging technologies, complexities of policies and procedures are streamlined by a business stance that indicates all transmission of cardholder data via end-user messaging is prohibited.
In the next blog posting, we will cover “Maintain a Vulnerability Management Program”.
Adam Goslin, Co-Founder, High Bit Security, LLC
Adam has an IT career that spans more than 15 years, recently leading the IT and Infrastructure teams of Osiris Innovations Group as the Vice-President of IT, including leading the company through achieving PCI DSS Compliance. Adam went on to found the full service security firm, High Bit Security, LLC., specializing in assisting companies looking to achieve Payment Card Industry Data Security Standards compliance; and cost effective Penetration Testing.
For more information about PCI compliance, you can email Adam at agoslin at highbitsecurity.com
Online Tech brings you a new series on PCI Compliance by Adam Goslin, Co-Founder of High Bit Security, a full service security company specializing in Payment Card Industry Data Security Standards Compliance and Penetration Testing. PCI compliant hosting is important for all of our clients who hold and handle credit card information. The series will explain the six objectives of PCI DSS and how to maintain PCI compliance for your company. We hope that you find it useful and we welcome your feedback.
The next installment in this series covers the second principle of PCI DSS compliance – Protect Cardholder Data.
This principle literally sets the tone for your entire PCI DSS compliance effort scope. For those commencing with Payment Card Industry Data Security Standard compliance, your first objective should be to mitigate and preferably avoid the storage (in any form), receipt (in any form) and transmission (in any form) of cardholder data. Further, one should take steps to minimize the number of physical / logical devices within the cardholder data environment.
Of course, this begs the question “What is cardholder data?”. Cardholder data is comprised of the card number on the front of the card; the magnetic stripe data captured when the card is swiped and the security code (3-4 digit code also known as the card-verification code or value) imprinted on the reverse side of the physical card and the personal identification number (PIN).
Consultation with a firm experienced with the PCI DSS requirements is a critical step early in your compliance objective to minimize your scope and streamline your implementation. Minimization of both cardholder data stored, and the amount of time the data is stored (retention period) is key. The storage of sensitive authentication data after authorization is prohibited; this includes storage of: the magnetic stripe data, card-verification code or value (CVC / CVV), personal identification number (PIN).
Whenever the card number (also known as primary account number or PAN) is displayed, it must be masked. For ease, most organizations will display account numbers as XXXX-XXXX-XXXX-1234, and this requirement applies to any situation where the card number is displayed – physical or electronic.
Should the card number be stored, you’re required to render the card number unreadable (encrypted) when stored. There are several methods one can leverage to accomplish this goal, including encryption of each individual value, encryption of a column in the database, encryption of the file leveraged for storage or encryption of the entire disk. Selection of the encryption approach really depends on your particular situation, and should be considered carefully before making a snap decision as there may be ramifications that impact your application layer, middleware and encryption authentication requirements.
Any form of encryption that is needed as a result of having cardholder data stored will also require you to establish an encryption key management program that will be required to be included in your policies, limit number of locations of key storage, and limit the number of key custodians (people with access to any portion of the cryptographic keys). For the key management requirements of PCI DSS, there are several requirements from a process / policy perspective that need to be addressed and numerous possibilities for maintaining compliance.
Whenever transmission of cardholder data is required across an open, public network (the Internet) that transmission must leverage strong encryption and security protocols such as SSL / TLS or IPSEC. An example of SSL would be the electronic transmission of web based traffic, such as when you log into your web based banking interface and the URL is begins with HTTPS:// and the lock is showing on your web browser. An example of IPSEC could be a situation where your organization requires an encrypted tunnel from your firewall to the firewall of one of your customers.
There are numerous requirements for the deployment of wireless technology when that technology is transmitting cardholder data or connected to the cardholder data environment. Unless your implementation specifically requires wireless technology, there are numerous advantages to avoiding the implementation of wireless. However, if you do require wireless technology for your environment it would be strongly recommended to consult with an expert regarding your specific needs.
Lastly, your policies need to prohibit the unencrypted sending of cardholder data through end-user messaging technologies such as email, instant messaging, chat. Unless your business requires the encrypted transmission of cardholder data through such end-user messaging technologies, complexities of policies and procedures are streamlined by a business stance that indicates all transmission of cardholder data via end-user messaging is prohibited.
In the next blog posting, we will cover “Maintain a Vulnerability Management Program”.
Adam Goslin, Co-Founder, High Bit Security, LLC
Adam has an IT career that spans more than 15 years, recently leading the IT and Infrastructure teams of Osiris Innovations Group as the Vice-President of IT, including leading the company through achieving PCI DSS Compliance. Adam went on to found the full service security firm, High Bit Security, LLC., specializing in assisting companies looking to achieve Payment Card Industry Data Security Standards compliance; and cost effective Penetration Testing.
For more information about PCI compliance, you can email Adam at [email protected]
