Slashdot Log In
PCI Compliance
Posted by
samzenpus
on Mon Aug 27, 2007 01:32 PM
from the read-all-about-it dept.
from the read-all-about-it dept.
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 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.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Useful book (Score:2)
Re:Useful book (Score:5, Funny)
Parent
"PCI" or "PCI" ? (Score:2, Informative)
Re:"PCI" or "PCI" ? (Score:5, Informative)
Parent
Huh? (Score:2)
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 HyperT
And for those wondering what PCI refers to (Score:5, Informative)
Re: (Score:2, Insightful)
Re: (Score:2, Interesting)
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
Costly... (Score:4, Interesting)
10. Monitor and track all access to network resources and cardholder data
11. Regularly test security systems and processes
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.
Re: (Score:3, Insightful)
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.
I am pretty sure that when they say "network resource", I am pretty sure that they are talking about the network that the cardholder data is on. It is not necessary that all of your company's business goes on on the network that handles your credit card processing. As a matter of fact, it is probably a good idea if things like cell phones that access the company network, don't access the network that handles credit card data.
Re: (Score:2)
OSSEC-HIDS helped a lot in the monitoring requirements, along with nmap and the LOG/ULOG targets in iptables.
Workarounds... (Score:3, Informative)
Re: (Score:2)
That's pretty solid, actually. Except perhaps that the App won't like that config and the vendor will never have heard of doing it that way before.
It would be rare to see the network that houses the workstations to be considered 'open'.
You'd pretty much be forced to go thin-client, too.
Again, assuming this is your only reason for implementing these measures, costs will attach...
Re: (Score:2, Insightful)
Re: (Score:2)
Th
Re: (Score:2)
Re: (Score:2)
I don't the issue would be that there IS data on the workstations, but proving that there cannot be. If you can't prove that, you'd have to assume that there is.
Re: (Score:3, Informative)
Re: (Score:2)
Everyone, let's welcome John Gage to Slashdot.
Though I must say, I'm intrigued by your choice of username, and that your UID is even higher than mine.
Re: (Score:2)
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.
It gets worse. PCI is a far-reaching set of requirements, when read in specific. It even has implications as far as how you run your business, outside of technical security.
In general, companies tend to isolate the PCI-compliance requirements to a section of the company that simply doesn't interact with the rest of the company except through tightly controlled channels. This becomes even more important as you add on any fiduciary requirements from the U.S. Federal Government or privacy restrictions from th
Re: (Score:2)
Re: (Score:2)
Welcome to IT. Not all costs here are measured in dollars and cents, my friend. Uttering the phrase "No Mr Business Owner you may not sync your iPhone over your own network" does in fact bear a cost. It can be said successfully, but is no small thing.
And that is only one example. There are millions:
1) CFO selects the vendor
2) Copiers replace printers due to 'company wide initiative'
3) Partner insists on 'unlimited' access to the network
Etc
There are ways to deal with ANYTHING. But again, not using well-
Re: (Score:2)
Partner insists on 'unlimited' access to the network
Does that include the bit with series 70 data or do you not have to deal with that?
Re: (Score:2)
"No Mr Business Owner you may not sync your iPhone over your own network" does in fact bear a cost. It can be said successfully, but is no small thing.
Bah, that's ridiculous. It's a very small thing, and should absolutely be done. It's not at all difficult to segment your network and isolate the systems that handle CC data from the rest of the office network, and only the most security-clueless admin would put the production systems on the same network segment that has the wireless AP you'd use for syncing an iPhone.
Segment the network, configure the routers that touch the sensitive segment to log all accesses, then get an appropriate log analysis t
Just like HIPAA or Sarbanes-Oxley... (Score:2, Troll)
I'm not a big believer in the whole "identity theft" hype -- if someone steals your credit card numbers or social security num
Re: (Score:2)
Re:Just like HIPAA or Sarbanes-Oxley... (Score:5, Informative)
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.
Parent
Re:Just like HIPAA or Sarbanes-Oxley... (Score:5, Informative)
Parent
Re: (Score:2)
The truth of the matter is, criminals will always find a way. You can setup hidden cameras in strategic locations inside businesses now-a-days, and use software to rip CC #'s. There's been a problem with retailers and other places that use credit cards for payment having their employee's (and sometimes employers) enabling fraud.
The truth of the matter is, any electronic payment t
Maybe they do know. (Score:3, Interesting)
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.
Re: (Score:2)
Whoever drew up the questionnaire is not competent. From the document:
You may argue about whether the term "UN
Re: (Score:2)
You are confusing the specification document with the questionnaire drawn up the the OP's consultants. The original specification does state that anti-virus is only relevant for some platforms, but I interpreted the OP to say that that the questionnaire he had to complete did not make this distinction. The questionnaire should have been
Re: (Score:2)
Sauce for the goose... (Score:4, Insightful)
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.Re: (Score:2)
PCI isn't that bad to implement (Score:2, Informative)
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
FWIW: Razors: what is secret is how long they last (Score:3, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2)
1) Remove, to any extent possible, any questions of transport. Ideally, treat everything as a public network.
2) If you want to store credit card track data for later approval (only storage subsequent to approval is prohibited), think twice or thrice about it. If it is necessary, though, there are compliant ways to do this.
3) Review all logs regu
Re: (Score:3, Interesting)
If it touches your webserver at all then you need to be PCI complaint, the only solution (to avoid having to certify your webserver) is to use an online gateway where you hand the customer off to make payment. This is how it's going for small
Re: (Score:2)
Re:It is too complex! (Score:4, Informative)
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...
Parent
Re: (Score:2)
Re: (Score:3, Informative)
* 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 MasterC