In PCI requirement 10 is about actively watching the activity within your environment and keeping records of what’s happening, so you can investigate when something does go wrong. That isn’t always due to someone compromising your systems, but it is one of the possible use of event logs.
Overall Thoughts
This is the most reactive element of IT security. Keeping records of what is happening by its very nature can only present you with needed data AFTER the event has taken place. To be fair the very nature of IT security frameworks is all reactive, as they adjust to changes in the landscape. At least that is the only noticeable way to view it. If changes are made ahead of a new threat, no one notices that threat – since it has been already made a non-threat. (If a tree gets hacked in the woods and no one hears it, do we even wonder how it got internet or what it was doing with it? Probably not).
What’s New for Req 10 in v4
There isn’t too much new in requirement 10, from the net-new perspective. The new controls in requirement 10 of v4 are:
- 10.1.2 – Roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and understood.es to the existing controls (surprised?) <- literally cut and paste this line from the post on requirement 9 (which was cut from 8, etc.)
- 10.4.1.1 – Audit log reviews are automated. A clear attempt at minimizing risk associated with human error (or bad faith internal actors).
- 10.4.1.2 – A targeted risk analysis is performed to determine frequency of log reviews for all other system components. Do the due diligence to check the risk of other possible entry points into your sensitive system areas from other internal points.
- 10.7.2 – Failures of critical security control systems are detected, alerted, and addressed promptly. Combined with the new 10.4.1.1, this one is all about reduction of time to respond.
- 10.7.3 – Failures of critical security control systems are responded to promptly. It feels redundant, since 10.7.2 clearly states “addressed promptly”, but this control is the SSC being very specific that a response of some fashion is the only acceptable way to “address it”. What is the difference between a “response” and something being “addressed”. To be short with the answer – action taken.
Changes to v4.10 (Looks like a kid’s shotgun written this way – BAM!)
Requirement 10 is mostly changing the focus on the use of automated solutions when reviewing log files. They are even changing the language to refer to “audit logs” instead of “audit trails”, to further reinforce the idea that event monitoring is key, along with technical solutions to provide alerts to the correct people and start the investigation process (ideally via ticket creation).
- 10 – Clarification/guidance – Updated principal requirement title to reflect focus on audit logs, system components, and cardholder data. Clarified that these requirements do not apply to user activity of consumers (cardholders). Replaced “Audit trails” with “Audit logs” throughout.
- 10.2 – Removed – Structure/format – Removed “null” requirement (all content pointed to other requirements).
- 10.5 – Removed – Structure/format – Removed “null” requirement (all content pointed to other requirements).
- 10.5.1 – 10.5.5 – Now 10.3.1 – 10.3.4 – Moved audit log protection requirements under Requirement 10.3.
- 10.5.3 / 10.5.4 – Now 10.3.3 – Structure/format – Combined requirements to align similar topics.
- 10.6 – Removed – Structure/format – Removed “null” requirement (all content pointed to other requirements).
- 10.6.1 – 10.6.3 – Now 10.4.1 – 10.4.3 – Structure/format – Moved requirements for audit log reviews to 10.4
- 10.7 – Now 10.5.1 – Structure/format – Moved requirements for audit log history to 10.5.1
- 10.4/10.4.1 – 10.4.3 – Now 10.6.1 – 10.6.3 – Structure/format – Moved time synchronization under 10.6 and reorganized.
- 10..8 – Now 10.7.1 – Structure/format – Moved service provider only requirement to detect, alert, and promptly address failures of critical control systems to Requirement 10.7.1.
Conclusion
As you can see by looking over the exciting, bulleted list (?) of changes to requirement 10, almost all of them are only structural changes. The one that isn’t is focused on the semantics of “trails” versus “logs”. Even with those minor changes and the short list of new controls, don’t let your guard down on this one. Most of you are probably already doing some form of automated log review and alerting system. Take the time to go through it and confirm it is configured to remove the manual processes as much as the technology will support. It would be a good idea to also go through your firewall access lists and do the TRA on all potential entry points into your environment. My advice would be to look over each VLAN managed by the firewalls that control access to sensitive networks and do a separate TRA on each of them. For some this will likely take only a few minutes. Others will require a deeper dive, but in either case it is worth the effort – even if you think it only a tool towards compliance.
As always, I hope this tidbit of information gives you a base to have discussions with your internal subject matter experts and your trusted external sources for IT security and PCI knowledge. Feel free to reach out to me directly with questions or to have a conversation via my email and/or social media information on the TBF website. Thanks for taking the time to read my thoughts on PCI v4 Requirement 10. We will continue to work through each of the PCI requirements each week.
~ Shawn