PKF AvantEdge

Tag: compliance (Page 1 of 5)

PCI-DSS Scope Understanding: Encryption

July 20, 2024 / / 0 Comments

Scoping is one of the first and main thing that we do the moment we get engaged, after the customary celebratory drinks. In all projects, scope is always key, moreso in auditing and consulting, in standards compliance, be it PCI, ISMS, NIST 800s, CSA or all the other compliances we end up doing. Without scope there is nothing. Or there is everything, if you are looking at it from the customer’s viewpoint. If boundaries are not set, then everything is in open season. Everything needs to be tested, prodded, penetrated, reviewed. While this is all good and all, projects are all bounded by cost, time and quality. Scope determines this.

In PCI, scoping became such a tremendously huge issue that the council deem it necessary to publish an entire supplemetary document called “Guidance for PCI DSS Scoping and Network Segmentation” back in December 2016. Now, here is a trivia for you, from someone who has been doing PCI for donkey years. Did you know that this isn’t even the first attempt at sorting out scope for PCI-DSS?

Back in 2012, there was a group Open Scoping Framework Group that published the extremely useful Open PCI-DSS Scoping Toolkit that we used for many years as guidance before the council amalgamated the information there into formal documentation. This was our go-to bible and a shout out to those brilliant folks at http://www.itrevolution.com for providing it, many of its original concepts retained when PCI council released their formal documentation on scope and eventually within the standards itself. YES, scoping is finally in the iteration of v4 and v4.0.1 for PCI-DSS in the first few pages, so that people will not get angry anymore.

Or will they?

We’re seeing a phenomenon more and more in the industry of what we term as scope creep. Ok fine, that’s not our word. It’s been in existence since the fall of Adam. Anyway, in PCI context, for no apparent reason some of our customers come back to us and state their consultants, or even QSAs insists on scope being included — for NO REASON except that it is MANDATORY for PCI-DSS. Now, I don’t want to say we have no skin in the game, but this is where I often end up arguing with even the QSAs we partner with. I tell them, “Look, our first job here is to help our customers. We minimize or optimize scope for them, reducing it to the most consumable portion possible, and if they want to do anything extra, let them decide on it. We’re not here to upsell Penetration testing. Or segmentation testing. Or Risk Assessment. Or ASV. Or Policies and Procedures. Or SIEM. Or SOC. Or Logging. Or a basket of guavas and durians.” Dang it, we are here to do one thing: get you PCI compliant and move on with our lives.

The trend we see now is that everything seems to be piled up to our clients to do this and to do that. In the words of one extremely frustrated customer: “Everytime we talk to this *** (name redacted), it seems they are trying to sell us something and getting something out of us, like we are some kind of golden goose.”

Now, obviously, if you are a QSA company and doing that:- STOP IT. Stop it. It’s not only naughty and bring disrepute to your other brethren in the industry, it’s frowned upon and considered against your QSA code! Look at the article here.

Now PCI scoping itself deserves a whole new series of articles but I just want to zoom down to a particular scoping scenario that we recently encountered. It’s in a merchant environment.

Now many of our merchants have either or both of these scopes: Card terminal to process card present at the stores and E-Commerce site. There is one particular customer with card terminal POI (point of interaction), or traditionally known as EDCs (Electronic Data capture). Basically this is where the customer comes, take out the physical card and dip/wave it to this device at the location of the stores. So yes, PCI is required for the merchant for the very fact that the stores have these devices that interact with cards. Now what happens after this?

Most EDCs have SIM based connectivity now, and it goes straight to the acquirer using ISO8583 messages. These are already encrypted on the terminal itself and routes through the telco network to the bank/acquirer for further processing. Other ways are through the store network, routing back to the headquarters and then out to the acquirer. There are reasons why this happens, of course, one would be the aggregation of stores to HQ allows more visibility on the transactions and analysis of traffic. The thing here is, the terminal messages are encrypted by the terminals, that the merchants do not have any access to the keys for decryption. This is important.

Now, what happened was that some QSAs have taken into their mind that because the traffic is routed through the HQ environment, the HQ gets pulled into scope. And therefore , this particular traffic must be properly segmented and then segmentation PT needs to be performed. This could potentially lead to a lot of issues, especially if your HQ environment is populated with a lot of different segments – it could constitute multiple, tiring, tedious testing by the merchant team….or it could constitute a profitable service done by your ‘service providers’ (Again, if these service providers happen to be your QSA, you can see where the question of upsell and independence come from).

Now here’s the crux. We hear these merchants telling us, oh, their consultant or QSA say that it’s mandatory for segmentation PT to occur in this HQ environment. The reasoning is that there is card data flowing through it. Regardless whether it is encrypted or not, as long as there is card data, IT IS IN SCOPE. Segmentation PT MUST BE DONE.

But. Is it though?

The whole point of segmentation PT is that it demarcates out of scope to in-scope. By insisting to have segmentation PT done, is to concede that there is an IN-SCOPE segment or environment in the HQ. The smug QSA nods, as he sagely says, “Well, as QSAs, we are the judge, jury and executioner. I say there is an in scope, regardless of encryption.”

So, we look at the PCI SSC and the standards, and let’s see. QSAs will point to page 14 of PCI-DSS v4.0 standards under “Encrypted Cardholder Data and Impact on PCI DSS Scope”.

Encryption alone is generally insufficient to render the cardholder data out of scope for PCI DSS and does not remove the need for PCI DSS in that environment.

PCI-DSS v4.0.1 by a SMILING QSA RUBBING PALMS TOGETHER

Let’s read further this wonderful excerpt:

The entity’s environment is still in scope for PCI DSS due to the presence of cardholder data. For example, for a merchant card-present environment, there is physical access to the payment cards to complete a transaction and
there may also be paper reports or receipts with cardholder data. Similarly, in merchant card-not-present environments, such as mailorder/telephone-order and e-commerce, payment card details are provided via channels that need to be evaluated and protected according to PCI DSS.

So far, correct. We agree to this. Exactly like what was mentioned, PCI is in scope. The question here is, will the HQ gets pulled in scope just for transmitting encrypted card data from the POIs?

Let’s look at what causes an environment with card encryption to be in scope (reading further down the paragraph)

a) Systems performing encryption and/or decryption of cardholder data, and systems performing key management functions,

b) Encrypted cardholder data that is not isolated from the encryption and decryption and key management processes,

c) Encrypted cardholder data that is present on a system or media that also contains the decryption key,

d) Encrypted cardholder data that is present in the same environment as the decryption key,

e) Encrypted cardholder data that is accessible to an entity that also has access to the decryption key.

So let’s look at the HQ scope. Does it cover the following 5 criteria for in-scope PCI-DSS dealing with encrypted card data? There is no decryption or encryption process done. The encrypted cardholder data is isolated from the key management processes. The merchant has no access or anything to do with the decryption key.

So now you see the drift. Moving down the paragraph, we find noted that when an entity receives and/or stores only data encrypted by another entity, and where they do not have the ability to decrypt the data, they may be able to consider the encrypted data out of scope if certain conditions are met. This is because responsibility for the data generally remains with the entity, or entities, with the ability to decrypt the data or impact the security of the
encrypted data.

In other words: Encrypted cardholder data (CHD) is out of scope if the entity being assessed for PCI cannot decrypt the encrypted card data.

So now back to the question, if this is so, then why does the merchant still need PCI? Well, because it’s already provisioned above: For example, for a merchant card-present environment, there is physical access to the payment cards to complete a transaction and there may also be paper reports or receipts with cardholder data.

So therefore, stores are always in scope. The question we have here is, if the HQ or any other areas are pulled in scope simply for transmitting encrypted CHD as a passthrough to the acquirer. In many way, this is similar to why PCI considered telco lines as out of scope. They simply provide the highway where all these encrypted messages travel on.

Now, of course, the QSA is right about one thing. They do have the final say, because they can still insist on customers doing the segment PT even if its not needed by the standard. They can impose their own risk-based requirements. They can insist the clients do a full application pentest or ASV over all IPs not related to PCI. They can insist on clients getting a pink elephant to dance in a tutu in order to pass PCI. It’s up to them. But guess what?

It’s also up to the customer to change or have another opinion on this. There are plenty of QSAs about. And once more, not all QSAs are created equal as explored in our article here.  Here we debunk common myths like whether having a local QSA makes any difference or not (it doesn’t), and whether all QSAs interpret PCI the same way (they don’t) and how important independence and conflict of interest should play a role, especially in scoping and working for the best interest of the customer, and not peddling services.

So, if you want to have a go with us, or at least just get an opinion on your PCI scope, drop a message to pcidss@pkfmalaysia.com and we will get back to you and sort out your scoping questions!


PCI-DSS V4.0 Deep Dive 2: Keyed Cryptographic Hashing

May 20, 2024 / / 0 Comments

As we delve into the intricacies of the PCI-DSS v4.0 standard, it’s crucial to understand the significance of each requirement and its impact on safeguarding sensitive cardholder data. For this article, we’ll be focusing on Requirement 3.5.1.1, which revolves around the use of keyed cryptographic hashing for protecting Primary Account Numbers (PANs).


Requirement 3.5.1.1 states that “Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures in accordance with Requirements 3.6 and 3.7.”

Firstly, like everything else from interpreting history to interpreting your wife’s nuanced tone when she says, “It’s fine.”, everything needs a little contextualization. Luckily for us, PCI has placed some explanation for us to jumpstart the discussion.

A hashing function that incorporates a randomly generated secret key to provide brute force attack resistance and secret authentication integrity.
Appropriate keyed cryptographic hashing algorithms include but are not limited to: HMAC, CMAC, and GMAC, with an effective cryptographic strength of at least 128-bits (NIST SP 800-131Ar2).
Refer to the following for more information about HMAC, CMAC, and GMAC, respectively: NIST SP 800-107r1, NIST SP 800-38B, and NIST SP 800-38D).
See NIST SP 800-107 (Revision 1): Recommendation for Applications Using Approved Hash Algorithms §5.3.

Definition of Keyed Cryptographic Hash, PCI Glossary

So that’s a lot of MACs.

Let’s break it down. The requirements has 3 areas of importance, which we have helpfully underlined.

Keyed Cryptographic Hashes

The requirement mandates the use of keyed cryptographic hashes to render PANs unreadable. A keyed hash basically takes the entire PAN and combines it with a secret key to produce a unique, fixed-size output that is practically impossible to reverse-engineer without knowing the key. This way, even if an attacker gains access to the hashed PAN, they won’t be able to derive the original PAN without the secret key.

In 3.2.1, this was not stated and therefore the assumption that a simple hash was sufficient. Let’s listen to what this old obsolete standard says: “It is recommended, but not currently a requirement, that an additional, random input value be added to the cardholder data prior to hashing to reduce the feasibility of an attacker comparing the data against (and deriving the PAN from) tables of precomputed hash values.”

That aged like milk. Basically they are talking about salt. The goal of salting is to protect against dictionary attacks or attacks using a rainbow table. If no secret salt is used, or if the salt has not been sufficiently protected, the corresponding data, for example the PAN, can be read from the attacker’s previously calculated dictionaries or rainbow tables. So in short, salts are good for the world. Except for Salt Bae. He’s no good.

Salting creates slow hashing, which is the point. So that it takes a few billion years for brute force to be successful. How different is salting from keyed hashes? For one, salts are generally known. Sometimes they are even stored together with the hash in the database. So if let’s say, that’s compromised, Salt is known. I suppose, you can say “Live by the salt, die by the salt.” Ha!

Keyed Crypto Hashes mean there is a secret key. And before you go and jump off the building, there are already existing algorithms out there (The MAC brothers) that has previously been used — primarily, to my knowledge — for message integrity checks. In fact, the MAC here means Message Authentication Code to check integrity and authenticity. Unlike the salt, it ISN’T known, or at least not unprotected. So even if the database is compromised, they can’t get the key, because it’s protected (through encryption, later on to explain).

Now, why the change from normal hash, with recommended Salt, to hash with secret key?

The problem is with card numbers. Those dang card numbers, which is so different from let’s say passwords. Unlike passwords, where it could really be random, credit card numbers are NOT random. They are unique, but they are far from random. You see, a credit card consist of:

  1. The bank identification number (BIN) or issuer identification number (IIN): The first six digits is the issuer id. You can go https://www.bindb.com/bin-list
  2. The account number: The number between the BIN and the check digit (the last digit) is six to nine digits long and is used to identify the individual account number.
  3. The check digit: The last digit, added to validate the authenticity of the credit card number. This is by using the Luhn algorithm.

The thing about Luhn is that it is used to validate primary account numbers. I am not going into details, as other people have done so and will do a much better job in explaining this. But the short of it is that, if I have the BIN, and I have the Luhn and I have, let’s say 3 more numbers of the account number, then you get the picture. The Luhn digit is the result of the luhn algorithm applying to all the previous numbers (right first to left), which you already known, if it’s truncated! You would already know 9 digits (first six, last three, the last being the final luhn result). It’s likely still going to take a lot of effort, but the predictable way credit cards are structured actually provides less fields to be guessed. As scary as it may sound, hashes can be possibly reversed. Well, not ‘reversed’ per se but ‘reconstructed’ through guesswork and bruteforce.

While salt adds complexity and make it slower, salts aren’t secret, remember, so eventually that can still be broken. A Key however is secret. Remember the data encryption key, key encryption keys? Well, hashing now requires the same treatment as encryption in that sense that these keys need to be encrypted.

The other important bit of this requirement is the requirement emphasizes that the entire PAN must be hashed. This is important because hashing only a portion of the PAN would still leave some sensitive information exposed. By hashing the entire PAN, we ensure that no part of it remains in plain text, adding an extra layer of protection.

Lastly, the requirement stresses the importance of proper key management processes and procedures, as outlined in Requirements 3.6 and 3.7. This means that the secret keys used for hashing must be securely generated, stored, and managed throughout their lifecycle. Weak key management can undermine the entire purpose of keyed hashing, so it’s crucial to get this right.

What does this mean?

It means, like a lot of new requirements in v4.0: more work.

It is, in its heart, a concept of defense-in-depth. Requirement 3.5.1.1 serves as a secondary line of defense against unauthorized access to stored PANs. Even if an attacker manages to exploit a vulnerability or misconfiguration in an entity’s primary access control system and accesses the database, the keyed cryptographic hashing of PANs acts as an additional barrier, preventing the attacker from obtaining the actual PANs, unless they manage to compromise the key.

By implementing a secondary, independent control system for managing cryptographic keys and decryption processes, entities can ensure that a failure in the primary access control system doesn’t automatically lead to a breach of PAN confidentiality. For instance, instead of storing the PANs in plain text, a website employs a keyed hashing algorithm, such as HMAC-SHA256, to render the PANs unreadable. Each PAN is combined with a unique, randomly generated secret key before being hashed, and the resulting hash values are stored in the website’s database.

Final note: It’s important to note that Requirement 3.5.1.1 applies to all instances of stored PANs, whether in primary storage (databases, flat files) or non-primary storage (backups, audit logs, exception logs). This means that entities must ensure that keyed cryptographic hashing is implemented consistently across all storage locations, leaving no room for gaps in protection.

However, the requirement does make an exception for temporary files containing cleartext PANs during the encryption and decryption process. This is a practical consideration, as it allows entities to temporarily work with unencrypted PANs while performing necessary operations, as long as the temporary files are properly secured and promptly removed after use.

If you have any questions or need assistance in navigating the complexities of PCI-DSS v4.0, don’t hesitate to reach out to us at avantedge@pkfmalaysia.com. Our team of experienced professionals is here to help you every step of the way, ensuring that your organization stays secure, compliant, and ahead of the curve in the ever-evolving landscape of data security.

PCI-DSS: Estimating the Cost

February 7, 2021 / / 0 Comments

Ah money.

This is how most conversations start when we receive calls from PCI. How much will it cost?

I think this is one of the toughest subject for PCI, because it really depends on what is being done by the service provider/consultant for you, and how much you can actually do the implementation of PCI-DSS on your own. And obviously it also depends on your scope, and on top of that, depends on compensating controls if any, or any current controls you have in place. And then it also depends on the validation type – SAQ vs RoC and so on.

So, in the classic riposte to this classic question, it would be “It depends”.

Where we really need to clear the air though is the myth that once you have done PCI-DSS the first time, everything gets easier on the renewals and everything gets cheaper year on year going forward. That is for another article. There is a lot of things going on in PCI-DSS, and if you approach it from a product perspective (like most procurement do), you end up either sabotaging your entire compliance, or getting an auditor willing to sign off on God knows what, and later on realise that you’ve been out of compliance scope all the while.

To start with the pricing, you should understand a bit on the cost of PCI-DSS. And we should start with the QSA, because after all they are the focal point of the PCI program. They are the Qualified Security Assessor. Of course, you can opt to do your PCI (if allowed) without a QSA involvement (Merchant level 3 or 4) and just fill up an SAQ with or without assistance from consultants; but for the most part, a QSA would be involved in the signoff for larger projects, and this is where the cost questions take life.

Lets look firstly at the base cost of becoming a QSA. It’s very helpfully listed for us here: https://www.pcisecuritystandards.org/program_training_and_qualification/fees

So here are the maths. Imagine you are a QSA with projects in Malaysia: to start off, you will need to set aside over RM100K just to get you qualified to to audits in the Asian Region. We’re not talking about Europe or Latin America or USA here. Just APAC. That’s qualifying the company. A company, to service any region properly will probably need a bunch of QSAs trained and ready, let’s say around 3 to start off with. Each QSA will need to go for a training costing around RM12 – 13K, so let’s say you have 3 (which is very few), you are setting aside around MYR 50K for that. On top of that, there are obligations such as Insurance Coverage that is specified in the QSA Qualifications Requirement document. So it depends on which insurance you are taking, but it could be in the region of around MYR6K or above premium (spitballing). There is a requalification each year as well.

QSAs then can make their own calculations on how fast/long they need to recover their cost, but let’s say they set aside 200K just to get things set up with 3 or 4 QSAs, then they need to recover that cost. A man day of a QSA/Consultant may range from quite widely in this region but let’s say you decide to price it at “meagre” MYR2K, depending on how senior you have, so overall, you would need to have almost around 1.5 months of engagement of their QSAs just to recover the cost of setting up shop. That’s why its not unreasonable to see higher rates, because of the cost it takes.

You have salaries to consider as well. You also have to consider if something happens to one of your clients, where you happily audited them remotely and believed everything they said, and found out that they have done jack-shoot in their actual environment and you have to handle the fallout of liabilities.

Some procurement compares QSA engagements to firewall engineers. No knock on other technical engineers, but the cost of getting a Checkpoint firewall engineer and the cost to maintain one QSA is a different proposition. I am not saying one is better than another technically (I’ve seen a lot of firewall engineers who could put any auditor into their place, due to their extremely proficient technical skills), I am stating the underlying cost behind the position, which is why PCI-DSS is priced at a rate that’s comparable to say, CMMI, as opposed to say, the ISO9001.

On top of just auditing cost, QSAs take into account the actual support they are giving year on year. Some of them unburden this cost to partners and consultants who have been trained (such as PKF – and there are also other matters such as independence of audit vs implementation advisory which we will discuss later), or some of them take it upon themselves. But you must know the QSAs job is not easy. Aside from auditing and supporting, there is evidence validation and report writing. Then there is the matter of undergoing the Quality Assurance process, which brings more resources/cost to the QSA company. All this while travelling to and from audit sites, reviewing etc – the life of a QSA (ask any QSA) is itinerant and often travel heavy. Burnout may also be a concern, so if the QSAs are involved in the day to day or week to week assistance to their client’s PCI program, this isn’t sustainable.

Understanding all these underlying cost will allow the procurement or whoever is evaluating to understand how to look at projects. If a QSA is pricing extremely low, the question you will need to ask is: What’s being offered? Because all QSAs have more or less the same baseline cost and if a QSA priced themselves at RM800 per man day, and they are a small shop with less than 5 QSAs, what would then be their recovery rate? 200 man days of engagement to recover their initial cost? Most procurement wouldn’t think of things like this and they would just go to their “BAFO” Best and Final Offering – but when you break it down on what is expected, then you would understand that not all PCI offerings are the same. I could simply quote a client 3 man days of QSA work for the final audit and be done. That would be the best and final offering that would win. But what about the healthchecks, the management of the evidences and how they are submitted, the quality checking, the scope optimisation process, the controls checking etc etc?

And in line with our effort estimation, one should also split the pricing into two: Audit and Consultation vs Implementation service and products.

Because if let’s say we find your Requirement 10 is completely empty, and you are thinking to purchase a QRadar SIEM to address it, you could be looking upwards of RM60,000 just to get the product in. Couple that with training for engineers, usage, hiring etc, and you are well over the six figure stage just for Requirement 10! How about testing and application reviews? If you don’t have the personnel on this, then you have to consider setting aside another RM50K etc depending on how many applications/mobile applications/ systems you have in place. So it’s highly essential to have the QSA/consultant assist you in scope reduction. Most may not view it that way, so it’s essential to find an auditor who is experienced and who looks after your interest.

Finally, understand that cost of audit/consulting would be different depending on how you go through PCI-DSS. Level 1 certification requires the effort of validating evidences, doing gap assessments and auditing and writing the RoC. Level 2 SAQ with QSA signoff is slightly easier, as there is no RoC to write while the last option of self signed SAQ without QSA is obviously a lot less costly as you are basically doing a self-signoff. Those are just broad guidelines and not how QSAs may price it, because as I say, due to variables.

You could opt to use the rule of 1/3 when it comes to estimating these costs, although your mileage may vary. For instance, if the QSA throws a RM100K audit fees (comparing it to CMMI fees) for a Level 1 Certification, then a RM60-65K (2/3 of the Level 1) for a SAQ Signoff could be reasonable; and furthermore if you just need them in for consultancy for the non QSA signoff SAQ, it could be 30K (1/3 of the level 1) or so. But note, the SAQ self signoff can be carried out entirely on your own, so the cost could be close to zero as well.

I know its a tough one to place this as pricing varies so often. We aren’t selling a product with specific hardware/software. We are selling a service that will take you through 6 months of work to cover scoping exercise, project meetings, changes, consultancy and advisory, pre-audits and post audits checks, evidence and artefacts sample validations, audit, report writing, training and all the variables in between.

Let us know if you need us to look at your PCI today, drop us a note at pcidss@pkfmalaysia.com and we will attend to you immediately!

PCI-DSS: The AoC Problem

November 28, 2020 / / 0 Comments
pci-compliance
pci-compliance

Recently we were reminded once again why we constantly state that PCI-DSS must chuck away the Certification of Compliance for good. Not only it’s an unacceptable documentation to the PCI Council, but it presents a lot of problems for auditors and assessors, as well as organisations seeking PCI-DSS compliance evidence from their service providers.

Let’s go back to how PCI-DSS flows in the first place.

PCI-DSS applies to all organisations that store, process and transmit credit/debit card under the umbrella of Visa, Mastercard, Amex, JCB and Discover/Diner.

Requirement 12.8 further extends the need to manage service providers where card data is being shared, and where “they could impact the security of the customer’s cardholder data environment”. That word is key because many service providers we have spoken to retorts they are out of scope of PCI-DSS of their clients because:

a) They only provide infrastructure and has no access to card data

b) They only store physical copies of forms that are sealed in boxes and they don’t access it

c) They only provide hosting

d) They only provide customer service support

e) They only provide toilet cleaning services

Of the 5 most popular services above, only the last one, we can probably surmise, does not require PCI-DSS. The rest – not to say they are 100% applicable – would require at the very least a bit of scoping to determine if they are applicable or not for PCI. Such is the problem here.

Having established that even, say a cloud service provider that only provides IaaS, requires PCI-DSS, what is then the next problem?

We call it the problem of the AoC. Or rather, the lack-of-AoC. Or more accurately, the-refusal-of-service-providers-to-provide-AoC-since-they-already-have-the-Certificate-of-Compliance problem. Its a very long problem name, so we will just call it the Problem of the AoC.

The AoC is the Attestation of Compliance, which is basically a shortened version of the Report on compliance (ROC) or the Self Assessment Questionnaire (SAQ). So in ALL PCI-DSS Compliance, whether assessed by 3rd party or self assessed, there is an AoC. 100%.

This AoC will describe in summary what are the processes in scope of PCI-DSS AND services that are NOT in scope of PCI-DSS. This is absolute key. In Part 2 of the SAQ, it states the type of service and the name of Service included in the PCI-DSS compliance (below):

Right after that, we need to ensure there may be services being offered that for some reason is NOT assessed for PCI. An example here could be a company offering BPO services, but at the same time offering a payment gateway service. They could be PCI compliant for payment gateway but not compliant for their BPO – even though both would deal with credit cards. So we need due care in determining whether the service we are procuring from them is indeed, PCI Compliant.

This is very important. And the fact that most “Certificate of Compliance” actually does not state the scope of services under PCI-DSS, presents a problem for assessors.

We once had a very animated discussion with a large service provider providing a customer support application to our client that collected credit card information. The service provider insisted they are PCI-DSS compliant and they showed their ‘Certificate of Compliance’. The said their AoC is private and confidential and all of their customers have accepted their Certificate as proof of their compliance, which meant, we are obligated to accept it as well (according to their very animated representatives).

Now, we all know the Certificate of Compliance is as valuable as toilet paper (actually, maybe less, since toilet paper can sometimes be VERY valuable during the pandemic and panic buys) – so we insisted on them showing us their AoC. For the simple reason:

They offered the on-prem application to our client, i.e installed onsite to our client’s environment. Our client says since this application is ‘PCI-DSS’ compliant, we should not need to assess their application under Requirement 6 of PCI-DSS. Hmm.

This doesn’t sound right. The vendor kept insisting that PCI-DSS only requires them to show their Certificate, and that the information in their AoC are private and confidential and we have no right to request from them.

PCI-DSS is applicable to an environment, process and location. You can see these ALL clearly in the AoC. Not in the nonsensical and utterly useless Certificate of Compliance. Why we didn’t believe this was that, because the application was installed in our client’s environment, there shouldn’t be an instance where this application is “PCI-DSS” compliant. At most, they could claim an application to be PA-DSS compliant (or the new SSF compliant) – but that is also impossible as their application wasn’t a payment application related to settlement or authorisation – so it’s not eligible for PA-DSS! So how can this be ‘PCI-DSS Compliant’?

We were at an impasse. Because they refused to give their AoC, we refused to accept their Certificate of Compliance. They lodged a complaint, we stood firm. We were not going to pass our customer on the basis of some hocus-pocus documentation which was clearly NOT acceptable to the PCI council!

Finally, they relented, and gave us a redacted, valid AoC and telling us how wrong we were in insisting on this and we did not know what we were doing. But all we needed to see was the page above – where the scope of compliance was summarised. And in it, stated “XXXX Customer Service Cloud Solution”.

Cloud solution.

We asked the customer, did they subscribe to the cloud solution?

No, they didn’t. It was an on-prem. Installed, lock stock and barrel application into the VM managed by our client. In an environment and location secured by our client.

Wait, said the vendor. The on-prem solution is the same as the cloud solution backend they were using and have been assessed for PCI. So what was our problem? The only difference was that their ‘cloud solution’ was now installed on customer side, so this should still be acceptable.

So, well, that isn’t a cloud solution then, is it? I mean, if you have a secured safe and you put it into your high-security house, would that also mean you can put the same safe in the middle of Timbuktu somewhere and still have the same level of security? (No offense to Timbuktu, we are just using that as a reference…we should stop using it actually but oh well.) Wouldn’t the cloud solution also be assessed for its environment, processes and policies? Would this be the same on the customer end?

The point here, is that based on the AoC, we can clearly say that the PCI compliance isn’t applicable to the on-prem solution. So we still have to assess the application as it is, under Requirement 6, under the client’s PCI program.

This isn’t any ‘victory’ or whatever we can claim, but it is so extremely frustrating to waste so much time on matters that would not be any issue at all, if the problem of the AoC is resolved. Just HAVE THE AoC TO ATTEST PCI-DSS! And stop this Certificate baloney! Because of this, we end up behind schedule and we have to chase up again and again.

So, read the AoC thoroughly before you decide on a vendor/service provider – because the certificate they provide to you could very well be invalid to the services they are actually offering you. Insist on the AoC.

Drop us a note at pcidss@pkfmalaysia.com to know more about your compliance. We will respond to you immediately!

ASV Scans /= PCI Compliance

November 22, 2020 / / 0 Comments

There is an old story about a chicken and eagle. I hear this story being told by life coaches or motivational trainers trying to get through to our thick, jaded, technical skull that there is something more to life than coding and technology.

The abbreviated version is this: A farmer was walking and finds an eagle’s egg fallen out of the nest. He picks it up, brings it back to his farm, and puts it into the chicken coop. Soon, it hatches, and joins the other chickens in the farm and learns how to be a chicken, even though its an eagle. So this is where some of the version diverges.

a) The chicken and the eagle starts talking one day and the eagle notices another eagle flying high in the sky and he goes, “Dang, I wish I could be an eagle,” and his chicken-pal looks at him scornfully and says, “You are a chicken. How can you be like the king of all birds, soaring through the sky?” So the eagle keeps thinking he is a chicken and the next day he gets roasted for dinner. And the farmer finds his meat a bit tough and doesn’t taste like chicken at all. The moral here is: Don’t let your limitations inhibit you or you will end up a cooked and eaten. This is probably the original version before the other two came along below:

b) The farmer is visited by a naturalist who observes this ‘chicken’ and immediately knows he is an eagle. So he takes this chicken up to a high cliff, and throws him over, shouting: “Spread your wings and fly! Soar like the eagle you are meant to be!” And the eagle soars through the clouds and sky and become the king of all birds. The moral of the story: All of us are eagles, even if you think you are a chicken. All you need is a life coach or a motivational trainer to throw you off the ledge and you will soar. This is the preferred version for life coaches and motivational speakers. For obvious reason.

c) Same as story b) above, but instead of soaring, the naturalist throws the ‘chicken’ off the ledge, and it falls 100 feet and splatters its brains all over the bottom of the ledge and dies since it doesn’t know how to fly. And gets cooked and roasted for dinner. The moral of the story (and this is by far, our more preferred, realistic and risk-averse version): Don’t do something you may be destined for but not ready for. Or you will end up smashed, cooked and eaten.

All three versions have this theme in common: The eagle isn’t a chicken and the chicken isn’t an eagle. The chicken may have commonalities of an eagle, like wings and a beak, but just because it has those doesn’t make it an eagle.


Yes, I am aware that the anecdote above isn’t a very good illustration of the point I am trying to make, but I couldn’t think of a better one. And in a roundabout way, what I want to illustrate here is that ASV scans do not make you PCI Compliant.

We get this a lot.

A company would come and say they are PCI-compliant. Or we have a client who outsources certain portion of their operations to another company and that company comes back and shows us their ASV compliant scan and says this is all they need to show us. We (The auditors/consultants) are compelled to accept this because the ASV scans demonstrate their PCI Compliance, they say.

Let’s make a point here: ASV questions and subquestions in the SAQ D covers around 14 queries. Out of around 600. That means ASV covers 2.33% of PCI-DSS. There is a massive load of other controls and items covering PCI-DSS Other than those precious ASV quarterly scans. What about your patching? Hardening? Firewall security? HR policies? Logging and monitoring? Logical access? MFA? Hardening of systems? Anti-virus and host firewalls? What about service provider management? What about vendor default passwords? What about storage, encryption, key management? Software development? Application and penetration testing? Internal vulnerability scans? Training?

You can see how impossible it is to accept just the ASV report as an evidence of PCI compliance, much like how we cannot accept the chicken as an eagle, but yet, we are constantly berated upon that we don’t know what we are doing and that their Banks have accepted their ASV scans as a sign of PCI compliance, so we should to. But we can’t. We can’t accept 2.33% as a 100% of something. It’s simply mathematically not possible.

So there you go – banks. Why do banks perpetuate this myth that PCI compliance = ASV scans? Why? It’s 2.33% of PCI-DSS! You can’t accept something as an eagle just because it has wings and a beak! There’s really no argument about it.

Here is what 2.3% feels like:

a) The number of Jazz music of all US Music sales in 2013

b) Increase in slot machine spending in New Zealand in 2018 Q1

c) Auto parts industry against the US GDP in 2013

d) Android 6.0 Marshmallow installation for all Android devices in July 2016

e) Thats lesser than the % of freshwater we have on this planet (2.5% of water on the planet is freshwater)

I am sure there’s a lot of 2.33% out there on this planet, but the point we are making is this: It’s not compliance. It’s a small but important part of compliance but it’s not compliance. So no matter what your banks tell you, we can never accept the ASV scan as a sign of PCI compliance. It can be accepted as one of the evidences of PCI compliance amongst many, but not as an evidence of complete compliance.

Now, stop calling a chicken an eagle. Let us know about your questions for PCI or any compliance at pcidss@pkfmalaysia.com.

« Older posts

© 2024 PKF AvantEdge

— Up ↑