PCI Compliance
Ben Rothke writes "It has long
been rumored that manufacturers of items such as razors and batteries
specifically produce their products to an inferior level in order to ensure repeat
business. A similar paradox is occurring in the
information security space where many are complaining that the PCI Data Security Standard (PCI DSS) is too complex and costly. What is most troubling is that such opinions
are being written in periodicals and by people that should know better." Read on for the rest of Ben's review.
PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance
author
Tony Bradley
pages
352
publisher
Syngress
rating
9
reviewer
Ben Rothke
ISBN
1597491659
summary
Great for anyone who has PCI responsibilities or wants to gain a quick understanding of the PCI DSS requirements.
PCI came to life when Visa, MasterCard, American Express, Diner's Club, Discover, and JCB collaborated to create a new set of standards to deal with credit card fraud. PCI requires that all merchants and service providers that handle, transmit, store or process information concerning any of these cards, or related card data, be required to be compliant with the PCI DSS. If they are not compliant, they can face monetary penalties and/or have their card processing privileges terminated by the credit card issuers.
The primary purpose of PCI is to force organizations to embrace common security controls to protect credit card data and reduce fraud and theft. The following are the six primary control areas and 12 specific requirements of the PCI DSS:
Build and maintain a secure network
1. Install and maintain firewall configurations
2. Do not use vendor-supplied or default passwords
Protect cardholder data
3. Protect stored data
4. Encrypt transmissions of cardholder data across public networks
Maintain a vulnerability management program
5. Use and regularly update anti-virus software
6. Develop and maintain secure systems and applications
Implement Strong Access Control Measures
7. Restrict access to need-to-know
8. Assign unique IDs to each person with computer access
9. Restrict physical access to cardholder data
Regularly monitor and test networks
10. Monitor and track all access to network resources and cardholder data
11. Regularly test security systems and processes
Maintain an information security policy
12. Maintain a policy that addresses information security
A quick review of these 12 items shows that PCI is a textbook example of the fundamentals of information security. With that, PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance is an excellent resource that provides the reader with all of the fundamental information needed to understand and implement PCI DSS.
The books 13 chapters provide the reader with a comprehensive overview of all of the details and requirements of PCI. The first three chapters provide an overview of the basics about PCI and the basic requirements of the standard. The following six chapters go into detail about each of the primary control areas.
In particular, chapter 6 provides a good overview of the PCI logging requirements. This requirement can be time-consuming to put into place. The author notes that a commonly overlooked but essential requirement, namely that of accurate and synchronized time on network devices. Enterprise information network and security infrastructure devices are highly dependent on synchronized time and PCI recognizes that correct time is critical for transactions across a network.
In a further discussion about synchronized time in chapter 9, the author unfortunately makes an error when he states that local hardware is considered a stratum 1 time source since it gets its time from its own CMOS. From an NTP perspective, only a device that is directly linked to a stratum-0 device is called a stratum-1. CMOS clocks are notoriously inaccurate and can't be relied upon.
The title of chapter 12 is both amusing and accurate 'Planning to fail your first Audit'. The irony is that so many organizations lack a CISO or formal business security program in place designed to protect corporate information assets. They don't focus on information security as a process, rather as a set of products or regulatory items to be checked-off. Yet, these same organizations are surprised when they fail an audit.
The book concludes in chapter 13 with the well-known observation that security is a process, not an event. The book astutely notes that it is impossible to be PCI compliant without approaching security as a process. Trying to achieve compliance without integrating the various aspects in an integrated fashion is bound to fail.
Overall, PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance is a great book for one of the most sensible security standards ever. Anyone who has PCI responsibilities or wants to gain a quick understanding of the PCI DSS requirements will find the book to be quite valuable.
Ben Rothke is a security consultant with BT INS and the author of Computer Security: 20 Things Every Employee Should Know
You can purchase PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
PCI came to life when Visa, MasterCard, American Express, Diner's Club, Discover, and JCB collaborated to create a new set of standards to deal with credit card fraud. PCI requires that all merchants and service providers that handle, transmit, store or process information concerning any of these cards, or related card data, be required to be compliant with the PCI DSS. If they are not compliant, they can face monetary penalties and/or have their card processing privileges terminated by the credit card issuers.
The primary purpose of PCI is to force organizations to embrace common security controls to protect credit card data and reduce fraud and theft. The following are the six primary control areas and 12 specific requirements of the PCI DSS:
Build and maintain a secure network
1. Install and maintain firewall configurations
2. Do not use vendor-supplied or default passwords
Protect cardholder data
3. Protect stored data
4. Encrypt transmissions of cardholder data across public networks
Maintain a vulnerability management program
5. Use and regularly update anti-virus software
6. Develop and maintain secure systems and applications
Implement Strong Access Control Measures
7. Restrict access to need-to-know
8. Assign unique IDs to each person with computer access
9. Restrict physical access to cardholder data
Regularly monitor and test networks
10. Monitor and track all access to network resources and cardholder data
11. Regularly test security systems and processes
Maintain an information security policy
12. Maintain a policy that addresses information security
A quick review of these 12 items shows that PCI is a textbook example of the fundamentals of information security. With that, PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance is an excellent resource that provides the reader with all of the fundamental information needed to understand and implement PCI DSS.
The books 13 chapters provide the reader with a comprehensive overview of all of the details and requirements of PCI. The first three chapters provide an overview of the basics about PCI and the basic requirements of the standard. The following six chapters go into detail about each of the primary control areas.
In particular, chapter 6 provides a good overview of the PCI logging requirements. This requirement can be time-consuming to put into place. The author notes that a commonly overlooked but essential requirement, namely that of accurate and synchronized time on network devices. Enterprise information network and security infrastructure devices are highly dependent on synchronized time and PCI recognizes that correct time is critical for transactions across a network.
In a further discussion about synchronized time in chapter 9, the author unfortunately makes an error when he states that local hardware is considered a stratum 1 time source since it gets its time from its own CMOS. From an NTP perspective, only a device that is directly linked to a stratum-0 device is called a stratum-1. CMOS clocks are notoriously inaccurate and can't be relied upon.
The title of chapter 12 is both amusing and accurate 'Planning to fail your first Audit'. The irony is that so many organizations lack a CISO or formal business security program in place designed to protect corporate information assets. They don't focus on information security as a process, rather as a set of products or regulatory items to be checked-off. Yet, these same organizations are surprised when they fail an audit.
The book concludes in chapter 13 with the well-known observation that security is a process, not an event. The book astutely notes that it is impossible to be PCI compliant without approaching security as a process. Trying to achieve compliance without integrating the various aspects in an integrated fashion is bound to fail.
Overall, PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance is a great book for one of the most sensible security standards ever. Anyone who has PCI responsibilities or wants to gain a quick understanding of the PCI DSS requirements will find the book to be quite valuable.
Ben Rothke is a security consultant with BT INS and the author of Computer Security: 20 Things Every Employee Should Know
You can purchase PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I don't think this is talking about the "PCI" that most of us know and love... :-O
TMA!
It's "Payment Card Industry" (maybe in the USA this is a common term, but I've never heard it in the UK, to my knowledge). From the summary, I thought it was some kind of PCI (Peripheral Component Interconnect) bus level security (i.e. encrypted electrical transport), for DRM!
if someone steals your credit card numbers or social security number, just get copies of your credit reports, make the appropriate phone calls, and the problem goes away
Never had it happen to anyone you know, huh? The problem doesn't just "go away" if your checking account is cleaned out right when you need to make a mortgage payment. It doesn't just "go away" if this happens to you during your job application cycle, especially to a secure or trusted position. It can take months or years to clean up after something like this, and you have to watch it like a hawk pretty much for the rest of your life.
Don't disappoint your bird dog. Go to the range.
Storm
Exactly right. It can take years to clean up. And if your stolen information is used on the other side of the country, you need to file police reports with the appropriate authorities in that other city/county/state. And guess what, they'll probably want you to come into their offices in person to do it. And if you don't have a copy of the appropriate police reports, the big three reporting agencies won't even want to hear from you, cos you're obviously just wasting their time (remember, you are not their customer--the credit companies are). Yeah, it's no problem to get crap like this removed from your record. I'm usually not the type of person to say this sort of thing, but I really hope ErichTheRed has his identity stolen some time so he can see just how "simple" the whole process is...
This guy's the limit!
the services are typically web-based, and do handle the full processing. A user logs in to the website, since it's a website access is logged and it's not your system that can be compromised. Otherwise you can store credit card numbers if you encrypt and password protect them, you can't store the CV2 number, which you can always bypass. Global Payments is a nice package for the little guy.
Under the influence of Post-Cyberpunk Gonzo Journalism
At the lowest level, yes it's trivial. However it's a graded program:
* Level 1-Visa U.S.A. and MasterCard World Wide transactions totaling 6 million and up, per year, and any merchants who experienced a data breach.
* Level 2-Visa and MasterCard transactions totaling 1 million to 6 million per year. (The new requirement expands the number of Level 2 merchants to include former Level 4 merchants.)
* Level 3-Visa and MasterCard e-commerce transactions totaling 20,000 to 1 million per year. (The new requirement expands Level 3 to include former Level 2 merchants who process fewer than 1 million e-commerce transactions per year.)
* Level 4-Visa and MasterCard e-commerce transactions totaling up to 20,000 per year. (The new requirement decreases the number of Level 4 merchants.), and all other merchants, regardless of acceptance channel, processing up to 1 million Visa or MasterCard transactions per year.
As you process more the burden of compliance increases. It's not that hard though, and mostly common sense if you don't want to go out of business anyway. I agree with the author that the key point it getting companies to see that this is in their interests, rather than just a checklist to address once per year, and that the auditor can be an asset rather than someone to be deceived until they give a pass mark.
The requirement only applies to systems which hold or transmit CVV/PII and/or are on the same network segment as those systems with no mitigating security controls in place (firewalls, IDS/IPS, etc). Thos are your in-scope PCI systems. Your desktop at work? Not a PCI in-scope system unless your internal network is completely flat. The Oracle DB back-end to your webserver shopping cart? In-scope. The blog server in the same DMZ as your shopping cart? In-scope.
The intervals are defined in sections 11.2 (quarterly external testing by a qualified ASV, or after any significant change in PCI in-scope infrastructure) and 11.3. (annual penetration-testing requirement and after any significant in-scope infrastructure change).
Believe it or not, the cost for testing is actually quite small compared to what most organizations need to fix with infrastructure and internal processes. The 11.2/3 requirements are mostly verifying that you are PCI-compliant and stay that way.
The only problem I have with PCI is the fines for non-compliance. Currently I think it's around $25k/month, which for large organizations is almost a rounding error. And there is now way VISA etc are going to remove the merchant status from a huge income stream like Amazon or similar. There has been talk of instead changing the fine to a doubling of the transaction cost for non-compliant merchants. If your costs went from $.05/transaction to $.10/transaction and you are doing several hundreds of thousands or even millions of $ per day... that is a huge hit to the bottom line. If this fine structure ever comes to pass I will have klots of fun watching the ensuing shitstorm as companies fight to reach compliance. Amoeba
Do not taunt Happy-Fun Ball
The requirement language is sometimes a little vague but by using your best judgement and putting your security and customer hats on, it isn't too hard to figure out.
I actually found the requirements a great tool to convince upper management that they need to invest the time and money into really cleaning up the security of the site and backing systems. Most of the gaps were things that should have been fixed, but always fell behind the latest marketing push project for budget and resources. The threat of large fines made it possible to do a thorough analysis and overhaul, resulting in a much more secure system.
Most of it is really common sense:
I think that while the actual wording and guidelines could have been handled better it provides a pretty good start at a baseline of security, and is a good tool to force companies to really address security, instead of always focusing on maximizing profits all the time.
I am not qualified to do an external audit but I do provide assistance to smaller businesses which need to do internal reviews, help understand what is required, etc.
The PCI-DSS 1.1 is actually relatively flexible. It is possible to show that valid business needs preclude certain requirements (such as video surveillance of server rooms) and that any possible threats are being dealt with in other ways. See the appendix on compensating controls.
Assuming you have somewhat competent help on security, about 80% of the work is in the area of documentation. You can't just be compliant, you have to document your policies, show that they are in fact compliant, and so forth.
Honestly, I help small convenience stores to PCI-DSS security evaluations (as the equivalent of an internal audit-- my goal is to help them reach complaince, not to provide independant varification of such compliance). It is a pain, but not impractical. Most of the requirements are basic industry-standard best practices. Anything that is too overwhelming for the little guy can be dealt with in compensating controls.
The key rules to minimize issues are:
1) Store only what you need. The less you store, the fewer areas of concern you have.
2) Build and maintain secure systems.
3) Establish and defend appropriate security perimeters.
4) Document, document, document.
This isn;t rocket science. And quite frankly, 1-3 ought to apply to everyone anyway...
LedgerSMB: Open source Accounting/ERP