Tweet
If you're involved in, or interface with, IT security the chances are good you're going to be impacted by the "Payment Card Industry Data Security Standards", or "PCI DSS", directly or indirectly. It's a good thing to add to your conversational arsenal, too, in case you're asked about it.
The DSS sets up the requirements for protecting credit card and related information. It's tough, no-nonsense, and can be applied to the protection of any form of information...which is why it is being discussed as a model for data security in a number of venues other than credit card processing.
For instance, I just attended a HIPAA (healthcare information security) seminar where the PCI DSS was spotlighted as a model for achieving HIPAA compliance (which has never been defined in a way that is widely accepted). Similarly, the PCI DSS has been featured in a symposium in Boston for government information privacy officers.
The standard itself is deceptively brief - just 17 pages - but it's tough and comprehensive. You can fail a PCI audit in a thousand different ways.
Here is the link to the PCI Council website. In the menu near the top, click on "About the PCI DSS" to follow the link to the page requiring you to accept the terms for downloading...accept, select "English" (or your preferred language) and download the PDF file. Then, do the same for the supporting documents.
When you read these documents, read between the lines and you'll see how tough compliance with the standards can be. For instance, here are a couple of little items:
_________________________
11.4 Use network intrusion detection systems, host-based intrusion detection systems, and intrusion prevention systems to monitor all network traffic and alert personnel to suspected compromises.
Keep all intrusion detection and prevention engines up-to-date.
11.5 Deploy file integrity monitoring software to alert personnel to unauthorized modification of critical system or content files; and configure the software to perform critical file comparisons at least weekly.
Critical files are not necessarily only those containing cardholder data. For file integrity monitoring purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. File integrity monitoring products usually come pre-configured with critical files for the related operating system. Other
critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).
_________________________
Anyone who "knows IT", knowing that during an audit these requirements WILL be checked, down to the tiniest detail (when they say monitor ALL network traffic, they mean it), will understand why I say these are tough standards. As for identifying "critical" non-system (application-related) files, have fun! An item might only take a few words to describe, but achieving it is another story.
Very few organizations are passing their audits the first time, and even with a June 2008 "drop-dead" deadline approaching, the failure rate even for second-repeat audits is nearly 50%. Here's a link to one analysis of the reasons for this from Verisign. As you might expect, it's a little self-serving since Verisign is a solution provider, but it's worth reading.
The DSS sets up the requirements for protecting credit card and related information. It's tough, no-nonsense, and can be applied to the protection of any form of information...which is why it is being discussed as a model for data security in a number of venues other than credit card processing.
For instance, I just attended a HIPAA (healthcare information security) seminar where the PCI DSS was spotlighted as a model for achieving HIPAA compliance (which has never been defined in a way that is widely accepted). Similarly, the PCI DSS has been featured in a symposium in Boston for government information privacy officers.
The standard itself is deceptively brief - just 17 pages - but it's tough and comprehensive. You can fail a PCI audit in a thousand different ways.
Here is the link to the PCI Council website. In the menu near the top, click on "About the PCI DSS" to follow the link to the page requiring you to accept the terms for downloading...accept, select "English" (or your preferred language) and download the PDF file. Then, do the same for the supporting documents.
When you read these documents, read between the lines and you'll see how tough compliance with the standards can be. For instance, here are a couple of little items:
_________________________
11.4 Use network intrusion detection systems, host-based intrusion detection systems, and intrusion prevention systems to monitor all network traffic and alert personnel to suspected compromises.
Keep all intrusion detection and prevention engines up-to-date.
11.5 Deploy file integrity monitoring software to alert personnel to unauthorized modification of critical system or content files; and configure the software to perform critical file comparisons at least weekly.
Critical files are not necessarily only those containing cardholder data. For file integrity monitoring purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. File integrity monitoring products usually come pre-configured with critical files for the related operating system. Other
critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).
_________________________
Anyone who "knows IT", knowing that during an audit these requirements WILL be checked, down to the tiniest detail (when they say monitor ALL network traffic, they mean it), will understand why I say these are tough standards. As for identifying "critical" non-system (application-related) files, have fun! An item might only take a few words to describe, but achieving it is another story.
Very few organizations are passing their audits the first time, and even with a June 2008 "drop-dead" deadline approaching, the failure rate even for second-repeat audits is nearly 50%. Here's a link to one analysis of the reasons for this from Verisign. As you might expect, it's a little self-serving since Verisign is a solution provider, but it's worth reading.