By Tim Cranny
Panoptic Security Inc.
This installment of our multipart series drills down on the tenth of the 12 requirements of the Payment Card Industry (PCI) Data Security Standard (DSS). I will discuss what the issues are, what merchants need to do, and what their ISOs, banks, or processors can do to help them.
Requirement 10 is "Track and monitor all access to network resources and cardholder data." It is the first half of the section "Regularly Monitor and Test Networks."
The core idea behind Requirement 10 is that security has to be an active, ongoing process: you cannot simply "get safe" and then turn your attention away.
Instead, you need to do your best to get safe and then stay vigilant, looking for and responding to signs of attackers who have penetrated your defenses, or are trying to.
Requirement 10 is specifically about merchants' computer networks. It requires merchants to track and record who is accessing which systems; what actions they take; what actions are attempted; and the details of who, what, where, when and how. These records are called audit logs; they are critical in identifying what is going on in merchants' networks.
You can think of audit logs as the inside-the-computer equivalent of a security camera that sees and records all actions, good or bad, so that someone can then review them as needed or watch them in real time.
The distinct Self-Assessment Questionnaires (SAQs) treat Requirement 10 very differently, with the most complete one (SAQ D) treating it in detail, and the other, shorter ones (A through C) ignoring it completely.
When I talked about Requirement 9 in "Digging into PCI - Part 9: - Restrict physical access to cardholder data," The Green Sheet, March 22, 2010, issue 10:03:02, I mentioned how physical security issues seemed natural and obvious to most merchants, and how that knowledge helped alleviate problems in complying with that part of the PCI DSS.
Unfortunately, Requirement 10 is the opposite. It is one of the sections that can give merchants the most pain and confusion.
Very few merchants are familiar with the need for logging and monitoring; to many, the demands of Requirement 10 seem both unnecessary and excessive. In addition, the solutions seem hard to find, complicated and unrewarding.
In reality, much of that resentment is unfounded and unwise. Computer systems do need to be "watched." In recent years, we have seen dozens of stories of security disasters that could have been prevented (or nipped in the bud while they were still tiny issues) if only the systems in question had been properly monitored.
The main challenges of Requirement 10 are that it requires both continual effort and software solutions that are foreign to most small merchants. Either of these issues in isolation would be a problem, and the combination is particularly painful.
As with other parts of the PCI DSS, merchants should endeavor to avoid or minimize the challenges of Requirement 10, rather than defeat them.
While the SAQs and the PCI DSS itself are inconsistent on some issues here (and when that happens, the Standard is the ultimate authority), it is clear that the fewer computers one has involved in card data transmission and storage, the less work is required to handle Requirement 10.
To comply with Requirement 10, merchants need to set up their computer systems so the following actions are automatically "noticed" and put in an audit log:
A common problem with log-keeping is missing logs. Some logs go missing because the systems that would generate the logs are simply not being collected from. To get complete coverage, logs should be collected from:
As always with the PCI DSS, one can ignore computers that do not deal with cardholder data at all, so long as they are not connected to computers or systems that do.
For audit logs to be useful, merchants also need to:
Fortunately, for most of the above issues, solutions are available, and there is little need to create your own. As always, though, the parts of Requirement 10 that talk about procedures (for example, the regular checking of logs) require more than hardware or software - you have to do the work yourself or pay someone to do it for you.
One important "gotcha" pertaining to audit logs can be a spectacular way of shooting yourself in the foot: be very careful not to record in your audit logs any of the things that you're not allowed to record anywhere (customer PINs, card verification value numbers and so on). Requirement 10 does not ask you to record this information, so there's no upside in doing so. But there is a huge downside: massive risk and an instant PCI failure.
Requirement 10 is a challenging aspect of PCI compliance for most merchants, and therefore they greatly appreciate even a little assistance with it. The first step, as always, is to give merchants advice on how to minimize their compliance burdens. By reducing the number of devices in the scope of PCI, the pain and cost of Requirement 10 can be significantly reduced.
Secondly, because a number of solutions can help with Requirement 10, simply pointing merchants in the right direction takes relatively little effort and helps them start to take control of the issue. (A simple search online for the terms "security information," "event management" or "log management" will reveal a healthy crowd of vendors offering solutions.)
Historically, most vendor attention has been on larger organizations, but some solutions are now offered as relatively low-cost services, which is a beneficial development for smaller merchant businesses. In short, this part of the PCI DSS is painful, but as the available tools and services improve, it is slowly becoming a little easier to manage.
Dr. Tim Cranny is an internationally recognized security and compliance expert and is Chief Executive Officer of Panoptic Security Inc. (www.panopticsecurity.com). He speaks and writes frequently for the national and international press on compliance and technology issues. Contact him at email@example.com or 801-599 3454.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.Prev Next