Month: September 2022

Posted on

Intro to PCI version 4: Requirement 3

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

Posted on

Intro to PCI version 4: Requirement 2

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

Posted on

Intro to PCI version 4: Requirement 1

Our previous discussion touched on the (very) high level aspects of what makes version 4 of the PCI DSS different than its predecessors, so now we are in a better position to dive into some of the details.  To this we are going to look at each requirement individually.  This week we are going to start at the beginning – Requirement 1. As we work through the differences, let me apologize in advance for how dry the content is going to be as you work through it.  I really wanted to make it lighthearted and fun.  I decided that the information regarding the changes was too important, and I didn’t want anyone to miss something.  I will write something clever (someday) to make up for this (and the next 11 or so blogs in this series)

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

Posted on

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

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)

Posted on

Decluttering the IT Sec Alphabet for Data Privacy

With the focus over the past few years on Data Privacy at the institutional level continuing to gain traction across the globe, it is important for companies to understand how these (potential) changes will affect their IT department.  With that in mind, I thought it good to start with some of the foundational concepts regarding data privacy.  Specifically, what role do the key players actually represent, assuming they are properly vetted and sourced to fill the correct business needs within the enterprise.  Today I will discuss three of the key leadership positions and the ideals and focus of each – in a perfect (well-funded) IT department.

Chief Technology Officer/Chief Information Officer (CTO) – The CTO, also known as CIO, is the head of the company’s technical assets

The CTO’s focus should be on making certain that the Enterprise is running as smoothly as possible and it set up to support the key business objectives.  Depending on the size of the company, the departments under the CTO umbrella have a wide range of responsibilities that have some aspect of building and supporting electronic products and/or business processes. In a nutshell, the CTO is the person that translates the executive plans for the company into “technical speak” and controls how the IT related staff works to support those executive plans.

Chief Information Security Officer (CISO – sounds like See So) – The responsibility of this position is the integrity of the technical systems

The CISO, in most situations, will report to the CTO.  IT Security is the primary driving point of this person/department.  Again, depending on the size of the company the title may change some (Director of IT Sec, VP of Cybersecurity, etc.), but the function will remain the same.  A number of companies I work with also “outsource” some of the work to internal operations or third-party companies to manage the day to day efforts, while serving in an oversight and advisory manner.  The where and how the work get’s done is less important than making sure that it is done correctly.  This group also tends to be the primary point of contact when working with external auditors/assessors on compliance related efforts.

Data Privacy Officer (DPO) – Tasked with representing the customer’s interest within the environment

This position is a relatively new position that is quickly becoming one of, if not the most important leadership position in the enterprise.  It also has a much different approach to the focus of their mission.  The Data Privacy Officer’s main focus is on the integrity and management of the customer data.  I know what you may be thinking right now.  “Didn’t you just say that was the job of the CISO?” Well, yes.  I did say something similar to that.  Let us look again.  The DPO’s main focus is on the integrity and management of the CUSTOMER DATA.  There are two subtle differences in the approach between a CISO and DPO.

  1. Customer Data – The DPO’s approach is that as a representative of the customer.  Their job is to make certain that the company isn’t doing anything that places the customer at risk or acts in a way that is outside of the agreed upon terms between the company and the customer that provided their personal data.  This is a direct response to the focus of privacy acts and regulations popping up around the globe, such as GDPR (EU Privacy) and CCPA (California) and the expectation of many more governments passing similar laws.
  2. Hierarchy – Typically the DPO is outside of the IT department.  While they are a technical resource, and require technical knowledge to do their job properly, due to the nature of them being a voice on behalf of the customer they usually report outside of IT to avoid conflicts or internal pressure that may sway them from doing their job correctly out of fear of losing it.  In larger companies the DPO will report to the legal department.  In companies that don’t have legal departments in house, they can also report directly to the President/CEO.  Of course, that does not mean there is a need to do a reorg if this isn’t how you have the structure within your company.  If things are working well and the DPO is a Rockstar – then don’t fix something that isn’t broken.
conclusion – What does this mean for the data privacy needs of your organization? 

To be honest, I cannot give a specific answer on that (without talking to you.)  My best suggestion would be to have the round table discussion with the leadership of your company and confirm that you have someone that is designated as the “voice of the customer” and get them trained on how the relevant security regulations will affect your business operations.  You can also hire a DPO.  According to Glassdoor, the average salary for a DPO (as of Sep 2022) is right at $113,000, ranging up to $277,000.  This is a national average, so cost will vary drastically based on the market.  You can also hire consultants if looking to save money on annual spending.  You could probably get a good privacy consultant for a third of the cost of a full time DPO, that can work with  your IT and HR leadership to build, design, and implement your privacy program in a compliant manner across all areas you are doing business.

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

Thanks for reading.  Talk to you soon!

Shawn Adams – @TBF_shawn (twitter)