PKF AvantEdge

Tag: pci (Page 2 of 3)

SAQ A and A-EP, the eternal struggle

October 26, 2020 / / 0 Comments

Another week, another lockdown struggle, another political instability and another question on the eternal confusion called the SAQ A and A-EP. And this time, it wasn’t so much of us trying to clarify with the customer on this – but us trying to explain to QSAs on it. It just shows how much confusion there is to this thing even after all these years, that even auditors, whose bread and butter is literally on PCI-DSS still struggle to understand it. I don’t blame them – it’s the way that the SAQs are worded, and the confusion that surrounds it that makes it so frustratingly difficult to interpret.

SAQ A by far gets the most mileage. Not because a lot of people are eligible for it, but because at 20+ questions, it’s by default the go-to SAQ for most organisations, whether they are eligible for it or not. I mean, comparing the SAQ D and the A is like scaling Everest vs the little sand hill that your 5 year old kid just built on the beach. Something like that. So everyone (even non-eligible Service Providers) always default to the Open Shortest Path First, which is the SAQ A when they need to choose an SAQ to be “PCI-Compliant”.

However, SAQ A is notoriously difficult to be eligible for and today we are going to look at it. Again. We have often seen everyone anything from storing card information, to hardcopy storage of insurance policies, to doing outsourced call center picketing in front of our office shouting for their SAQ A rights. I mean, let’s start here with SAQ A and A-EP and the difference.

We are not going to focus on the controls in these SAQ, but rather the ‘eligibility’ of it, meaning, on Page 4 of both SAQ under “Before You Begin”. Instead of just repeating all that is typed in there in this article, I will assume those reading this article is keen for a deeper dive into the murky waters of SAQ and not here for a shallow wade – so I am going to assume you have those SAQs right in front of you and I don’t have to delve into the history much, ok?

SAQ A’s story starts off by stating there are TWO types of business who are eligible for it.

a) E-Commerce Merchants

b) MOTO (mail order/telephone order) – card not present

c) Of course, those who do not STORE, PROCESS or TRANSMIT card holder data in ANY electronic format on their system and premise.

Let’s start with MOTO first, because this often confuses people. Straight away those doing MOTO will dance a jig in front of me and gleefully points out that they deserve the SAQ A. All your base are belong to SAQ A, if those nerds like me would understand. Because I usually move them over to SAQ C or C-VT depending on how their call center/MOTO transactions are set up (even B-IP may apply e.g MOTO function on terminal, but mostly MOTO ends up being in SAQ D because they often store card data on file).

Hold on there though. Eligibility of MOTO is tied to the eligibility of c) – i.e you do not store (OK), process (erm, yeah ok, sometimes) or TRANSMIT card holder. Often the transmit and process part is done when you have people on your premise doing MOTO. The moment a phone call comes in – BAM! you are hit. You are done for.

So the ONLY time MOTO is eligible for SAQ A is later described in the SAQ:

Mail order/telephone order (MOTO) or e-commerce merchants that have completely outsourced all operations (where there is no redirection mechanism from the merchant to the third party) and therefore do not have any systems in scope for this SAQ, would consider these requirements to be “not applicable.”

SAQ A

The above is talking about how we can mark Requirement 2,6 and 8 as Non applicable. But notice where it states: COMPLETELY OUTSOURCED ALL OPERATIONS. This means, your company’s MOTO transaction is never done by your own company or on your own premise or by your people or using your technology. You have Completely, irrevocably, irreversibly outsourced the entire function to someone else who is PCI-DSS compliant. Then OK, you cool.

So now we know how to deal with that MOTO part. Oh wait, wait. There is a scenario from one client, where customers actually come over to the counter and try to make payment. However, because they have upgraded everything, instead of dipping or waving that card into a terminal for a POS payment, the counter person whips up a high tech iPad, connects to the companies website, looks at the credit card (while the customer is in front of them) and type out the transaction onto the e-commerce site itself for the transaction. How do we deal with this?

Well. This certainly doesn’t qualify for SAQ A in a strict sense, since this is considered a ‘face-to-face’ channel. However, logically, that transaction is made as an e-commerce, card non present transaction, because the CVV is entered as well and on the merchant end, it qualifies as a e-commerce transaction based on the flow and the fee they are paying. This is an interesting scenario as I would likely look at it as an e-commerce flow, since technically, the customer can do it themselves, but its just that for some reason, maybe they don’t know how, or they can’t figure it out, they go over to the counter to do it. The acquirer certainly doesn’t know about it. But because the information is going through the company’s asset, the company’s line, the company’s network, there would be additional risk they need to consider. In the end, it would be the call of the QSA on how they view this, however, I don’t think this could qualify for an SAQ A channel. It could be technically treated as a SAQ B-IP as we can assume its a terminal, but most auditors, to err on the side of caution may just opt for the full SAQ D on this.

OK, MOTO done.

Now for the e-commerce. I am not going to repeat what I’ve written some years back: https://www.pkfavantedge.com/it-audit/pci-dss-saq-a-and-saq-a-ep-differences-in-a-nutshell/

But I am just going to dive right in where the confusion begins. SAQ A-EP is written in a way that confuses people, and requires some sort of Indiana Jones exploration to figure out what in tarnation they are trying to get at.

So, under Before you begin, the second eligibility point (we call this ITEM 2):

Item 2: “All processing of cardholder data, with the exception of the payment page, is entirely outsourced to a PCI DSS validated third-party payment processor;”

This is confusing. They say – “All processing of cardholder data EXCEPT the payment page”. This means, the payment page actually SITS with the merchant, while everything else is outsourced to PCI third party. This means, this SAQ is eligible for merchants with PAYMENT PAGE (where credit card is entered) residing in their premise. So therefore, if the PAYMENT PAGE is also outsourced, immediately, this SAQ is no longer eligible. In a simple logic:

if (paymentpage) then { read next line;} elseif (!paymentpage) { exit();}

That means, SAQ A-EP doesn’t apply anymore to us if we have outsourced the payment page because this condition is not met, and therefore the if statement should exit, or if you are in a loop, it should end. SAQ ENDS.

The problem is auditors are generally non-programmers and even when the condition is no longer eligible, they keep going!!

And it’s really, the next line that is the confusion of all confusion:

Item 3: “Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor;”

I mean, if we had exited the SAQ loop on the second condition, we won’t need to deal with this nonsense. So let’s break it down. YES, my e-commerce website does not receive card holder data, since I outsourced ALL MY PAYMENT page already to third party. But wait, you are saying “CONTROLS’ how consumers or data are ‘redirected’ to a third party? What? Obviously there is an element of control here, so how do we define ‘control’? Isn’t redirecting to an outsource payment page CONTROL?

The next confusion is the next line:

Item 4: “If merchant website is hosted by a third-party provider, the provider is validated to all applicable PCI DSS requirements (e.g., including PCI DSS Appendix A if the provider is a shared hosting provider);”

Hold up – didn’t we already agree that if the merchant entire website is hosted by a third party PCI provider, this would already not be in SAQ A-EP (see the exit rule of item 2). In fact, isn’t completely outsourcing the website the whole point of SAQ A? What sort of black magic is this?

Item 5: “Each element of the payment page(s) delivered to the consumer’s browser originates from either the merchant’s website OR a PCI DSS compliant service provider(s);”

Look at this wording. Look at it. Tell me that this is not contradicting item 2, the ‘with exception of the payment page’ condition. Let me rephrase item 2:

“You can go for SAQ A-EP if you host your payment page and have outsourced your processing to a PCI third party” –therefore implying that if you don’t host payment page and outsource everything, then another SAQ (SAQ A) applies.

Item 5 slaps Item 2 in the face and goes, “No. SAQ A-EP for you if you host the payment page, or the payment page is hosted by your PCI-DSS service provider. So no, Item 2, you wrong. You dead wrong.”

That usage of the word “OR” in that sentence confuses programmers or those with IT background, I think. This is a logical connector where if condition A OR condition B, if any of this is TRUE or both TRUE, we enter into the loop. Compared with the AND connector, where both needs to be true, otherwise we don’t process the loop. So the above statement is stating “ANY CONDITION WHATSOEVER” since it uses “OR”, will need to apply SAQ A-EP.

In fact, if they had clarified if all of these conditions are connected to each other either through the AND or OR operator, it would makes much more sense to us. It’s like the question, “Are you going to do it now OR do it later?” and we answer “Yes!” because we are indeed doing it now or later, and the question didn’t specify which condition as long as we are doing it.

Anyway, back to the story. The note in SAQ A-EP states:


For the purposes of this SAQ, PCI DSS requirements that refer to the “cardholder data environment” are applicable to the merchant website(s). This is because the merchant website directly impacts how the payment card data is transmitted, even though the website itself does not receive cardholder data.

SAQ A-EP OMINOUS NOTES

It is very ominous. It states, even if your website does not receive card holder data, you still impact or ‘control’ how the payment card is transmitted.

All is not lost though, because if you flip back to SAQ, under the SAQ A notes:

For this SAQ, PCI DSS Requirements that address the protection of computer systems (for example, Requirements 2, 6, and 8) apply to e-commerce merchants that redirect customers from their website to a third party for payment processing, and specifically to the merchant web server upon which the redirection mechanism is located

SAQ A OPTIMISTIC NOTES

I mean, I don’t know how clear it needs to be. It states in SAQ A “FOR THIS SAQ” – apply to merchants that ‘REDIRECT’ customers FROM their website (merchant website) to 3rd party for payment processing and specifically TO the merchant web server where the redirection occurs.

I am going to clarify the phrase that is underlined. the word “TO” is a preposition of the verb “apply to” in the earlier sentence, i.e this applies to merchants, specifically to their web server etc etc. Why its confusing here is because some may read it as a preposition to indicate direction , i.e redirect customers from their website to a 3rd party, specifically TO a merchant web server etc etc, which basically indicates the redirect is going into a loop (from merchant site to third party back to the merchant site) which doesn’t make sense.

I just want to point this out as I may not be the only one confused with this play of words and irresponsible usage of the preposition “TO”. Only me? Ok, fine.

Anyway – long story short, we used the notes in SAQ A to get out of jail for our client, and the QSA seemed to be resigned to that, noting there is a huge huge confusion with how A-EP is written. You do need to know, A-EP was born after A, so definitely, there would be some contradiction since they weren’t written together. SAQ A-EP is like the grumpy uncle that sits in the corner in your Christmas party and snaps at you when you ask him how he’s doing, while SAQ A is like the uncle with all the presents and all the children running around him and laughing with him as he tells a joke. Ah, SAQ A, we like you a lot.

Anyway – a final note on us, while we can state on PCI side, a full outsourcing of e-commerce payment page to third party qualifies for SAQ A, you do need to think – SAQ A-EP makes sense. The page doing the re-direct could be attacked and compromise and the redirect sent to another ‘payment page’ that looks exactly the same as the actual one. So while you are laughing with SAQ A, you need to take into account not to ignore the reasonable requirements that A-EP puts to you – vulnerability scan, firewall rules, penetration testing – i.e these are all best practice baselines that should be practiced regardless of compliance conditions etc. I would recommend a middle ground and take up a risk approach to it – implement these controls based on a good risk assessment and not just ignore the poor, grumpy SAQ A-EP uncle sitting in the corner. Because he may have a point in terms of security, after all.

Let us know about your experience or questions on PCI, SAQs or any other compliance questions at avantedge@pkfmalaysia.com!

Is PCI-DSS the most confusing standard?

June 24, 2020 / / 0 Comments

After being involved in PCI-DSS for almost a decade as well as other standards and guidelines like ISO27K, 27017, 9001, PDPA, GDPR, CMMI and a partridge in a pear tree, we can almost unanimously say: PCI-DSS is probably the most confusing standard out there. Not so much of the content itself – it’s fairly easy to understand in terms of the technical controls. The confusion begins at the start: Applicability and Scope.

Now scoping for PCI-DSS has been hammered by us in many articles over the years, so for this article, we will look at Applicability.

So what is applicability?

It simply means, who does this standard apply to? This is different from ‘scope’. A scope is basically what is being assessed? Applicability is basically: Do I need to do this thing?? For instance for simplicity:-

a) GDPR = Applies to entities processing EU personally identifiable information. Entities that may have a more global presence or require to deal with customers with a larger market distribution may end up being applicable to the GDPR.

b) PDPA = applies to entities in Malaysia processing personal information, which basically means almost everyone.

c) ISO27001 = guideline that can be used by any entity to cover their core processes. This may also be required by some governments on certain industries, e.g the government requiring CNII (Critical National Information Infrastructure), so simply, if you are CNII, then you should be doing the ISO27K.

d) CSA Star Alliance = standard for our data centers to apply, but it’s not mandatory (as far as we know).

e) TVRA = based on MAS (Monetary Authority of Singapore) requirement for financial institutions, so generally if you are regulated by them, then you need to get this done. It’s actually a subset of their Technology Risk Management Guidelines. It’s pretty much a mirror of Malaysia’s RMiT (Risk Management in Technology) subset of data center resilience section. As an aside it seems slightly comical that these two countries, tied so closely together in terms of history and economy would sit down and decide to name their federal bank’s IT standard so closely to each other. I mean, it’s like:

i) Singapore – Let’s call our technology standard Technology Risk Management!

ii) Malaysia – Hmm, we can’t sound the same otherwise we might look like we aren’t original. Let’s flip it around and call it Risk Management in Technology!

Back to the subject, most standards out there has a reasonably clear idea of who it applies to. Even Bank Negara’s e-money guidelines or their baseline IT security requirements – apply to those regulated by them. HIPAA (not in Malaysia) applies to medical and healthcare entities.

Which leaves us with PCI-DSS.

From the onset, PCI-DSS applicability is actually very clear:

PCI DSS also applies to all other entities that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD).

PCI-DSS Standard

So in general, whenever you are storing, processing or even transmitting any part of the card holder data (PAN) or the sensitive authentication data, e.g track data, CVV etc, then PCI applies to you.

The confusion begins when these exact terms are used by those who are NOT doing any of these 3 (Store, Transmit, Process or STP) –lets call them NON STP– but still gets pulled into scope kicking and screaming like a child on his first day of kindergarten or adults on their first day of work after a holiday in the Bahamas. Examples are data centers, hosting providers, physical security storage companies (storing secure boxes for companies) – in their business model, they don’t deal with credit cards at all. But their customers may. Or may not. They don’t know. So for instance, if an insurance company decides to store their policy files with credit card information physically into a box and ship it to the physical storage company, how does the storage company gets yanked into ‘applicability’ of PCI?

The problem of section 12.8.2:

12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment

pci dss standard

The last part is where QSAs hook on – ‘impact the security of the customer’s CDE’. Now, just to be clear, 12.8.2 by itself has no indication that PCI is a requirement for these “NON STP” providers. It comes later in 12.8.4 and 12.8.5 where it states

12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.

PCI dss standard

Argument on whether this relates to PCI-DSS compliance as a program or just service providers adhering to the PCI-DSS controls internally is an argument beyond time and space itself and requires a thesis to be written on it. Hence for now, simplicity wise, going by the standards and how many QSAs interpret it, multi factor authenticating providers gets pulled in. Hosting and cloud providers get pulled in. Storage vendors get pulled in. Cloud HSM and security providers gets pulled in. Fraud management gets pulled in. The whole thing about who could impact the security of customer’s environment gives QSAs a field day in including everyone in the party.

So applicability isn’t so straightforward after all. After determining anyone that stores, transmit and process credit/debit card with the PCI council members badges — now we have anyone that influences the security of the first group’s card data environment. This basically pulls almost everyone into applicability.

It doesn’t end there, however.

Because of the way PCI is structured, the PCI council actually washes their hands to determine who should be PCI compliant, and how they should be compliant. They pass that over to the individual card brands (I guess that’s themselves), who passes it to their banks connecting to their network, who in turn passes it on to their payment providers and who in turn passes either to their service providers or to their merchants. This is looked into in FAQ #1473, #1126, #1212 and a whole lot of other references. They always have this statement:

The PCI SSC recommends that entities contact their acquirer and/or the payment brands directly, as applicable, to understand their validation reporting requirements. Please contact the payment brands directly.

Everywhere to ensure everyone knows

When we were kids we used to play a party game whereby two teams have everyone sitting in two long straight lines. At the front of the line, the gamekeeper passes them a message, for instance “There is a blue wolf sitting in the Artic, looking at you with yellow, hungry eyes tonight” or something like that. Each kid will then need to whisper that message to the person behind him until it reaches the last person and that last person will have to go to the front and declare the message aloud, which invariably ends up something like “There comes wind that blew into the attic and sitting at me with fellow grey ice to the right.”  And everyone laughs.

This is how it is in PCI. The message gets passed down and somehow along the way, the message gets so jumbled that we can only shrug and go, “OK…” Some messages we have heard (from customers who claim their banks said):

a) “You need to show us their SAQ and ROC together! The AoC is not enough” – Not really. If you are doing SAQ, there’s no ROC (Report of Compliance). Likewise, if there is a ROC, it’s not SAQ. Both have AoC though.

b) “Physical storage companies that store physical card data like forms needs to do SAQ C-VT” – We’ve seen this, where storage company gave a SAQ C-VT (virtual terminals) to their banks and was accepted. No, you can’t. A physical storage company, being a service provider should look at the SAQ D and then mark of the irrelevant controls (such as firewall etc) as Not Applicable.

c) “You can do SAQ A – as a payment gateway!” – A permutation of b) – whereby a payment provider gave us an SAQ A as proof of their PCI compliance. I think they just scanned through which is the shortest SAQ A and go, OK, let’s go for the easiest. No, SAQ A isn”t applicable to service providers. SAQ D needs to be done and controls that are relevant to be identified.

d) “You can store hashes with truncated data, its more secure!” – This is more of our previous post, where a company we spoke to started arguing on the merits of implementing truncation, encryption, hashing and storing everything together. No, it doesn’t work like that. If Truncated information and simple hashing is stored together, without a random salt, it may be easier to determine the card information through common sense brute force (please don’t talk about rainbow tables).

e) “They need me to be a level 4 certified gateway provider since I do less than 6 million transaction.” – In general service provider levels are only level 1 and level 2, according to visa and mastercard and amex. Secondly, the transaction levels for level 1 Visa and Mastercard are 300,000 volume, significantly lower than 6 million (which is for merchants). Amex has a higher threshold (2.5 million) but in general, we look at Visa/Mastercard since they are the most widely distributed.

f) “They insist on seeing a certificate of compliance – other documents are not allowed” – This has become so common that it’s painful. There is no such thing as certificate of compliance. These are all conjured up in the imagination of QSAs and PCI-DSS never issues certificates. It is technically as useless as showing your birth certificate to your bank. Yet, your bank insist upon it. FAQ #1220 of PCI addresses it below. So while it’s not wrong to issue certificates, but these are not considered “official documents”:

Because certificates and other non-authorized documentation are not officially recognized, entities that receive these documents to indicate their own compliance (for example, from a QSA or ASV) or another entity’s compliance (for example, from a service provider) should request that official PCI SSC documentation be provided. Any organization issuing, providing, or using certificates as an indication of compliance must also be able to provide the official documents. 

FAQ #1220

g) “Since you only transmit and process card data and not store, no need for PCI-DSS” – We get this a lot from banks. Technically if you transmit or process card data , you should be PCI applicable. However, since banks have a big say in your compliance (for instance they may force you to be level 1 compliant even if you have zero transactions), on the flip side, if they say they don’t need it, then well, you don’t need it. You could probably argue with them and say you actually do need it from a technical point of view, but most customers just take the bank for their word and move on. The bank has made their risk assessment, and if they insist we don’t need to be PCI compliant and gives a black and white stating they don’t need – essentially they (the bank) is absorbing all the risk of non-compliance, aren’t they? Remember – PCI-DSS is generally a contractual obligation between parties. If the bank says contractually you are not required for PCI-DSS, then what’s the argument? In this case, we usually advice our clients to still undergo a self assessment to ensure they are aware of the security practices and we then get a nod of wise agreement before they shoo us out of the room, never to be heard from again. If they had a trapdoor button that drops us into the Rancor’s pit, I guess they would have used that.

h) And finally, most recently – “they say the since we only store PAN and without expiry and CVV, they said PCI-DSS isn’t applicable to us” – this is a bit mind boggling since this bank was an international bank and we think they should know better. But that doesn’t mean local banks know less, we’ll take it back. It’s just that international banks, being exposed in so many countries, would probably have the mindshare larger than local banks to know more about these things. But this one was – “You don’t store CVV and expiry date? OK – no problem, just go ahead and store PAN for all we care! Yeay!” Granted, the use of card information without information like CVV, expiry etc may not be as useful, but there are still other ways for PAN to be used – identity theft for one. Or, it can be used in combination with other information they already have. Or they just want to sell it on the dark web. PCI-DSS puts a big premium on PAN storage, so much so saying, if PAN is stored, all other information must be protected. And oh – CVV is considered Sensitive Authentication Data (SAD), and no, it cannot be stored post authorisation for whatever reason.

There are a whole lot more of strange things we have heard over the years from banks and service providers but those are the main examples. Again, I do not think it’s due to them purposely misinterpreting the standard, but like that party game, once the message gets passed down the line so many times, eventually it’s just going to end up like garbage. It’s like how I had to deal with my wife’s instructions to buy stuff from the grocery. It’s sanskrit to me…I mean how many different pasta brands are there and why must we buy such a specific one? Pasta’s pasta, no?

If you need us to help un-garble PCI-DSS for you, drop us a note at pcidss@pkfmalaysia.com and let us get to it!

Clarifying ASV Scans

April 3, 2020 / / 0 Comments

It has been a while since our last post but as we are getting back up to speed to restart our work, our email engines are churning again with a lot of queries and questions from clients and the public on PCI-DSS, ISMS, ITSM, GDPR matters. We even have an odd question or two popping up regarding COVID-19 and how to secure against that virus. I don’t know. It’s a multi-billion dollar question which nobody can answer.

So while all these things are going, the one relentless constant we are still facing is: PCI-DSS deadlines. Despite the worldwide pandemic, we still get clients telling us they need to get their certificate renewed, their ASV scans done, their penetration testing sorted within x number of days. The reality of course is a bit more difficult. For example, once you have tested or scan, how does one remediate the issue when we cannot even get onsite to do proper testing? What about the development team, or the patching process, or the testing procedures and change management that needs to be done? The reality is simply, due to the pandemic, DELAYS will occur.

One of the main concerns are ASV scans, because ASV scans need to be done quarterly, there may be actual issues in remediation delays that may cause the company to miss the quarter.

How do we overcome this?

The main step is to always check with your QSA on this. I cannot repeat this ENOUGH. An organisation undergoing PCI-DSS, no matter what your size, especially if you are undergoing QSA certified program (Level 1 or Level 2 SAQ signoff from QSA) – ENGAGE your QSA to assist you. The QSA isn’t just supposed to come in at the end of your certification cycle, start poking holes into all your problems and tell you – you can’t pass because you missed our your internal VA back in Quarter 1. Or state your segmentation testing is insufficient at the end of your certification cycle. Or tell you that your hardening procedures are inadequate, with 1 month left to your certification cycle. The QSA needs to be in engagement at all times – or at the very least on a quarterly basis. Get them to do a healthcheck for you – all QSAs worth their salt should be able to do this. The mistake here is to treat your QSA as just an auditor and not onboard them throughout your certification cycle. An example is in the supplementary document from the council “Penetration-Testing-Guidance-v1_1” shows the possible involvement of the QSA:

In order to effectively validate the segmentation methodologies, it is expected that the penetration tester has worked with the organization (or the organization’s QSA) to clearly understand all methodologies in use in order to provide complete coverage when testing.

Pg 10 PCI Data Security Standard (PCI DSS) v1.1

It’s essentially critical to understand the relationship the QSA must have and the involvement they have, especially in the scoping part of PCI-DSS. The problem we often see is there is a disconnect between the company and their QSAs in terms of scope, or expectation, or evidences, which generally leads to A. LOT. OF. PAIN.

For ASV scans, a QSA may also provide ASV services provided these are properly controlled that there is proper segregation of duties and independence within the QSA/ASV company itself.

However, we have also done many companies whereby we provide the ASV scan and another QSA does the audit. Or the other way where we provide the QSA audit, and ASV is done by another company.

There is one example whereby we were auditing a company, and the ASV scans were done by another firm. We have been engaged from the start on a quarter basis and we highlighted to them that their Q1 ASV scan isn’t clean. We got on a call with the ASV company and worked together to ensure that the next quarter, these non compliant items would be remediated. So even with Q1 ASV not passed, at the end as QSA we still accepted the PCI recertification. PCI Council addressed this in FAQ 1152 – “Can an entity be PCI DSS compliant if they have performed quarterly scans, but do not have four “passing” scans?”

Without early engagement of the QSA and ASV, there would be a lot of problems once the recert audit comes around. In this case we could set the proper expectation early in the cycle for the customer to address.

Another possible instance is whereby the ASV themselves can pass a quarter scan with non compliant findings with compensating controls. This procedure is detailed out in section 7.8 of the ASV program guide, whereby within the quarter scan itself, before the expiry of that quarter, compensating controls are provided and validated and the ASV is able to issue an acceptable report for that quarter. This is important, because QSAs like to see 4 quarterly clean reports, and they throw a tantrum if they don”t get what they want. So in short, for ASV scans, do the following in this order:

a) Remediate all and get a clean report for the quarter; or

b) If you have non compliant for the quarter, engage your ASV, provide acceptable compensating controls, and attempt (not influence) with the ASV to accept/validate these controls and provide a clean report for the quarter but documented under Appendix B of the scan report summary; or

c) If for whatever reason, a clean report cannot be provided for the quarter, work closely with the ASV and the QSA to ensure that at least the next quarter or quarter after next remediation is correctly done. This is tricky because once the quarter report is out, it’s out of the ASV’s hands and into the QSA – on whether they can accept these reports or not. You can hang on to FAQ 1152 – but remember, FAQs are NOT the standard, so you are essentially in the hands of the QSA.

Those are your options for ASV, if there are any delays. DO NOT, in ANY CIRCUMSTANCE, MISS Your quarterly scan. Missing your scan is NOT THE SAME as getting a non compliant report. Missing your scan means there is no recourse but to delay your certification until you can get your 4 quarters in.

Finally before we sign off – let’s clarify here what a ‘quarter’ means. Some clients consider ‘quarterly’ scans to be their actual calendar year quarter. No. It’s not. Essentially a quarter is 3 months of a cycle of 12 months compliance year. A compliance year is not your calendar year (it could be, but it doesn’t have to be). So let’s divide this into two scenarios:

a) Where the ASV scans are required for the compliance year

In the case – the compliance year first needs to be defined, and this is usually done by identifying the signoff date of your AoC. For example if the QSA signed off your certification on April 1st, then that is where your quarter 1 begins. April – June; July – September; October – December; January – March. 4 quarters. You need to perform your ASV scan within the quarter, resolve the issues, and get the clean report out. This is CRITICAL to understand. Because many organisation fail this portion where they do not even perform any scans for the first few quarters and only pick up their PCI-DSS again mid way through and everyone is like: “Oops.” So while drinks and celebration are in the works once you signoff the AoC – your quarter 1 has also begun, so don’t drink too much yet.

So know your quarters. Start your scan early in the quarter, rescans must be done after remediation, and in case you need compensating controls, you need to get ALL THESE DONE within the quarter. If you perform your rescans in the next quarter, you are doomed. You MAY perform the rescan in this quarter and the clean report comes out next quarter for the current quarter – but all scans must be done within the quarter itself.

a) Where we have NO clue when the quarters are

As funny as this may sound (in a tragic way), there are many instances where we (wearing the ASV hat) gets plopped into situations where the client HAS NO CLUE when their compliance quarters are. I don’t know why this occurs. When I request them to check their AoC, or their QSAs for guidance, some can’t provide it. This is as great a mystery as the Sphinx itself. We call these internally, ‘Orphaned ASV scans’. These are projects where we are given the IPs and just told to shut up and scan the IPs. In this case because we onboard all ASV scans with quarters to define when we need to remind our customers, or escalate issues if the quarter runs out – we generally just use the date of the scan as a reference for quarters. So for instance, we provide a clean scan on April 31st. Since they are orphaned scans, without a compliance year/cycle for reference, we use the date of the scan report itself – meaning this scan expires 31st July.

By and large, we are seeing less and less of these orphaned ASV scans issues. Because QSAs these days are more engaged with customers and their customer service has also improved, it’s rare we find a client who isn’t aware of these cyclical requirements. Most clients, not just the large ones, are serviced by QSAs who themselves are reinventing themselves not just as auditors coming in once a year to observe and audit, but provide separate, independent units/consultants to assist healthchecks and support as well to enquiries pertaining to clients.

And a final note on this article – when we refer to ‘QSA’ or ‘ASV’ – we mean ControlCase International (QSA and ASV), whom PKF have been working with for close to a decade. We are not their representatives nor partners, but as our vendor, we’re keenly aware of how they do their certification and we try to manage our projects according to their expectations. As to why we do not want to become QSAs ourselves, we take independence and segregation of audit and operations seriously, as accounting and audit is our DNA. An article has been written at lenght on this:
http://www.pkfavantedge.com/it-audit/pci-dss-so-why-arent-we-qsa/

So – drop us a note at pcidss@pkfmalaysia.com for any queries on ASV scans, PCI-DSS or compliance in general. And no, we don’t know how to solve the resolve the Coronavirus yet, but I hope we get there soon. Stay safe and stay well!

PCI-DSS For Software Developers

August 22, 2019 / / 0 Comments

Of late we have been receiving numerous calls from software developers requesting us how on earth do they become PCI-DSS certified.

It’s never easy to explain over the phone, especially with misconceptions that PCI-DSS is a license, or a software, or a solution, or some sort of exam or some other thing. And also, how do we go about explaining to them that technically they don’t (or can’t) be PCI certified as a software vendor, but they can opt for PA-DSS or the new Secure Software Standard from PCI.

So the first thing to ask is (assuming this application/solution is handling credit card information):

a) Are you developing software only and selling that software to your customers?

b) Are you developing a solution where you are hosting and managing and allowing clients?

If it’s a), applicability of PCI-DSS is simply on your customer that is buying your software, not on you as a company. After all, you generally don’t handle credit card – your customer does. However, your software is likely in scope for their PCI-DSS assessment, so there could be an instance where you need to participate in your client’s assessment or to develop your software in a manner where it would be “PCI Compliant”. Developing a PCI compliant software doesn’t make it certified, but it does assist in helping your clients getting certified. An example would be to develop your solution with logging capability and able to log to a central location. Another example is your solution being able to integrate with AD, or to have PCI compliant password policies (session timeouts, password expiry etc). Other examples are to ensure there is Role Based Authentication and Authorisation. Or ensuring encryption is properly done for data at rest and in transit. By doing these doesn’t make it immediately PCI certifiable – but it does provide your client with less headache.

If it’s b), then yes, you are not considered just a software developer but a service provider. You are providing SAAS, so generally that makes you responsible for the day to day security of card data in behalf of your client. In that case, PCI-DSS is able to be applied to you on your solution and your process.

As with PA-DSS, the new Secure Software Program applies to the following software:

Software products involved in or directly supporting or facilitating payment transactions that store, process, or transmit clear-text account data.

Software products developed by the vendor that are commercially available for sale to multiple organizations.

So all the CRM systems, call systems, in house systems, customised systems are all not eligible for PA-DSS or the new program. This is typically in line with what has always been, anyway.

So that leaves us back to square one. What happens if you are not eligible for PA-DSS or Secure Software program and you are just a software developer and NOT a service provider, but your client is insisting on you being PCI-DSS certified?

Well, hopefully you can explain to them or point them out to this article. Another option you can have is to say you have developed your software that is compliant to PCI requirements. The following list shows what it should take to address PCI compliance (not comprehensive):

1.      Requirement 2 – Ensure no clear text for administrative access

2.      Requirement 3 – Application is transmitting /store and strong encryption needed

3.      Requirement 4 – Application must encrypt when transmitting over public network

4.      Requirement 6 – Software development process – secure code review, remove test data before rolling to production,  ensure application is patched, prompt when bugs are discovered.

5.      Requirement 8 – ensure the application can support PCI DSS password requirements, password is encrypted at rest and transmission

6.      Requirement 10 – the application is capable of sending logs to the SIEM, Application penetration testing is conducted and documented what methodology of testing is used.

Requirements affecting Software: Sample Evidences
For all system components in scope (servers, network devices, applications, databases, etc.) and POS devices, provide evidence of strong cryptography being implemented (ssh, TLS 1.2 or later, RDP over TLS etc.)
Provide the following for all filesystems, databases and any backup media
– Details on method (encryption, hashing, truncation, tokenization) being used to protect covered information in storage
– Evidence (screenshots or settings) showing  covered information is protected
Provide evidence of encryption being used for transmission of in-scope data over any open or public communication channel (i.e. Internet, Wireless network, GSM, GPRS, VSAT technology etc.). Encryption must confirm to strong industry standards.
For the selected sample, provide evidence of,
– Current patch levels
– Patches being deployed in a timely manner
Provide secure software development process document in accordance with industry best practices
Provide a recent secure code review report for an application that stores, processes or transmits covered information.
Provide a document that outlines
– the process for generating test data to be used in lower (test/development) environments.
– the process for removing test data and test accounts prior to moving the system to higher (production) environment.
Provide 4 sample change request (2 for software modification and 2 for security patch implementation) from the last 6 months.
Provide the following from a secure code training perspective
– Material used for training
– Attendee list showing that all developers are covered
Provide evidence of logical access account and password features to include,
– Account lockout policy
– Account lockout duration
– Session timeout policy
– Password length
– Password complexity
– Password history
– Password expiry
Provide evidence that passwords (for platform and/or consumer applications) are encrypted during transmission and storage.
Provide the audit log policy settings.
Provide actual event logs for each of the platforms identified in the sample.
Provide a documented methodology being used for penetration testing.
Provide internal penetration test report.

You would get stuck if your clients want to see the PCI-DSS certification, which obviously you won’t have. In this case, the only way forward is to talk to them saying it’s not possible for you to be PCI certified in that sense. If you want, you could actually engage a third party auditor or even a QSA to assess the application based on PCI requirements. You won’t get a certificate for PCI, but at least you have a third party attestation or report, which hopefully should be enough.

Another option is to just get a hold of us at pcidss@pkfmalaysia.com and we can maybe provide a bit more persuasion to your client in accepting your application for PCI-DSS!

The Service Provider Challenge for PCI

August 12, 2018 / / 0 Comments

While it’s very tempting as consultants to just sometimes approach a customer requiring PCI-DSS and after identifying all their service providers, declare: “I need all your service providers to also be PCI-DSS compliant and certified!”, the truth of the matter here is, that you don’t need to. As in you (undergoing PCI) do not need to have all your service providers compliant and it will not affect your own compliance.

PCI SSC made it very clear with the publication found in their Third Party Assurance supplementary document. 

If you have time, it’s a very good read.

Service provider compliance comes in requirement 12.8. As per document:

 

When engaging with a service provider, the PCI DSS compliance must be verified with one of the following methods:

  • For providers that have undergone their own PCI DSS assessment: request and review the Attestation of compliance, scope, date
  • For providers that have not undergone their own PCI DSS assessment: include the provider’s environment as part of the entity PCI DSS assessment (increase your own assessment scope). You may need to request your own QSA to perform the provider’s review.

For the second part, it’s of course, a bit tough, seeing that you are actually paying a QSA to perform an audit for someone else, when you would think they should be paying for it.

Basically, we do need to ensure that PCI DSS clauses are present in all contracts, especially for ensuring compliance maintenance, liability, right to audit, and right to terminate in case of non-compliance to PCI-DSS. This might be a good time to call your contracts personnel and start drawing up another one. (Address 12.8.2)

It’s 12.8.4 that stuffs us up: Maintain a program to monitor service providers’ PCI DSS compliance status at least annually. This generally means, it has to be either a level 1 or SAQ verification of the service provider.

The document above actually provides a guidance for different scenarios in section 6.2: Other Considerations. It’s certainly worth the read. We have a scenario where the service provider is compliant but refuses to provide information. In 6.2.2 we also have a scenario very relevant to many: Third-party Service Provider has not Validated PCI DSS Compliance.

This is quite troublesome, but unfortunately, this is much more common than you think. A lot of providers don’t even have a clue what PCI-DSS is all about.

So if you do end up with a provider without any PCI but its too difficult to change, there is still a way out:

  • “If the TPSP (Third Party Service Provider) has not yet completed PCI DSS compliance, ask for a detailed plan with deadlines for finalizing the PCI DSS compliance process; make sure the TPSP provides status checks on a regular frequency until it achieves PCI DSS compliance.”

It really doesn’t sound that great to be honest. It’s like babysitting a misbehaving child and you just want to get it over with and have other things to do later that night but this kid is just not wanting to sleep and you feel like getting some cough syrup to mix into his milk…that sort of feeling, not that we have any first hand experience on that kind of inhumane stuff. Pftt. Of course not. We all have perfect children.

But for these service providers, you do find yourself wondering if you ended up with the short end of the stick.Extract below:

  • “If an agreement exists between the entity and the TPSP, the entity may consider an examination of the contract or agreement with the TPSP to determine which party is responsible for mitigating the non-compliant data or process.
    • Consider whether the non-compliant service or process is essential and the impact of stopping it as soon as possible until a solution can be developed.”
    • For business-critical issues, the entity and TPSP should work together to determine who will be accountable for the cost and responsibility for correcting the issue, if necessary. Discuss with legal counsel to ensure the entity or the TPSP and any nested TPSP use appropriate agreement/contract change provisions or clauses to negotiate a fair and reasonable timeframe to remediate the non-compliance issue.
    • Discuss with the TPSP and agree on introducing compensating controls as soon as possible that mitigate the risk of continuing with the non-compliant process or data exchange—while work continues on its remediation.
    • Prepare a remediation plan that can be provided to the entity or the TPSP in a form that can be used as evidence (e.g., Compensating Controls Worksheet) to provide a QSA if a PCI DSS compliance review is due within the remediation timeframe.
    • Ensure any nested TPSPs meet the agreed obligations with regard to remediating the non-compliant issue and keeps the TPSPs informed of progress.”

That’s a lot of stuff. “Nested” TPSPs in the last point doesn’t mean they have the same nest, it simply means that if there are dependence on remediation of this TPSP (i.e the TPSP of the TPSP), these guys also need to understand they are pulled into scope. It’s very headache.

In conclusion, it’s probably better to start looking out for TPSPs who are already compliant or who understands their PCI compliance obligations, and for those who refuse to put in their effort on this compliance, well, be prepared to get left behind. Because once one or two of the same industry TPSP gets compliant, it will no longer be the norm to be NON-COMPLIANT and this TPSP will stand to lose out customers in the future.

For information on how to handle your PCI-DSS requirements, please drop us an email at pcidss@pkfmalaysia.com and we will get right back to you ASAP!

« Older posts Newer posts »

© 2024 PKF AvantEdge

— Up ↑