Slashdot Mirror

Not SOX, at least not directly.

I think you mean PCI-DSS: https://www.pcisecuritystandards.org/

Working link (without the trailing slash): https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

• Independence PCI DSS auditors are permitted to audit companies where the auditor sold, installed, configured, or has rights to the security software being used. Also, if the auditor disagrees with the client, the client is free to hire a more pliable auditor with no one the wiser.
• Scope The standards permit the client to limit the scope of the audit to defined systems and their components using defined methods. If the client doesn't want to pay for penetration tests, the auditor doesn't do them.
• Completeness A typical PCI DSS audit uses the client's system and security documentation as the starting point. The responsibility for gathering other evidence is limited. There is no requirement to do any network scanning (like with NMAP) or to go sniffing for undocumented wireless entry points, so there may be elements of the system not documented and not tested. This sounds like the case discussed here.
• Validation PCI DSS auditors are not responsible for verifying that the client's controls worked as intended. There is no mandate for penetration testing, war driving, or independent virus scanning.

Even if the auditor had done his job (not really clear from the articles), that to me would not demonstrate that the customer data was safe.

Links:
Congress is not happy, either.
PCI DSS Validation Standards
PCI DSS audit procedures

So much for my lunch break.

• Independence PCI DSS auditors are permitted to audit companies where the auditor sold, installed, configured, or has rights to the security software being used. Also, if the auditor disagrees with the client, the client is free to hire a more pliable auditor with no one the wiser.
• Scope The standards permit the client to limit the scope of the audit to defined systems and their components using defined methods. If the client doesn't want to pay for penetration tests, the auditor doesn't do them.
• Completeness A typical PCI DSS audit uses the client's system and security documentation as the starting point. The responsibility for gathering other evidence is limited. There is no requirement to do any network scanning (like with NMAP) or to go sniffing for undocumented wireless entry points, so there may be elements of the system not documented and not tested. This sounds like the case discussed here.
• Validation PCI DSS auditors are not responsible for verifying that the client's controls worked as intended. There is no mandate for penetration testing, war driving, or independent virus scanning.

Even if the auditor had done his job (not really clear from the articles), that to me would not demonstrate that the customer data was safe.

Links:
Congress is not happy, either.
PCI DSS Validation Standards
PCI DSS audit procedures

So much for my lunch break.

CISP applied to Visa only. At the time, each payment card was instituting a separate security program. Due to feed back from merchants, all of the programs were rolled into PCI.

PCI is very similar to the original Visa CISP program.

The standard can be found here in case anyone is wondering what all is involved in a PCI audit:
https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml/

PCI in itself doesn't guarantee 100% safety.

It says so right on their common myths page;
https://www.pcisecuritystandards.org/pdfs/pciscc_ten_common_myths.pdf
Quote "Successful completion of a system scan or assesssment for PCI is but a snapshot in time.
Security exploits are non-stop and get stronger every day, which is why PCI compliance efforts
must be a continuous process of assessment and remediation to ensure safety of cardholder
data."

It's a very good PDF to read. Now if the auditor said they were PCI Compliant and there was something obvious he negligently overlooked, that would be another thing. But PCI does not mean you can not have a data breech. You can never be 100% protected from that. What if someone came in, put a gun to a privileged employees head, said give me all your data or he dies? Will PCI stop him?

Interestingly, PCI-DSS does not itself appear to be sufficient to prevent a security breach in the first place; among other things, they mandate a set of principles which are pretty, but not a guarantee:

        https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

Yeah, if everything were to work out, and all virus threads were already covered by the antivirus software, and there were no such thing as a zero-day exploits, it might stop a penetration. But not otherwise.

-- Terry

Some states like California do punish companies who have a security breach involving Credit Card numbers and SSNs.

2.) make it illegal to store a social security number/credit card number?

If credit card numbers are hosted by your company, the company is probably subject to the rules established by the PCI Security Standards Council (See https://www.pcisecuritystandards.org/ ). If your business does not comply, the Payment Card Industry will now allow you to process financial transactions, or they will limit the amount of money your business can handle. These rules apply to any systems which touch the Credit Card numbers, even if the numbers are not permanently hosted on the systems.

The problem with implementing PCI DSS rules is mostly institutional, political and financial. It takes time, effort, equipment and money to bring a non-compliant business into compliance, and staff and management will often object to some of the rules ("But I need root access on the database server. It makes my life easier."), or they don't understand different aspects of security ("We have a firewall. That means we're protected, right?") In addition, many of the PCI rules are purposely vague to apply to a wide range of systems. They are subject to interpretation. You may believe one thing, but your PCI auditor may disagree, and a second PCI auditor may believe something else entirely.

I believe there are similar rules for Social Security Numbers.

Most of the breaches are not "major credit card companies". They're retailers who didn't take security seriously.

The major credit card companies have, on the other hand, been very serious about card security, and in fact created an industry organization specifically to create security standards that are required for doing business with them. Failure to meet those standards opens retailers up to getting sued into the ground.

To those of you offering technical solutions: stop. You're wasting your energy.

Any time you see "policy" or "auditing," turn off your brain and channel your inner Bill Lumbergh. These tools are all about generating pretty graphs showing how many computers were checked and had the "IT policy enforced and audited." SOX, PCI/DSS, and other auditors get their jollies seeing reports like this. As long as the software generating the report is a name they know (and, preferably, expensive -- because, you see, expensive means it's good), they'll check that box on their report without so much as a second thought, making your C*O happy.

For all the auditors know, this software could be doing nothing other than generating (fake) reports. For them, it doesn't matter; as long as the other auditors are doing it, it's a "best practice" and their butts are covered.

If you're handling credit card data at least, you should (better) be familiar with PCI-DSS. Basically, the credit card industry has gone to great lengths to set standards that can simply be followed to help assure that you're NOT handling data (or HTTP) in an insecure manner.

It's amazing what proper due diligence can do for you. It's also amazing how many people think because they CAN take credit card data online, that they automatically should.

"the PCI DSS is a security standard for payment card industries. Their documents go into detail on the specific vulnerabilities that needs to be addressed to be certified. For example they mention specific flaws (say cross-site scripting), and also measures to protect data if an attack succeeds"

All the PCI standard does is set down a number of criteria to be PCI certified. In the real world this provides no defense against getting hacked, as Heartland Payment Systems learned to their regret.

"This document lists specific flaws that are known to be a problem, and had better be comprehensive since these are the standards banks are measured against. "Comprehensive" is perhaps a gross understatement, but it will give you an idea of the aspects to watch out for"

If you need this PCI standard to tell you how to secure your network, then perhaps you shouldn't be in the security industry. Lets see what the 'document' has to teach us that we don't already know:

.. install a firewall, don't use default passwords, encrypt the transmission data, assign a unique ID to each user, restrict physical access to cardholder data, track all access to network resources and ..

WOW, I would never have thought of that. But how does one go about getting PCI certified, well there is self assessment or an 'on-site data security assessment' by a suitable qualified security assessor (QSA). How do you get QSA qualified, by filling in a bunch of forms .. :)

For example the PCI DSS is a security standard for payment card industries. Their documents go into detail on the specific vulnerabilities that needs to be addressed to be certified. For example they mention specific flaws (say cross-site scripting), and also measures to protect data if an attack succeeds.

This document lists specific flaws that are known to be a problem, and had better be comprehensive since these are the standards banks are measured against. "Comprehensive" is perhaps a gross understatement, but it will give you an idea of the aspects to watch out for.

Actually, PCI is fairly stringent. But a lot of merchants aren't there yet.

Only because they lie to their assesors:

8.5.8.a For a sample of system components, examine
user ID lists to verify the following
  Generic user IDs and accounts are disabled or
removed.
Shared user IDs for system administration activities
and other critical functions do not exist.
Shared and generic user IDs are not used to
administer any system components.

8.5.8.b Examine password policies/procedures to
verify that group and shared passwords are explicitly
prohibited.

8.5.8.c Interview system administrators to verify that
group and shared passwords are not distributed, even if
requested.

8.5.9 For a sample of system components, obtain and
inspect system configuration settings to verify that user
password parameters are set to require users to change
passwords at least every 90 days.

https://www.pcisecuritystandards.org/security_standards/download.html?id=pci_dss_v1-2.pdf

The standard really does a decent job of promoting best practices, but can be both over detailed and overly lenient at times.

The payment card industries standard 1.1 states that AV software has to be installed on every box (especially servers and personal computers), but also clears that UNIX boxes and mainframes don't need to fall under that rule and so don't need AV software.

Currently, PCI 1.2 is in the works and there's already a brief overview on the changes.

So far, the guys kicked that UNIX/mainframe excemption and extended that AV rule by "must address all known forms of malicious software".

So, when I'm running a few Cisco ASA routers on my network (which basicly are Cisco appliances running linux), I am supposed to either get AV software for those boxes?
And the AV software on my windows boxes doesn't scan for Linux rootkits - do I even have a chance to get the PCI 1.2 compliance?

On the other hand, PCI 1.1 is currently perfectly fine with a WLAN running WEP "encryption" and PCI 1.2 is said to state that you should change any WLAN from the long-broken WEP-obfuscation to WPA-encryption by at least 2010.

If you're running a web application, you're only to required to run reviews on this applications code or sanitzing input for SQL injections and the like when this web application is facing the internet. As long as that application sits on some internal network, you're perfectly PCI compliant.
Well, galf a year ago, credit card details of 4.2 million Hannaford Bros customers were stolen - not by some employee sniffing at the right points, but from some malware exploiting a vulnerability in the Hannaford Bros-internal credit card application.

The PCI standard also states "one primary function per server".
Well, some virtualizations like OpenVZ/Virtuozzo may not seem "that" secure (you can attach to the guest OS from the host box, sniffing traffic or processed kernel code "for free"), but others (HVM solutions like VMware or Xen) quite clearly are "strong enough".
But wether you'll be failing or getting PCI compliance by running a dozen virtualized servers on a physical box is merely a matter of the auditing company you've chosen.

Which brings me to the last point: getting PCI standard compliance means that you're paying some PCI-approved auditing company, who you've chosen on your own and who do turn checks various boxes (either "in place" or "not in place") in some form, mail the form to the council and wait for the response.

Excuse me, but such things are plain nuts.

That said...I think there should be something to "encourage" companies to actually invest the resources in protecting that data, or just to stop collecting it.

Chargebacks (card holders disputing charges with their credit card company) are good incentive. Ultimately, it is the vendor that looses money when a user claims a charge is unrecognized and the vendor is unable to provide sufficient proof that it was a legitimate purchase (though the CVV2 number helps the vendors here). To add to that, even more incentive is provided by the banks because they keep track of the unresolved chargebacks on all merchant accounts. If they find your merchant account has had too many unresolved chargebacks per month, they'll typically send you a notice informing you that you have 30 days to find another bank, and setting that up to continue your sales is generally next to impossible to achieve. It is, in some cases, possible to pay the bank extra money to keep the merchant account active for a bit longer, however.

Seems to me not collecting it is far easier and more viable in many many cases.

Indeed, it is. A vendor's ability to meet PCI DSS standards is much simpler when card data is not retained. However, there are some cases, such as automatic recurring payments, where storing card data is appropriate. At that point, additional measures are obviously necessary.

Personally, since the monetary liability ultimately comes back to the vendor, I don't feel criminal charges are necessary. That, and it seems like it may be simple to exploit such a system to make money suing vendors via charges designed to appear fraudulent. Additionally, many of the chargeback requests are often people simply not recognizing charges (i.e. they didn't remember making the purchase, and/or the card processing was done by a third party on behalf of the company selling the product). Now, fraudulent use of retained credit card data is an obvious crime. But provided a vendor has not abused their data and has taken the appropriate measures to meet the PCI DSS guidelines, I'd say they should be in the clear in terms of criminal charges. However, I may agree that reasonably increasing chargeback fees would significantly increase incentive.

Criminally negligent is a very serious allegation you are making . I can not understate that.

it's easy. Europe, and member states have strict data protection laws, Best Western have broken more than one. Certainly, in the UK directors of a company are responsible for data protection and could be criminally responsible - although this has not been tested in court.

Also, I think Best Western will certainly be having uncomfortable discussions with their merchant acquirers because Best Western have not met the terms in the acquirer contract to appli PCI DSS (Credit card security standards)

Certainly, I've worked in a few large organisations that have had to encrypt credit card data in databases so that members of staff may not see the data. if Best Western had done this, then the data would have been a bit more secure.

Here's where the company gets in trouble:

https://www.pcisecuritystandards.org/tech/

which is funny, I used to work upgrading old credit card systems for the pci dss, the scuttlebut at the time was that TJX was the REASON for implementing the DSS in the first place. TJX ought to have the Credit Co.s run a train on 'em for this shit.

Please tell him to make it accessible via the Internet and to not encrypt his credit card data. It would make life so much easier for my Russian friends.

Ever heard of PCI-DSS?

My company develops and supports retail point of sale software for a large number of retail chains. In the interest of ensuring my job security I will not identify my employer, but I can offer some insight.

The first thing to do is check out JPOS, an open source mini-framework for controlling POS peripherals such as MICRs, sigcaps, pole displays, barcode scanners, MSRs, receipt printers, etc. This will only help if you are using Java, but there may be similar libraries for other languages. Regardless, playing around with JPOS may help you understand the hardware and how all the pieces fit together.

Please realize that even a small inventory application is a major undertaking. The software I work on has an inventory module, and it is insanely complex to meet the requirements of retail inventory. Hardware abstraction can be a pain too, as you need to code at a high level in your application but deal with low level crap that most devices throw at you. For example, scanning a barcode sounds simple and may be relatively easy for UPCs, but what about SKU or inventory tags that are nonstandard? You can program the scanners to pad zeros, truncate to a specific length, strip or retain check digits, etc. and there are so many pieces of hardware out there that behave slightly differently it will give you a headache.

If you decide to add credit card processing, my advice: don't. If you have to ask this question to Slashdot, you are not prepared to deal with PCI-DSS compliance. It costs a lot of time and money to process cards securely and to prove to the payment processors that you can do it securely.

And neither will anyone working with finances or credit cards. Specifically, PCI doesn't allow for WANs. You must have a firewall and web server in a DMZ.

People who say LANs will go away have no idea what they are talking about. NAT may go away, but LANs will never go away. It's just way too cost effective to aggregate your traffic into one higher speed WAN link. I can transfer files between computers in my house via gigabit Ethernet, but if they all had to go out to te "internet" first, forget it on my 2 Mbps uplink. Granted you could run each into a port on a WAN router, but that's expensive and not really helpful. A switch with a higher-speed uplink port is really all you need, and that's a WAN.

Similarly, wired networks aren't going away for security and speed reasons as well. I'd wager my gig Ethernet can out pace any fance 802.11n connections, especially between multiple computers on the same WLAN. I can get full one gig between every port and my switch was less than $300 for 24 ports.

Payment Card Industry https://www.pcisecuritystandards.org/ - Data handling standards for CC data.

Er, or a link that is actually working and hasn't been obsoleted.

https://www.pcisecuritystandards.org/tech/index.htm

Firstly, most of the acquiring banks actually request that the merchants keep card number data for *at least* 6 months after the original transaction. This is to allow the cardholder time to make a chargeback, and for the acquiring bank to make enquiries with the merchant about the transaction. Some acquirers have much longer data retention periods.

So the full card number is required for a) initial authorization request, typically taken when the cardholder places the order,

b) reauthorisation prior to dispatch (typically required when the order has taken more than a week or so to process - if the card is not re-authed the merchant may face chargeback. This varies between card issuers and acquirers.)

c) Settlement, ie when the merchant actually banks the money. For this the merchant sends an end of day settlement file containing card number and authorization details.

d) Then, as mentioned most acquirers request the details are kept for at least six months to allow for Request For Information queries about the transaction.

That's why you need to use thin clients in retail environments. No data to steal. It makes PCI compliance easier, too, just for that reason.

These security requirements apply to all "system components." System components are defined as any network component, server, or application that is included in or connected to the cardholder data environment. The cardholder data environment is that part of the network that possesses cardholder data or sensitive authentication data. Adequate network segmentation, which isolates systems that store, process, or transmit cardholder data from those that do not, may reduce the scope of the cardholder data environment. Network components include but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances.

See, the deal with PCI members (credit card companies) is that, if you don't comply, your credit card agreement says you're on the hook to reimburse anybody whose credit card gets p0wned due to your lazy, sloppy practices, plus some "administrative costs" for reimbursing them.

Anyway, #10's not anything any decent sysadmin isn't doing already. If you'd like to see more details, all you need to do is accept the soul-stealing license agreement and you can read more details.

Ditto for #11. Regularly means regularly. If some tests quarterly and some annually means frequently to you, then it means frequently. As I said, all you need to do is surrender your immortal soul to learn more.

Oh, wait... this is Slashdot... never mind. Comment away.

See, the deal with PCI members (credit card companies) is that, if you don't comply, your credit card agreement says you're on the hook to reimburse anybody whose credit card gets p0wned due to your lazy, sloppy practices, plus some "administrative costs" for reimbursing them.

Anyway, #10's not anything any decent sysadmin isn't doing already. If you'd like to see more details, all you need to do is accept the soul-stealing license agreement and you can read more details.

Ditto for #11. Regularly means regularly. If some tests quarterly and some annually means frequently to you, then it means frequently. As I said, all you need to do is surrender your immortal soul to learn more.

Oh, wait... this is Slashdot... never mind. Comment away.

However, Visa indicated in February, through a number of documents sent to financial institutions that issue cards and manage Visa transactions, that TJX was storing card number, expiration date, and card verification value codes, all of which are prohibited by PCI.

Append only files have not been required in my experience. What is required is that there be no ability to overwrite a previously written file by the team that is sending the log data. This can be done a number of ways, but the easiest method is to transmit the data in a way that the server chooses the filename, not the client. Add a date string into the filename and you can (with a few other details I've worked at but am here waving a wand at) avoid the problem.

syslog works for most data, but not all. Linux is one of the only Unix based systems that puts sulog through syslog. The failed logins log is much more difficult, as is the wtmp data. wtmp data is especially annoying as it is one of the only ways to semi-reliably record both login and logout regardless of login type (including ssh), and can't really handle real time data streaming. The other annoying item is the command line history of all commands with EUID 0. I'm hoping to hear some news soon on a solution to that problem, but it is really difficult, especially since a lot of SAs become root via `sudo -s` or `su` (as opposed to `su -`, which would not modify their HISTFILE variable. Many root shells do not support direct sending of HISTFILE over the network.

As to writing periodically to a optical media, I wouldn't worry quite so much about that. I would instead worry more about the encrypting all that security data while in network transit. (Sorry, can't recall if that is a firm requirement of PCIDSS 1.1 or not). Unfortunately, this makes use of syslog a less trivial solution. Authenticity is also an issue to be concerned with. How do you know that the event that got inserted into the log really came from that box, and not some random other server? Traditionally, syslog has not concerned itself with such issues, but a PCI system may care a great deal.

Once the data is on the central logging host, it is already in a state that the author of the data (the SAs for the PCI impacted box) cannot modify it. That eliminates at least in the interpretation of PCI I've been working on, the need for writing to optical media. Immutable is not so much immutable by anyone, but immutable by the server in question.

The point of the central copy of the logs is so that modification on either side can be readily detected and investigated. But if you cannot trust your central log host to have an accurate copy of the logs because you are receiving log data from anyone who chooses to pretend they are your PCI impacted server, then your central log host does not give you as much value as it may seem. The audit requirements aren't just for making lives miserable, they usually have a valid point behind them.

When working with PCI, know which DSS you are on, 1.0 or 1.1. (I don't know the release schedule for the next PCIDSS.) The requirements do differ, as do even the interpretations. Reference https://www.pcisecuritystandards.org/ for the information.

i dont know about hippa/sox but i did recently have the "pleasure" of creating a pci-dss v1.1 compliant system from pretty much the ground up on the freebsd platform and have read all 16 (wow!) pages of the pci-dss 1.1 "spec" (if you can call it that, i put that in quotes because it it doesnt "spec"ify anything. at least it is short read albeit a vague one) the following is a rant. however if you read to the bottom (or skip there) there is a reward of a paragraph actually more directly pertinent to the original ask /. question :)

it (pci-dss) eerily reminded me of iso 9001. (i have a little experience in qual. assurance of manufacturing.) basically [pci-dss|iso9001], while its advocates will try and trumpet [security|quality], has nothing to do with either, and more to do with documentation and accountability. (ie whos responsible ie who gets fired/resign (after they've already pocketed enough money so that its actually basically a retirement) so that another scapegoat can be brought in to take his place) sure, documenting your process has always been a cornerstone of [security|quality] but anyone worth their weight in horse-sh^H^Hmanure already knew that and already did that.

[pci-dss|iso9001] seems to me (a small business operator) to mean more about burying the little guy in a mess of paperwork and red tape while letting the big guys pat themselves on the back with another acronym or seal-of-approval that in the end gets so watered down and turns into just another way for fool-hearty consumers/customers to increase their complacency (complacent-fool consumers both a. deserve to be separated from their money quickly and b. are in my opinion one of the major problems w/ american society) rather than study beyond the flashy outter packaging (in a manner of speaking) what they are buying.

and i dont have much experience with SOX but from the whiff of it based on what some colleagues have told me, is roughly the same thing (swap consumers w/ investors in the above text), despite glowing reviews in a recent usa today article on its 5th birthday. (usa today basically credits SOX for all of the US's economic growth since its inception after the post-enron market bomb, not the fact that the fear of being caught still looms in the air like a stench and so would-be corruptees might just be chilling out for the time being, seeing that 5 years is nothing the grand scheme. however my hypothesis is that they in fact aren't chilling out at all, and are going at it just as strong or stronger, because from what i have seen in business, i would tend to think that: just like there is nothing really stopping a iso9001 certified company from producing sh^H^Hpoor quality products, SOX smells like just a better way to bury the real story in cooked-books that are now just that much deeper. i know, i know, now the board is responsible and not just the CEO, and its a legal crime and they can't claim plausible deniability anymore, all good steps in the right direction, but that only matters if you get caught and my point is that SOX is just more paper to hide under so they dont get caught) (ok please label all flame replies telling me i dont know squat about SOX by keeping SOX in your subject while taking PCI-DSS out of your subject line if it no longer has anything to do with pci-dss, and do please enlighten us)

back to pci-dss: as consultants first and developers second, we reviewed handfulls of pci-dss compliant "solutions" before resorting to a custom built system. despite trying to scare those like us out of it, with a little patience and attention to detail we little guys could still implement a pci-dss compliant system that was WAY better than many systems i wont go into bashing here, and all for the cost of some lower priced of the pre-cooked "solutions".

to an experienced developer, the pci-dss "spec" reads like: 1. dont be so stupid, 2. pull yer head out of yer as^H^Hrear-end, 3. dont g

The PDF isn't full of anything revolutionary, and most are just common sense data security, but it is a great starting point for securing virtually any highly confidential data.

Far too many shops don't comply with the majority (or any) of the recommendations.

A lot of people seem to have a misconception of exactly what PCI is, what it covers, and what it does.

PCI affects all areas of the transaction stream.

When looking at ATM's for instance the units must be tested and Certified (InfoGuard, TNO and T Systems). If you attempt to open the device it dumps the program and tampers the unit so it can't be reprogrammed. this prevents a situation such as the one at stop and shop where a malicious party opened the POS device and apparently hooked up a device to sniff the card reader (article is a little vague on exactly what was done to the POS devices) There should be no place in between the PIN PAD and the CPU of the device where data can be read in the clear without causing a temper condition to the unit.

Some of these requirements are relatively new and some older terminals that are currently in place may not meet these requirements. Any existing units that are relocated or changed must meet the new requirements at that time. One exception to this is Data encryption. All terminals must now transmit data using 3DES encryption, any terminals that are not utilizing 3DES encryption and are running the older Single DES were to be taken off-line at the end of last year.

Also all software run on the device must be certified through testing and any software changes must be re-certified as well. Software is sent to the device in an encrypted format, routinely verified on the device for changes, and units must identify themselves with a unique set of keys in order to access updated software. On top of that each Switch (STAR, CORE DATA, ECS, LYNK, etc..) that the terminal may dial into has to certify the equipment and software to work with their systems before you can use that terminal to process transaction through that switch.

Now go to the company/merchant/etc.. that is processing transactions whether they be web based, Point of sale, or ATM. any company that has Card data on file is subject to PCI requirements as well. This can be everything from segmenting card holder data on the network, encryption the database containing card holder data, additional logging requirements that show who accessed what data, when and from where. Physical security, the PCI requirements are quite extensive. https://www.pcisecuritystandards.org/tech/download _the_pci_dss.htm

If a card number is lost it costs VISA,or Mastercard about $60.00 to re-issue a new card. now if several thousand cards get lost those numbers can get large rather quickly. If you are PCI compliant as a merchant or processor, and have adhered to all 240+ requirements of the PCI certification that apply to you, and you loose card holder data, you will probably dodge the huge fines (think tens of thousands or millions of dollars here depending on the size of he breach) levied by VISA in case of a breach which is on top of the fees to re-issue the cards. if you are NOT compliant all those fines and fees will be passed on to you.

PCI is not an instrument put in place to address the use of a stolen card. it's to prevent the loss of large numbers of card holder data at one time.

I think it's great the industry is imposing the regulations on itself, some of which are extremely stringent. And it beats the heck out of how the government could butcher doing the same process by trying to regulate it.