Category: Assurance

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

For those of you that found the previous blog posts on changes in the specific requirements for PCI v4, I have some great news.  This one will be just as exciting, so get comfortable and prepare to be informed AND entertained! Requirement 3 is one of the key areas with PCI.  When you talk about a security standard specifically designed around protection of credit card data, then we all need acknowledge the importance of the part of the standard focused on actually storing that data.

Overall Thoughts

Obviously, the best plan is to not store any cardholder data, if you can help it.  For those that can’t (or won’t) avoid storing cardholder data in their environment, protecting it should be a top priority for you.  Bury it deep in the environment.  Restrict the access to as few people as possible.  Encrypt the data when it is at rest.  You get the idea.  Worst case scenario you have unencrypted data in your environment that is accessible by numerous employees.  Actually, it can get much worse than that, but I want to give you the benefit of the doubt on having some modicum of sense in this area.  We have a lot to go over in requirement 3, so I am not going to go on and on here, despite it being my nature to drone on (and on).

What’s New for Req 3 in v4

Compared to our previous requirements discussed, R3 has a fair number of new changes to it in version 4.  As previously mentioned, anyone reading the series won’t be surprised to learn that a new 3.1.2 has been added to further develop the needs to account for ownership of the PCI program. Of course, with requirement 3 you might want to go into a more detailed accountability matrix or RACI based on your environment.  Some companies will have different management chains for different types of databases (SQL v Oracle, etc.) and may have different responsible parties handling application level data management.  This needs to all be accounted for in 3.1.2.

The other net new changes for requirement 3 are:

• 3.4.2 – Technical controls to prevent copy and/or relocation of PAN when using remote-access technologies except with explicit authorization. – A policy is no longer sufficient to prevent this from happening.  A technical control/tool needs to be in place to manage this potential aspect of data management.
• 3.5.1.1 – Hashes used to render PAN unreadable are keyed cryptographic hashes with associated key management.
• 3.5.1.2 – Implementation of disk-level or partition level encryption when used to render PAN unreadable.
• 3.6.1.1 – A documented description of the cryptographic architecture includes prevention of the use of cryptographic keys in production and test environments.

Changes to the existing controls 

Changes to existing controls for requirement 3 are about the same amount as new controls.  As previously done in this post and others, we will just touch on the items in these blog posts and save detailed discussions on the changes for you to have between yourself and your trusted subject matter experts and/or consultants.  There are few that we will list below in changes that the DSS lists as “new”, but I disagree with that designation, so am placing them here under changes.  I will mark them through, so you can treat them as is appropriate in your environment.

• 3 (in general) – Clarification/guidance – Updated principal requirement title to reflect the focus on account data over the term cardholder data.  It is still the “credit card account” though, not the individual’s personal data.  That data will be covered by privacy standards.
• 3.2.a – Clarification/guidance – Combined with 3.2.b to now be 3.3.3 and added a requirement to address former testing procedures that any storage of SAD by issuers is limited to that which is needed for a legitimate issuing business need and is secured.
• 3.2.1 – Listed as “new” – Any SAD stored prior to completion of authorization is kept to a minimum during implementation of data retention and disposal policies, procedures, and processes. (Fun Fact – 3.2.1, along with 3.2.2, 3.2.3 are the only areas in the DSS that cannot be checked as N/A)
• 3.2.2 – Listed as “new” – Encrypt SAD that is stored electronically prior to completion of authorization.  (HUGE  – this is usually done in VRAM, so make sure you are doing this, or are at least capable of doing so).
• 3.2.3 – Listed as “new” – SAD stored by issuers is encrypted using strong cryptography.  (This one probably won’t have much, if any, impact on you.)
• 3.3 – Evolving Requirement – Previously 3.4.1 – Clarified that PAN is masked when displayed such that only personnel with a business need can see more than the BIN/last four digits of the PAN.  (Note – it used to be that masked PANs referred to first 6 and last 4, but they have updated the term to be BIN/Last Four, to account for some Bank Identification Numbers being longer than 6 digits).
• 3.4 – Evolving Requirement – previously 3.5.1 – Removed pads from the “Index tokens and pads” bullet for rendering PAN unreadable.

Conclusion

As you can see running through the list, the PCI council is changing both terminology and technical control requirements for how data storage is managed.  You will see this approach throughout the majority of the v4 changes.  A push for updated technical capabilities and automation, when applicable, allows for a faster reaction time when attacks happen, which lowers potential impact and risk. In the case of R3 the efforts are focused on making sure that not only are we reacting faster, but if (when) we fail to protect data from being taken by some unethical actor that has access to the environment, the usability of that data is reduced (ideally eliminated). 

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

~ Shawn

As you noticed during our discussion around the updates to requirement 1 (and if you didn’t go read that blog post), the content is pretty dry, but I try to present it in a way that is at least easy to consume and use.  That won’t change throughout the rest of the requirements, not even requirement 2 – the “common sense” requirement (as I like to call it.)  The reason I refer to it in that way is simple – If you just do things based on what just makes sense, you have achieved most of the needs for compliance in this one.  If you want to hear my thoughts on that, feel free to reach out directly for a conversation on the topic.

Overall Thoughts

As we discussed in our PCI discussion there is a major shift on ownership of the PCI program.  If you don’t dig too deeply it feels like the only motivation is to just shine a light on PCI and prevent it from being forgotten in the overall security stance of the company, and I admit I do think that is part of it.  I also think that the council is motivated by making sure the process owners are acknowledged within the organization, so they have the internal credibility and awareness of their position to act in a way that helps them be almost as agile as the threat landscape they are facing.  In IT security the defenders are mostly in a reactive mode, giving an edge to the attackers, so the shorter the reaction window is the less the impact.  Requirement 2 is designed around the idea that we reduce risk and increase the window allowed for reaction from the start, or introduction of items to the environment to begin with.  With that focus in the overhaul of Requirement 2, the updates will provide clarification on how the environmental elements are expanded and managed during the introduction period.

What’s New for Req 2 in v4

The only net new item in version 4 for requirement 2 is the new 2.1.2, which states “Roles and responsibilities for performing activities in Requirement 2 are documented, assigned, and understood.” If the previous sentence feels like I just took the same sentence from the post on requirement 1 and changed the 1 to a 2, good job remembering what we discussed in the previous blog post.  You truly might be my biggest fan! 

Changes to the existing controls 

As in our previous post dedicated to a specific section of the DSS, I am going to bullet them out for you and give a (very) brief note on them.

• 2 (in general) – Clarification/Guidance – Updated principal requirement title to reflect that the focus is on secure configurations in general, and not just on vendor-supplied defaults.
• 2.1 – Clarification/Guidance – Now will be 2.2.2 where the SSC wants to clarify the intent is to understand whether vendor default accounts are in use and to manage them accordingly.
• 2.2.1 – Clarification/Guidance – Updated as 2.2.3, adds details to the intent of the requirement for managing primary functions that require different security levels.
• 2.2.2 – Structure/format – Combined with 2.2.5, to now be 2.2.4 as a combination of what the council feels to be “similar topics”
• 2.2.3 – Clarification/Guidance – Renumbered to 2.2.5 and added details on the intent of the requirement is if any insecure services, protocols, or daemons are present.
• 2.1.1 – Clarification/Guidance – Split into two separate controls (2.3.1 / 2.3.2) to provide focus on different aspects of assessment on wireless vendor default settings.
• 2.4 – Structure/Format – Removed from requirement 2 and now part of requirement 12 (12.5.1)
• 2.6 – Structure/Format – Removed from RoC/SAQ assessments.  The council felt it was covered under other areas and no longer needed to be a standalone part of the assessment process.

Conclusion

Well, this week we had less to talk about, due to the nature and length of requirement 2 in general.  Don’t let the limited number of requirements in this section of the DSS lull you into a sense of complacency.  Reduction of risk through removing it prior to its introduction of your environment is an important step for all.  The reason I refer to requirement 2 as the “common sense” requirement, yes even when talking to my clients, is because you must be pretty naïve and brand new to the IT world to think that putting devices on the network without going through some hardening process.  As with most, if not all, items in the PCI Digital Security Standards, if it is included – someone wasn’t doing it.

When reading through the bulleted list you may have noticed that I didn’t go too deep into the changes and kept it as a high-level description on the type of change more than the actual change.  In order to not publish a book weekly I am choosing to provide some general information, so you know how to frame the conversation with your internal subject matter experts and/or your third-party experts.  I don’t want to provide detailed specifics without knowing your environment.  Even leaning in that direction would be irresponsible of me, in my opinion.

As always, if you have additional questions or feel the need to discuss payment card security (or data privacy or any other IT security/risk/privacy topic) feel free to reach out to us to continue the conversation.  If you already have a trusted consultant, good for you on finding someone that you can rely on for counsel.  Either way, make sure you are having conversations to build a better understanding of the changes happening that will have an impact on your organization.

~ Shawn

Hot, hot, hot . . . Hot Topic! (PCI version 4)

If you read the title to this blog to the cadence of the hot chocolate song from the Polar Express, well done – you win!  I have no idea what you won, so let’s just call it bragging rights.  Ok, enough of me and my strange sense of things, let’s get on to the actual “Hot Topic”, PCI DSS v4.  For those wondering, “What does that actually mean”, well – Payment Card Industry Digital Security Standards version 4.  Now you can go out and impress your friends with that bit of trivia.  Ok, back on topic.  The most talked about subject in the realm of IT security assurance is the upcoming release of new payment card security standards.

Should I be panicking and becoming a cash only business?

ABSOLUTELY – not!  The current economic structure makes it almost impossible to run a business and generate revenue sufficient to paying your expenses in a timely manner without the use of credit card transactions.  The ability to barter and trade for goods and services is an art that has been lost to the ages.  Even mom and pop businesses (what we used to call small individually owned family businesses) are able to accept card payments with little effort on their part, thanks to the likes of Square and Paypal acting as a processing partner. So the short answer is – No, don’t panic or worry.  We will get through this together.

What is THE biggest change coming from version 4?

This is a complicated answer.  A lot has changed and what is the biggest for one entity may have little to no impact on others.  Overall if I had to list what I believe to be the overall most impactful changes within PCI v4, compared to the current version (3.2.1) it would be one, or both of the following:

1. A focus on ownership and accountability.  Each of the 12 sections of requirements within the DSS has always started off with “what is the policy/standard used to govern this area and does it do so in a PCI compliant manner?”  This hasn’t changed but they have added a sub requirement to also specify who owns these processes and standards.  Who is the member of management responsible for controlling the requirements in each section and who is the person responsible for making certain the daily requirements are followed.  For those companies that have been focused on strong governance to build a robust security culture this will most likely already be documented.  For those companies that take IT security as something the “IT people handle”, this will be a cultural shift.  The days of IT security and security assurance being run out of that dark closet in the basement by lads named Roy and Moss are coming to an end.  The threat landscape continues to evolve faster than the defensive posture of most companies and we are well past the time that a secure culture is prioritized in most, if not all companies.
2. Management of the assurance process.  What does this mean exactly?  Well, it means that if you are reading the DSS, and it says you must have “insert requirement here” to be compliant, but you think for your environment you have a better way that provides more security and functionality for your specific environment – you can now do it your way.  HOWEVER, before you run down this rabbit hole you need to be very mindful of what it truly entails.   The introduction of the “customized approach” at first glance looks like an invitation to ignore the security standards and just do things your way.  To quote a great general of my time, “It’s a trap.”  Now, I’m not saying the council is setting you up for failure with this, what I mean to say is that line of thought is the trap.  The amount of work needed to use the customized approach is significantly higher than the standard way of achieving compliance.  For EACH requirement that you wish to do the customized approach with you must do a validated targeted risk assessment. (On top of the one already required and each one is specific to the individual requirement and must be done prior to the start of the assessment.) 

There are some other changes, some of them significant but these are the ones that I feel are the most widespread.  We will talk about the other changes coming with version 4 via future blogs and podcasts, so don’t worry.  We will cover it all.         

Ok, so break it all down for me.  How do I prepare for v4?

The initial steps are like any other issue or change in the environment.  Educate yourself.  Seek out blogs on topics you feel need improvement.  Read other posts, find podcasts, videos, articles.  The council website (https://www.pcisecuritystandards.org/document_library/) has a lot of great information.  Once you feel like you have a decent understanding of the v4 requirements start looking over your environment to see how it impacts your day-to-day operations.  When you identify areas that are lacking, create a workstream for a project.  Some of these will be for upgrades to processes, etc and others will be for the customized approach (and unfortunately some will be for compensating controls.)

If this sounds like a large amount of work, then that is good.  Take PCI seriously and do the work thoroughly.  Remember the goal is NOT to be PCI compliant but rather to be as secure as possible, with PCI compliance being one of your KPIs that you are achieving your goals.

Conclusion

I know we only scratched the surface on PCI DSS v4, but to discuss it all would require me to write you a book (you are welcome to print out the blogs on the topic and put them in a folder if that is what you desire – I will be truly flattered).  If you feel as though the change is too much, we understand.  Those of us here at TBF work in IT security assurance, governance, and data privacy full time and it is a lot for us to take in as well, so know that you are not alone in that feeling.  However, it is manageable with the proper processes and planning in place.  There are also other consultants out there who can help you (and will do so gladly). 

Find someone that you trust and will take the time to get to know you, your environment, and your company’s threat appetite to work with you on the preparation and transition over to v4.  You have all of 2023 to get the work done, so while there isn’t time to waste you have time to plan and take action.

As always, if you have any questions reach out to us via social media or our contact information listed on the website.

Thanks for reading.  Talk to you soon!

Shawn Adams – @TBF_shawn (twitter)