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.

So, what exactly is this and how is it different?

At first glance most of you see this and think to yourselves, “I already do risk assessments, so I am good.”  That line of thought would be a fast pass (don’t sue me Disney) to non-compliance.  This new process is not the same thing as the current risk assessment you are required to do on an annual basis.  Let’s look at the change in terminology and discuss what that means for you.  The annual risk assessment is now a targeted risk analysis.  An assessment is a form of judgement.  To perform an assessment, you need a set of prescriptive controls, or standards (like PCI) that can be used as a guide to measure against.  In the end, a summary finding, or judgement, can be issues on if the control requirements were met.  This is how PCI works under version 3.2.1.  They say, “passwords need to be at least 7 characters” and your environment password settings are judged against that required standard and found compliant or lacking (non-compliant).  How does this relate to the TRA?  Directly it doesn’t (unless it does for you specifically, but more on that later), but is just an example of what an assessment is in its purest form.

Ok, so that is an assessment.  What is an analysis?  My favorite way to answer this question, as it pertains to PCI is from the 2^nd listing at dictionary.com: “this process as a method of studying the nature of something or of determining its essential features and their relations”.  Looking at the nature of the risk for a specific system to better understand the “essential features and their relations”.  What are the risks to this system and let’s track them, dig into them, and determine the true likelihood and impact of a compromise.  In a nutshell, you are now going to look at potential attack vector points through the microscope of “How, what, when, WHO, and how bad” to determine individual system/environment threat appetite. 

Ok, so there is a difference.  What do I do with this information?

Great question internet user!  In PCI v4, the TRA is the gatekeeper for doing a customized approach for any of your controls.  To use the customized approach, it requires that the entity being assessed has performed a TRA for EVERY control addressed by a method of compliance that is outside of the standard control language/requirements.  With the change of approach for PCI coming in version 4 (meeting security objectives over just meeting the standard – for you TTRPG gamers it is RAI v RAW), the ability to document and justify why security in place is sufficient for PCI compliance is required.  Any (all) TRAs in use within the entity must be developed, tested, and implemented prior to the start of your annual PCI assessment.  On top of that, the QSA that works with you to develop the TRAs within your environment CANNOT be the one performing your assessment (checks and balances).  My advice would be to take that aspect seriously and engage a secondary QSA-C for development of the TRAs from the one doing your assessment, if you can find one doing this level of work. 

There are also some situations where the TRA can be used to determine how often security reviews need to take place.  It is no longer a default to do everything on an annual basis, instead companies are expected to understand their risk in enough detail to make the judgement call on how often these take place.  Sometimes, due to system isolation and lack of modifications (or system delicacy) you may not feel it is needed to do security reviews more than every couple of years.  Other systems, due to sensitive nature of the work being done and possibly high turnover of the workforce with access to the data, you may need to do some formal review process quarterly – or monthly.  I know this was written vaguely, but I want you to be aware of this so a conversation with your QSA of choice can take place, not influence you in any specific direction.

Conclusion

On initial glance the TRA looks to be less work than the current risk assessment being conducted for v.3.2.1.  This, however, isn’t the case.  To do a proper job, with sufficient environmental coverage, requires you to start with the current risk assessment process most likely as a way of identifying the area in need of the TRA.  There isn’t a requirement for a risk assessment to be conducted for the identification of areas needing a targeted risk analysis.  You can just use them when your security team opts for the customized approach, or as a justification method for modifications to some of the PCI annual reviews (FYI – this would also be considered a customized approach process).  However, which ever path you take the TRA is going to require that extensive knowledge in the areas of risk analysis, your environmental factors (technical, process, human factors), and possibly threat modeling and custom security control creation.  These are all the areas utilized when using the targeted risk analysis in your toolbox to assist with achieving compliance, and overall security.

As always, thank you for taking the time to read my thoughts on this.  I know we could go much deeper into the topic, and I would love to provide any details that interest you on this (or any other topic).  If you already have a trusted security expert in your organization and/or as a third-party consultant, reach out to them and seek a better understanding of this process ahead of the implementation of PCI v4 in your environment as the assessed against standard.  Most companies won’t (and shouldn’t) use customized approaches during their assessment.  That is something for the truly mature security programs, but that doesn’t mean you shouldn’t talk it over with your relevant sources and make the determination that is best for you and your company.

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.

Cheers – Shawn!

The post PCI v4 – Targeted Risk Analyses (TRA) appeared first on Shawn's Blog.

Overall Thoughts

Almost all of the items here are only applicable for service providers.  If that is not you, it still may be worth the 2 minutes it takes to read this post to make sure you know what to expect from any service providers engaging with you in these areas.

What’s New in the appendixes for v4

• A1.1.1 – The multi-tenant service provider confirms access to and from customer environment is logically separated to prevent unauthorized access. Deeper dive into the management of the hosted (now called ‘multi-tenant’) environment. 
• A1.1.4 – The multi-tenant service provider confirms effectiveness of logical separation controls used to separate customer environments at least once every six months via penetration testing. Make sure you are including this in your pen testing now.
• A1.2.3 – The multi-tenant service provider implements processes or mechanisms for reporting and addressing suspected or confirmed security incidents and vulnerabilities.
• A3.3.1 – Failures of the following are detected, alerted, and reported in a timely manner:
  • • Automated log review mechanisms
  • Automated code review tools.

None of the existing controls within the appendixes are being adjusted or modified.

Conclusion

So, as I stated at the start of the post, almost every change to appendixes is focused on service provider.  As you can see, it is even more specific to “multi-tenant” (or what we used to call shared hosting) service providers.  The goal here is to make sure that the QSA is doing the proper due diligence when looking into the environment’s client access management, to prevent one customer from being able to access and view information from another.

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 Appendix changes.  Now that we have gone through the incremental changes to the requirements for PCI v4, we will start a series on some of the other changes coming up as we come to the end of the year.

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

Overall Thoughts

Requirement 12 has been the backbone of the PCI program management process.  The majority of the focus is on the management of processes, risk, and third parties.  In v4 this does not change, but there are some changes and updates worth mentioning.

What’s New for Req 12 in v4

The new controls in requirement 12 of v4 are:

• 12.1.2 – So unlike all the other requirement updates, the SSC does not add in a new control for 12.1.2.  Then why do I mention it?  Only as an anchor to reference the lack of it, so you aren’t confused and thinking I forgot it (as if!)
• 12.3.1 – A targeted risk analysis is documented to support each PCI DSS requirement that provides flexibility for how frequently it is performed.  Where TRAs are used, you need to determine the “R” and impact probabilities to use as the determining factor for how often you perform the TSA.  Some areas this might be annually and others it could be quarterly, monthly, or every couple of years.
• 12.3.2 – A targeted risk analysis is performed for each PCI DSS requirement that is met with the customized approach. (ie – if you are going to use the customized approach towards compliance, you need a TRA for EACH control.  Not one per assessment, but one per control).
• 12.3.3 – Cryptographic cipher suites and protocols in use are documented and reviewed. – Basically, you need to create an inventory type record of the different cipher suites and protocols in the environment, along with a review process to ensure that it is stays accurate.
• 12.3.4 – Hardware and software technologies are reviewed. Be MORE proactive with your inventories and manage support contracts/models.
• 12.5.2 – Requirement to document and confirm scope of PCI compliance annually. Prior to your PCI assessment, the company needs to review the cardholder data environment (CDE) to validate the scope is accurate.  This does not replace the scoping efforts required of the QSA but should make the process significantly easier (if done correctly).
• 12.5.2.1 – PCI DSS scope is documented and confirmed at least once every six months and upon significant changes. Additional requirements for service providers.  In a nutshell this is the same as 12.5.2, but the frequency has changed.
• 12.5.3 – The impact of significant organizational changes on PCI DSS scope is documented and reviewed and results are communicated to executive management. Another service provider control, focusing on changes to employee resources.  If administrative staff leave, document what was done to manage the impact to the environment.
• 12.6.2 – The security awareness program is reviewed at least once every 12 months and updated as needed. On top of doing the required training within the company, you must also formally review the training program itself and document the process.  Looking to improve and make corrections that have such a major impact on the security culture of the company.
• 12.6.3.1 – Security awareness training includes awareness of threats that could impact the security of the CDE, to include phishing and related attacks and social engineering. Adding in requirements for employees to be taught about the different entry points they have some form of risk associated to them.
• 12.6.3.2 – Security awareness training includes awareness about acceptable use of end-user technologies. (Same as above, but different topics).
• 12.9.2 – TPSPs support customers’ requests to provide PCI DSS compliance status and information about PCI DSS requirements that are the responsibility of the TPSP. This one is something I am glad about.  It is service provider only and requires for a process to provide the proof of compliance to your clients AND the ever-elusive Responsibility Matrix.  It is very common for me to have clients that can’t get this from their providers and must create one for themselves.  If the service provider doesn’t agree with what is written, this responsibility matrix isn’t worth much.
• 12.10.4.1 – A targeted risk analysis is performed to determine frequency of periodic training for incident response personnel.
• 12.10.5 – The security incident response plan includes alerts from the change- and tamper-detection mechanism for payment pages. The expansion of FIM, or something similar in functionality for payment pages.  Some could make the argument that even if you are using iFrames to outsource this, you should be monitoring the pages with the links to those as well, to prevent someone from changing that page and redirecting to their own iFrame for card capture.
• 12.10.7 – Incident response procedures are in place and initiated upon detection of PAN.

Changes to 12 in v4

Requirement 12 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).

• 12 – Clarification/guidance – Updated principal requirement title to reflect that the focus is on organizational policies and programs that support information security.
• 12.2 – Removed – Evolving Requirement – Removed requirement for a formal organization-wide risk assessment and replaced with specific targeted risk analyses (12.3.1 and 12.3.2).
• 12.4 – Now 12.1.3 – Evolving Requirement – Added formal acknowledgment by personnel of their responsibilities. Executive management will now be required to sign a document confirming they are aware of their responsibilities.
• 12.5 / 12.5.1 – 5 – Now 12.1.4 – Clarification/Guidance – Clarified that responsibilities are formally assigned to a Chief Information Security Officer or other knowledgeable member of executive management. Merged requirements for formally assigning responsibility for information security.
• 12.3 / 12.3.1 – 9 – Now 12.2.1 – Clarification/Guidance – Clarified the intent of the requirement is for acceptable use policies for end-user technologies. Merged and removed requirements to focus on explicit management approval, acceptable uses of technologies, and a list of hardware and software products approved by the company for employee use.
• 12.3.10 – Now 3.4.2 – Evolving Requirement – Removed requirement and added new Requirement 3.4.2 for technical controls to prevent copy and/or relocation of PAN when using remote-access technologies.
• 12.11 / 12.11.1 – Now 12.4.2 / 12.4.2.1 – Structure/format – Moved requirements for reviews to confirm that personnel are performing PCI DSS tasks in accordance with policies and procedures under Requirement 12.4, to align with other requirements for managing PCI DSS compliance activities.
• 2.4 – Now 12.5.1 – Structure/format – Moved under Requirement 12.5 to align with other requirements for documenting and validating PCI DSS scope.
• 12.6 – Now 12.6.1 – Clarification/guidance – Clarified that the intent is that all personnel are aware of the entity’s information security policy and their role in protecting cardholder data.
• 12.6.1 / 12.6.2 – Now 12.6.3 – Structure/format – Merged requirements for security awareness training.
• 12.8 – Removed – Structure/format – Removed “null” requirement (all content pointed to other requirements).
• 12.8.1 – 12.8.5 – Now the same – Clarification/guidance – Replaced “Service Provider” with Third-Party Service Provider (TPSP). Clarified that the use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity’s responsibility for its own PCI DSS compliance.  Clarified that where an entity has an agreement with a TPSP for meeting PCI DSS requirements on behalf of the entity, the entity must work with the TPSP to make sure the applicable PCI DSS requirements are met. If the TPSP does not meet those applicable PCI DSS requirements, then those requirements are also “not in place” for the entity. Clarified that the information about PCI DSS requirements managed by the TPSP and the entity should include any that are shared between the TPSP and the entity.
• 12.10 – Removed – Structure/format – Replaced “system breach” and “compromise” with “suspected or confirmed security incident.”
• 12.10.1 – Now Same – Clarification/guidance – Replaced “system breach” and “compromise” with “suspected or confirmed security incident.”
• 12.10.3 – Now Same – Clarification/guidance – Replaced “alerts” with “suspected or confirmed security incidents.”
• 12.10.4 – Now Same – Clarification/guidance – Replaced “system breach” with “suspected or confirmed security incidents.”
• 12.10.5 / 11.1.2 / 11.5.1 – Now 12.10.5 – Evolving Requirement – Merged requirements and updated the security monitoring systems to be monitored and responded to as part of the incident response plan to include the following:
  • Detection of unauthorized wireless access points (former 11.1.2),
  • Change-detection mechanism for critical files (former 11.5.1),
  • New requirement bullet for use of a change- and tamper-detection mechanism for payment pages (relates to new requirement 11.6.1).
  • (This bullet is a best practice until 31 March 2025.)

Conclusion

If you have been involved in a PCI assessment and had the need to review the actual report on compliance (sorry for you on that), you have probably noticed that the majority of requirement 12 just reads as the name of the QSA doing the assessment.  “Provide the name of the assessor who confirms . . .)” So, it might see like there are a LOT of changes to a requirement that is just demonstrating compliance with someone’s name.  Well, the backend work that has to be done to get that signature has always been somewhat substantial, since 12 is all about the PCI program and management thereof.  When you look over the additions and changes you can see that from the perspective of the goals behind requirement 12 not much has changed.  It is still about focusing on making sure the PCI program within each entity is something that is proactive in its approach and not something designed solely to skirt security and do the least amount possible to get the AoC.

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

~ Shawn

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

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.

The post Intro to PCI version 4: Requirement 11 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

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.

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

Overall Thoughts

When I am chatting with my peers in the realm known as “IT Security-landia” (I know, I know. I panicked), one of the common thought processes is around how to mitigate the biggest area of risk in most environments – the human factor.  Not just from external threats, even those are real and need to be part of the overall equation, but also from internal threats.  To get even more granular, internal threat doesn’t just mean an employee who is acting in what I call “bad faith”, or counter to the benefit of the company.  Most of your internal risk comes from employees that just make mistakes.  This can happen via weak passwords, poor management of their own personal information, or being to naïve/trusting of others.  Requirement 8 is designed to help the company reduce the impact from these people (and the others mentioned as well).

What’s New for Req 8 in v4

The new controls in requirement 8 of v4 are:

• 8.1.2 – Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood.es to the existing controls (surprised?) <- literally cut and paste this line from the post on requirement 7 (which was cut from 6, etc.)
• 8.3.6 – Minimum level of complexity for passwords when used as an authentication factor. – Most of the changes are for internal/non-consumer accounts, with an exception for companies with a technology barrier (look this one up)
• 8.3.10.1 – If passwords/passphrases are the only authentication factor for customer user access, passwords/passphrases are changed at least every 90 days, or the security posture of accounts is dynamically analyzed to determine real-time access to resources.
• 8.4.2 – Multi-factor authentication for all access into the CDE.  (ALL ACCESS – this will have heavy impact on call centers and client support groups – plan ahead and start working on the workstream planning and training)
• 8.5.1 – Multi-factor authentication systems are implemented appropriately. (aka, increased assessment requirements and documentation needed)
• 8.6.1 – Manage interactive login for accounts used by systems or applications. (A lot of the system accounts that the enterprise views as “set it and forget it” will require a more active management philosophy.)
• 8.6.2 – Passwords/passphrases used for interactive login for application and system accounts are protected against misuse.
• 8.6.3 – Passwords/passphrases for any application and system accounts are protected against misuse.

Requirement 8 is changing not only how user accounts are managed, but also how system accounts are as well.  Between the changes to system accounts and MFA needed for all users that access the cardholder data environment, you can see where they are forcing companies to exert additional effort into preventing unauthorized users from gaining access to sensitive data.

• 8 – Clarification/guidance – Standardized on terms “authentication factor” and “authentication credentials.”
• 8 – Clarification/guidance – Removed “non-consumer users” and clarified in the overview that requirements do not apply to accounts used by consumers (cardholders).
• 8 – Structure/Format – Removed note in overview that listed requirements that do not apply to user accounts with access to only one card number at a time to facilitate a single transaction and added that note to each related requirement.
• 8.1.1 – Now 8.2.1 – Clarification/guidance – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
• 8.5 – Now 8.2.2 – Evolving Requirement – Changed focus of requirement to allow use of shared authentication credentials, but only on an exception basis. (Rejoice Root users! Rejoice!)
• 8.5 – Now 8.2.2 – Clarification/guidance – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
• 8.5/8.5.1 – Now 8.2.2 & 8.2.3 – Structure/format – Moved requirements for group, shared, or generic accounts and for service providers with remote access to customer premises under Requirement 8.2.
• 8.1.8 – Now 8.2.8 – Structure/format – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
• 8.2 – Now 8.3.1 – Structure/format – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
• 8.1.6 / 8.1.7 – Now 8.3.4 – Structure/format – Merged requirements and moved under Requirement 8.3. Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
• 8.1.6 / 8.1.7 – Now 8.3.4 – Evolving Requirement – Increased the number of invalid authentication attempts before locking out a user ID from six to 10 attempts. (Woohoo!  The helpdesk is happy)
• 8.2.6 – Now 8.3.5 – Clarification/guidance – Clarified that this requirement applies only if passwords/passphrases are used as an authentication factor to meet Requirement 8.3.1
• 8.2.5 – Now 8.3.7 – Structure/format – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
• 8.4 – Now 8.3.8 – Structure/format – Moved content about communicating user authentication policies and procedures under Requirement 8.3.
• 8.2.4 – Now 8.3.9 – Clarification/guidance – Clarified that this requirement applies if passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation).
• 8.2.4 – Now 8.3.9 – Clarification/guidance – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
• 8.2.4 – Now 8.3.9 – Clarification/guidance – Added a note that this requirement does not apply to service providers’ customer accounts but does apply to accounts for service provider personnel.
• 8.2.4 – Now 8.3.9 – Evolving Requirement – Added the option to determine access to resources automatically by dynamically analyzing the security posture of accounts, instead of changing passwords/passphrases at least once every 90 days.
• 8.2.4.b – Now 8.3.10 – Structure/format – Moved content from a former testing procedure to a requirement for service providers to provide guidance to customers about changing passwords/ passphrases.
• 8.6 – Now 8.3.11 – Structure/format – Moved requirement about authentication factors such as physical or logical security tokens, smart cards, and certificates under Requirement 8.3.
• 8.3 – REMOVED (all components covered by other requirements)
• 8.7 – Moved to 7.2.6 Discussed in previous post)

Conclusion

As you read over the list of changes to requirement 8 you will see there is a lot of them.  Don’t let this intimidate you however, as a lot of the changes are changes to the control number and/or just a note to be specific about the personnel that are in scope for it (ie it shouldn’t be applied to retail workers that have access to a single payment card at a time, etc.)  The areas to spend time looking into the impact of your environment are going to be mostly found in the new items.  Not that you can ignore the changes to existing controls, but the new ones have some changes that from a PCI perspective would be on the fundamental level.

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

~ S

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

Overall Thoughts

So, as we have discussed in previous posts the council is working to mature the standards in a way to add additional accountability and limit risk associated with human error.  In requirement 7 for version 4, we see a continuation of this mindset.  As you will notice when we run through the changes most of them are focused on some form of oversight. 

What’s New for Req 7 in v4

The new controls in requirement 7 of version 4 are:

• 7.1.2 – Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood.es to the existing controls (surprised?) <- literally cut and past this line from the post on requirement 6 (which was cut from 5, etc.)
• 7.2.4 – Review all user accounts and related access privileges appropriately.
• 7.2.5 – Assign and manage all application and system accounts and related access privileges appropriately.
• 7.2.5.1 – Review all access by application and system accounts and related access privileges.

Changes to the existing controls 

Requirement 7 is maturing along with the rest of the controls to expand not only the controls but the overall mindset and philosophy behind it.  This is very evidence in the changes to requirement 5 existing controls.

• 7 – Clarification/guidance – Updated principal requirement title to include system components and cardholder data.
• 7.1 – Now 7.2.1 / 7.2.2 / 7.2.3 – Clarification/guidance – Removed requirement for specific documented procedures and added testing procedures to verify policies and procedures to each related requirement. (Expanding the requirements within the company documentation, which by its nature will require more involvement from management and business owners).
• 7.1.1 – Now 7.2.1 – Clarification/guidance – Clarified requirement is about defining an access control model.
• 7.1.2/7.1.3 – Now 7.2.2 – Structure/format – Combined requirements for assigning access based on job classification and function, and least privileges.
• 7.1.4 – Now 7.2.3 – Clarification/guidance – Clarified requirement is about approval of required privileges by authorized personnel. (This is one I have clients with long tenured employees having difficulty providing evidence on during their assessments.  If you know you are going to have to provide proof of approval on your administrative staff’s access levels, make a point to have an annual review that is thoroughly documented, in a format that can be exported into an evidentiary document.  Don’t just fall back on using an email from their manager saying “Yup.  Looks good.”
• 8.7 – Now 7.2.6 – Structure/format – Moved requirement since it aligns better with the content in Requirement 7. (Aligns with our earlier comments on the two requirements being two halves of the same coin.)
• 7.2 – Now removed – Structure/format – Removed “null” requirement (all content pointed to other requirements).

Conclusion

As I mentioned at the start of the post, most of the changes to requirement 7 in version 4 have to do with making certain the access management aspect of your environment.  The new areas of 7 are focused on account management and review for user and system accounts and the controls that have been modified are moving around to require a deeper dive into those areas to show compliance with the PCI standards.  Developing proper management policies and processes will be key in improving your security stance in this realm.  In a perfect world you will implement new processes for reviewing accounts (of all kinds) and find out you were already doing everything as you should.  I suspect that some of you are going to have some amount of enlightenment when you start putting together an inventory of system level accounts. (Because if you don’t have an accounting of these accounts, how can you perform the needed reviews on their access each year, as required in 7.2.5.1?)

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

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

Overall Thoughts

It feels like the overall vibe of R6 is making sure the people outside of the development shop know what they are doing behind the curtain to me.  Changes towards automation and more detailed record keeping.  Outside of the tech sector (and even inside it for a lot of companies), how many members of the executive team actually understand the processes involved in software management?  I am including not only customized coding for internal applications, but also vendor managed patches and other third-party software solutions.  For most of these people their responsibilities is outside of this space and it makes sense for them to pay attention elsewhere.  However, with privacy laws springing up and maturing globally the days of execs being able to claim ignorance are quickly going by the wayside.  PCI is moving closer to this mentality with v4.  You will see in the changes for Six some of this shift in thinking and maturity.

What’s New for Req 6 in v4

With that said, here are the changes in the form of new controls in requirement 6 of version 4 are:

• 6.1.2 – Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood.es to the existing controls (surprised?) <- literally cut and past this line from the post on requirement 5 (which was cut from 4, etc.)
• 6.3.2 – Maintain an inventory of ‘bespoke’ and custom software to facilitate vulnerability and patch management.  “Bespoke” is now how we refer to applications purchased from outside of the organization for use with in-scope processes.
• 6.4.2 – Deploy an AUTOMATED technical solution for public-facing web applications that continually detects and prevents web-based attacks.  If you have a solution that monitors and alerts you, so you can act, you need to upgrade it or change it out for a full service WAF.
• 6.4.3 – Manage all payment page scripts that are loaded and executed in the consumer’s browser. This is going to require companies to do some form of the following:
  • Confirm that payment page scripts are authorized.
  • Validate the scripts, to ensure the integrity or trustworthiness of the payment page scripts.
  • Track the scripts used in the PCI payment process through a formal inventory process, complete with a business justification associated with each.

Requirement 6 is maturing along with the rest of the controls to expand not only the controls but the overall mindset and philosophy behind it.  This is very evidence in the changes to requirement 5 existing controls.

• 6 – Clarification/guidance – Updated principal requirement title to focus on ‘software’ instead of applications.
• 6 – Clarification/guidance – Clarified that Requirement 6 applies to all system components, except for Requirement 6.2, which applies only to bespoke and custom software.
• 6.3 – Changing to 6.2.1 – Clarification/guidance – Replaced “internal and external” with “bespoke and custom” software.  Clarified that this requirement applies to software developed for or by the entity for the entity’s own use and does not apply to third-party software.
• 6.3 – Changing to 6.2.1 – Structure/Format – Moved requirement for developing software securely to align all software development content under Requirement 6.2.  (Basically 6.2 will not be the content area for development)
• 6.5 – Changing to 6.2.2 – Clarification/guidance – Moving the requirements for training the development staff under 6.2
• 6.3.2 – Changing to 6.2.3 and 6.2.3.1 – Clarification/guidance – Moving requirements for code testing prior to release under 6.2 and split into secondary control if manual code review is in use instead of automated. (Note – if you have an automated syntax checker and a peer review process, both of these will be in-scope for you.  Syntax checkers do not meet the requirements for automated code reviews.)
• 6.5.1 – 6.5.10 – Changing to 6.2.4 – Clarification/guidance – Moving development controls under 6.2 and FINALLY condensing the list of common coding vulnerabilities into a single control.  (So glad for this one)
• 6.1 & 6.2 – Changing to 6.3 – Structure/Format – Moved requirements for identifying security vulnerabilities and protecting system components from vulnerabilities via patching under Requirement 6.3.
• 6.1 – Changing to 6.3.1 – Clarification/guidance – Added a bullet to clarify applicability to vulnerabilities for bespoke and custom and third-party software.
• 6.6 – Changing to 6.4.1 – Structure/Format – Moved requirement for addressing new threats and vulnerabilities for public-facing web applications under Requirement 6.4.
• 6.3.1 / 6.4 / 6.4.1-6.4.6 – Changing to 6.5.1-6.5.6 – Structure/Format – Moved and combined requirements for changes to system components under Requirement 6.5.
• 6.4 – Changing to 6.5.3-6.5.6 – Clarification/guidance – Removed requirement for specific documented procedures and added testing procedures to verify policies and procedures to each related requirement.
• 6.4.1 – Changing to 6.5.3 – Clarification/guidance – Changed term from “development/test and production” to “production and pre-production” environments.
• 6.4.2 – Changing to 6.5.4 – Clarification/guidance – Changed term from “development/test and production” to “production and pre-production” environments.  Also, changed term “separation of duties” and clarified that separation of roles and functions between production and pre-production is intended to provide accountability so that only approved changes are deployed.
• 6.4.3 – Changing to 6.5.5 – Clarification/guidance – Changed term from “testing or development” to “pre-production” environments and clarified that live PANs are not used in pre-production environments except where all applicable PCI DSS requirements are in place.

Conclusion

So, as you can see by all them lovely bullet points in this post, Requirement 6 has a lot going on.  Luckily, some of it is long overdue structural changes to the report (I’m looking at you 6.5.1-10).  Don’t let that lull you into a false sense of readiness on the new v4 R6 though.  Some of these changes are significant from an overall approach to security (automation > manual) and can potentially be the starting point for some projects with hefty workstreams associated with them.  You should start having conversations along these lines ASAP to make sure nothing sneaks up on you and potentially causes security and compliance issues.

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

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