PKF AvantEdge

Category: ISO27001 (Page 2 of 3)

PCI Delta Assessments

July 16, 2021 / / 0 Comments
pci-compliance

Let’s start off by saying this isn’t a way for us to make light of the current situation by using the word ‘Delta’ here. We all know how dangerous and virulent the current strain of COVID is and this isn’t a matter of writing an article simply to get a search hit on that word.

That being said, this is a topic that seemed a bit obscure, even to us who have been doing PCI-DSS for more than a decade now.

So the question that can sometimes pop up would be: Great, we got our PCI-DSS certification now, everyone is celebrating and patting each other on the back. In 2 weeks time after our AoC/RoC has been produced, our product management rolls out a new Application XYZ which deals with credit card information along with a new environment, database, systems etc. Is this Application XYZ included in our current PCI-DSS certification or not?

It’s a good question. Because the fact is that many view PCI-DSS as a point in time audit, whereby the audit is done at a certain time and not over a period of time. One might argue that during the audit itself, sampling will be done over a 12 month period, therefore it cannot be categorised as a strictly point in time assessment. Regardless how you categorise it, at the end of the audit, there is the big result: a compliant AoC/RoC pair. Don’t get us started on the dreaded Certificate of Compliance or CoC, or CoC-n-Bull in our terms. Enough of that certificate nonsense. As for the AoC/RoC pair, the scope is stated clearly in it, defining the audit scope, the boundaries, the applications scoped in, locations etc. So this is great. When we get a new application onboard, we just add in that application into the AoC, right?

Right?

Unfortunately, at this point, the QSA will say, not really. Once the AoC is out, it’s out. Unless you want to re-do the audit or to recertify, then yes, that new application can be added in.

Now, we’ve faced such a situation before. And in fact PCI-DSS addresses it nicely at this wonderful piece of work: https://www.pcisecuritystandards.org/documents/PCI_DSS_V2.0_Best_Practices_for_Maintaining_PCI_DSS_Compliance.pdf

In item 3.10.3 it states:

Any change to the network architecture or infrastructures directly related to or supporting the CDE should be reviewed prior to implementation. Examples of such changes include, but are not limited to, the deployment of new systems or applications, changes in system or network configurations, and changes in overall system topologies.

PCI reminding us to stay focus!

So in this case, application XYZ falls under new application. The point of PCI-DSS is that, just because you deploy a new thing or new firewall or new application doesn’t mean you are no longer compliant to PCI-DSS. After all, PCI encompass the practice and process as well, so the council understands and advice that these changes be implemented into the PCI program and PCI processes ensures that this stays compliant. So in short, if you have application XYZ coming in, make sure the PCI controls apply to it and it will then be reviewed under the next audit and included into the PCI AoC of the coming year. Let’s just update the current Aoc and we all go home now, right?

Right?

But wait, you aren’t listening, says the auditor, you still can’t update the current AoC. The AoC is already fixed for that year, unless you want to do an audit. Again. Like a month after you have done and dusted your recertification audit for that year.

In most cases, these changes for our clients go through the maintenance cycle without and issue and the following AoC simply gets updated to include it. But what if the customer insist on having the CURRENT AoC updated? This could be due to requirements from their client, regulatory or what not. How do we put that application into the current AoC without spinning off the whole audit all over again?

In short, you can’t. You either wait it out for the next year audit OR you re-do your certification audit and nullify the previous one. However, this is where that little obscurity comes in. Delta assessment.

Now I’ve heard of Delta assessment for PCI, but it’s almost invariably related to PA-DSS (SSF now), PCI PTS, P2PE where basically, vendors who had completed, let’s say their SSF, can validate low risk changes to their application and do a delta assessment. In PTS, the delta is done by the PTS Lab, but for SSF, the SLC vendor can basically do a self attestation. However, we don’t see any such item or recourse for PCI-DSS.

Discussing with the auditors, we find that indeed, there are possibilities of a delta assessment to be done, although rare, and not exactly cost effective, since whatever the delta is doing, it’s would just have a short lifespan before the changes get swallowed up by the main PCI program once the yearly audit cycle rolls in. That’s why we rarely see this done. But I rarely see a tapir doing a jig in a tutu, but that doesn’t mean it doesn’t exist.

So what happens is that the auditor will formally audit this application and its environment and go through the certification process as would normally be done – except that this is limited to the application and systems. Once assessed, a formal delta AoC/Roc pair is released to supplement the existing AoC/RoC pair. And so that’s it, these supplement documents can then be shown together with the current AoC/Roc for verification purpose and in the next cycle, it’s consolidated back into the main RoC.

Now, this is fairly new to us. The logic of it is still beyond us somewhat because the whole point of PCI is for an environment to be able to handle changes and not have it audited everytime there is a significant change that occurs. Because every audit is costly and I’m sure every organisation has already got its hands full trying to sort out budgets during these times, without worrying about delta assessments.

The above is basically what we gather from discussions with auditor and not really from experience, because at the end, once the proposal was put out, our client thought better of it and decided not to pursue. So really, it’s still in the realms of theory and we may not be accurate in our assumptions. However, it’s still something interesting to keep in mind, though rare – like the tapir in tutu – it helps to know that this option does possibly exist.

Drop us a note at pcidss@pkfmalaysia.com and we will try to address all your concerns on PCI or other compliance matters like ISO27001, ISO20000 etc!

The Biggest (Real) Myths of PCI-DSS: Part 1

April 4, 2021 / / 0 Comments
pci-compliance

Sometime back, PCI-DSS published the Top 10 Myths of PCI-DSS which we debunked in our series of Myths of the Top 10 Myths here. In this article, we are going to jump into the real actual Myths of PCI-DSS and we will explain it as we go along. We are not going to touch on the original myths published by PCI Council, but this is really very much based on our experience in PCI-DSS for more than a decade here in Malaysia, and what we often hear companies going about.

Often this misinformation is because the client facing PCI-DSS finds it hard to dissect all the information needed for the standard. Unlike standards like ISO27001, PCI-DSS is like a journey with different routes to the same destination: PCI Compliance. There are 3 separate destination for PCI – Level 1 Certified with QSA, Level 2 Self Assessment with QSA/ISA signoff, and Level 2 Self Assessment with Self Sign off (no QSA, no ISA signoff). Of course if you are a merchant, then you have level 3 and level 4, but those are the same as the third iteration where you signoff the SAQ on your own without involvement of QSA/ISA.

But while the destination itself can be clarified, the whole process to obtain PCI can be convoluted. Some clients are told by their banks, that because they do not store credit card, they are considered SAQ level 2. Or some are told because they have a website, they must do ASV scans. Or some are told that QSAs must be involved in everything. Some are even told, that local QSAs must be hired, and not any other QSAs. Some are of the opinion that PCI is a license they need to purchase, or a training they need to do. And some are of the opinion that the ASV scan will make them PCI compliant.

Hence, it’s easy with all the above misinformation and more, that customers get frustrated with the expectations of PCI. When they hear a level 1 certification may set them back 15 – 20K USD or more, or that it would take them 6 months or so, they balk at it. It’s funny because often I would start my sales pitch by saying: “At the end of our conversation, it would be goal to try to get you to avoid getting services from us if possible.” Because it’s essentially true. Our job at the beginning isn’t to peddle services or consulting or audit that our clients may not need. Our goal is to provide them with enough information of PCI-DSS so they can make informed decisions. And yes, even if those informed decisions would be that they can avoid PCI, or do their own SAQ without any consultation or ASV scans or certification, or get exemption from their banks/customers or anything else that can lower their requirements for PCI-DSS. And yes, many people who have called us actually just pay us by saying ‘thank you’ and we never hear from them again. Because as advisors, it’s better we start doing the right thing at the very beginning instead of focusing to sell services that customers do not need. This philosophy has been adopted from the start of our company – which is one of the reasons why I failed so miserably in my previous corporate role as regional head of professional service sales. Or also why I was once told off by a potential business partner that I was a poor sales person and that he preferred to work with an organisation with someone better handling sales. Ah well.

So here are some of the top REAL myths of PCI-DSS that needs to be debunked, burned, destroyed and thrown out of the window for the garbage that it is.

1) All PCI-DSS Projects Require ASV Scans

2) ASV scans makes you PCI compliant

3) All PCI-DSS requires (local) QSA

4) All PCI projects are the same (One Certificate to Rule them All)

5) All PCI-DSS services must be outsourced

6) All service providers MUST be certified to do implementation services

7) PCI scope and application of controls can be determined by the customer

8) PCI-DSS gets easier and cheaper every year

9) A company is considered PCI compliant even after the expiry of certification, due to 90 days grace period from the council

10) If the company is an ISMS certified company, they have already complied to 90% of PCI-DSS

So there is quite a bit of stuff – some may be half truths and other are utter nonsense – we need to uncover, likely will need to break this article up into two parts. Let’s jump into it.

Real Myth 1: All PCI-DSS projects require ASV scans

This myth is often peddled by those who are selling ASV scans as part of their service. Don’t get me wrong, we also do ASV scans through our ASV partners for sure, but you can’t go around town telling people that all PCI requires ASV scans when it doesn’t! Read SAQ A. Read SAQ B. You don’t see ASV being mentioned anywhere in the SAQ except for this portion in Part 3a:

ASV scans are being completed by the PCI SSC Approved Scanning Vendor (ASV Name)

And under “PCI DSS Self-Assessment Completion Steps”:

Submit the SAQ and Attestation of Compliance (AOC), along with any other requested documentation—such as ASV scan reports—to your acquirer, payment brand or other requester.

The thing is, if you go through each control under the SAQ, the ASV control 11.2.2 isn’t mentioned, so therefore it’s not required. It’s highly frustrating to us, especially when travel agencies for instance who are just doing EDC terminal business (SAQ B) that connects directly via cellular or phone line to acquirer coming to us and asking us to quote for an ASV scan for their website. We tell them, you don’t need to do ASV scan for your website unless its in scope. You can force us to sell to you, but it’s against our moral code to sell you stuff you don’t need. We take a look at it, find its a simple site with only information and they tell us, “Well, their PCI advisor previously told them to scan their website.” No. You don’t need to. Don’t waste your money, and don’t do it unless you have a website in scope or you are doing an SAQ requiring ASV scan or you consciously make a decision to do it out of best practices and security requirement – NOT as a mandatory PCI-DSS activity.

So, please, take a look. Even SAQ A, usually adopted by e-commerce sites that redirects to a payment gateway for card input – where there is likely a website, the myth is that ASV needs to be done. Read SAQ A. Again, no requirement for ASV scan. You can still do an external scan for security purpose, but strictly for compliance? No. Not needed, unless requested specifically by the acquirer.

And yes, we do have ASV scans as part of our service. But that shouldn’t make us charlatans peddling services to customers when it isn’t mandatory. If the client still wants to pick it up, ok, fine – but don’t say it’s compulsory when it’s not!

Real Myth 2: ASV scans makes you PCI compliant

We have flogged this one half to death in our earlier article here: ASV scans=/ PCI Compliance

I won’t repeat what we have said there but by far, this is a myth that gets peddled a lot. One, sadly, is because the propagation of this nonsense seems to be acceptable by banks. I hear: “Oh, no problem, the bank says all we need to do is to run an ASV scan on our website.” I interject: “Wait sir, you aren’t doing that e-commerce business. You are doing a call center with virtual terminal payments..” <Click> <Dial tone due to hang up>

So there you have it : companies and merchants that have no business doing ASV scans , but using ASV scans as a means to ascertain PCI compliance. We get this even weirder ones when we are trying to obtain an AoC from one of our client’s service providers and they pass us their passed ASV scan report. We ask what the heck that is and they go – that’s our PCI compliance, so please shut up and stop bothering us. And it’s so difficult to go out and explain to them that whoever told them that, is wrong, and they have to go through the actual PCI compliance, which their wonderful ASV scan may (or may not) be part of that overall PCI Compliance.

Real Myth 3: The Auditor (QSA) must be Local

This is one of the strangest myths ever.

We get calls from customers going, “Is your QSA a Malaysian?” And I go, “No, we work with our partner QSA, from India, US or Singapore”. And they go, “Well we want a Malaysian QSA.” And I ask, “Why?”, and most of them are not able to ascertain why they need the QSA to be local, except that it may be a requirement checkbox in their document or policy.

Ok, I can’t argue with your policy, if you have nationalist preferences to your auditors for whatever reason. But it’s not logical for companies to have that requirement, that only local QSAs must be used. PCI-DSS never stated that. In fact, its preferable to have a QSA with regional/global experience as opposed to a local QSA. If PCI-DSS had this requirement for local QSAs to carry out audits, how can QSAs then say they have ‘regional experience’? You see the conundrum? You want an experienced QSA company, yet you want a QSA that is only local. If every enterprise in the world thinks that way, how would QSAs have regional/global experience? By that argument, then all QSAs would be local to that country – not just Malaysia – but each country would only have QSAs auditing in that country and nowhere else. And immediately you can see the fallacy and illogical argument attached to this myth. But this myth still prevails, for whatever reason (we sort of know the reason actually).

PCI-DSS requires a lot of experience. The last thing we need is a QSA with only a handful of experience and no operational idea of how to run things or recommend solutions and just rely on a checkbox and some cute marketing gimmicks. I’ve seen plenty of good auditors overseas, a whole lot better than the local ones I come across and vice versa. “Local QSA requirement?” It could be peddled by local auditors attempting to block off better equipped, or even cheaper auditors from overseas (better or worse) and really narrowing the options for their clients, who would be hemmed in by such requirement, thinking its a PCI-DSS requirement. It’s not.

If you mean by local support- that they can respond faster since they are local, then, yes, there is some sense in that. If you mean they are cheaper compared to a guy in US, then yes, but let that be a commercial decision and not a technical one. Sometimes even overseas (good) QSAs can be cheaper. Local support I agree, 100%. Nothing is more frustrating than sending a message to someone and them taking 24 hours to reply due to them being in another timezone. Local presence, local support – yes. But they technically don’t need to be a QSA. They could be consultants and there is a very good case in that. We noted it here in this article “PCI-DSS – So Why Aren’t We QSA?”. We consciously made a decision NOT to be a local QSA a few years ago to avoid possible conflict and to support our clients a lot easier and not to be bogged down by auditor responsibilities in PCI.
QSAs are a busy and itinerant lot. Aside from handling other audits, writing reports, they also need to be careful of overstepping their independent role by advising and implementing for their clients and then auditing this same control they devised.

There is really, if you come down to it, no perceivable value in saying having a “local QSA” is better or not. Having local support throughout the PCI-DSS compliance is important – and whoever is supporting should have at least the same or more knowledge than the QSA.

In some QSA Companies, they have a set up to differentiate the auditor and the consultant. Whereby the consultant is different from the auditor to ensure there is more independence. We have the same set up – PKF is the consulting arm and we deal mainly with implementation, testing and assistance of our client to get past PCI. The QSA is well, the QSA in this case, and they can do their audit without being too involved in the implementation. We know as much (and if not more, sometimes) than the QSA due to our operational experiences, and this puts us in a better position – conflict free- to get our clients certified.

So, no, in this opinion, there is no real value or even PCI requirement in having a local QSA, because that generally does not make sense and is counter-intuitive to peg a customer to only select local, less experienced auditors. Most QSAs can (and should) be able to do regional or even inter-regional work because a QSA Company, by its very nature is a regional or global company anyway (QSA pays to be auditors based on regions, and not country specific). Again, while our opinion may be biased because of the strategic decision we made years ago, we made that decision with all these considerations in mind.

Select the best QSA option based on experience, pricing and quality, not because they are local or non-local.

Real Myth 4: All PCI projects are the same (One Certificate to Rule them All)

A customer once said that we didn’t have much value and all we did was to forward their emails to the QSA for validation (not true). He said he had his team done PCI across other countries and we were just making it more complicated than necessary since they have already been experienced, implying that we hoodwinked them.

It’s very difficult to talk to people who are in this position because you can see from the onset, they do not support outsourcing advisory and consulting and they have a personal vendetta against this profession. So we don’t need to speak reason to them. In this case, we decided to pull out of the deal for advisory and all other works of implementation except for the ASV scans.

Two years from starting their PCI project on their own, and they are still in the wilderness. We ended up supporting them in any case, and perhaps their thought process had somewhat soften now because we are now finally seeing the end of the project, with us (ironically) leading them to it.

And their ‘experience’ from other PCI compliance projects? Different experience. Some were basically e-commerce SAQ A, A-EP type, some were their retail arm SAQ B or B-IP. But what they were doing in Malaysia was the outsourcing, call center and BPO – all of which involves credit card storage, processing and transmission.

Not all PCI-DSS projects are created equal.

Another company employed the ‘One Certificate to Rule Them All’ philosophy. They were providing warehouse storage facility to one of our clients, essentially storing physical copies of forms containing credit card information. So, this is a service provider, providing storage that needs to be assessed for their physical security.

They immediately told us they are already PCI compliant and they will send us the certificate. We insisted on AoC but they obliged us with their ‘certificate’ anyway, emblazoned with their QSA logo proudly, stating – SAQ C-VT Certified.

Huh? What has SAQ C-VT (merchant SAQ) got to do with the warehouse storage you are offering to my client?

Apparently that SAQ C-VT cert is from one of their parent companies overseas or something and has as much relation to our current project as me running to become the president of the United Sates. It means, One Certificate 100% does not rule them all. It’s a completely different business function and you can’t just use another SAQ or AoC from another parent/child company that is selling ice-cream cakes and had their call agent processes certified and say this applies to your warehouse storage facility half a world away!

Ok, we are halfway there, bear with us. Writing all these myths really can drag an article and you can probably read the frustration oozing out each paragraph. I’ll admit, we get extremely frustrated, but we also must remind ourselves – most of them (customers, banks – NOT QSAs, they don’t get any free passes for giving misinformation!) do not know better and they are just doing what they think it’s right or what they have been told by so called consultants or QSAs. That’s why we need to set their paths correctly so they know what options are there before them. So, we need to stop getting frustrated and blaming them for bad decisions, and get more involved in educating and providing information so they can make good decisions.

We will continue the next time once we catch our breath and go through the other wonderful misinformation on PCI-DSS we have heard over the years. Till then, drop us a note at pcidss@pkfmalaysia.com on anything to do with this standard or other standards like ISMS/ISO27001 etc.

Credit Card transaction flow

March 10, 2020 / / 0 Comments

It has been a VERY long while since we last updated. Q1 has been a very challenging period for not just us, but for our clients, and I am sure, many businesses around the world as well. It’s just a lot of things (not necessarily good) happening, and we can only wish all our customers and readers to be safe and to take care of oneself during these challenging times.

Instead of going into too technical a subject, it may be a good idea to just start off this decade with a quick recap on some basics of credit card flows. This allows us to understand certain things dealing with PCI-DSS and gives us some background on more technical subjects later. This article takes us back to the basic.

How does a credit card transaction flow look like?

a) A cardholder (you and me) uses a credit card to purchase something – either online (card not present) or physically (card present).

b) The merchant either uses a POS, or virtual terminal or e-commerce, but at the end the authorisation request is transmitted to the ‘acquirer’.

c) The acquirer in this case the the merchant’s bank (or payment gateway, if not a bank). Not yours (issuer). So when you receive a credit card receipt, take a look at the receipt and it should state the acquirer. The acquirer acquires (signs up) merchants to accept card payments and ensure the merchant gets reimbursed for the credit card payments they accept.

d) The acquirer sends on the request to the processor. A processor does the authorisation and settlement service for all credit card transactions for each of the cards accepted by the merchant. These generally requires a front and back end processor.

e) The processor passes the transaction to the issuer, who approves/declines the transaction for whatever reason. Your issuer is the one issuing your card and generally has badge over the card (e.g your bank).

f) Whatever the response from issuer, the processor then sends it back to the acquirer, and the acquirer then sends it back to the merchant, through the terminal or however the request came in.

g) The merchant now has the approval (or decline) code, and the transaction is completed by providing the cardholder with the receipt.

h) Now the merchant and the acquirer goes through the clearing and settlement phase and the acquirer credits the merchant’s account.

i) The acquirer submits the transaction for settlement via the processor, and the processor requests the issuer to reimburse the acquirer for the transaction.

j) Finally, the issuer post the transaction to the cardholder account and the cardholder needs to settle the account (or not) on their statement.

That, in a nutshell is how a basic credit card flow works. Of course, there are inner workings in there, such as usage of settlement banks, consolidation of different acquirers, daily clearing data file reconciliation etc. But the above overall should give you a good working knowledge of what happens when you dip or wave your card in the next transaction you make.

For more information on PCI-DSS or ISO compliance, please drop us an email at pcidss@pkfmalaysia.com! We will get back to your immediately. Stay safe!

PCI DSS and the Problem of Scoping

June 5, 2016 / / 0 Comments

pci-compliance

I recall in an actual case a few years back when I received a call from a company requesting us to do a certification for PCI for them. So I met them and drew out their PCI plan starting with a gap assessment, remediation and certification audit.

They said they have already done their own gap assessments internally by their ISMS guys. And they will be doing all their remediation on their own and they just needed me to quote for certification audit because “PCI is forcing us to be certified by a third party, which we believe we can do it better than you can”.

There was nothing much to talk to them about, but I did mention that if we find major NC (non compliances, in ISMS speak), we would then use that ‘certification audit’ as our own gap assessment and that we might be required to come back again to verify.

The company truly believed that PCI was a subset of ISMS and they handled it as such.

So we came in for the certification and found out that their entire scope was completely messed up. For instance, there was another out of scope network and systems connecting into their CDE for monitoring. Because card data wasn’t passing through, they marked it as out of scope. Unfortunately, PCI doesn’t see it that way. This would be considered an Non CDE In Scope, and systems within this network will need to be secured as well, and hardened as per PCI. The logic is that if these systems are compromised, there is a path into the CDE that can be exploited.

They made a huge fuss on this, claiming that they are willing to absorb the risk and that their management signs off on the risk assessment.

ISMS is a best practice/guideline at best – it’s a great marker for security, but PCI is a standard. If you can’t meet it, then you don’t meet it. Of course, there are ways around this particular issue, but they insisted we passed them simply because their management accepted the risk.

Here’s another idea: PCI-DSS generally doesn’t really care about your business. It’s not about you. It’s about card data. Visa/Mastercard and the Jedi PCI council are not concerned about your business – they are concerned about the confidentiality and integrity of card data. That’s why you will not find any BCM or DRP requirement in PCI. RTO and RPO? Pfft. They don’t care. Your business can go down for 10 weeks but as long as card data is safe, it’s good.

And that’s why, scoping is HUGELY important. Many people might think that a gap assessment is a waste of time. It is, if it’s done incorrectly. I recently witnessed a ‘gap assessment’ report that was a complete mess. It just detailed the PCI twelve requirements and in each requirement gave an overview of the company’s controls and what they should be doing: ripped off almost verbatim from the actual standard itself. That can be downloaded for free.

A gap assessment needs to bring you from one place to another and needs to provide these:

a) A clear understanding of your scope, including a writeup on your network, and processes that have been assessed. It should also be clear what is out of scope. This initial scope usually is not set in stone as remediation would sometimes change what is in scope and what is not in scope. But at least you have something concrete to start with.

b) If possible, an asset register. For PCI. If this is not possible (for many reasons, e.g they have not purchase some assets required for a control), then the asset inventory needs to be prioritised a quickly as possible to see what is scoped and not. Asset should be clear on: Public ips, internal devices, servers, network devices, people involved, desktops, databases etc.

c) Network in scope and out of scope. This is key as companies are required to identify segments scoped out, and do segmentation testing. Also, CDE is clearly marked, NON-CDE IN SCOPE (we call it NCIS) must also be identified. Systems in NCIS could be monitoring system, SIEM, AD etc. Any system that connects to the CDE, but does not store, transmit or process credit card data are considered NCIS. NCIS must be scoped for testing, quarterly scans, hardening and such.

d) Clear roadmap for remediation and recommendations to proceed, specific to the organisation. These ‘gaps’ should all have a corresponding solution(s).

If the gap assessment doesn’t give you any of these, then it’s pretty useless. If it doesn’t move you forward or provide you with the information to move forward, it’s not a gap assessment. It’s an expensive training session.

So back to the first example of a customer. It wasn’t possible for us to certify them no matter how they argued, because simply they were not compliant (there were also many issues that they did not comply, for instance storage of card data in text files and sending via emails).

As a lesson – don’t neglect the proper scoping. It’s hard work, but as I always say: Start wrongly, do wrongly, finish wrongly. And that’s 6 – 8 months down the drain, with thousands of ringgit gone in investing, and job on the line. The second example is pertinent also. There is always a chance to OVERSCOPE as there is to UNDERscope.

An overscoping example would be to purchase all sort of snazzy security systems worth thousands of ringgit only to find that these were not needed, or that current controls were sufficient. It’s nice to have – but most of our customers, no matter how big they are, always have a trigger on the budget and cost optimisation is the topmost in their priority.

If you want us to help you in your PCI-DSS scoping, drop us a note at avantedge@pkfmalaysia.com and we can get you started with the initial understanding straight away!

The Myths of the Top 10 Myths of PCI-DSS

April 9, 2016 / / 0 Comments

pci-compliance

A while back, the PCI council published a good article called the Ten Common Myths of PCI-DSS, to basically debunk a few conclusions people (or so they think) might have on PCI-DSS.

After wading deep into this standard for the past 6 years, I am taking a look again at these myths and I am like, Wait a minute, this isn’t exactly correct.

Myth 1 – One vendor and product will make us compliant

This myth is hard to beat. It’s obvious that one vendor and one product doesn’t make anybody compliant since PCI-DSS is so much more than a product or an implementation. It’s the practice of security within an organisation itself. But wait. Not all PCI projects are created equal, and here’s where we call ‘scope reduction’ comes into play. It is possible that a product can significantly reduce scope so much so that it’s almost easy to become compliant. For instance, tokenization. This is a solution created to remove the need of dealing and storing actual card data in a merchant environment. Instead a token is used and is mapped in the token vault provided by a service provider. Hence, the merchant does not have the key or means to decrypt. Of course, they still handle the first time card data is transmitted through, but it removes the need of the merchant to completely fill the dreaded SAQ D-MER as they no longer need to store card data. Or P2PE for instance. When it started, the solution was to provide a point to point encryption so that merchants need not have the means to manage the keys or decrypt the data. Of course, P2PE bombed and they had to revise the standard to make it more realistic.

Myth 2 – Outsourcing card processing makes us compliant

Again – if you outsource card processing, it might not immediately make you compliant but it sure as heck make it a lot easier to be compliant! With the new revisions of SAQ, we have the nicely flavoured SAQ-A and SAQ A-EP for ecommerce merchants to deal with, to avoid the death knell of SAQ D-MER. There are like 9 flavours of SAQ (self assessment questionaire if you are wondering), and merchants might differ in their journey of PCI depending on their business. Outsourcing to a PCI compliant card processor or payment gateway is a great way to reduce your scope. So while this myth is correct, outsourcing is still a great strategy if payment processing is not your core business.

Myth 3 – PCI compliance is an IT project

Everyone will nod their head in the board room and steering com and agree to this one sagely. But from experience, I will tell you, whether it’s business or IT project – IT guys will be significantly involved in it. If you think you can breeze through this sucker the way you championed through ISO27001, you are in for a little surprise. A large part of the 12 requirements deal with technical requirements, from firewall configuration to antivirus to logical access controls. Logging and key management are significant challenges we find, and an entire requirement 6 deals with patch management and secure coding practices. So, if you are not familiar with terms like OWASP, KEK, DEK, WSUS, TACACS/ACS/LDAP, XSS, CSRF,CVE and all these, it’s time to get cracking. Having done both ISO27001 and PCI, we can say the ISO is more of a best practice/guideline on security while PCI is a standard. It’s either you do or do not. There is no try.

Myth 4 – PCI will make us secure

I know what this myth is trying to say, but technically, if you are practicing PCI, you are a heck lot more secure than someone that’s not. Besides, being ‘secure’ isn’t a final state to be – it’s not possible, but rather it should be a constant practice of a hundred different activities to contribute to ‘being secure’. It’s like when people talk about ‘enlightenment’ or ‘world peace’ – it’s not actually achievable – and even if it is – it’s not sustainable. So yes, PCI will make you secure , relative to the company that has their server under a marketing director’s desk and the password “PASSWORD”.

Myth 5 – PCI is unreasonable; it requires too much

Obviously, PCI Council wants you to think this (again, they are saying these are myths, so whatever you read, PCI Council is asking you to think opposite). They are saying, PCI is reasonable, it doesn’t require much.

I disagree.

It requires a lot.

I mean, OK, if you say SAQ A or A-EP, fine, agreed, it’s a breeze.  But if you are talking about SAQ D or a full cert?

Unless you have unlimited resources, money, time or already practicing some Level 5 Maturity of security, then you need to really look into managing PCI. Most of our clients aren’t in that state, so when you talk to them about the amount of work needed? Oh boy.

Let’s say they have 40 devices in scope. Multiple applications, running on multiple servers. Several layers of firewalls. Firewall rules need to be clean. Sounds easier than it is. The amount of legacy rules we see in some clients would make you think that firewall has been around since the internet was invented. Server upgrades due to EOL. Network changes because the database is accessing the internet directly. Applications not patched. Devices not updated. Logging not centralised. No correlation of logs or event management. No incident management. No central management of passwords and users. Applications developed eons ago and developers have since left the company with the only document being a note saying, “Goodbye and thanks for all the fish!”. You get the drift.

Myth 5 and Myth 10 (PCI is too hard) is the same. When you put the word “TOO” in there, its brings in relativity. What is “TOO” to some companies? When you have a single administrator running the whole thing and he is dividing his time between this and a thousand other things, “TOO” might be the key phrase there. So, I won’t say it’s not possible for a full certification – it obviously is, since we have certified a number – but what we don’t want is our clients walking into PCI with expectations of breezing through and then get slammed like a deer in headlights. It will take effort. It will take resources. It will take money and it will take time. Yeah, time. Around 3 – 4 months if you are lucky for a full certifications. I often get a stunned look of disbelief and a general retort that goes like: “<insert invectives here>, I thought it would only take 2 – 4 weeks, man.”

Look – PCI is really useful and it’s not the intention to discourage people from going for it – but it would be great to be better informed so that expectations can be synced to reality. In the next article, we will cover the remaining myths of PCI.

« Older posts Newer posts »

© 2024 PKF AvantEdge

— Up ↑