Well PCI 3.0 is finally here and your due date for compliance is January 1st, 2015. Are you ready? Answers to this question may vary from yes, no, probably, and I don’t know. Here is another question you can use to evaluate whether you are ready. Does your organization treat PCI compliance as “Business as Usual”? Let’s first define what we mean by that. “Business as Usual” implies that PCI DSS compliance activities occur throughout ongoing business processes and are not just executed during annual compliance audits. Here are some additional questions to help you determine if you are “Business as Usual”.
- Are all processes and procedures defined within the PCI DSS fully documented within your organization? (access management, patch management, vulnerability management, etc.)
- Do you monitor PCI DSS controls to identify control failures and remediate them in a timely fashion?
- Is your PCI DSS processing environment free of any software, hardware, or applications classified as End-of-Life (EOL) by the vendor? (Think XP and soon to be Windows 2003)
If you answered “yes’ to all of these then you are probably ready and can stop reading now. If you answered “no” to any of the above then you have some work to do. Read on and hopefully we can provide you with some additional ideas on getting to “Business as Usual”.
Let’s Get Critical!
So one of the key components stressed by the PCI Council is that PCI DSS controls are monitored to identify control failures and to remediate those failures in a timely fashion. Wow! Doing this may seem daunting and it certainly can be depending on the size of your organization. Large organizations may even setup formal compliance programs that monitor controls on a continual basis. Even in these organizations much of the work is done through manual reviews with process owners and/or point in time audits. I’ll let you in on a secret. With the right tools and data, controls can be monitored in almost real-time. Let’s spend a bit of time first on the tools that one could use to make this possible.
Tools of the Trade
Do you have tools to get the job done? You should have some of these if you are PCI compliant. They provide a wealth of information and functionality that can be used for monitoring critical PCI DSS controls. Here is a brief summary of each:
- Vulnerability Scanner
While this may seem obvious, a vulnerability scanner can be used to monitor other configuration items beyond just checking for vulnerabilities. Additionally, vulnerability scanning tools collect a lot of valuable data that can be mined to monitor controls and control processes to ensure you will stay PCI compliant. - Patch Management Tools
Like vulnerability scanners, patch management tools can also provide a wealth of information. Logs from these tools can be fed into security information and event management tools (SIEM) to monitor patching status, demonstrate that patch management processes are occurring, and identify failed patches or outliers that have escaped the patch management activities. - Systems Monitoring Tools
Another great way to monitor controls is with system monitoring tools. Do you use Big Brother or Nagios? Well you may be in luck. These systems can often be configured to validate system configurations or check logs for various activities such as patching. - Intrusion Detection, Data Loss Prevention, Network Analysis Tools
With a couple of simple signature/configuration changes these tools can monitor for default passwords/account usage, clear-text credit card transmission, and insecure protocols. - Configuration Management Tools
There are a lot of interesting configuration management tools in environments these days. Tools such as Puppet, Chef, Salt, Ansible, Microsoft SCCM, and BMC allow for the ease of operations management while offering some interesting possibilities to not only monitor but enforce various security configurations. - Security Event and Information Management (SIEM)
With the right data collection a SIEM tool can become the central monitoring point for your PCI DSS compliance program. SIEM solutions are designed to accept data feeds from a variety of systems. Mostly deployed for tactical use, the SIEM can be used to bring executive level visibility to compliance problems.
Manipulating the Data
Now that we have collected all this data, what can we do with it? Well, from a PCI compliance prospective we need to transform it from something very tactical to something more strategic. These days we need to answer the question that our customers, leadership, and boards are asking and that is “Are you PCI compliant?”. Reliance on subjectivity will simply not work any more. You and your QSA need actual data.
I’ve compiled a quick list of controls and potential data points that can be used to monitor compliance. Keep in mind that this is not an exhaustive list, but simply a starting point. You’re limited only by your imagination and the data collected.
| PCI DSS Requirement | Tools Description | Example Reporting |
|---|---|---|
| 1.1.6.b Identify insecure services, protocols, and ports allowed; and verify that security features are documented for each service | Security Information and Event Management System or Configuration Management Tools Used to identify insecure port usage. |
Report identifying insecure (i.e. FTP, LDAP, etc) protocols and where they are in use. For instance, internal to enclaved networks, PCI networks, or Internet facing segments. |
| 2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. | Vulnerability Scanning Tools Used to test for default password usage. |
High-level report showing summary of environments and whether they contain systems with default passwords. |
| 4.1 Use strong cryptography and security protocols to safeguard sensitive data during transmission over open, public networks. | Network Intrusion Detection, DLP, Network Analysis Tools Used to monitor traffic for clear-text cardholder data. |
Report showing that internet egress points are monitored and metrics indicating number of violations. |
| 5.2 Ensure that all anti-virus mechanisms are maintained as follows: • Are kept current • Perform periodic scans • Generate audit logs which are retained per PCI DSS Requirement 10.7. |
Security Information and Event Management System Used to collect and report on anti-virus activity. |
Report showing that internet egress or ingress points are monitored and metrics indicating number of violations. |
| 8.1.1 Assign all users a unique ID before allowing them to access system components or cardholder data. | Security Information and Event Management System Used to monitor non-user account activity. |
Report demonstrating that no shared accounts are used for SSH/RDP access. |
Compliance and the Future
I hear a lot about how compliance does not equal security. However, according to the latest Verizon breach report, most environments do not even come close to meeting the compliance baseline. How can we ever hope to be secure if we can’t hit contractual baseline security requirements? Let’s be honest, that’s what we should be calling them, contractual security requirements. You don’t have to take credit / debit cards as part of your business process. You choose too, and as such you must agree to adhere to the security requirements outlined in the PCI DSS. Continuously monitoring these controls will help to ensure that you are meeting these security requirements as well as protecting your customers.
A bunch of information on PCI is available from AlienVault here. The blog author, Jeff, is with AlienVault partner, Terre Verde.