One of the most often asked question whenever we have a first call on PCI-DSS would be: How much effort will it take? The other question would be, how much would it cost? Let’s take a look at the first question first.
Misconceptions aside, which we have written on (whether PCI is a training program, a certificate, a license, a subscription etc), effort dedicated to PCI-DSS has always been a question for clients and potential clients (and ex-clients) of ours. And I admit – it’s not an easy thing to get hold of. Because, like costing and pricing, there is so much variable. But we do have some common guideline one can take – especially when it comes to initial budgeting and estimation of effort. It’s common this is needed and although it isn’t all the time accurate, it at least provides you with some idea on how this PCI-DSS standard is approached.
Before we start – we assume that you will be undertaking PCI-DSS the proper way. We say ‘proper way’ as we’ve seen a few consultants or advisors out there that just tell our client that PCI-DSS is just sorting out documentation, and sell a bunch of policy and procedures templates for RM2K and say bye. That isn’t the proper way. That’s amounting to modern day charlatans. Or some other companies knowingly decide to do a self signoff when their controls are not in place, or have any clue what a firewall is, but still mark firewall reviews as “Compliant”. If you are planning to go down this path, good luck and God speed.
So now – the best way to look at effort is (like pricing) split it into two. This makes it less overwhelming when you are evaluating vendors, because like pricing (effort generally has a direct correlation to pricing anyway) – it can vary A LOT. We see companies that price extremely high and we see companies that price extremely low. For anyone in procurement without an iota of understanding in technical projects, it’s going to be very overwhelming. Just by looking at pricing or effort by itself on paper and not understanding what it is puts you into a position of comparing apples to oranges, or potatoes to durians. Making a decision to go for the lowest price (which is common practice in Malaysia) works if you are evaluating a product, because the specifications are standard. Not so much for PCI projects as they vary significantly. So here’s a break down for procurement who may have some challenges understanding the project. Again, this is a guideline we use to help our clients and there is no ‘standard’ approach to measuring effort for PCI-DSS.
The two main portions of PCI-DSS for effort estimation are:
a) Advisory/Consulting/Audit Services
b) Implementation/Technical Services
a) Advisory/Consulting/Audit Services
This constitute a few parts :
i) Scoping and Optimisation of Scope
This is a critical part of advisory. Scope is generally determined by the customer, but most customers have no idea what the scope is. The critical thing about scoping is that it’s easy to either miss out things to do for PCI-DSS, or to ‘over-do’ it. An example here of missing things out would be: “Oh crap, I didn’t realise we had 15 other servers in scope for PCI-DSS penetration testing, and now only 2 weeks left to the deadline.” An example of overdoing it would be: “We just purchased this wonderful DLP system for PCI-DSS for RM5 million and busted our entire technology budget for the next year and a half. Cool eh? What? PCI doesn’t mandate it? We could have other processes in place to address that control? Ooops.”
ii) Gap Assessment
Nobody starts from a zero. Well, at least that’s our experience. In some form or another, most companies already have controls in place. The purpose of this assessment is to find out how close these controls are to the baseline requirements of the standard – hence the word “gap”.
iii) Remediation Support and Pre-Audit
Not to be confused by implementation services. Remediation support is the advisory work that comes during the remediation. A lot of services will be done during the remediation period and it’s often quite overwhelming, even for someone with project management background. Evidences need to be collated and submitted in specific formats. Evidences also need to be validated first before submission, as evaluation of evidences for PCI is a key part of the whole program. Often times, this is missed out and clients just submit lock, stock and barrel whatever they have and cry foul when the whole batch is rejected and they run out of time. It’s critical for evaluation of evidences to be done properly and in a proper methodology, whether by milestone a’la Prioritized approach , or based on the QSA’s approach. A pre-audit is usually done as well to ensure clients are well and prepared for the final certification audit. This pre-audit acts like an internal audit review for ISO equivalent. A good consultant here should also provide monthly healthchecks to ensure the implementation isn’t go wayward. In fact, we spend almost 2-3 days a week with our clients onsite around a month before the actual audit starts to ensure they have everything in place for a successful audit.
iv) Certification audit and post audit
Cert audit is what the QSA does. After that, there may be a period of 2 -3 weeks to clean up whatever non-compliances found during the audit. During this time, the Report of Compliance is also prepared for level 1 clients. The process of RoC can take up to 4 – 6 weeks from the QSA, so be aware of this timeline.
b) Implementation/Technical Services
The reason this should be separated from the advisory/consultation portion is because this is actually done during stage a.iii above. It can be done by your vendor, but it also can be done internally if you have the resource. PCI-DSS doesn’t specifically require stringent standards to do services. We have customers insisting that PCI-DSS requires CREST certified penetration testers to pass. That’s simply not true at all. If you have qualified individuals (and this may not even mean they need to have certifications) who can demonstrate aptitude in doing testing in both usage of tools, experience and methodology, it’s considered acceptable, as long as they are independent enough and free from conflict of interest, for instance they shouldn’t be the application developers doing the penetration testing for the app. While it’s all fine and well to have an experienced company certified with a dozen certification to do testing, the baseline interpretation of PCI has always been agnostic to these specific certifications. So now you know. On the other hand, you also can’t just do the remediation services as and how you please. Firing up OpenSSL scanner and calling it a web application pentest won’t cut it.
There are a whole lot of other services here to be done – firewall reviews, patching, logging and monitoring, physical security, encryption, policies and procedures, web app testing, secure code review, SDLC, card data scans and the list goes on. There is a lot of work here, and how you estimate the effort should depend on what sort of gaps you get.
This is the hardest portion to estimate.
For Cert and Advisory, the effort is usually based on two factors:
a) Processes – is authorisation/settlement in scope? Is backend processes in scope? Is call center in scope? Is POS /ecommerce scoped? Is managed Service scoped? etc
b) Locations – is your DC/DR in place? Are branch offices scoped in? What about outlets (for merchants like retailers/fast food/oil and gas) etc?
The more processes in place for PCI, the more needs to be audited. The more locations, the more time. One may think, what about systems in scope? Wouldn’t auditing 10 servers vs 200 servers be vastly different? The answer is: it depends. Because technically, if you have a large amount of assets, we revert to sampling basis so we can still have a control of how many systems to audit. Some QSAs will deal with either 10-15%, but it really ranges depending on the distribution, the error variance, the type of systems, the standardisation of processes etc. So because of sampling, auditors and consultants have a measure of control over the effort required for large/small projects. Locations are similar, but locations oftentimes need a physical audit, so it’s not just remotely looking at screenshots or evidences, but actually going onsite – which requires time and effort.
For implementation/technical services, there is no sampling. A lot of confusion stems from clients thinking that implementation of controls are also on a sample basis. No. If there are 250 servers in scope, all need to have PCI controls (patched, pentested, secured, hardened). The auditor may select 20-50 systems from that set to review, but that doesn’t mean you just implement controls on 20-50 subset of the systems. So for implementation, the effort is directly related to how many assets/systems are in scope to implement. Furthermore, these should be broken down into
a) Services that can be done in-house – anything that can be done in-house, whether services or with products like logging and monitoring system etc
b) Services that require external vendors(like an ASV scan or any services you may not be able to do in-house)
c) Services that require product purchases or implementation – this is important as there would be effort for implementation, migration, testing. Somewhat similar to b), but there may be products you can actually implement yourself.
Putting it all together
Whew. That’s a lot of ground.
As you can see, the budgeting process can actually be:
Advisory/Cert Budget –> after gap assessment –> Implementation Services Budget.
Because only after the gap, would we know what we need to fix, right?
Unfortunately, procurement is often faced with the prospect of budgeting for ALL phases from the get go. This produces a lot of problems, and a LOT of variations. Procurement runs the risk (without them knowing) of getting consultants/QSA on board for advisory and cert and under-budgeting/over-budgeting for the implementation service. Any QSA/consultant worth their salt should be able to do ALL the services listed above under Advisory/Cert portion. Many QSAs only do certification only with a sprinkling of support. This is a problem because their involvement is often too late and because their price point is so low, they generally don’t do any internal advisory support, healthchecks etc. This is basically you get what you pay for concept.
As for the implementation – budgeting BEFORE knowing what is wrong is akin to giving medicine before having a diagnosis. So you could either give the right medication or the wrong one. A wrong one could be providing panadol for someone facing terminal brain cancer, or providing a liver transplant to someone having stomache from eating too much nasi lemak. Both bad.
Instead, procurement should give some standard guidelines as much as possible – number of assets estimated, number of locations, number of processes, number of firewalls, number of applications etc. The more information provided, the more accurate the effort is. Also, request for a breakdown of each, so at least you know if they quantity changes later, how much would it be more or less. Armed with this, it may be worthwhile to guestimate that the implementation cost if majority services are outsourced, would be around 1 – 1.5x the cost of the advisory. That is an extremely liberal estimate, but at least that’s what we see mostly.
We do have clients that insist on us passing them a ‘generic’ PCI cost without them providing us any information. I don’t know why. But mainly because they don’t know what’s happening. In this case, we just interpret the scope for them from an external perspective and make assumptions and send to them an estimate. But because of this, the effort and price range varies INCREDIBLY.
Remember – least effort doesn’t mean that PCI-DSS is being achieved. Because this isn’t a product, there is a huge amount of variation in effort estimation by different companies. Procurement needs to get onboard and understand the process and not just look and say – oh, why does this guy give me only 10% effort of yours? Because, Mr/Mrs Procurement, they are giving you 10% of what you need. Or, on the flip side, someone is giving you 200% more than what you need.
The next article, we will have a look at price points and see what’s really there to budget for in a PCI -DSS program. Before that, drop us a note at pcidss@pkfmalaysia.com for any enquiry and we will get back to you immediately! Be safe!
