PKF AvantEdge

Category: IT Compliance (Page 15 of 17)

The Obfuscation of PCI Standards

August 14, 2016 / / 0 Comments

pci-compliance

When you go through the PCI-DSS standard, while in most part, the sections are clear, there are some that just annoys the heck out of me, for good reasons.

Stateful inspection and Anti-spoofing in firewalls – I know these are useful features, but it is extremely rare these days to encounter clients going for PCI-DSS that own firewalls without these capabilities inbuilt. Even the humble ScreenOS running on your tiny SGs (Juniper) are enabled by default. While this isn’t an issue, we’ve faced vexing times when our clients are sometimes asked by their QSA, to show the firewall rules that prove that Stateful inspection and anti-spoofing is turned on. We have to come in and explain to them that its already enabled by default, and they insist on us testing and showing them traffic captures. Sometimes, I just show them the manual and entitle my email “RTFM: Stateful Inspection was first introduced in 1994.” You would think that PCI would do something better than to ask this question.

AntiVirus and AntiMalware – the researchers at Imperva, a couple of years back, did a study of effectiveness of antiviruses.They collected 82 new computer viruses and ran the malware against antiviruses from some of the largest companies like Symantec, Kaspersky, McAfee. The results: initial threat detection rate was 5 percent. That’s detection. This means 95% of malware is undetected. I don’t know how strong this hypothesis is, but frankly, we have known for years antiviruses, while there are limited uses, presents to us a false sense of security. Just because the antivirus says, “ALL IS SECURED” doesn’t really mean anything. The annoyance here is not that PCI has antivirus as part of their controls, they dedicated an entire requirement to it. It’s not effective – move on!

Confusion of application testing – Requirement 6.6 states:

For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

a) Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes

b) Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.

Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2.

Now, we need to clarify this because this is obfuscation. Note the nice caveat they put into 11.2. Now, if you go to 11.2, you get a whole bunch of requirements for vulnerability scans, quarterly ASV etc.This is understood, right

So the above, you would surmise this: if I have a WAF (web application firewall), I do not need to do any web applications review, correct? What IS a web application review anyway? In a lot of instance, QSA will interpret it as web application testing, covering OWASP top 10. In pentest world this is called WEB APP PENTEST. This tests issues like cross site scripting, validation etc. You can find more here

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

A web app PT can set you back around RM10 – 25K depending on your web app and the provider. I’ve seen web applications go into the RM50 – 80K regions before for massive applications, but in general for a web application payment system, you would get that range (unless the provider is looking to rip you off, in which case I suggest you give us a buzz).

So if you have 10 – 20 Web App, that would set you back a mile, so the suggestion is to “Let’s invest in WAF”, where you pay a license and every year you don’t have that WEB APPLICATION testing headache siting on your books. In the long run, it makes more sense if you have a lot of web applications to test.

Now, here is the PCI problem.

Requirement 11.3 – Implement a methodology for penetration testing that includes the following:

blah blah blah

 – Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5

Unfortunately the presence of 11.3 renders the earlier requirement choice useless, because now QSA interprets at despite having invested in WAF, they are still insisting on getting 11.3 passed, which requires this application layer PT!

My question to the PCI-SSC, why don’t you include this 11.3 caveat in the earlier 6.6 requirement instead of the useless 11.2 caveat which anyone knows how to read? And if my interpretation is wrong, I am going to war against some of these QSAs because they basically said, it’s nice to have WAF, but you still need to do App PT. In fact, one of them actually said: “Well, the advantage is that you are more secure.” Yes – but our client’s goal was to pass PCI. If they wanted financial modelling and investment advise from you, they would ask it, if not, just do our job and interpret the standards properly! Will someone from PCI-SSC actually clarify this because I’ve talked to some QSAs on either side of this opinion – some say WAF OR APP PT, some say, APP PT regardless of WAF.

To be safe – get your QSA to interpret this before making a decision to invest in WAF, because this is a major roadblock in a lot of cases we are in.

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!

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!

PCI-DSS v3.2 is officially published

April 29, 2016 / / 0 Comments

pci-compliance

After some back and forth on the draft versions, PCI v3.2 is now officially published. You can go ahead and download it here, and click on the nice little link saying 3.2 and agree to all sorts of terms and agreements nobody ever reads about.

Anyway, a little bit of background on this release. Usually, versions for PCI are released in the later stages of the year in November. In fact, even I mentioned this to a few clients that version updates were done in November, until PCI recently announced that v3.2 is to be released in March/April timeline due to a few factors as described in this article. So yeah, now I need to admit I was bamboozled. PA-DSS v3.2 is likewise to be released sometime in May or June.

So here’s how it works: 3.2 is now officially effective. PCI v3.1 will be retired end of October 2016 (basically to allow everyone to sort of complete the v3.1 if you are already in the final stage of completing it). So all assessments/audit that occurs AFTER October will be version 3.2. This is important to note, because if any gap assessments begin now, and has a timeline to complete AFTER October, you want to use 3.2. For ongoing projects, it is best we scurry and get it all done before October! Chop chop!

There is a bunch of ‘best practices’ that will become requirements by February 2018. Other dates you need to be aware of:

a) June 30, 2016 – for companies not migrated yet out of SSL/early TLS, you will need to have a secure service offering (meaning an alternative service utilising TLS.1.1 and above. I will go out on a limb here and suggest to use TLS1.2 knowing how volatile PCI guys are in changing stuff).

b) June 30, 2018 – SSL/early TLS becomes extinct as far as PCI is concerned. No more mitigation plan! The exception is on POS terminals that has no known exploits.

c) January 31, 2018 – This is the deadline where new requirements graduate from being ‘best practices’ to ‘mandatory requirements’.

OK, now that’s out of the way, here’s a snapshot on the main stuff of v3.2 and what we are facing:

a) New Appendix A3 covers the Designated Entities Supplemental Validation. This basically means that if any acquirer or VISA/Master deems that a service provider needs to go through ADDITIONAL requirements on top of the torture they have endured for PCI, they can. These victims could include companies making ridiculous amount of transactions, aggregators or companies that are constantly breached. So PCI has a whole bunch of extra stuff for you to do, mainly to deal with BAU activities, incident response, documentation and logical access controls.

b) Additional cryptographic documentation – Service providers are not going to enjoy this. We will now need to formally document the protocols, key strength, cryptoperiod, key usage for each key and HSM inventory. This should technically be done anyway in your key management procedure document, but now its a requirement. Take a look at NIST SP800-57 for the key concepts to get you started.

c) 8.3 is significant : Multifactor login. Whereby previous versions stated that 2 factor authentication is required for remote access from non-secure networks, now 3.2 shifted this requirement to “all personnel with non-console administrative access, and all personnel with remote access to the CDE”. Wait, what? This means, even if you are accessing an administrative UI or page (non-console) from a secure environment, multi-factor (2 factor is good enough) is required! I think there would be some pushback on this as this requires a fair bit of effort. We have until February 2018 to implement this.

d) Another big one is 11.3.4.1 – segmentation PT now needs to be done every SIX months as opposed to a year. This is not good news for some clients who have segments popping up like acne on a pubescent face. That’s quite a lot of work for them to do and this might give them more cause to think of a completely isolated network just for PCI-DSS with its own link and architecture, as opposed to sharing with multiple not in scope segments. Again, we have some grace period till Feb 2018.

e) New requirement 12.11 is interesting. I have always been an advocate to do constant checks with clients to make sure they are at least practicing PCI. We have this free healthcheck service every quarter for clients who take up our other services and we are checking exactly this: daily log reviews, firewall is clean, new systems are documented and hardened, incidents are responded, proper approval for changes etc. It’s nice to see that our efforts now have something formal tied to them. Feb 2018 is the deadline.

f) Here’s a downer. Appendix A2. We all know there was some sort of escape loop for those who were caught with SSL and early TLS in their applications. They created mitigation documents which may or may not be true. Just saying. Now, if you take this route, this is no longer a free pass for your ASV scans or vulnerability scans. If you have these protocols in place, your mitigation plan must fully address A2.2 requirements. If you are a service provider, take note of A2.3: YOU MUST have a secure service option in place by June 30, 2016! Not 2018. 2018 is when you stop using SSL/early TLS. So this timeline is slightly confusing. Like X-Men:Days of Future Past confusing.

Some main clarifications include:

a) Secure code training now officially needs to be done annually – you won’t want to guess how much push back I get on this when I tell clients it’s annual, and not something that is done when they have the budget for it (which is never).

b) Removing the need to interview developers to ‘demonstrate’ their knowledge – I do programming a bit, but I’ll be foolish to think I can go up against a senior developer who eats, breathes and … lives for coding. How awkward I’ve seen some younger QSAs struggle to do this (determining whether the senior dev guru is good enough), when its obviously not something they even know about. Let auditors audit and let developers code.

c) Finally, note added to Req 8 to say that authentication requirements are not required for cardholder accounts, but only to administrative or operational/support/third party accounts. We have always practiced this anyway but now its clear.

d) More clarifications on addressing vulnerabilities considered ‘high’ or ‘critical’. I am not a big fan of these. I think every vulnerability should eventually be addressed, just prioritised in terms of timing. Even if it’s low or medium, it’s still important to have a mitigating factor to it. There is a reason why it’s a vulnerability and not something you can sweep under the carpet.

e) A good note on pentesting in 11.3.4c – testing now needs to be done by qualified internal or external resource with independence. Again, we already practice this but it’s good that now it’s official.

So, that’s about it. Of course, there’s a fair bit more. I suggest you to poke through the summary of changes first and then go through the documentation itself.

Be aware of those dates! It’s all over the place (June 2016, June 2018, Jan 2018), and who knows these might change in the future. Have a happy compliance.

 

 

 

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 »

© 2025 PKF AvantEdge

— Up ↑