November 2022 - Shawn's Blog

November 27, 2022November 27, 2022

Intro to PCI version 4: Requirement 11

In PCI requirement 11 the focus is on vulnerability management. From all aspects – prevention, awareness, and remediation (and all steps in between).

Overall Thoughts

While at the top level this sounds a lot like requirement 5, which focuses on anti-malware, requirement 11 is more in line with the concepts of anti-threat vector. While some malware, especially the types that act as entry points for ransomware seem to fall under the auspice of “targeted attack vectors”, most are not. Requirement 11 is designed around the concepts of making sure that as a company you do the due diligence needed to protect the environment against the impact of all forms of risk and attack vectors in the environment.

What’s New for Req 11 in v4

The new controls in requirement 11 of v4 are:

11.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 10 (which was cut from 9, etc.)
11.3.1.1 – Manage all other applicable vulnerabilities (those not ranked as high-risk or critical) – The term ‘manage’ is the key to this one. Develop a program for how you will manage anything found during your scanning and testing that ranks as medium or lower. (HINT – Risk rankings and impact statements, as part of a targeted risk analysis, will probably be some great steps.)
11.3.1.2 – Internal vulnerability scans are performed via authenticated scanning – For those of you who have been running your internal scans using credentials all along, while everyone snickered at you for making compliance harder than needed – Now is your turn to have the last laugh on the matter! (Well done).
11.4.7 – multi-tenant service providers support their customers for external penetration testing – Service provider only, and ‘multi-tenant’ refers to the shared hosting environment used by some. The rest is self-explanatory. You MUST provide ways for them to do their external penetration testing (unless you are testing on their behalf as part of your service provider agreement, but that opens a whole new set of logistics).
11.5.1.1 – Covert malware communication channels detect, alert and/or prevent, and address via intrusion-detection and/or intrusion-prevention techniques – manage the different methods and com paths used by malware programs to coordinate internally and externally.
11.6.1 – A change-and-tamper-detection mechanism is deployed for payment pages – THIS. Start looking for your vendor or having conversations with your dev team (or both) on this one early enough to properly build/purchase, test, and implement. If you were happy about what feels like a relaxation in R6 on the OWASP related requirements (re: combined into a single versus several independent ones), this is part of why they feel good about being about to make that change.

What are the changes/modifications?

Requirement 11 changes/modifications are mostly focused on just providing additional details in what the expectations are going to be (along with the structural changes – of course).

11 – Clarification/guidance – Minor update to the principal requirement title
11.1 – Now 11.2.1 – Clarification/guidance – Clarified the intent of the requirement is to manage both authorized and unauthorized wireless access points. Clarified that this requirement applies even when a policy exists to prohibit the use of wireless technology.
11.2.3 – Now 11.3.1.3 / 11.3.2.1 – Structure/format – Separated requirement to perform internal and external vulnerability scans and rescans after any significant changes into a requirement for internal scans (11.3.1.3) and external scans (11.3.2.1).
11.3 – Now 11.4.1 – Clarification/guidance – Adding clarification around methodology, retention, addressing exposed risk, and definitions between ‘internal’ and ‘external’
11.3.3 – Now 11.4.4 – Clarification/guidance – Clarified that penetration test findings are corrected in accordance with the entity’s assessment of the risk posed by the security issue.
11.2 – Now N/A – Structure/format – Removed as previous requirements now covered by other controls
11.1.2 – Now 12.10.5 – Structure/format – Moved requirement for incident response procedures if unauthorized wireless access points are detected to align with other incident response items.
11.5.1 – Now 12.10.5 – Structure/format – Moved requirement to respond to alerts generated by the change-detection solution to align with other the incident response items.

Conclusion

Most of the changes and additions in requirement 11 are focused on additional clarification and guidance towards management of the vulnerability program overall. For service providers, making certain they are not preventing customers from being able to manage their piece of the environment, and using proper access and mechanisms to ensure the environment is being monitored and tested in depth. Some areas have been moved down to 12, which we will discuss next week, but for the most part the areas covered by requirement 11 are unchanged. There is a shift on the expectations on management of the environment.

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 11. We will continue to work through each of the PCI requirements each week.

November 13, 2022November 13, 2022

Intro to PCI version 4: Requirement 10

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

November 6, 2022November 6, 2022

Intro to PCI version 4: Requirement 9

In PCI requirement 9 is on physical security of data assets. Protecting the physical aspect of data integrity in your environment and after it potentially leaves your environment as well.

Overall Thoughts

On the surface physical security looks the easiest. Check IDs so that people pretending to be employees don’t walk in and take your stuff! If only it was that easy, but that isn’t the entirety of what is ‘physical security’ in the data world. Digital assets can be modified and/or compromised through ‘physical’ interaction with the media used for storage – which is the other part of the data security equation. Protecting the physical equipment from actual theft is important, but so is protecting the data on equipment/items that are deemed no longer needed for business purposes. This is the crux of physical security in the modern data era.

What’s New for Req 9 in v4

There isn’t too much new in requirement 9, from the net-new perspective. The new controls in requirement 9 of v4 are:

9.1.2 – Roles and responsibilities for performing activities in Requirement 9 are documented, assigned, and understood.es to the existing controls (surprised?) <- literally cut and paste this line from the post on requirement 8 (which was cut from 7, etc.)
9.5.1.2.1 – A targeted risk analysis is performed to determine frequency of periodic POI device inspections – The entire concept of the Targeted Risk Analysis is new to PCI. We will cover the details in a later post.

Changes in 9 v4

Requirement 9 is following the previous requirements we have discussed by focusing on managerial accountability and awareness, but is also moving in a direction to align things in ways to make it easier to manage and make more sense for internal operations.

9 – Clarification/guidance – In the overview, clarified the three different areas covered in Requirement 9 (sensitive areas, CDE, and facilities). Throughout, clarified whether each requirement applies to the CDE, sensitive areas, or facilities.
9.1 – Now 9.2.4 – Clarification/guidance – Added a requirement to address a former testing procedure bullet to restrict access to consoles in sensitive areas via locking when not in use.
9.2 – 9.3.1/9.3.2 – Structure/format – Split requirement for identifying personnel and visitors into separate requirements, Requirements 9.3.1 and 9.3.2 respectively.
9.4/9.4.1/9.4.2 – Now 9.3.2 – Structure/format – Combined requirements for authorizing and managing visitor access together in Requirement 9.3.2.
9.5/9.5.1 – Now 9.4.1/9.4.1.1/9.4.1.2 – Clarification/guidance – Removed requirement for procedures to physically secure media (9.5) and merged the procedures into the related requirements. Split requirement for storing media backups in a secure location and reviewing the security of the offline backup location at least every 12 months into 2 requirements.
9.6/9.6.1/9.6.2/9.6.3 – Now 9.4.2/9.4.3/9.4.4 – Clarification/guidance – Removed requirement for procedures for internal and external distribution of media (9.6) and merged the procedures into the related requirements.
9.7/9.7.1 – Now 9.4.5/9.4.5.1 – Clarification/guidance – Removed requirement for procedures for strict control over storage and accessibility of media (9.7) and merged the procedures into the related requirements. Split requirement for maintaining media inventory logs and conducting media inventories annually into 2 requirements.
9.8/9.8.1/9.8.2 – Now 9.4.6/9.4.7 – Clarification/guidance – Removed requirement for procedures for media destruction when media is no longer needed (9.8) and merged the procedures into the related requirements. Clarified options for destroying media when no longer needed includes either destruction of electronic media or rendering cardholder data unrecoverable.
9.9 – Now 9.5.1 – Clarification/guidance – Clarified the focus of the requirement is on “Point-of-interaction (POI) devices that capture payment card data via direct physical interaction with the payment card form factor.” Clarified that this requirement applies to deployed POI devices used in card-present transactions.

Conclusion

Even though most of the changes in R9 look to be structural, since they are combining controls and moving them around, the council considers them to be ‘clarification’ or additional ‘guidance’. This is because the movements within the order of the standard are aligning controls to be grouped with others that they feel share a common theme among them. There are some additional changes within those areas with specifics on the expectations of the physical aspect of payment card security. I don’t foresee a lot of expensive projects associated with the changes in requirement 9, but that is an assumption made with no knowledge of your environment. At the risk of sounding like a broken record, it is best to start talking to your trusted experts and any external sources early to determine the workstreams you have ahead of you coming up.

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 9. We will continue to work through each of the PCI requirements each week.