How does the PCI Data Security Standard compare with other compliance regulations?
Compliance is never fun but if I could pick which regulations I had to comply with I’d choose PCI over Sarbanes-Oxley and most of the other requirements so many of us are subject to today.
PCI is a comparatively straightforward standard with well defined scope and 12 specific requirements.
| The standard applies these 12 requirements to all system components connected to the “cardholder data environment”. The cardholder data environment is the network or portion thereof that possesses “cardholder data” or “sensitive authentication data”. Some of the PCI requirements apply to protecting specific data elements if storage of such data is stored and if so, how it is protected. PCI is one the most focused, specific and actionable security standards documents I’ve ever seen. Whereas many regulations are purposefully vague and subject to interpretation, PCI is pretty easy to follow.
|
| Get more tips from me on PCI in my webinar: Thursday, November 8, 2007 Noon Eastern Time Can’t make the live event? Register anyway to view the recorded webinar. |
What are the most challenging parts of PCI compliance?
It’s very interesting to note that while there are 12 requirements, they differ widely in how much effort they require for the average organization. While most of the 12 requirements are presented as process oriented, there are several that are mostly a one-time investment of effort with little or no ongoing work involved.
Others, such as Requirements 10 and 11 are potentially massive never ending processes. I come from a software development background and as you know I’m an Infosec guy today. In my blog I posted a chart to convey my take on the relative effort involved in the 12 different requirements of PCI DSS in terms of sustained, ongoing effort.
How can you most efficiently address the most burdensome requirements in PCI?
As you can see in the chart, requirements 10 (Monitoring) and 11 (Testing) are among the top 4 biggest requirements in PCI based on my experience with clients. These 2 requirements are also the best candidates for automation if you invest in the right tools from ISV market.
Take log management for instance. The standard mandates requirements for securing and managing audit trails and related logs against unauthorized viewing and modification. In fact PCI DSS requires a centralized log server and monitoring processes for alerting appropriate staff in the event log data is changed.
Log management is hugely laborious; manually managing and reviewing logs on a sustained basis is absolutely out of the question. Thankfully there are a host of great log management solutions out there today.
Another opportunity for automation is change management. Throughout the PCI DSS document, companies are required to recognize significant system changes and perform appropriate tests and other security related procedures to ensure the change has not introduced new vulnerabilities or risk.
What other tips do you have for folks under the gun with PCI?
Besides automating, make sure you have your scope clearly defined in terms of systems and networks impacted by PCI. The standard impacts all system components connected to the “cardholder data environment” so defining the boundaries of that environment is very important. Make sure you identify all logical data flows, physical connections and catalog everywhere “cardholder data” is stored. You may save a lot of work by eliminating some of those data stores and installing internal firewalls to scale down the “cardholder data environment” to something more manageable.
Where can I learn more from your experience with PCI?
Register for my webinar “Comply with PCI and Still Have a Life”. Even if you can make the live event this Thursday, register now and I’ll send you a link to the recorded version.
No comments:
Post a Comment