A laser focus on PCI compliance
The QSA has to understand the scope of the audit. To help, we provided things such as network and data flow diagrams, a list of hardware and software assets and the names of everyone who has a significant level of access to the environment that we use to store customer credit card data. With this information in hand, we met with our QSA and narrowed the scope to our two production data centers and our disaster recovery data center, where we store customer credit card data. Because we use very strict firewall rules and proper physical and logical segmentation, our very large corporate IT infrastructure is not in scope.
And now the fun begins. Of those more than 400 controls, it is just a few that tend to get companies in trouble. One of these pertains to security incident and event management (SIEM). If you have a robust SIEM infrastructure, a dedicated security operations center or a managed service, you'll probably do well. I wish that were the case for us, but our SIEM program is still in its infancy. We're working on selecting and then implementing a robust SIEM tool, but for now we are still doing things via log collection, scripts and the manual review of events. That makes it difficult for us to prove that we can reliably identify and take action on security attacks. We do an OK job but could really use the help of a modern event correlation product or service.
Another area that many companies are weak in is configuration management. I'm hopeful that we will be OK. We use standard baseline images for our Microsoft Windows, Linux and Cisco operating systems and major applications, such as Apache and Oracle, which follow most of the recommendations from the Center for Information Security. We also have integrity-checking software that monitors when any of the configurations have changed from the initial baseline. I know the QSA will choose a sampling of identified devices (servers, firewalls, routers, etc.) and match the configuration against our defined baseline, and given our procedures in this area, I think we'll pass this portion of the audit without any problems.
Then there's vendor management. Some of our vendors process credit cards and must meet new, more rigorous PCI rules for third-party vendors, including some that relate to contract wording. This will affect things like our content delivery network (CDN). Many of our CDN vendors decrypt network traffic in order to inspect it for Web application security issues and other things before re-encrypting it and sending it to our servers. Since that traffic may contain credit card data, those vendors will have to be in compliance.
The new requirements for PCI compliance will also require regular testing of our infrastructure, including application and system penetration tests from both external and internal locations. Of course, it's a constant struggle to ensure that our apps and servers are maintained in a secure manner. We already run monthly credentialed and non-credentialed scans from our internal network, and we have two qualified application security vendors and other vendors run scans against our infrastructure from the public Internet. We are well aware of the value of this. Our main application goes through many changes throughout the year, and it's all too easy for a programmer or system administrator to inadvertently introduce application vulnerabilities such as cross site scripting or open redirects or for a sysadmin to forget a vendor patch.
Gaining the PCI stamp of approval will take months. I will be reviewing policies, ensuring that processes are in place and generating the plethora of evidence needed by the auditors to prove that we meet the hundreds of requirement imposed by PCI.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.
Click here for more security articles.