Tag: PCI-DSS (Page 1 of 10)

Major Changes of PCI v4

So now as we approach the final throes of PCI-DSS v3.2.1, the remaining 3 weeks is all that is left of this venerable standard before we say farewell once and for all.

PCI-DSS V4.0 is a relative youngster and we are already doing hours of updates with our customers on the things they need to prepare for. Don’t underestimate v4.0! While its not a time to panic, it’s also not a time to just lie back and think that v4.0 is not significant. It is.

Below is a table that provides an insight of the major changes we are facing in v4.0.

Bearing in mind that most of the requirements now start off with keeping policies updated and document roles and responsibilities, the major changes are worth a little bit of focus. In the next series of articles, we will go through each one as thoroughly as we can and try to understand the context in which it exists on.

Let’s start off the one on the top bin. Requirement 3.4.2.

Req. 3.4.2: When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel, except for those with documented, explicit authorization and a legitimate, defined business need

PCI v4.0

Ok, we have underlined and emphasized a few key points in this statement. Because we feel that is important. Let’s start with what 3.4.2 applies to.

It applies to: Remote Access

It requires: Technical Controls

It must: PREVENT THE COPYING/RELOCATION

Of the subject matter: Full Primary Account Number

In v3.2.1 this was found in section 12.3.10 with slightly different wordings.

Req 12.3.10 For personnel accessing cardholder data via remote-access technologies, prohibit the copying, moving, and storage of cardholder data onto local hard drives and removable electronic media, unless explicitly authorized for a defined business need. Where there is an authorized business need, the usage policies must require the data be protected in accordance with all applicable PCI DSS Requirements.

PCI v3.2.1

I think 4.0, aside from the relocation of the requirement to the more relevant requirement 3 (as opposed to requirement 12, which we call the homeless requirement for any controls that don’t seem to fall into any other earlier requirements), reads better. Firstly, putting it in requirement 3 puts the onus on the reader to consider this as part of protection of storage of account data which is the point of Requirement 3. Furthermore, digging into the sub-requirement, 3.4 section header states: Access to displays of full PAN and ability to copy PAN is restricted.

This is the context of it, where we find the child of this 3.4 section called 3.4.2 and we need to understand it first, before we go out and start shopping for the first DLP system on the market and yell out “WE ARE COMPLIANT!”

3.4 talks about displays of FULL PAN. So we aren’t talking about truncated, or encrypted PAN here. So in theory, if you copy out a truncated PAN or encrypted PAN, you shouldn’t trigger 3.4.2. Its specific to full PAN. While we are at it, we aren’t even talking about cardholder data. A PAN is part of cardholder data, while not all cardholder data is PAN. Like the Hulk is part of the Avengers but not all Avengers are the Hulk. So if you want to copy the cardholder name or expiration date for whatever reasons like data analysis, behavioural prediction, stalking etc…this isn’t the requirement you are looking for.

Perhaps this is a good time to remind ourselves what is Account Data, Card Holder Data and Sensitive Authentication Data (SAD).

The previous v3.2.1 doesn’t actually state ‘technical controls’, which goes to say that if it’s a documentary controls, or a policy control, or something in the Acceptable Use Policy, it can also pass off as compliant. V4.0 removes that ambiguity. Of course, the policy should be there, but technical controls are specific. It has to be technical. It can’t be, oh wait, I have a nice paragraph in section 145.54(d)(i)(iii)(ab)(2.4601) in my information security acceptance document that stated this!

So these technical control(s) must PREVENT copying and relocation. Firstly just to be clear, copy is Ctrl-C and Ctrl-V somewhere else. Relocation is Ctrl-X and Ctrl-V somewhere else. Both has its problem. In copying, we will end up PAN having multiple locations of existence. In relocation, the PAN is moved, and now systems accessing the previous location will throw up an error – causing system integrity and performance issues. Suffice to say, v4.0 demands the prevention of both happening to PAN. Unless you have a need that is:

a) DOCUMENTED

b) EXPLICITLY AUTHORIZED (not Implied)

c) LEGITIMATE

d) DEFINED

When a business need is both “documented” and “defined,” it means that the requirement has been both precisely articulated (defined) and recorded in an official capacity (documented). So a list of people with access is needed for the who, why they legitimately need to access/copy/relocate PAN in terms of their business, explicitly authorized by proper authority (not themselves, obviously).

Finally, let’s talk about technical controls. Now, remember, this applies to REMOTE ACCESS. I’ve heard of clients who says, hey no worries, we have logging and monitoring in place for internal users. Or we have web application firewall in place. Or we have cloudflare in place. Or we have a thermonuclear rocket in place to release in case we get attacked. This control already implies ‘remote access’ into the environment. The users have passed the perimeter. It implies they are already trusted personnel, or contractors or service providers with properly authorized REMOTE ACCESS. Also, note that the authorization here is NOT for remote access, it is for the explicit action of copy/relocating PAN. In this case, most people would probably not have a business reason of copying/relocating PAN to their own systems unless for very specific business flow requirements. This means, only very few people in your organization should have this applied to them, under very specific circumstances. An actual real life example would be for an insurance client we have, they had to copy all transaction information, including card details in an encrypted format and put it into a removable media (like a CD-ROM) and then send it over to the Ombudsman for Financial Services as part of a regulatory requirement. That’s pretty specific.

So what passess off as a ‘technical control’? A Technical control may be as simple as to completely prevent copy/paste or cut/paste ability when accessing via remote access. This can be done in RDP or disable clipboard via SSLVPN. While I am not the most expert product specialist in remote access technologies, I can venture to say its fairly common to have these controls inbuilt into the remote access product. So, there may not be a need for DLP in that sense, as the goal here is to prevent the copying and relocation of PAN.

Now that being said, an umbrella disallow of copy and paste may not go well with some suits or C-levels who want to copy stuff to their drive to work while they are in the Bahamas. Of course. You could provide certain granular controls, depending on your VPN product or which part of the network they access. If a granular control cannot be agreed on, then a possible way is to enforce proper control via DLP (Data Loss Prevention) in endpoint protection. Or control access to CDE/PAN via a hardened jump server that has local policy locked down. So the general VPN into company resources may be more lax, but the moment access to PAN is required, 3.4.2 technical controls come in play.

At the end, how you justify your technical controls could be through a myriad of ways. The importance is of course, cost and efficiency. It has to make cost sense and it must not require your users to jump through hoops like a circus monkey.

So there you have it, a break down of 3.4.2. We are hopping into the next one in the next article so stay tuned. If you have any queries on PCI-DSS v4.0 or other related cybersecurity needs, be it SOC1 or 2, ISO27001, ISO20000, NIST or whether Apollo 11 really landed on the moon in 1969, drop us a note at avantedge@pkfmalaysia.com and we will get back to you!

An Ode to the Invalid Certificate

Once upon a time, in a not-so-faraway land of PeaCeEye, merchants, credit card transactions, online payments, payment gateways, POS terminals all lived in harmony. In this land, all citizens carry a trust symbol, held together by validation documents, called the Citizen Badge. However, PeaCeEye is now facing an existential threat. A threat shrouded in the cloak of validation, a false symbol of security and trust – called the Certificate. But, dear reader, beware! For this tale of caution and deception, and the Certificate, much like the elusive unicorn, while tangible, carries a false value – nothing more than a fabrication. A figment of imagination, conjured up by the minds of its idle creators, the Qessays.

You see, in the kingdom of PeaCeEye, there exists a council – a council of wise men and women who determine the rules and regulations that govern this realm. This council, known as the Secret Sorceror Council (SSC), has decreed that only three sacred documents hold the key to validation for the Citizen Badge – the Attestation of Compliance (AoC), the Report on Compliance (RoC), and the Self-Assessment Questionnaires (SAQs). Yet, despite the council’s resolute stance on this matter, a mysterious fourth document continues to emerge from the shadows – the Certificate.

Ah, the Certificate, a work of art crafted by the Qessays. You see, these Qessays were charged by the council to uphold what is truthful and right, and to ensure that all Citizens of PeaCeEye are identifiable by their Citizen Badges – The AoC, Roc and/or the SAQs. However, over the years, some of these noble Qessays have turned to the darkside and the sinister art of producing corrupted documentation, called the 4th deception, or the Certificate as it is now known. These dark Qessays have mastered the art of illusion, conjuring certificates out of thin air to dazzle their customers. They’ve become modern-day alchemists, turning mere paper and ink into a symbol of validation, which, in reality, is as weightless as a feather and as useful as a chocolate teapot. Or a fork and spoon when eating Chapati. It’s a thing of beauty, destined to hang on the walls of businesses, gracing them with its shimmering falsehoods.

But why do these Qessays continue to spin their webs of deception, offering their customers a document that has no merit in the eyes of the SSC? Something that even invalid citizens to PeaCeEye can procure? To unravel this mystery, we must dive into the murky depths of human nature. For, you see, people are drawn to shiny, pretty things, much like moths to a flame. A certificate, with its elegant calligraphy and embossed seal, is a testament to the allure of appearance over substance. It is a tangible representation of validation, regardless of its actual worth.

Moreover, the Certificate serves as a placebo, a sugar pill of sorts, which instills in businesses a false sense of security. It is a talisman that they cling to, convincing themselves that they are protected from the malicious forces of the World beyond PeaCeEye – the World called Cyberattacks. And, in the process, they become blind to the fact that the true power of validation lies in the sacred trio of documents – the AoC, RoC, and SAQs.

Now, one might argue that those who peddle these invalid certificates are merely fulfilling a demand. After all, the customer is always right, and if they desire a shiny piece of paper to adorn their walls, who are we to deny them? But, as the saying goes, “With great power comes great responsibility.” And these Qessays, as the gatekeepers of the citizenship of PeaCeEye, must hold themselves to a higher standard.

By offering these overvalued and useless certificates-that even the SSC had themselves admonished and had announced to the citizens to not place any value to them- these certificates not only betray the trust of customers but also undermine the very foundation of Citizen Badge. They turn the realm of PeaCeEye into a farce, a stage where pretenders masquerade as protectors, and businesses are lulled into a false sense of security. There are even Qessays who are not even involved in the process of validating an SAQ being answered; luring their customers to portals with questionnaires answered by the citizen themselves and then conjuring these certificates that look as if it has been validated by the Qessays, but instead are just self aggrandizing papers that has been only self validated by the person answering their own questions! In other words, the person becomes their own judge and jury and are able to produce a Certificate that looks as if they have been properly validated by a third-party Qessays. Amazing art! An ostentatious object of grandeur and magnificence, yet with all the actual value of a discarded banana peel withering in the Sahara sun.

But, dear reader, do not despair, for there is hope. You see, the truth has a funny way of revealing itself, much like the sun breaking through the clouds after a storm. And, as the truth about the invalidity of these Certificates spreads, businesses will begin to see through the veil of deception, and the demand for these counterfeit documents will wane. Qessays who persist in peddling these worthless certificates will find themselves exposed, their credibility crumbling like a house of cards.

In the meantime, we must not sit idly by, complacent in the face of falsehoods. Instead, we must raise our voices and spread the word, educating businesses on the true path to Citizen validation. We must sing the praises of the AoC, RoC, and SAQs, enlightening those who have been led astray by the allure of the invalid certificate. For it is only through knowledge that we can pierce the veil of deception and lay the mythical beast of the Certificate to rest.

So, let us embark on this crusade together, wielding the sword of truth and the shield of knowledge. As we march forward on this noble journey, let us remember the wise words of the SSC: “Trust, but verify.” Let us tear down the great wall of this Certificate, brick by brick, and replace it with a fortress built on the solid foundation of the council’s sacred trio of documents. And as we watch the last remnants of the Certificate crumble to dust, we will know that we have triumphed over the forces of deception.

We bid farewell to this Certificate, and to welcome a new era of transparency, security, and trust. An era where the mythical beast of the Certificate is relegated to the annals of history, and where the true power of validation is embraced, in all its glorious, council-approved forms. May the sacred trio of documents – the AoC, RoC, and SAQs – guide us on our path to a brighter, more secure future, and may the Certificate forever remain a cautionary tale of the perils of deception and the triumph of truth.*

** The above is written obviously in satire and tongue-in-cheek with absolute no journalistic value nor based on any real world reimagination and solely based on our absolute frustration at the continuous dependence and insistence from acquirers or banks to have our customers produce them ‘certificates’. In addition, some clients even go through self-service portals provided by QSAs and answer SAQ questions on their own, at the end of this process of self answering, a certificate is produced. Granted, the certificates do come with disclaimers in small prints stating that the certificate is actually based on self assessment and even admits that it isn’t recognised by the council.

But in reality, who actually reads the fine print?

In the end, anyone having gone through these ‘compliance’ portals, answering affirmative to everything would be able to procure these certificates and remarkably, some acquirers even accept them as proof of third party audit (which they are clearly NOT). Again, we are not stating that QSAs providing this service is doing anything wrong. There is nothing essentially wrong with certificates on its own, or QSAs providing these certificates as a simple means to show a company has undergone PCI-DSS compliance. But where it becomes a gray area is when there is too much dependence placed on these certificates to the point where even the AoC is rejected and acquirers insist on every company showing them these certificates. In this case, QSAs who are willing to provide so called certificates to companies without having undergone any assessment and only answering questions from the SAQ based on their own knowledge or whim – unless the QSA is willing to go through each question of each customer and validate these through evidence submission and review (the process called audit); then these creation of self signed certificates should be stopped. It’s akin to a banking website issuing a self-signed SSL cert on their own website and tell everyone to trust it. Does this happen in the world of e-commerce? No, it’s absurd. Then why is it different in the world of compliance? Why is this practice still allowed to prosper? How do we stop this practice?

We have been advocating removing certificates for years now from the PCI-DSS landscape and to have a more consistent and acceptable way to show PCI validation. Unfortunately, unlike the satirical tale above, this still eludes us. Drop us an email at pcidss@pkfmalaysia.com if you have any ideas and comments to this!

PCI-DSS v4.0 vs v3.2.1 Deepdive Part 1

OK, now that we are well into 2023, the main question here is why isn’t the current assessments this year going into v4.0? Most of our customers are still doing their v3.2.1 for 2023, before doing 4.0 the next cycle. The answer is: Well, you can go for v4.0 if you want to. There’s really not much difference for now. The difference is probably more on the auditor side, as reporting requirements are different in V4.0. But from the client end, some of the scary changes like authenticated scans for internal vulnerability scanning, or updating of password complexity to 12 characters etc – these actually don’t come in force until March 2025. So there’s actually a grace period for v3.2.1 to v4.0 and another grace period for PCI v4.0 controls to be implemented, up to March 2025. Basically, anything past March 2025, the controls in v4.0 becomes Standard. No more compromise. Its like the biblical ten Commandments, except you have around 300+ commandments here. That’s a lot of chiseling on the rock by Moses.

Before we deepdive into v4.0, let’s set out the landscape a bit again, like unfurling a carpet or a mat before we feast into our metaphorical compliance picnic.

  1. Scope and Applicability

One of the key changes in PCI DSS v4.0 is the clarification of the scope of the standard. The new version provides more explicit guidance on how to apply the standard to different types of organizations, and it emphasizes the need for organizations to understand the scope of their cardholder data environment (CDE). This comes as a fairly significant change, as the initial pages of V4.0 is strewn with explanations of scoping and methodologies on how to define scope. It reads almost like they are trying to make up for lost time, and trying to cover all their bases, whereas in the previous version, just a cursory glance was done. PCI DSS v4.0 also provides guidance on how to identify and manage different types of risks. Risk has always been a difficult item to quantify in PCI. Because at the end, PCI is a result of a risk assessment anyway, done by the card schemes. It’s specifically to mitigate the risks they identified that the PCI program was born. So what’s the point of running a risk assessment in PCI-DSS if its already a standard? Well, PCI DSS v4.0 states that organizations should have a risk management program in place to identify and prioritize risks, and to take appropriate measures to mitigate those risks. Its a way of saying that while controls are required, how you address the controls are dependent on your risk assessment. Additionally, you can even opt to go above and beyond the PCI standard to address a particularly high risk area (although to find a company doing this is like finding the Lost Ark). Above the brownie points you would get from the QSA by showing you are a company keyed into your risk assessment practices; a risk assessment will likely help you identify other areas of concerns as well. The standard also requires organizations to have a process in place for identifying changes to their CDE, and for reviewing and updating their risk management program as needed. So to the point on whether the risk assessment is useful – yes. Whether it is critical to passing your PCI-DSS – well, I would say that depends a lot on your QSA. We’ve seen QSAs pass a bunch of colored coded excel sheets off as a PCI risk assessment easily.

2. New Control Objectives

PCI DSS v4.0 introduces several new control objectives to address emerging security risks. One of the key new objectives is to address the risks associated with cloud computing. The new version of the standard includes new requirements for securing cloud environments, including the need to assess the security of cloud service providers and to implement additional controls to secure cloud-based data. In v4.0, the word ‘Cloud’ appears 42 times in the entire standard. In v3.2.1, the word ‘Cloud’ appears as often as ‘NasiLemak’. Which is zero.

3. Password Requirements
PCI DSS v4.0 introduces new requirements for password management. We are in 2023 and we are still trying to remember all our passwords. PCI is now making our lives easier by introducing longer passwords! Great, now everyone just add incremental numbers behind your password from seven to twelve. The standard requires the use of multi-factor authentication for all non-console administrative access, this has already been evident in previous version. This just basically means that organizations must implement additional security measures, such as biometric authentication or smart card authentication, in addition to a password, to access sensitive systems and data

4. Encryption

The new standard maintains that organizations use more robust encryption algorithms and key lengths as per 3.2.1. Key management more or less remain as it is, but the biggest issue in v4.0 is the doing away with full disk or transparent encryption. We will do a deep dive in this later.

5. Penetration Testing and Vulnerability Management

PCI DSS v4.0 includes new requirements for penetration testing and vulnerability management. Among others is the requirement for Internal vulnerability scans to be authenticated whereas previously, this was a bit more gray area (actually not required). This could have potential impact especially for entities chasing a quarterly deadline, if you have a lot of systems in your scanning scope. So this makes the scoping a lot more critical. Because you can be sure the effort for internal scans are going to be going way up.

6. Remote Access

PCI DSS v4.0 includes new requirements for securing remote access to cardholder data environments. PCI requires organizations to implement multi-factor authentication for all remote access, and to use secure protocols, such as SSH or VPN, to access sensitive systems and data. While this remains, the other issue with 4.0 is the need to implement controls to prevent copy/relocation of PAN for all personnel unless there is a business need. We have a bad feeling about this. This could generally mean getting a DLP in place or a NAC in place to limit what can or cannot be done by users logging in remotely. There are solutions for these, but this needs to be planned and invested. The key word here is to ‘prevent’ not just ‘detect’, so this basically mean a proactive control in place to block these actions.

So in the next couple of articles, we will dive right into the changes for v4.0 in detail, including those requirements where it is stated “This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.”

We will also look into the SAQs and what has changed in the SAQs for those preparing to do self assessment in accordance to v4.0.

In the meantime, for any PCI related queries or any standards like CSA, ISO27001 etc, drop us a note at pcidss@pkfmalaysia.com and we will get back to you!

Let’s Talk v4: Overview

So, on March 31st 2022, PCI-DSS v4.0 dropped on us.

The original timeline for v4.0 has already passed a long time back. Back in 2019, there had been talks that v4 would drop in late 2020. Then due to the global pandemic of unknown origins, it was moved to 2021 and now finally, they decide to release it in 2022. We all know PCI SSC loves deadlines. They love the whooshing noise deadlines make as they go by.

First of all, let’s start with another quote from the wisest sage of all generations:

Don’t Panic.

Douglas Adams

Because if we take a look at the timeline below, there’s a pretty long runway to adopt v4.0.

The above basically means this:

a) Entities undergoing PCI right now, whether it’s first time or renewals, if you are going to be certified in 2022, your current cycle and next renewal in 2023 can stay with v3.2.1.

b) Entities thinking to go through PCI-DSS, and will likely be certified in 2023, you can stay with v3.2.1 for this cycle, and then for the next renewal up in 2024, you will need to move to v4.0

Long story short, entities have 1.5 years to stay on PCIv3.2.1 and go v4.0 on your 2024 cycle. That doesn’t mean that you don’t do anything from now till then of course. Depending on your processes, there may be some changes. However, it’s not too crazy and it’s more incremental than anything else, including areas where we are already practicing , but was not noted in v3.2.1 (example being anti-phishing controls, which have been a staple for most of our FSI clients).

So we’re going to have a few breakdown of areas we think is fairly relevant to note in v4.0; a deeper dive into requirements that are added or changed, and more importantly how we think a company can move forward in preparation.

Of course that being said, the v4.0 is only 3 weeks old. A toddler in terms of its predecessors. Let’s put it into perspective. PCIv1 (and its sub versions 1.1 and 1.2) lasted almost 6 years from 2004 – 2010.

PCIv2 lasted half that time from 2010 – 2013.

PCIv3 and its sub-versions (3.1, 3.2, 3.2.1) lasted from 2013 to 2022. That’s 9 years old. So in retrospect, we are literally in the 0.6% timeline for v4 if it were to follow the v3 age. Meaning, there could be a lot of changes yet to come, or clarifications or explanations etc.

Over the life of v3, we’ve seen many supplementary documents (for scoping, logging, penetration testing, risk management etc) churned out in support to clarify v3 items. While not part of the standard itself, these supplementary documents and hundreds of FAQs are generally quoted or referenced by us to support our arguments for and against some of the decisions that QSAs put to our clients. These are extremely useful especially when QSAs put in some pretty daft interpretations of the requirements (see our previous post on CDD).

There has been some extremely subtle changes aside from the major ones and we want to note these items in page 4 of v4:

PCI DSS is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE).

Some PCI DSS requirements may also apply to entities with environments that do not store, process, or transmit account data – for example, entities that outsource payment operations or management of their CDE.

In accordance with those organizations that manage compliance programs (such as payment brands and acquirers); entities should contact the organizations of interest for more details.

pci v4.0 warning to those entities that scream i am out of scope because i don’t store, transmit or process stuff!

There’s a lot of things we dislike about v4.0. But there’s a lot of things we LIKE about it as well. So it’s like that family trip that you are taking with your entire extended family. There’s that cousin that you completely dislike that you wish you don’t need to make small conversations with – you know, the one that constantly name drops and questions whether you have achieve as much as he has in life. And tries to coach you to be a better person and live a better life, and have more than your currently unfulfilling, loveless marriage and a deadend, purposeless job as a PCI-DSS consultant. Yeah, you know it. But at the same time, you like these trips because it’s time with your family as well, and time to goof off with your kids, walk on the beach with your spouse and basically fantasize throwing your cousin into a pit full of vipers. v4.0 is like that trip.

The main takeaways from the above quote would be

a) No more free passes to those entities who claim they are out of scope simply because they don’t store, process or transmit card data. If you have impact on the security of the CDE, then you are in.

b) First time we are seeing the word “Organizations of Interest”. While this is nothing much, it’s like watching a movie in the cinema that’s based on a comic book and you see an obscure easter egg referencing to that comic and you get goosebumps because you know, you’re a nerd. And you like this kind of subtle references that no one else knows about. Basically OIs are the upstream customers, banks, FSI, organisations that are requesting your PCI-DSS compliance. It’s easier now to make this reference as it is now an official term in v4.0. Yay.

c) Organizations that ‘impact security’ is in. Previously the problem is that we had outsourced SOC/NOC, or outsourced providers that do not handle card data (e.g managed providers for firewalls etc) and even cloud services that handle the MFA or authentication generation, claiming that there is no card data, therefore they don’t need PCI. That’s fair enough, but we still need to assess that service as part of an on-demand assessment to ensure that that service is properly secured or at least has basic security functionality over it. While a majority of providers are fine with this, we have had antagonistic providers shouting to high heaven that we are idiots because of the very fact that they do not store, process or transmit card data; they should be completely disregarded from the PCI assessment. Um. No. You’re not and V4.0 is smacking you in the face for this.

Another item on v4.0 is the sheer amount of information they provide right at the beginning of the standard. They are talking about the scoping methods, segmentation, encryption and applicability on third party providers, use of third party providers and how to be compliant with them, BAU best practices, sampling methods, definition of timeframes, definition of words like significant changes, approaches to implementation of PCI-DSS, testing methods, assessment process, RoC writing and if you look carefully, there is also a recipe in there for Jamie Oliver’s Yorkshire Pudding.

In the previous v3.2.1, the requirements started on page 20. In v4.0 the requirements start on page 43. The total number of pages in v4.0 is 360, up 158% from the previous 139 pages. So, simply put, you are going from reading Enid Blyton’s Famous Five Goes to Finniston Farm to Leo Tolstoy’s War and Peace.

The requirements themselves remain as 12, so in essence, despite all the fluff at the beginning, the actual requirements are still intact. There’s quite a fair bit of items to look at, and here we provide a brief overview of it:

a) Customized implementation

So, we have this outcomes-based implementation of PCIv4. This is based on the purpose or the ‘spirit’ of the requirements and may not necessarily use the standards-defined controls to achieve it. So, for instance, the requirement to do quarterly internal scans – the objective is to identify vulnerabilities in a regular interval and to ensure that the organisation addresses this vulnerability. Instead of having an option for on-demand scanning, the organisation may opt to sign up for a continuous analysis and automated scanning that are available in cloud such as Google or AliCloud. So while the controls are different, it addresses the same objective.

It is noted that custom implementation should only be done by organisations with a mature risk management practice in place, as this requires more work for the organisation and the QSA to define tests of these controls.

On how this is implemented or samples of it, I am sure we will be seeing more examples as the standard starts maturing. Remember, v4.0 is still a baby, not even out of the maternity ward yet.

b) Multi-factor and Passwords

Multi factor is now needed for any access into the CDE. So, we call in Multi-Multi Factor – whereby, an MFA is required for remote users to get into the network, and from the non-cde network, to get into the CDE, it requires additional MFA. It would seem fairly straightforward, but companies now have to consider to implement a jump server in the CDE to act as a control aggregator to go to multiple systems in the CDE – or they could just deploy another MFA solution on the network .

Passwords are to be changed to 12 alphanumeric up from 7. There’s still a runway on this as it is only considered standard in 31 March 2025. A lot of things can happen from now till then and a lot of technology can change. We could be facing global climate crisis and end of the world, or world war 3 nuclear warfare, or an asteroid could hit earth, or the Rapture happens, you know, future stuff. But in case none of those things come to past, then yeah, make sure you move your passwords to 12 alphanumeric.

c) Group Accounts

8.2.2 gives a needed reprieve on this kerfuffle of having group accounts. In v3.2.1, this is disallowed, but v4.0 , it is allowed, based on the rule of common sense. Some systems do have group accounts for a purpose, or is unable to provide certain functionality to individual accounts. So while there is now more justifications etc needed, it’s no longer a hard no for group accounts.

d) Targeted risk analysis

Targeted risk analysis can now be done to determine the frequency of certain actions – such as password changes, POI device inspections, non-CDE log reviews, low vulnerabilities remediation, FIM review, frequency of training etc. Now while we want to believe that the PCI-SSC idea on having this is for organizations to change frequencies of controls to be MORE stringent (example to have the password changed every 30 days instead of 90 days), the reality is that most of us would stretch this requirement to make life a lot easier for us. I mean, what’s the point of having flexibility if you can’t make it as flexible (i.e as little work to be done) as possible, right?

e) Card data discovery (CDD)

Card Data Discovery Scans – CDD. There is finally some clarifications on Card Data scans to be done every 12 months and to clarify what we have already covered in our previous post in educating the QSA on how to interpret the particular CDD requirement. So yeah, kudos PCI-SSC for supporting us!

d) Misc – Anti Phishing and Full Disk Encryption

As mentioned previously, we now have references to Anti-Phishing requirements, which should have been there long before, to be honest.

We have clarifications which will have significant impact to some of our clients – the use (or abuse) of the full disk encryption requirement. V4.0 has basically blocked that way out for some of our customers utilising Bitlocker with TPM to get past Requirement 3. This is , to us, a fairly significant item of v4.0 which we will be dedicating a post later on it.

Well, so that’s it for the overview for now. We hope to get more articles out to do deeper dives into v4.0 but like I said, it’s still early days and there would be more clarifications ahead. Hopefully it will be more positive, and the experience of v4.0 will be less like that family outing with the cousin that should be thrown into a pit of vipers.

Contact us at pcidss@pkfmalaysia.com for any queries you have on PCI and we will get back to you immediately.

PCI-DSS 2022 and Version 4

pci-compliance

So we are now in 2022. PCI-DSS v4.0 is due to be out and one of the things we have been doing for the first two weeks of the year is to get over our holiday hangovers. That’s right. In our country (Malaysia), the slowest months are December, January and February. It’s like starting a car in the dead of winter. These 3 months are like the Amen Corner in Augusta for businesses. December hits like a ton of bricks due to the Christmas season; and then just when things start moving in January, it grinds to a halt for Chinese New Year, where the entire nation just flat out refuses to work. When we are back in the second week of Chinese New Year, we are once more in first gear climbing up the hill again of 2022.

So we did things a bit differently. We started the first two weeks with a series of training for clients and potential clients, to go through PCI-DSS v4.0 and create an awareness of what is there to expect.

The above is taken from the PCI website and immediately we see some interesting things here. Number one: PCI-DSS v3.2.1 only retires in 2024. This is interesting, because usually the transition period isn’t so long. It’s long now because – I don’t know, there may be an ongoing pandemic and such. So here we are Q1 2022, and our customers are asking when do we transition to v4.0?

Well, the answer would be: as soon as you can. But in theory, you can probably stick to v3.2.1 validation for 2022 and realistically move to v4.0 in 2023. In fact, for some of our clients whose PCI maintenance period follows the calendar year, they can even force 3.2.1 into their 2023 validation year.

As for the actual content in PCI v4, it’s still a well kept secret like the plot of Spiderman: No Way Home; but we have been reading a bit and also have joined last year’s PCI-DSS community meeting and learnt some interesting tid-bits of it.

No 1: Compensating Controls

The-get-out-of-jail-free card. Customers have been dangling this Compensating Controls card in front of our faces ever since the Mesopotamian times. When they can’t address a control – use compensating controls! When they cannot implement something due to budget – compensating controls! When they can’t make changes to an application because it was designed by a group of kindergarten kids and it would break the moment you touch it – Compensating Controls! When you don’t know what to say to your wife after a long night out at the pub with the mates and come back smelling like a keg of kerosene – Compensating Controls!

The problem with compensating controls is that they are a pain in the neck to implement and to document. And to justify. The compensating control worksheet, the justification documentation, the implementation of the control itself to be ‘above and beyond’ the scope of PCI-DSS etc. Everyone things this is a silver bullet only to find it the deepest rabbit hole you can ever fall into.

So, PCI v4 does away with compensating controls. Great.

And they introduce Customized Implementation.

A lot of people are saying this is a game changer.

Honestly? Until more information comes out, we only have this to go with:


Customized implementation considers the intent of the objective and allows entities to design their own security controls to meet it. Once an organization determines the security control for a given objective, it must provide full documentation to enable their Qualified Security Auditor (QSA) to make a final decision on the effectiveness of a control.

Cryptic PCI v4 DOCUMENTATION

Design their own security controls? Well, ok, isn’t this the same as compensating controls? I am thinking this just expands the interpretation to something a bit broader in which case the control may not even be a technical control. So instead of stating , ok, we can’t meet certain password controls due to the legacy application issue, and compensating controls were previously excessive logging and monitoring; isolation of network, whitelisting of IPs and access; using WAF and DLP and Virtual patching etc etc; are we stating now, a possible customized approach would be: instead of all these technical controls; we now have a customized security approach. Which includes isolation of network, whitelisting of IPs and access; using WAF and DLP and Virtual patching etc etc.

Until we see some examples of this, it may just be well that most companies will go along with the ‘normal’ approach; or adopt a wait and see approach and eke out the last remaining drop of v3.2.1. into 2024.

No 2: UP in the Clouds

Another item that has been long overdue? Cloud. It’s about time things get addressed and not just cloud, but how services and containers work as well. We have had auditors coming to our clients insisting on them doing testing, VA/PT on services from AWS, not recognizing there’s not even an IP address to start with. To be fair to the SSC, they do have a few Cloud Guidelines Supplementary documentation, which we actually find very useful especially in our projects on certifying cloud technologies. We can see this being incorporated more formally into v4.0 where the requirements will be designed around Cloud environment more organically than what we see right now (sort of force-fitting many of the traditional concepts like Network IDS, Patching etc into the cloud environment).

No 3: Not another MF-A!

I have a bad feeling about this.

MFA has been a constant pain for us. Firstly, where MFA is being implemented – not just on perimeter but now on every access to the CDE. At least it’s now still on admin accounts. We hear they plan to introduce for ALL users. We also hear the collective screams of the tormented from the nine hells of Dante. Secondly, a lot of customers are still depending on MFA via SMS. If PCI goes along the NIST route, we could see this being deprecated soon. Also, clarifications as well on whether client side certificate are acceptable as a ‘something you have’ factor would be most welcomed. We see different QSAs interpreting this so differently you’d think we’ve asked them to interpret some ancient Thuggee text. Multi-factor challenges are already there for us over the past years, with Bank Negara’s RMIT focus on ‘strong MFA’ for large financial institutions. A clear guidance also should be there on how to evaluate multi-factor that is dependent on a cloud provider; and whether common implementation like Google Authentication etc can still be considered as good enough for V4.0

No 4: Encrypting everything

We also hear now that the “Pocket Protector Trope” security may be implemented. Remember those movies we watch, where the hero gets shot in the chest and you think he dies but he reveals that the bullet is stopped by his pocket watch; his badge; a bible; or some other dang sentimental thing that was given to him like 40 scenes ago?

So in PCI, usually when data is traversing the internet or network, it states the transmission needs to be encrypted. It doesn’t technically state anything about encrypting the data package itself while in transmission. The data encryption almost exclusive occurs during data at rest. So in this case, they are doubling the protection: They are adding that pocket watch to catch the bullet; so if the transmission gets compromised, the data is still secured. The bullet doesn’t hit the hero!

No 5: Recovery and Continuity

Not so much as something coming, but more of what we’d like to see. One of the biggest criticism we see customers bemoaning at PCI (other than the cost and budget and the complexity and..ok, everything else) – is that PCI has little focus on business continuity and disaster recovery. It’s almost as if PCI is standing there saying, “OK, you have outage for a few days? Great, make sure your credit card information is safe.” It’s not really business focused, it’s more credit card confidentiality focus. What we would like to see is a little more focus on this area. Over the past 2 years, we have seen customers getting all sorts of attacks from cyberspace. Malware, ransomware, hacking, fraud, defacement — it’s like the world goes into a pandemic and everyone’s bored to bits at home and everyone is taking up hacking as a part time gig. Malware for instance – how prepared is a PCI compliant company against ransomware attack? Have they done their backups? Have they tested their systems to recover?

So, if you have any queries on PCIv4 for us, drop us an email at pcidss@pkfmalaysia.com and we will definitely get back to you. Have a great and safe year ahead for 2022!

« Older posts

© 2024 PKF AvantEdge

Up ↑