I question whether or not there really is a need to change the PCI DSS this Fall. You look at the requirements and if they were truly followed as designed; the vast majority of breaches would either not occur or would be fairly limited and contained. But when you look at the breach reports from Verizon, Trustwave and the like, they tell a different story. Most breaches were the result of one or more PCI requirements that just were not working properly and a breach occurred as a result.
I think where the changes need to be made is in the assessment process as I believe this is where the most impact could be realized. The current assessment process falls way short in confirming that an organization is complying with the PCI DSS all of the time, not just when the QSA is around. This results in the very valid complaint by PCI critics that the process is a “check the box” approach.
If you look at the current PCI assessment process, it tests a very limited number of requirements over the period of time of the assessment. QSAs only ensure that an organization has had: four quarters of passing external and internal vulnerability scans (11.2), quarterly facility wireless scanning (11.1), and that any changes to the cardholder data environment have been appropriately documented and approved (6.4). All of the other requirements are assessed whenever the QSA assesses them at that point in time. The rest of the time the organization could be non-compliant and the QSA would be none the wiser.
If we are truly going to address the findings in these breach reports, we need to be ensuring that organizations comply with the PCI DSS all of the time. That means that QSAs need to be testing more requirements over the assessment time period to ensure that an organization is actually complying with requirements.
Based on that premise, here are my recommendations.
- Change controls. The PCI DSS requires QSAs to request all changes to the CDE so that they can determine if more than quarterly vulnerability scanning and annual penetration testing was required during the assessment period. The breach reports indicate that attackers are consistently finding simple misconfigurations as a way into networks which means that change control is likely not being followed consistently. QSAs should be testing the entire change control process to ensure that changes to infrastructure are being appropriately tracked, reviewed and approved throughout the assessment period. The reason is that we regularly encounter information security personnel that are only involved in evaluating and reviewing changes that affect PCI compliance and nothing else. We also encounter instances where only changes that affect PCI compliance are tracked. You have to wonder how changes are determined to affect PCI compliance. Obvious changes to the CDE are easy to identify. But other changes could implicitly affect the CDE but not necessarily be identified as such because the people reviewing them do not see the connection. As a result, organizations have no idea if changes outside of the CDE could impact their PCI compliance because there is either no record of those changes or information security has not been consulted. These organizations are typically relying only on luck to protect them.
- Mitigation of vulnerabilities. Most QSAs assess patching by reviewing the quarterly vulnerability scans and making sure that vulnerabilities do not appear on the next quarterly scan. If any vulnerabilities appear on subsequent scanning reports, then QSAs are supposed to assess what mitigating controls were put in place while the vulnerability was unpatched. QSAs typically do a pretty good job proving that organizations’ patching processes work reliably. But when it comes to mitigation, QSAs do not necessarily do a great job determining that open vulnerabilities are truly mitigated. This is not always the QSA’s fault as the organization may not be keeping the necessary documentation to support that open vulnerability risks are being mitigated. The bottom line here is that the assessment process needs to assess all vulnerabilities that were left unpatched during the assessment period to ensure that they were mitigated while they remained unpatched.
- Access controls. As with change controls, the current PCI assessment process only requires the QSA to test the accounts of those accounts that have access to the cardholder data environment (CDE). To add insult to injury, most organizations have multiple access control systems in use for securing servers, infrastructure, third party monitoring, etc. All of these systems are typically in-scope for assessment, but a lot of QSAs focus only on those in-house. Access control is an all or nothing proposition, you are either doing it consistently across the board or you are not. Based on the breach reports, attackers are using whatever accounts they can to get a foothold and then work their way to accounts that provide more privileges. If that is the case, then how will testing only accounts that have access to cardholder data (CHD) help this situation? It does not. Therefore, the assessment of access controls needs to look at the whole picture, not just a privileged few. The bulk of testing of the process may be relegated to those with access to CHD, but the entire process of granting and revoking access needs to be assessed to ensure that controls are being followed for everyone. Testing of privileged accounts needs to be enhanced to address what those accounts have access. Do the DBAs have administrative access to the OS? Do network administrators have administrative access to servers? Do system administrators have administrative access to network devices? These are just examples of questions that a lot QSAs do not answer during their assessments. A lot of QSAs are only interested in determining that privileged access is controlled, not who has access, why they have access and is that access justified.
- Monitoring and Alerts. QSAs are to ensure that logging and alerting is enabled as part of their testing. QSAs are to ensure that an organization has log data online for at least three months and offline for a year. QSAs then move to observing the various monitoring consoles to ensure that alerts are generated. However no testing is done for the period of the reporting period to ensure that alerting functioned as configured by sampling the alerts generated and then ensuring that those alerts were properly investigated to ensure they were not serious or required further investigative techniques. Based on the breach reports, anomalies are not being researched and this is resulting in breaches taking months to identify or, worse, going unnoticed.
- Sampling. Finally, testing needs to be more than just testing three or four items in each of these categories. There needs to be sampling over the entire assessment period not just the day the QSA is investigating the requirement or one item per quarter. A random statistic sample would be best but given populations that might be not feasible in the time frame required to produce a report. However it is not inconceivable that this could result in at least 50 to 100 items being tested in some of these categories.
These are the key tests that would go a long way in improving the assessment process and address the findings from the breach reports. The trouble is that this sort of enhanced testing is obviously going to drive up the cost of a PCI assessment whether the QSA does the testing or an organization’s internal audit function does the testing. If the PCI SSC and the card brands are truly serious about making the standards meaningful, then this is where I would focus, not on making changes to the standard.
Remember my mantra, “Security is not perfect.” So while these changes are not going to absolutely, positively prevent all breaches, they will go a long way in ensuring that organizations are as secure as they can be all of the time rather than just when the QSA is around.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
