Slashdot Mirror
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.
But there are a number of typos in the glossary.
I don't think this is talking about the "PCI" that most of us know and love... :-O
TMA!
PCI is far too complex for the little guys.
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!
"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."
...Who the hell wants military grade razors and batteries? I'm perfectly fine paying the price I do for these items, as producing them to the standards they do also helps keep the price down.
10. Monitor and track all access to network resources and cardholder data
11. Regularly test security systems and processes These two stand out as the most costly. Are they things you SHOULD do? Yes. Can you reasonably mark either of these as 100% compliant at any time? Maybe, but this isn't going to be pretty, or cheap...
Lets look at #10 first. What does "all access to network resources" define out to be? These days EVERYTHING is a network resource, and not all of them are within the admin's control. Take the iPhone for example. Is the PCI-compliant admin supposed to certify that every iPhone on the company's network cannot be accessed by others, thereby turning it into a 'network resource'? How do I, as an admin, track that Joe and Jim transfered files peer-to-peer style between their phones? I assume that we have to then ban all these devices?
It is _possible_ to comply with 'all access to network resources', but this is costly.
Cardholder data, on the other hand, can be limited and is perfectly reasonable as a requirement.
For #11, does 'regular' imply frequent as well? Does that compound with 'all network resources'? If so, this is a HUGE time sink. It could also be done, but this has a cost attached as well.
...PCI is an excuse to hire the KPMGs, Accentures and EDSs of the world. They will charge you $xM for "experts" to put in controls and make your systems secure. All the while, only a few percent of your card transactions are fraudulent. The thing about PCI is that you can't just take the hit for fraud anymore...you get smacked with huge fines for every leaked credit card number, etc.
I'm not a big believer in the whole "identity theft" hype -- 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.
From what I've seen, PCI's just a consultant-employment excuse. Anyone can still write down credit card numbers and sell them. Maybe forcing the card industry into adopting a secure payment system in the first place would be a better way to go. Overall though, having no standards is bad too, so that's definitely what PCI is good for.
For those who didn't catch the acronym, PCI = payment card industry, i.e. Visa, Mastercard et al.
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.
Maybe the opinions got it right. I lead the systems administration team for an organization which does a tremendous number of credit card transactions. PCI DSS compliance is a joke. You answer a long questionaire, much of which has no relevance (virus scanner for your Linux web server!?). Next you submit to a black-box scan of your exterior network interface by an external auditor who does nothing more than run Nessus against your address space. Then they hassle you about all the faulty Nessus hits. Yes we are running SSL IMAP and no it doesn't have any known security vulnerabilities despite the rank 7 nessus hit documented by a URL that returns a 404 error. Commence eyeroll.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
I'm going to have to call foul here. Working with point-of-sale systems, we deal with PCI compliance in software regularly, so I've tried to keep up with the PCI regs as it pertains to the software packages we sell.
It's a blatant double-standard. They want to lock down EVERYTHING downstream from them, with accountability, yet even after numerous break-ins, apparently have not applied the same standards to *themselves*.
On the flip side, most of our customers couldn't give a rat's kazoo about compliance, and would do without it 'cause of various inconveniences... {You can only transfer CC-orders twice per order, per spec...} We get buy-in by explaining the penalties if they're caught, and let 'em know that while it may be IMPROBABLE, it's quite possible.Don't tell me to get a life. I'm a gamer; I have LOTS of lives!
I do server admin and light coding work for a small company that has a primarily web-based business. Going through ScanAlert not only do we have a nice logo to put on the website but we also get a list of stuff that could cause problems such as XSS and software package vulnerabilities (and can check to see if problems are fixed after we've patched the problem).
:)
The thing is, obtaining PCI certification is not that hard. Any decent web admin should already be halfway there, the rest is just locking down applications and making sure you keep on top of the software installed on your server(s).
While their port requirement is somewhat absurd for anyone trying to run everything (web, email, dns) on one box (no more than 10 open ports, tcp and udp are counted separately) it is a pretty nice service and makes my employer more comfortable with their business, if the credit card companies get a kick out of it then all the better.
PCI is not a bus. You can't just get on it and ride it around all day without paying for it. And when it comes time to pay, there need to be standards...
Storm
They try and make everything downstream "more secure" but yet they roll out cards that just need to be within a 2" proximity of a card swipe while never checking to see if the person using it is allowed.
Having worked for a multi-billion dollar mutual fund company as the head of network security I saw first hand the many paradoxes of standards vs reality, as I am sure we all have in the security field.
1. Receive "quality" industry wide standard and procedures that are meant to protect and secure.
2. Huddle around a conference table and try and dissect what this means for the company.
3. Try and find the cheapest and best "close to scenario" for complying with the standards.
4. Implement and cheer that "WE HAVE COMPLIED!"
5. secretly mumble and complain under our breath that this is f$#ked and no where near as secure as it should be.
Watching a company, such as the one I worked with budget out and just squeak by in complying with ad-hoc measures and procedures left a huge distaste in my mouth for data security in corporate America.
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.
As I recall from a class a long time ago, all of those n-bladed hexi-flexi razors are built to very high technology standards. It was apparently a $1B and bet your company kind of investment by Gillette to initiate these sorts of razors and create the machines that could do the sort of precise welding needed.
The razors themselves are high tech and excellent quality -- they don't want you to cut yourself which would be bad for repeat business.
What is kept very secret is how the manufacturer thinks they should last. To create repeat business, they won't tell you to replace the blade daily, weekly, or monthly. They'll let you decide.
as a sysadmin for a managed hosting company the PCI compliance issues we run into are 99.9% of the time not even real legit issues that would be of a major risk to a credit card processing website. most of them are simply flag checks of versions of software that are installed. most of the time, say on a RHEL system the actual version numbers remain old and the required patches are backported into the rpm. almost any time i get the "OMG I AM SO OUT OF DATE" request from a client it means i simply have to paste the rpm information and sending a link to the errata. "you are fine, you are not going to be hax0r3d, your biz is not completely dead." companies that provide "free security scans" for your average web server colo normally just send total bullshit that just get people in a frenzy for no reason.
PCI is a good model for any company to follow who would like to secure sensitive data and audit, log, and track usage of said data. Most of the requirements are items that a good IT department should have in place to begin with. Part of the process is implementing an Information Security Policy in which all employees, contractors, or third parties must adhere to if they connect to your network. This is something that TONS of companies lack to begin with, and it brings an awareness of data sensitivity to your user base. Not all that bad if you ask me.
One negative thing that it does do is make it really hard for small e-tailers who use 3rd party carts and check out processes to make the jump to a fully owned supply chain. In that case, it can be costly.
Ok, I'll never make the top 40, but seriously the most recent PCI "standards" (I think they're at 2.1) have a LOT of vendor extension hooks, making me think that PCI is going to go the way of CORBA and SQL - standards only on paper and not in practice. Besides, the latency is high (and that's according to Intel!) and the signaling system has become nightmarishly complicated.
The alternatives seem to be HyperTransport and VXI, neither of which are either widespread or perfect by any stretch.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
PCI compliance is (a) a sensible set of rules to better protect the privacy and security of credit card transactions but, more importantly, it is (b) a new mechanism for banks to levy astronomical fees against non-compliant merchants and (c) build a self-serving governance consulting industry which will promote the rather profitable idea that banks are outside of the loop when bad things happen in the payment card industry.
First off, banks are parasitic business -- they do not typically kill the host. While they may threaten to cut merchants off, they are more about generating fees and mitigating risk. The threat of being cut off is simply to make the huge non-compliance fines seem like the more palatible alternative.
Next is: Since when is a bank blameless when somebody impersonates us and takes money out of our account? They've invented the "identity theft" thing to explain that what was stolen was our identity, not the money we entrust them with -- and which they disbursed to a third party without our proper authority. So we have to fix the fraud which was actually perpetrated against the bank by that third party, even though we were in now way involved in the fraudulent transaction. We should insist on calling this a monetary theft, to restore the notion of bank robbery, which it really is. PCI compliance will further insulate banks from their responsibilities to account holders. All risk will, by additional agreements, be transferred to either the merchant and the cardholder when things go wrong. Nice business when you can get it, even if it takes a bit of PCI collusion to set it up!
Living in New England, and being an employee of one of the two groups of battery/blade companies, I can tell you that rumor is bullsh*t.
Although I agree with you, there is one point I could add: the banks themselves are mostly not PCI compliant.
Yes, Visa and Mastercard push banks and payment processing companies to be PCI compliant, but they offer to check compliance through procedure called "Self audit". That is - you have to tell them you are compliant. So of course everyone is.
I was responsible for PCI compliance in one payment processing company in north Europe, so I know what it's like - a list of sometimes dumb rules you have to implement. Some standards you have to implement are already insecure (SHA-1, for example) and some things became more secure but you just can't use them, because authors of that standard have no clue it can be done in a secure way. For example - you have to say goodbye to FTP in your network, no matter how hard you are protecting the line and how advanced your server is. So PCI standard essentially is obeying dumb principles of basic security at very high cost. There is much you can do better, yet it won't be PCI compliant.
Lack of de-facto PCI compliance means that bank can use the "PCI compliance" factor to prove that its network/environment is extremely secure and so it's your fault that money were stolen. If you would see what I've seen about real PCI compliance in north Europe banks, you would have a serious risk of becoming paranoid.
PCI is NOT a problem for techies, it is a problem for managers. Several places I've worked there has been intense pressure to circumvent PCI because it all appears as 'non-functional' requirements on their charts.
I've even seen one place recycling client data as test data: those customers were seriously peeved about the odd charges and paybacks on their bills. Which was why I was brought in. Try explaining to a management team that a bug isn't in the code but in their technique.
threadeds blog
lol I'm doing this now and even I misread the title. It is a huge pain but it's also what we should have been doing all along, when I started doing POS support (coming from a corp. environ) I was amazed at how horrible security was and it's caused by failures all along the chain.
It's the fault of the program vendors (I'm working with Aloha mostly and its design from the ground up is god awful) the integrators (for doing things the easy way instead of the right way) and the consumers (retail owners) for not understanding why any of this matters and wanting, like all end users, for things to be simple when, sometimes, they just can't be as simple and easy as they'd like.
For example, 1 pcanywhere login for all stores with identical short passwords and no encryption on top of a system built around open file shares with no firewalls and default user names and passwords for system accounts that the POS program uses to access resources (including all CC info and log files) which is, amazingly enough, aloha and hello. and that's just the start. I could go on for pages and pages.
So yes it's a ton of work but it's shit that should have been done right the first time, it's a ton of work b/c it's never been done right and now they're trying to catch up.
oh, i guess I should post anonymously now...
The PCI group that is to "certify" our F100 company, wants all IDS and AV disabled so they can scan the systems without being blocked and locked out. It seems that when security is enabled (doors locked, guns loaded and aimed) the PCI scanning systems get blocked from access. Their solution is to disabled security and then scan the systems, then report that your systems are vulnerable!!!