Overall Thoughts

In today’s complicated realm of IT Governance, Security, and Regulations, the need for companies to bring in outside guidance has never been greater.  I am constantly having conversations with people about what they need to be aware of to keep their data protected.  Some of these conversations happen between me and my clients.  Luckily, I have been able to put of these discussions off when they come up during a formal assessment period.  This dialogue has gotten me thinking about the need to clarify the differences between my roles as a consultant and assessor.

The main differences between a consultant and an assessor

So, what is the difference between the two?  Let us discuss the two individually and see what they each have to offer you.

• Consultants – A consultant is an independent third party that works as a subject matter expert, or SME.  The subject in which they specialize can vary across many different areas.  The key things to keep in mind regarding a consultant are:
  • Consultants are paid for their expertise/knowledge.  Consultants working in the compliance arena have expertise/knowledge of industry standards.  They are not experts on “your” environment.
  • Good communicators – The consultant should be able to help you understand the industry standard that are relevant and work with your staff to appl them to your environment through a collaborative effort.
  • End goal is to help you and their focus is on using their knowledge to assist you in achieving the goals of your company, or at the very least the engagement they were hired for at the time.
• Assessor (Auditor) – An assessor is also an independent third party that is a SME.  The similarities of the two end there.  The assessor does exactly as their name implies, they “assess” your environment against a standard, either regulatory or industry to determine your level of compliance.
  • Assessors are experts over auditing standards, usually over multiple standards but some do specialize.
  • The assessor should have some widespread knowledge of technical architecture and business processes.
  • Probably a good communicator.  I say probably because the need to fully communicate and determine compliance is a skill that makes the engagements more enjoyable, but the requirement to properly communicate rests more heavily on the shoulders of the entity being assessed.  The company will bear the brunt of a non-compliant finding, is the reason for this.  There are plenty of people that are great communicators working as auditors, so if you happen to work with someone that is not you are not required to stay with them for any reason.
  • Most important thing to note – They are there to determine your compliance with the standard associated with the engagement.  They are NOT there to help solve issues.  Once it becomes a “fix” situation, this falls under remediation and is the role of the consultant (even if it is same person doing it outside of the assessment.)

What should you expect from a consultant?

When working with a consultant you want to make certain that you work amongst your management and effected internal staff, prior to hiring/selecting the company, and person, that you will be working with on the engagement.  Prior to signing a contract, you should get everyone internally on the same page and agree to a clearly defined area of need and focus.  Consultants tend to bill by the hour, so making sure everyone is marching in the same direction, so to speak will save money by reducing the risk that you will be changing course multiple times within the efforts.

However, you also must be open minded throughout the project and accept the notion that things may change based on feedback from your consultant.  If you are not agreeable to the idea of having to do things differently then you had originally planned, you should not have hired a consultant.  It is a waste of money to pay someone to sit back and tell you how great your ideas area and add nothing else to the conversation.  Any consultant worth the money spent on them should be able to help you grow in some fashion, otherwise they are just cashing in on your lack of understanding.

Even if you have the most technically savvy consultant you can find, do not expect them to be true miracle workers.  What I mean by that is this – If they show up and impress you with a lot of amazing ideas that you have never considered and are not capable of implementing without them, how will you support the changes once they are gone?  It is one thing to have someone that has experienced so many environments throughout their career, seen every option out there throughout their travels, and able to solve any problem they come across.  It is something entirely different to find a person that can sit down with your staff, learn your environment and business processes, and come up with solutions that are custom tailored for your needs (and on your budget).  Do not be fooled or feel pressured to take on work that is beyond your company’s capabilities (technical or financial).

Managing the assessor

If you find yourself in a situation where you are going through an audit or assessment, let us discuss some behavior and thoughts to make the process easier for both you and the person working to find a determination on your state of compliance.  These are some ideas that are based on previous experiences from sitting in the room as a member of internal operations and from the other side of the table as the independent third-party assessor.

Be friendly.  It seems odd to have to state this, but there have been times when the conversation can get contentious when pouring over the details of an environment and other evidence to determine if everything looks the way it should, based on a standard that is outside the control of anyone sitting at the table.  Remember that most assessors/auditors have no personal interest in the findings, other than it being their day job and reflects on their personal and professional integrity.  No assessor worth hiring will compromise their own integrity by doing something unethical, so rest assured they will produce reports that accurately reflect what they see throughout the assessment.  You may not see eye to eye on something but find a way to convey this without crossing the line and expect them to do the same.

Keep the non-assessment chatter to a minimum and away from hot button items.  By this, what I mean is don’t say things in front of your assessor that has them questioning why it was said or if they have missed something (or worse if you are hiding something).  Here are some examples I have heard over the years that caused some undue work to prove they were only said in jest:

• Hypothetical questions – Asking an assessor during the formal engagement about some “situation where we may have done this, knowing it was not ok, but we felt we had to do it anyway.”  This will never be an acceptable conversation.  I am not advocating for you to hide things from your auditor, quite the opposite, but if it really is a true hypothetical – sit on it until after everything is wrapped up.
• Jokes about poor security and/or business practices – Between evidence reviews it is a bad idea to make jokes about “Joe from accounting that keeps his password to the financial system written on a post-it note stuck to his monitor and what a pain it is to support him because he has admin access to the systems.”  You can probably set the over/under in under 5 minutes before Joe’s desk comes into scope and you need to pay Joe a surprise visit.  Again, even if it is a joke it is in poor taste and puts your company’s compliance in jeopardy.  Best to save these until afterwards when jokes are not going to increase risk for you (or just say them internally when the assessor is not around.)

Conclusion (What is the big take away from all of this?)

So, what have we determined?  First off, consultants and assessors are mostly the same people, from a skills perspective.  While they have a focus that is opposites of each other.  Consultants are there to augment your knowledge and help you to find manageable solutions, while Assessors focus on documenting the working details of your environment in a way to show compliance to the stated standards.  Ideally you will work with a company that has enough people among their staff to allow you to negotiate a single contract that can cover all your needs.  I know that among my team at Protiviti we have multiple clients with one person serving as a consultant and someone else working on assessments.

When looking to engage either for work to be done on your enterprise do the work ahead of time to have a clear direction and understanding of what it is you need to accomplish.  This will save you time and money, while increasing the chance of you getting a result you are happy about.  When seeking out the person you are working with look for a company with a history and track record of providing knowledgeable people that can deliver in the areas where you feel you have the most need.  Once you have decided that you need/want assistance from a third-party do your homework, both from an internal and external perspective.  Talk to people you trust about who they have worked with previously and ask for contact information.

As always, I hope this tidbit of information gives you a base to have discussions with your internal management about third-party needs within your IT and Data Privacy space.  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. 

The post Consultant v Assessor appeared first on Shawn's Blog.

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

The post Intro to PCI version 4: Requirement 10 appeared first on Shawn's Blog.

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

The post Intro to PCI version 4: Requirement 3 appeared first on Shawn's Blog.

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

The post Intro to PCI version 4: Requirement 2 appeared first on Shawn's Blog.

Overall Thoughts

Keeping with the general direction of the maturation of PCI with version 4, Requirement 1 is all about expanding the language to be more encompassing of changing technologies and assuring management takes ownership of the program.  One of the common shortcomings within security programs is figuring out who will own each aspect of the program.  The more complicated the environment, the more complicated the organization structure, and the number of security standards effecting the company all play into a (sometimes) overwhelming jumble of chaos that requires numerous specializations among the staff (PCI, HIPAA, SOX, FedRamp, GDPR, etc.)  Not wanting to get lost in the shuffle, PCI is making a point (that you will see mentioned in every post in this series) regarding not losing site of the importance of protecting consumers and their cardholder data.

What’s New for Req 1 in v4

The only net new item in version 4 for requirement 1 is the new 1.1.2, which states “Roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood.”  This goes back to what I was mentioning in the previous paragraph.  A formal document stating who is “responsible”.  An interesting note though about how this is worded.  It doesn’t say to document who is responsible for requirement 1, but rather “for performing activities” are “documented, assigned, and understood”.  In short, for each requirement in section 1 of the PCI DSS you have to list who is responsible for actually doing the work, confirm it has been assigned to someone, and they have to demonstrate understanding of the processes, as the apply to PCI.

Changes to the existing controls 

A decent number of items have been changed between v3.2.1 and v4.  To keep track of them all, I am going to bullet them out for you and give a (very) brief note on them.

• 1 (in general) – Evolving Requirement – Changing the terms “routers” and “firewalls” for a more open “network security controls”.  This is done to allow for an expansion of acceptable technologies that do the work normally associated with firewalls and traditional networking equipment.  It also opens the door for some outside the box solutions, for those wanting to use the customized approach for any areas.
• 1.1.5 – Evolving Requirement – Now will be covered under 1.1.2
• 1.1 – Clarification/guidance – Now will be 1.2.1 and focus on defining and maintaining configuration standards.
• 1.1.1 – Clarification/guidance – Now 1.2.2 and has additional clarification that change control documentation in Req 1 must match those of Req 6 (6.5.1 specifically)
• 1.1.4 – Clarification/ guidance – Removed, as the SSC deemed it redundant.
• 1.1.6 – Clarification/ guidance – Split into two separate requirements (1.2.5 and 1.2.6) to allow for specific intent of each to be clearer.
• 1.1.7 – Clarification/ guidance – Is now 1.2.7 and adds more specific language around requirement to review configuration files every 6 months.  (NOTE – Do NOT read this to be twice a year, but actually every 6 months.)
• 1.2 – Structure / Format – Removed.  The SSC felt this was covered in other areas and no longer needed.
• 1.2.2 – Clarification / guidance – Renumbered to 1.2.8.  Additional clarification on intent of securing configuration files.
• 1.2.1 – Clarification / guidance – Split into 1.3.1 and 1.3.2 to provide clarity around the intent.
• 1.2.3 – Clarification / guidance – Changed to 1.3.3 and provides additional details on the intent behind security controls between the CDE and wireless networks.
• 1.3 – Clarification / guidance – Renumbered to 1.4.1 to add specifics on the need for security between “trusted” and “Untrusted” networks.
• 1.3.1/1.3.2/1.3.5 – Clarification / guidance – Combined these three previous requirements to provide a focused intent on restricting ‘inbound’ traffic from untrusted networks.
• 1.3.4 – Clarification / guidance – Removed.  SSC also felt this one was redundant.
• 1.3.6 – Clarification / guidance – Is now 1.4.4 to provide clarity around security that prevents direct access to cardholder data stores from untrusted networks.
• 1.4 – Clarification / guidance – Now listed in the DSS as 1.5.1 and provides clarity for securing devices that connect to both the CDE and any untrusted networks.

Conclusion

Whew!  If you are still with me, then congratulations.  You have shown a dedication to IT security, specifically PCI security that makes you a true leader in your environment.  I don’t currently have a fancy plaque to present to you but know that I am proud of you.  Now, as I stated at the start of our road through requirement 1, it was going to be dry and full of bullets.  I feel like I delivered as promised (sorry).  As PCI continues to mature and adapt to the ever-changing threat landscape, we will continue to discuss it and make sure you have a base understanding of the changes.

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

The post Intro to PCI version 4: Requirement 1 appeared first on Shawn's Blog.

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)

The post Hot, hot, hot . . . Hot Topic! (PCI version 4) appeared first on Shawn's Blog.