PKF AvantEdge

Tag: saq (Page 3 of 3)

PCI-DSS Evidences: Your Type of Compliance

February 25, 2017 / / 0 Comments

pci-compliance

Since our last post, we have received some queries on how do we get PCI-DSS started. A majority of our clients are doing Level 1 Certification – this is where we come in and do a gap assessment, determine scope and then remediate and certify. However, lately we have been seeing more and more clients looking to do PCI-DSS on their own.

The question is: Can they?

Well – as with many questions for PCI-DSS, the answer is: it depends.

You see, the journey to PCI-DSS is different for different companies. Some need to go through the whole road. Some goes through just a little. Some need a third party to audit, some can do their own assessment…so while the standard is ONE, the ways to achieve it is MANY.

Now, enough of the philosophical babbling. Simply put: if you are doing PCI-DSS, you simply have 3 available options:

a) Third Party Certification

b) Validated Self Assessment Questionnaire (SAQ)

c) Self Signed Self Assessment Questionnaire (SAQ)

That’s it. You will fall into one of these buckets. If you fall under b) or c), you will then further have to wade through the types of SAQs: A, A-EP, B, B-IP, C, C-VT, D-SP, D-Mer, P2PE. Yes. They have a lot. But in general, your consultant or QSA should be able to tell you which one is right for your business.

Now back to the buckets. What’s a third party? No, it’s not literally a third party that you go to after your graduation and you are getting smashed. In audit terms, there are 3 kinds of audit – first party which is where internal auditors of the company audit themselves. Second Party which is where an external company with ties to the auditee company audits the auditee company – for whatever reason. It could be a supplier audit, it could be a due diligence audit before takeover, it could be a regulator auditing its regulatee etc. Finally a third party is a completely independent organisation auditing the company.

So the first bucket is a third party certification. This is where an external company called a Qualified Security Assessor (QSA) assesses your company and provide a Report on Compliance. This is where they will ask you to do a gap assessment, assist you through the ‘remediation’ period, and do the certification. What a lot of people don’t know is that actually, Merchant Level 1 also has an option to do a first party audit. This means they need an ISA (Internal Security Assessor) in their organisation who is able to sign off on the ROC. Of course, getting an ISA certified is another story, and in most cases, many just take the QSA route.

The second bucket is a Validated SAQ. This will not apply to Level 1 Merchants or Level 1 Service providers, and this is available for Service Providers Level 2 or Merchants Level 2 and below. Basically this means that theoretically, you can complete the SAQ that is applicable to your company and sign off and you are ‘compliant’. This also means any Tom, Dick and Harry who thinks that a firewall constitute setting an actual office wall on fire, can sign off on 1.1.4 (a) which asks if a firewall is implemented in your company. Seriously though. That’s why Mastercard has this caveat:

“Effective 30 June 2012, Level 2 merchants that choose to complete an annual self-assessment questionnaire must ensure that staff engaged in the self-assessment attend PCI SSC ISA Training and pass the associated accreditation program annually in order to continue the option of self-assessment for compliance validation. Alternatively, Level 2 merchants may, at their own discretion, complete an annual onsite assessment conducted by a PCI SSC approved Qualified Security Assessor (QSA) rather than complete an annual self-assessment questionnaire.”

Many, including myself, find this caveat extremely frustrating. To cut the long story short, Mastercard is simply saying for all Level 2 merchants you have 2 routes:

a) Do the Level 1 route. Get a QSA

b) Do your SAQ, but get the staff ‘engaged in the self assessment’ to be ISA certified. Now the first confusion is staff engaged in self assessment does not mean everyone involved in the audit. It basically means the one doing the assessment in behalf of the organisation and signing off at the AoC (Attestation of Compliance) of the SAQ. Whew! But still, now you need to get an ISA. It’s not cheap! And it’s also, to me, a really silly certification, but one that makes total Sen$e to the PCI-SSC.

In theory, option b) above is correctly still called ‘Self Assessment’ as it is still a first party audit in that sense.

Now the last bucket therefore is the truest first party audit. This usually applies to only Level 3 or Level 4 merchant, but sometimes we still find this existing in Level 2 Service Provider. Where the management say, “Screw it, let me sign it off and I don’t need any other signature on this” and the bank, customer or card scheme accepts it.

So this is the first step of your compliance – find out your type. Because you could be overdoing it (Level 3 Merchant doing a ROC Certification) or you could be underdoing it (Level 1 Service Provider doing an SAQ D). If you overdo it, it’s fine from PCI-SSC perspective, but your boss/stakeholders/board/customers might not be too happy when you have spent half the company’s budget and 8 months on the PCI program doing a full Level 1 RoC on all the 340++ subrequirements – and the vacation trainee points out that you only have to do a self signed SAQ A which takes about 1 day to complete. If you under-do it, likewise, you might be in an awkward position to explain to someone that your SAQ D-SP is not enough to convince your acquirer to start connecting to them, as they need a QSA signed ROC.

So how do we know?

Well – the easiest is to really, ask the ones who are pushing you for PCI? If you get the answer : “Ah, just get compliant!”, then you have more leeway to understand your business, and you might be tempted to just go for the easy way out. Don’t! Assess your business – if you are a merchant, then follow the number of transactions to determine which level you are at. Easy remembering:= 6 million and above for level 1, 1 – 6 million for level 2 and the rest level 3 and 4. I don’t differentiate 3 and 4 because there doesn’t seem to be a squat a difference to what you are supposed to do. It’s the same, they just classify it differently where level 3 is focused on e-commerce and level 4 is more on traditional transactions.

For service provider, it’s simpler. Level 1 is above 300,000 volume of card transactions and level 2 is below. There is no other levels for Service Providers. There is also only SAQ D available for Service Providers so you don’t need to think so much.

The next round, we will explore deeper into how do we get our scoping questions sorted out.

 

PCI-DSS and the SAQs that suck

June 21, 2016 / / 0 Comments

pci-compliance

While a good part of our PCI business is providing level 1 certification to service providers, we also have provided the same to Level 1 merchants. Where we are seeing a big need for advisory is in the Level 2 Service Providers, or the Level 2,3,4 Merchants. This is because they generally fall under the SAQ category. SAQ = Self Assessment Questionnaire.

Now, I am not going document what these SAQs are, or their individual applicability and requirements  – there are 2,345,565 sites so far that do this, so go ahead and google it – these sites do a great job in presenting the SAQs in a far more structured manner.

What we are going attempt to do here is jump right into it with the assumption you have some familiarity with these SAQs and you are as frustrated as most of our clients with it and want to find out why these SAQs suck so bad.

Well, mainly, there are a lot of ’em. PCI-DSS isn’t a guideline or framework like ISMS/COBIT. It’s a bunch of standards (some excellent in terms of making sense, some not so) that range from ‘oh that’s easy’ to ‘That is going to cost me a bomb’ sort of thing. So, different SAQs apply to different business. Each type of business have somewhat a different journey in PCI – the online mall with e-commerce vs the restaurant chain that has 100 branches nationwide etc.

We are going to focus where most the confusion happens: The SAQ A vs SAQ A-EP. Note that these SAQs apply to mainly e-commerce customers. So if you are doing mainly e-commerce business (we can go into POS issues later) – then it’s either SAQ A, SAQ A-EP or SAQ D-MER.

Now there’s a bit of history here – previously e-commerce companies that do online transaction with credit cards have two choices: SAQ A – which has a breezy 14 or so questions (now updated to around 20) or SAQ D – which jumps to the full monty, i.e 300++ questions covering the full 12 requirements of PCI. There is no middle ground. It’s like you are doing a weekend hike up your neighbourhood hill with your 5 year old son and suddenly someone tells you you are climbing up Mount Everest next. You can imagine merchants doing two things: they tear their hair out doing the SAQ D, or they just work on SAQ A, whether they qualify or not. More on the qualifying later.

So now, recently in the newer versions, PCI says, “Aha, let’s give these guys a break by introducing SAQ A-EP”. The ‘EP’ here stands for Ecommerce Payment, we assume. The problem here is that PCI Council, while trying their best to clarify who can or cannot be SAQ A, A-EP or D, only serves to make things even more confusing.

Your goal – if you are an e-commerce merchant – is to do your best to end up with SAQ A. Because it is the easiest. More importantly, it’s the cheapest. You don’t need to do any ASV scans, or pentest or all the kebabs that come with doing SAQ A-EP or SAQ D. The list of questions in the recent version increases from 20 to around 190 to 340+, when you go from A -> A-EP -> D-MER. That’s a difference between a days work to probably one to two months to a full five to six months.

PCI generally have a lot of documentation on SAQ A and A-EP and when to use it etc.We have provided a few good links below the article.

PCI generally slice the e-commerce implementations into 4 broad categories and in a layman description below: (for more technical explanation, google the words below with PCI appended to it and there should be some good sites coming up that explain in more detail):

a) Redirect – SAQ A

When you (customer) click on checkout with credit card after selecting your favourite golf clubs to buy (or high heels, whichever your fancy), you suddenly get a message saying, exiting www.ecommercemerchant.com, redirecting to PaymentProcessorName. This usually is a popup, or if not, another tab, or just a pure redirect. Now you see another page stating its the payment processor, and here is where you enter your card details (name, PAN, CVV etc). After entering, and being authorised, you are dropped back into the merchant page. The merchant has no idea of anything you have typed into the payment page.

b) IFRAME – SAQ A

Not as common, at least in our experience. This is when we click checkout with credit card, the page is still with the ecommerce merchant, but an iframe is loaded. An iframe is basically a page within a page, a child page that belongs to another site. It’s like a dream within a dream concept from Inception. So the merchant page now loads the payment processor page WITHIN its own page. The entire code for iframe is controlled by the payment processor. Even the code to Call the iframe is given by the processor. As far as the merchant is concerned, it’s like a redirect, a sleight of hand, it’s prestidigitation! (In the words of OZ). This is advantageous from a customer experience perspective as the customer feels that they are still with the merchant instead of being sent to another shop to make payment. The problem is, like everything, IFRAME is hackable. Here is a good rundown recently of an IFRAME hacking incident.

c) Direct Post – SAQ A-EP

OK – this is the one we see most (aside from the first). A lot of customers think they are doing a), when in fact they are doing c). Basically the form where we type in our Payment information is sitting with the merchant, and once we click submit, then it connects to the payment gateway and sends all the information. The payment detail collection page sits with the merchant.

d) Javascript – SAQ A-EP

We hardlysee this around, but even if we do, and if we are not firing up our developer tools, we probably won’t know. Basically, when we load the payment page on the merchant website, the processor page talks directly to us, the customer. The processor sends Javascript to our browser and our browser magically creates the payment form, which we happily fill in and send it back to the processor. Generating via Javascript has its advantages – dynamically it can fill in some parts of the form depending on where the client is, or basically improve the user experience overall. But again, a malicious code can be executed instead and instead of sending over to the payment processor, you might end up sending over to your friendly neighbourhood hacker.

The other scenarios falls into the bottom catch-all of SAQ D.

The confusion is added when in the SAQ A-EP document, it states: “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”

So my question is, wouldn’t the fact that the merchant site is controlling the iFrame code or the actual redirection make it fall under “Controls how consumers are redirected” caveat there? It does. So much so that PCI Council issued a statement here at their FAQ site: https://www.pcisecuritystandards.org/faqs. Just type in “1292” and you should see the article reproduced.

Basically they go a long about way saying that yes, they understand that iFrame and Redirect falls under that SAQ A-EP caveat but they are willing to allow SAQ A to be used in this circumstances because “in the payment brands’ experience these are detected before significant volumes of cardholder data are lost. The Council is working with Payment Service Providers to encourage tamper-resistance and tamper-detection which will also reduce the viability of a MITM-type attack.”

As we can see from the IFRAME hack, it’s not really that trivial to pull off as you do require some knowledge of the transaction ID and getting it from the payment processor. Like all man in the middle attack, it does take some skills to pull off and massive removal of credit card details is harder as each transaction ID is unique. It’s a lot easier getting a malware into a POS device and siphoning the credit card information there a’la Target breach a few years ago.

So you see, it really depends on how you code or implement your e-commerce site. We have seen many companies underscope themselves by doing SAQ A when actually they had to do SAQ A-EP. Worse, we have also seen some ecommerce merchants forced to go trough SAQ A-EP or even D when they can qualify for A. These are usually directed by their acquirers – either banks or gateways with little knowledge of SAQ and who somehow just randomly decide that all merchants must suffer through SAQ D. It’s like being jailed for 50 years for stealing an acorn from a squirrel. Maybe in Norway it’s a law, but it sure as heck not here!

And now we are seeing some really strange permutations coming from acquirers – some of our clients are told to do SAQ A, but must to ASV scans. What? If it’s SAQ A, it’s SAQ A. Done. Why ASV scans are needed? Oh – because the acquirer says so. Well, the PCI Council doesn’t say that, so what we are doing isn’t PCI requirement. And even one case whereby the company said, yes, the merchants need to do ASV – but hey, because their risk management approves it, only need to do twice a year, not four times a year. Wait – PCI still requires at least per quarter though.

And the best one we have heard in an RFQ so far – the requirement is to “ensure that company must get Level 1 certified and become member of PCI Council.”

Become a member of the PCI Council? How?

I don’t really blame the companies for misinterpreting actually. I mean, if you look at the amount of documents PCI forces us to go through, it’s like asking people to read War and Peace six times. In Russian. When you are not Russian.

So, it’s really our job, whether QSA, ASV, PCI-P or consultant, to generally stop, take a breath and try to get this PCI education going.

This is a long post. I haven’t even gone to live demo of actual sites doing the 4 things listed above (Redirect, Direct Post, IFRAME, Javascript). I usually do that during our PCI-DSS training but I will try to give some examples in the next few articles.

If you are interested in PCI-DSS training (HRDF claimable), a free PCI scoping or any PCI services like certification, ASV scans, penetration testing or generally dissecting the PCI-DSS novels you don’t want to read yourself – drop us an email at pcidss@pkfmalaysia.com and I guarantee we’ll pick it up.

No customer is too small (or big) for us to handle!

Here are some useful links on this topic:

a) Good PDF from VISA

b) Official document from PCI

c) PCIPortal

Good luck on your PCI journey!

The Myths of the Top 10 Myths of PCI-DSS Part Two

April 9, 2016 / / 0 Comments

pci-compliance

Continuing where we left off yesterday, let’s jump right into the next Myth

Myth 6 – PCI requires us to hire a Qualified Security Assessor

Technically true. Once again for merchant level 3 and below, SAQs are good enough to be compliant. Here’s how it works: merchants complete an SAQ, the management signs it off and they pass the Attestation of Compliance (AoC) over to whoever is asking – generally either the acquiring bank, or the payment gateway. Some of these SAQs are easy. Which SAQ you choose is a little bit more work. While we are not going into SAQ in this article, a quick comparison of SAQ A (mainly for Ecommerce merchants that outsource all processing functions) and SAQ D-MER (generally for merchants who store, process and transmit card data): 14 questions for SAQ A vs 326 questions for SAQ D-MER. That’s right. It’s 23X more work.

So while this Myth is generally true, for a merchant to undergo SAQ D-MER, most do not have the capacity to do it themselves, hence require expertise from either QSAs or consultants outside of the company. What about this Internal Security Auditor (ISA) option?

Here’s where it gets a little strange. In 2012 Mastercard released a statement stating:

“Effective 30 June 2012, Level 1 merchants that choose to conduct an annual onsite assessment using an internal auditor must ensure that primary internal auditor staff engaged in validating PCI DSS compliance attend PCI SSC ISA Training and pass the associated accreditation program annually in order to continue to use internal auditors.”

And

“Effective 30 June 2012, Level 2 merchants that choose to complete an annual self-assessment questionnaire must ensure that staff engaged in the self-assessment attend PCI SSC ISA Training and pass the associated accreditation program annually in order to continue the option of self-assessment for compliance validation. Alternatively, Level 2 merchants may, at their own discretion, complete an annual onsite assessment conducted by a PCI SSC approved Qualified Security Assessor (QSA) rather than complete an annual self-assessment questionnaire.”

What they effectively are saying is that Level 1 to 4 merchants CAN have an option not to engage a QSA, but the caveat is that for level 1 and 2, they need to be ‘validated’ by internal auditors. Not just any internal auditors, but auditors certified as “ISA”, by the PCI council. Yes, it’s a certification that is created to sign off SAQs.

If you do not have an ISA, you are stuck, and you will need a QSA to validate your SAQ. In most cases, having a QSA validate is as much work as having them certify the environment, so you do end up ‘hiring’ a QSA to validate it.

Why not all join in the ISA bandwagon then?

Well, you need to cough out around USD500 for the PCI Fundamentals course, then around USD3,000 – USD4,000 for the ISA course and then every year USD1,000 for requalification training fee. Only companies going for PCI-DSS can have ISA so if you are consultants like us, you are out of luck.

Large merchants probably might want to invest in an ISA. But note of caution, ISA is NON transferable. So if you are an ISA for Company A, and you move to Company B, your ISA status does not go with you. If Company B wants you to be their ISA, you need to go through the entire course again. Yes, even the fundamentals course again.

It is certainly less expensive to get an ISA to validate your SAQ compared to having an external QSA, so large merchants might opt to have one or two ISAs in their stable and invest in them yearly.

Myth 7 – We don’t take enough credit cards to be compliant

PCI likes to state, even if you take ONE credit card, you are supposed to be PCI certified/compliant. But honestly, unless that one credit card transaction is to buy a Bugati Veyron, the acquirer is likely not going to come knocking on your door to ask you to become PCI compliant. The theory is that everyone who deals with credit cards will happily agree to invest in time to go through the SAQ and 12 requirements. The reality is starkly different. Businesses have 600 different things to look into daily, and most business turn a blind eye to PCI as long as there is no burning platform or pressure from above. The card brands push the acquirers, the acquirers push the payment processors and gateways and large merchants, and the payment processors push their service providers. Somehere down the line, the little travel agency around the corner that collects credit card information, jots down the the PAN and CVV on a log book for recording purposes so they can book online flights in behalf of the customer, is overlooked. As long as there is no massive exercise to push everyone to be PCI compliant, there will be organisations that continue to operate outside the PCI requirements. Yes, your CVV will still be kept in a log book by that little travel agency – still oblivious to why storing CVV is such a big deal.

Myth 8 – We completed a SAQ so we’re compliant

Well – technically, you are. Again “being compliant” is not really an end state itself. How can anyone sustain compliance 100%? When Target was breached, they were just re-certified as compliant. Hence, the word compliant is generally just used as punchline for businesses. For instance – Ecommerce starts online payment system. They register with acquirer, acquirer tells them to be ‘PCI Compliant’. They finish their SAQ and submit. Acquirer is happy with the signoff and allows them to connect. Ecommerce proudly displays “PCI Compliant” Logo (which is not allowed, by the way) prominently on their website. They have actually successfully completed an SAQ and they are ‘compliant’ because the acquirer tells them that they are. If they are not compliant, they wouldn’t be able to connect. By the fact that this is allowed, shows that Myth 8 is actually true!

Myth 9 – PCI makes us store cardholder data

It’s true that PCI would rather you NOT store cardholder data. But this myth doesn’t make any sense. It’s not because of PCI that businesses shape their business processes after. It is because of the business processes, that there is a need for PCI. So, it’s up to the business to store, transmit or process cardholder data or not. Nobody goes into PCI-DSS saying, oh, because of PCI-DSS we now need to store data and need to invest in HSMs and key management, encryption etc. Because of PCI, we now need to have a payment business. I have never seen such a client. It’s always the other way round. Based on your business, PCI might or might not apply.

Myth 10 – PCI is too hard

This is the same argument as Myth 5. The PCI SSC makes a good point by saying, it’s good practice regardless to have controls in place, aside from PCI-DSS compliance. But the myth is here because they are actually stating PCI is not hard, simply because you should be practicing good security in the first place. To many, good security is hard! Turnover of staffs, zero day attacks, business as usual priorities, advancement of technologies, software and hardware being obsolete, pressure from management, costing issues, new vulnerabilities and exploits discovered (and not discovered yet) – and the fact that in the cybercrime world, the bad guys are miles ahead of the good guys – security is hard, make no mistake about it.

So there you have it. You would think with a post like this, PCI-DSS is a fruitless endeavor. Far from it. It’s an excellent repository of security practices that all organisations should consider. While some of the standards in there show their age (Anti virus, anyone? Please.), overall, it’s one of the more direct, implementable standards we have experienced (compared to the labyrinth we know as the ISO27001). The point of the post is to clarify that sometimes, standards in practice can turn out quite different from standards in documentation.

Now – should you check if your CVV is stored by your travel agency?

Newer posts »

© 2024 PKF AvantEdge

— Up ↑