Trying to comply with the Payment Card Industry Data Security Standard can be intimidating because it is a highly prescriptive, broad-reaching set of requirements, potentially including all of your information systems in its scope.
Trying to comply with the Payment Card Industry Data Security Standard can be intimidating because it is a highly prescriptive, broad-reaching set of requirements, potentially including all of your information systems in its scope.
Although the PCI Security Standards Council defines and builds the global PCI DSS, each card brand — Visa, MasterCard, Discover, American Express, JCB International — enforces it via its compliance program and dictates the validation steps and documentation required to show compliance. Even though you obtain “PCI compliance” by passing a PCI audit and filing the required paperwork, each brand maintains its own tracking, penalties, fees, rewards and acceptance process for compliance filings.
Generally, if you store, process or transmit cardholder data — such as a primary account number — from any brand, you must comply with PCI DSS and the brand’s compliance program. This includes merchants, banks and service providers from all industries, including bricks-and-mortar retailers with point-of-sale terminals, mail order/telephone order merchants, payment gateways, transaction processors and credit-reporting services. Brand-specific documentation requirements and compliance levels may be found on each brand’s Web site.
The 12 requirements
The PCI DSS requirements apply to all system components, which are defined as “any network component, server or application that is included in or connected to the cardholder data environment.”
The DSS specifies which cardholder data must be protected if stored, and which cardholder data is not allowed to be stored at all once the card has been authorized, such as the card validation value or code, the PIN or PIN block, and the full magnetic stripe.
Storage of the primary account number, cardholder name, service code and expiration date is allowed if that data is sufficiently protected as specified in the DSS. However, you should carefully consider whether you need to store cardholder data at all. You shouldn’t store cardholder data you don’t absolutely need to conduct business and process transactions; further, you should store it only for as long as you need it.
The 12 PCI DSS requirements are grouped into six categories created by the PCI Security Standards Council: 1. Build and maintain a secure network; 2. Protect cardholder data; 3. Vulnerability management program; 4. Implement strong access control measures; 5. Monitor and test networks; and 6. Maintain an information security policy.
The key to mastering the PCI audit and staying compliant involves proper management of three major areas: policy; network segmentation; and applications, vulnerability management and testing.
When put into practice effectively, these focal areas can help you define, implement, enforce and maintain a strong information-security program, and become PCI compliant in the process.
Policy is the foundation upon which a stable, maintainable information security program is built. Proactive and progressive organizations see the PCI compliance requirements as a catalyst for adopting a philosophy where security is the objective and PCI compliance is achieved in the process.
For policies to be useful, you must tailor them to your business; they must address your specific business needs, processes, assets and environment. The primary objective of creating security policy is to ensure that your business-protection needs are being met. When creating the policy to satisfy that objective you must structure your policies so they can be implemented and enforced.
Taking the relevant factors in a risk-management process and applying them to PCI compliance yields the following basic steps you should take:
* Identify your information and data assets.
* Define your risk tolerance (the tipping point where less risk is too expensive and more risk is unacceptable).
* Identify access controls and handling practices for your data — who has access and what can they do?
* Decide how you want to protect your assets and to what extent. This should include an incident-response plan and the definition of consequences so when implemented you can enforce it.
* Communicate and share your policy information — educate your organization on your information-security policy.
* Iterate the policy as needed (ideally based on feedback from step 5).
* Implement, monitor and enforce.
* Compare your policy to PCI requirement 12 (see below).
The result of this process will be the construction of a policy baseline — a foundation that sets off boundaries for acceptable data handling across your organization. Expected results include better business relationships and communication among groups, the ability to analyze your information-security state, security awareness throughout your organization, and a consistency with which to measure and test your information-security practices.
Finally, note that the 12 PCI DSS requirements correspond to 233 auditable statements and testing-procedure validations. Requirement 12, “Maintain a policy that addresses information security,” comprises 39 of these statements, while many of the others will correspond directly to elements of your information-security policy.
Excerpted from Building a Sustainable Information Security Program and Obtaining PCI Compliance along the Way by Ed Adams, CEO of Security Innovation, and Michael Gavin, a security strategist at Security Innovation.
