PKF AvantEdge

Category: PKF AvantEdge (Page 5 of 6)

PCI-DSS – Merchant EDC and Scoping

February 2, 2019 / / 0 Comments

Many merchants we meet often tells us this: They are not in scope because they only do EDC (electronic data capture) – or payment terminal – transactions and these belong to the bank. Therefore, the bank has to ensure these are compliant and merchants do not need PCI-DSS since they do not store credit card.

Upon this, it’s the prevailing myth that storing credit card information is what PCI-DSS is all about, and as long as we avoid this, we don’t need to be PCI.

While non-storage of credit card does reduce scope SIGNIFICANTLY, it’s not the only thing PCI is harping about. It’s pretty clear in the standard itself:

PCI DSS applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process, or transmit cardholder data and/or sensitive authentication data.

I don’t blame the merchants. They already have a hard enough time competing in a new digital landscape of virtual buyers and getting margins from their products – the last thing they need is a consultant coming in, brandishing some sort of standard called the PCi-DSS and the only thing that flashes through their minds is: How much is this sucker going to cost me, now ?

But it is what it is and we try to make our client’s (or in many cases, not even our clients, but anyone who calls us – and doesn’t even need to pay) life easier – and provide enough information for them to decide whether they need consultation, help or go it alone for PCI.

Yes – we technically consult them to potentially not consult with us.

But we believe in the long run, trust is something every consultants or advisors need to earn and it’s not something that comes with the territory. In fact, if I had a ringgit for every joke made about CON-SULTANS…we wouldn’t need to make any more new sales.

Anyway back to PCI. So the question to ask back the merchant is simply: “Great that you don’t store – but do you process card data?”

“No we don’t, the bank does it.”

“You don’t handle card data?”

“Handle? As in physically handle?”

“Yes”

“Of course (now somewhat flustered) – how do we get customer card if we don’t handle it?”

So in that sense – they answer their own question – if they are not there (handling the card), there is no transaction and no processing of card. Therefore, they are involved in the processing of card data. Does PCI apply? Yes, it does.

How does PCI apply?

Again, I am not going into the story of levels (how do be validated) vs controls (what to be validated) – already covered in previous posts on this, recently here .

But before our merchants get discouraged, most of their scope is very limited and in fact, I recommend them to try and go it alone.

Scenario 1

Their EDC connects directly to the bank through a dial up or cellular. No storage of card.O Only flow is to receive card, dip it, wave it and pass it back to the customer. That’s it.

Look at SAQ B. Last check, there are 41 questions. You don’t really have too much complexity in there, except to just ensure information security policy is there, physical security of the EDC is there etc. It’s not that difficult and really, most merchants should try to at least get these done.

Scenario 2

Their EDC connects to the bank via the merchant broadband.

This becomes trickier as this means the card data potentially passes through devices in the customer premise. This also includes when the branch locations sends credit card information back to the HQ and uses the HQ own internet set up to send to the acquirer. Another permutation here is that the acquirer would have their own equipment in the customer HQ where all branch data is consolidated to and sent.

The above scenario is more often found in very large Merchants.

In this case, the best bet we can go for is SAQ B-IP, with around 82 questions. Again, card data cannot be stored (full 16/15 PAN) or Sensitive Authentication data like CVV or track or PIN cannot be stored. In this case, PCI can still accept SAQ B-IP but most of the interim systems will be in scope for SAQ B-IP controls.

The trick here is really the SAQ B-IP requirement:

“The standalone IP-connected POI devices are not connected to any other systems within the merchant environment (this can be achieved via network segmentation to isolate POI devices from other systems);”

This is not as easy as it sounds as many environments still have their EDC all in a flat network as any other systems, and part of the requirement will need these EDCs to be properly segmented out to avoid pulling in the entire corporate into scope. This becomes complicated further if EDCs connect via wireless.

Another thing to be aware of is that you probably need a letter or confirmation from the acquirer that the entire card flow is encrypted end to end – meaning from the EDC all the way to acquirer environment, rendering the merchant environment as simply a transition point. Think of a road, being used by an armored truck that the merchant has no access to, as they do not have access to the encryption keys.

Other than that, depending on the number of segments you have – segmentation penetration testing is probably another headache you need to look at. However, this can be done via sampling, so consult with either the QSA or PCI expert for an idea of what an acceptable sampling is. Due to the risk being rather low, the challenge here is just to ensure that all setup is standardised across stores.

Your EDC shouldn’t be relying on your POS machine to send card data or process. The POS should only be passing transactional information and any information obtained from the EDC should be truncated PAN (if necessary) or only transaction information.

There you go.

With these, you can probably navigate through the initial headache of PCI for your merchant environment! Let us know at pcidss@pkfmalaysia.com if you have further questions! Since we sometimes consult you not to consult us, it would definitely be an interesting discussion!

The Service Provider Challenge for PCI

August 12, 2018 / / 0 Comments

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PCI-DSS Segmentation with Host-Based Firewalls

February 17, 2018 / / 2 Comments

One of the frequent queries we have faced in the past months as we ramp up our consultancy and advisory for travel agencies and other merchants, has been the question of segmentation.

Now, before travel agencies were imposed with the requirement for PCI-DSS by IATA, we had very few opportunities to work with small merchants for PCI-DSS. It’s not because small merchants are exempted from PCI. They are not. Small merchants must be PCI compliant, but in reality, very few banks are chasing smaller merchants for their compliance. Our experience with merchants had been with the fairly large ones – the large petrol companies, the large retailers, the telcos and the largest travel agency being our experiences. From the time we started PCI back in 2010 to around 2014, it has mainly been for financial institutions and banks. But now with IATA flexing their regulatory muscle to make sure agencies are PCI compliant by 1st of March 2018, we have had plenty of opportunities to go into much smaller environments that we are used to. And it has been a really great experience.

So when we discuss about the topic of network segmentation, we need to be clear from the start:- it’s actually NOT a PCI-DSS requirement. PCI doesn’t state that we need to segment our network. We could very well be PCI compliant on a flat network. Page 11, of PCI-DSS v3.2 states so:

“Without adequate network segmentation (sometimes called a “flat network”) the entire network is in scope of the PCI DSS assessment.”

And we have done this before. One of our client has a completely isolated network for PCI-DSS with its own gateway and basically its a flat network with everything as CDE (Card Data Environment). Possible, but in enterprise environment, probably not so realistic if it drags in hundreds of systems. Without going too much into scoping, the main topic of this article is: if we need to segment, how do we do it?

At the onset, the question seems superfluous. How to segment? Why, by network subnets of course, or by VLANs (virtual LANs). These terms (subnet and VLAN) have been used interchangeably by myriad of customers over the years, and in most cases, they actually do multiple VLANs across different subnets, but in theory you can also have VLANs on single subnet as well. So, no – VLANs and subnetting are actually not the same but for the sake of not being pedantic, most of the time, we just allow the client to use whichever term they choose.

In most cases over the years, our clients won’t have a problem with this. Segmenting either via VLAN or network subnet, they can achieve this fairly easily through their switch or their edge router, as they usually have advanced firewalls/routers/L3 switches deployed in their network.

But going into the very small companies with a handful of people, no technology personnel, and running the D-Link DIR-615 low end routers provided by Telekom? How do we do this?

We have heard other consultants declare that these companies need to invest in enterprise grade firewalls/routers to achieve PCI compliance, because some of the entry level router/firewalls are unable to do any segmentation or VLAN. Of course, you could hack the DIR-615 to WRT and that might provide you some limited VLAN capability, but that’s beyond the scope of this article. And in any case, we doubt any of the smaller merchants have the inclination to fiddle around with their routers. So if you are stuck with a firewall/router that cannot do any network segmentation, does that mean that everything needs to be brought into scope? Does that mean you need to spend thousands to get a firewall upgrade?

So let’s have a couple of references here. First of all, the canon document from PCI will help, this is the official PCI-DSS v3.2 documentation, page 11, stating a few salient points:

Without adequate network segmentation (sometimes called a “flat network”) the entire network is in scope of the PCI DSS assessment.

This phrase actually enables many people to pre-suppose that PCI is stating that the only segmentation allowed here is by the methods we discussed above – i.e anything that creates a non-flat network. But this is confusing because when we say ‘flat network’, we are already indicating we are referencing to Layer 3. However it’s entirely possible to have layer 2 VLAN isolating systems within the SAME SUBNET (multiple VLANs – Single Subnet design). Heck, you could even have multiple subnet on a single VLAN if you want … I think I remember this from my Cisco CCNP days. So, actually, in theory , unless PCI refers to something else when it says ‘Flat Network’, their statement isn’t that accurate. You could isolate systems in a flat network.

Network segmentation can be achieved through a number of physical or logical means, such as properly configured internal network firewalls, routers with strong access control lists, or other technologies that restrict access to a particular segment of a network.

While agreeing on this one as a whole, the other confusion here is the term “Physical OR logical”. As tech nerds, we take these conjunctions very seriously. For instance,  my wife asked me the other day if I wanted a cheeseburger OR a double quarterpounder happy meal. The answer to that would be “TRUE”, meaning, Yes, I can have cheeseburger OR a double quarterpounder since “OR” here is inclusive. As long as any or both of those statements are true, it’s true.  This is usually what we do in Boolean values, for instance

1 > 2 || 3 > 2 = TRUE

1 > 2 && 3>2 = FALSE

So back to the phrase Physical OR logical, this generally means PCI accepts Physical segmentation, even if there is NO LOGICAL SEGMENTATION? What does that mean? Does it mean if I have two systems hooked into the same switch, on the same network, pinging each other, I set up a physical brick wall between these two systems, I have achieved Network Segmentation? Surely not. The physical segmentation example here would be having two separate switches servicing two different networks as opposed to using a single switch and using it’s logical functions to achieve that segmentation. Can both be used or one or the other? Yes, either can be used. So whoever have written this phrase either needs to clarify this statement proper, or simply, he or she is !(Tech Nerd).

At a high level, adequate network segmentation isolates systems that store, process, or transmit cardholder data from those that do not.

So finally they decide and say, ok, anything that ISOLATES systems can be considered network segmentation. So at least we have a lead here to go with. Anything that ISOLATES.

The next journey we take is to this document:

https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf

Section 3.1, page 13:

Examples of controls that could be applied to prevent out-of-scope systems from compromising a connected-to or security-impacting system include:

– Host-based firewall and/or intrusion detection and prevention system (IDS/IPS) on in scope systems that block connection attempts from out-of-scope systems.

This is one indication that PCI looks at alternate ways of ‘segmentation’, other than getting an enterprise grade network firewall. Once more, the conjunction used here is “AND/OR”, which we take to mean, either AND (&&) or OR (||) can be used for these two statements (Host-based firewall, IDS/IPS). So what this basically states is that a host-based (not network firewall) firewall is good enough, if configured properly to be considered as a segmentation tool.

Now if you do know a little history behind this documentation, it has a grandfather document called “Open PCI DSS Scoping Toolkit”, a copy can be found here:

https://www.isaca.org/Groups/Professional-English/pci-compliance/GroupDocuments/OpenPCIScopingToolkit.pdf

This was way before the PCI-DSS document came about. We had to use the OPEN PCI scoping toolkit to define what is in scope, not in scope, CDE, non-CDE in scope etc. This is why sometimes we say systems that are non CDE are ‘infected’ , i/e pulled into scope because they are in the same subnet/VLAN. This term isn’t found in the PCI document but is used in the old scoping toolkit document. Of course, this document is deprecated and the SSC doesn’t officially endorse it. However, some concepts had made its way into the SSC scoping document and what we are focusing here is mainly on the usage of host based firewall, and whether it’s logical for it to be used for some sort of segmentation. Other parts of this document has been succeeded by the official PCI scope document, so be aware. Back to this document, a few QSAs had looked at us in amusement when we used these terms and some even commented that these are very strange terms we are using, showing how young these QSAs actually are. I am not sure about the other regions, but I have had discussions with QSAs who are 10-15 years younger than me and never had one day of experience in actual security operations. One QSA even insisted we put our logging system into the DMZ as good security practice, which I then responded with an emoji face slap to our customer. With all due respect to QSAs, I have had many arguments with them over the years – some are very good, very experienced; while some are, as Bart Simpson would put it: “Meh.”

Anyway, we digress.

In the scoping toolkit, Page 13 gives an indication of what we are talking about:

The mechanism providing the isolation or controlled access functionality may be either logical or physical. Examples of mechanisms include network and host-based firewalls, virtual routing and switching appliances, and access control lists

This is still less clear due to our “AND” and “OR” arguments, because aside from the illogical “logical or physical” statement (which PCI clearly inherited), we have the problem stating “network and host-based firewalls, virtual routing and switching appliances, and access control lists”. This, to us, might mean we need ALL of these things for isolation to be TRUE.

Thankfully, this is clarified further down in Page 36:

In order to restrict other workstations on the same network from being “infected,” the dumb terminals must be isolated (e.g., using a host-based or network-based firewalls, etc.).

The example here is “using a host-based or network-based firewalls.”. As you now are very well aware, this means this statement is true if any of these options, or both these options are true.

You see, some writers do not think twice about the usage of “AND” and “OR” operators or ‘conjunctions’ to normal English-speaking people. These are extremely powerful operators and carry entirely different meanings to what normal people may deem as normal sentences having the same meaning. Another key life example here would be if your wife (again a very relevant example) were to ask you after a late night out with the guys whether you’ve been to the bar to watch football or to watch strippers, to which you respond: “YES”.

So be careful because different people parses sentences differently, depending on whether you see life in code or not. It could very well change your life.

We have also discussed this topic of segmentation at length with some senior QSAs (QSAs who have much more experienced compared to the green horns) and they have agreed that host-based firewall, or Host IDS are acceptable forms of isolation, but requires a significant amount of configuration to ensure isolation is done properly. “Done properly” here carries a fairly subjective weight to it. QSAs are a funny lot, because many of the requirements in PCI are general, and then it’s up to the QSAs to decide whether a particular control satisfies their own concerns whatever that might be. To summarise, segmentation can be carried out easier through deployment of a network firewall and getting the segmentation rules sorted out there, but if the merchant is short on funds, and have 1 or 2 systems only to configure, a fix could be a “properly configured” host-based firewall, or a host-based IDS/IPS.

Segmentation testing still needs to occur, though, but that will be for another article for another day.

Now, I will have my coffee OR tea to finish up my day. TRUE.

For more information on PCI-DSS, feel free to drop us an email at pcidss@pkfmalaysia.com.

PDPA and the Tale of the Telemarketer

October 29, 2017 / / 0 Comments

We were working very late on Saturday to roll out a PCI manual for some of our merchant clients, so I only slept at around 4.30 am. I am usually up on Sunday around 9.30 am at the latest due to my kids utilising my body as a trampoline which I can probably ignore for about 15 minutes before being entirely awoken, but 5 hours of sleep is pretty good so I will take that regardless.

At around 9 am unfortunately, my phone rang and I saw a number I didn’t recognise. Thinking this could be an emergency, I picked up the call and on the other line, this unrecognised voice chirpily said, “Hi, I am calling from <name of telco> and I would like to do a marketing survey with you!”

“Do you know it’s a Sunday?”

“Yes, it is a Sunday, I know!”

“Don’t you realise that you shouldn’t be telemarketing me on a Sunday morning?”

“We believe that you would be too busy on a weekday, sir, that’s why I am calling you on a Sunday!”

“Well, I am too busy now on a Sunday. Goodbye.”

And I hung up.

Now, I was fuming, because I just felt it was completely distasteful and disrespectful for them to be calling me up on a Sunday morning because they think I would reject them on a weekday. They think they will get me on a better mood on a Sunday morning?!

For the record, I don’t usually do this, as in, be rude or just hang up even on telemarketers. I am always reminded, that telemarketers are people. The person on the other line has a family too, and she probably wish that she was with them on a Sunday morning, taking her kids out for breakfast or hanging out with her friends or something. I mean, I doubt she is jumping up and down with excitement at the prospect of going into the office and dialing up people on Sunday so she could make her survey quota. I never experienced being a telemarketer, but in our first year, I did experience the emptiness of having zero clients and doing cold calling if anyone wanted my audit services. So, yes, I do commiserate with them. On normal calls I am usually civil to them. I usually politely tell them that they have already called me many times (Astro calls me like every week asking me to upgrade), and even thank them before hanging up, before I put their number in my ignore list. Some, I admit, when they do call, and I am in a the middle of something, I tell them that I am currently busy and then I put their number on my ignore list. It’s hard for me to ignore phone calls on any number because there could be a potential sales opportunity and not a telemarketer. But if it is a telemarketer, I don’t shut them down rudely. At least not in my memory.

But Sunday morning is a different thing. I did kind of feel bad, and was contemplating to call her back again to take that survey, but then Sunday life started (me being a trampoline) and I lost track of it.

But how does our Personal Data Protection Act fit into all of this?

Contrary to many people’s beliefs, PDPA actually allows telemarketers to call you. There is nothing in the act that says telemarketers cannot call you. The problem isn’t so much of telemarketers calling. Them calling you is already way downstream of the actual issue. The actual issue is your information being shared, leaked, sold, brokered by service companies to information brokers. Sometimes it’s our fault. We sign up for things and we don’t read the fine print. When we get a direct marketing call we get all up in a tizzy and blame the entire planet for conspiring to wake us up on a Sunday morning. But hey, we agreed to it. Yes, in that terms of services we did not read. In that privacy statement we implicitly agreed to when we gave our information to get a chance to win that free trip to Tokyo.

Privacy statements from banks, telcos, service providers all have to include the section of ‘disclosure’. Google your favourite bank or telco and put in ‘privacy statement’ and click to get their privacy statement. In most cases you will find them defining who they intend to share your personal information with, and in most cases, some broad sweeping statement such as :

Our agents and service providers with whom we have contractual agreements for some of our functions, services and activities; and/or

 

Financial service providers in relation to the products and services that you have with us (e.g. mortgage brokers, insurance companies); and/or

 

Strategic partners with whom we have a relationship with for specific products and services if consented to, by you; and/or

Now, let’s break that down. The first one is very broad. “Agents” and “Service Providers” where they have contractual agreements  – this basically means the entire ecosystem of companies providing services to this bank! The second at least defines it, but generally these are a subset of the first. Finally the ‘strategic partners’ part isn’t so much of an issue but the ‘if consented to, by you’ sounds very good and positive, only for you to realise that the implied consent is usually obtained by you agreeing to the privacy statement in the first place! You see, there is no need for explicit consent if this is not considered ‘sensitive data’, so don’t expect your signature to mean consent. By you taking up their service and agreeing to pass your data – that’s a consent enough for them to share your information. Boom.

So, technically the moment we sign up for a service, we agree that we would allow telemarketers to call us – whether in the middle of the night or on a Sunday morning is irregardless – the fact is that we gave that permission, mostly without knowing it and all just because of that carrot they usually hang in front of us. Dang, I lost that Tokyo competition! Hey, here’s another one – “provide phone number to win a Mazda 3”. OK, here’s my number! Yaay! Let me be lucky!

You get the drift.

Now, back to telemarketers calling us. They have the right. They have a bunch of phone numbers given to them by the bank, and God knows what other information so they can sell us specific services: and so they make the call.

PDPA regulates telemarketing through Section 43 of the Act: Right to prevent processing for purposes of direct marketing. 

So the proper channel to stop this: Technically you are supposed to provide in ‘writing’ to the data user (company calling you), requesting you not to be contacted anymore for telemarketing. This can be a courtesy respond during the call itself, whereby you state to them, please remove your number from their list and not call anymore (it’s not in writing, but you can try this first). If they persist in calling, write to them (their email is found in their company’s privacy notice of who to contact if you have a complaint), and if you still get called up, you can formally complain to PDPA commissioner at aduan@pdp.gov.my and follow that up with a call to 03-89115000 (please check their website to see if this has changed).

So, there you go. Malaysia was supposed to implement a Do-Not-Call (DNC) registry to block these telemarketer phone numbers back in 2014, but it has seemingly died down and implementation is still not done. We are monitoring to see if this is being looked into again, but for now, it looks like we need to fend on our own here.

Remember though – the person calling you may not wish to be calling you at all, and they might just be a phone call away from losing their jobs. While I am not advocating you to entertain them just for the sake of being nice, but on the flip side, there is no reason for some of the foul-mouthed tirade I have seen some people venting on these callers, as if they want to personally reach into their mobile phone and strangle the guy on the other line. Cool down. Ask to be removed, and block the number and move on, knowing you can rely on PDPA if your notice of removal is constantly ignored.

If anyone needs to know more on PDPA, drop us a note at avantedge@pkfmalaysia.com. We have been working with many companies to sort their PDPA concerns out and also implementing controls to address the 7 requirements.

 

PCI-DSS – So Why Aren’t We QSA?

June 29, 2017 / / 0 Comments

We have faced this question many times before over the course of 7 years working on PCI-DSS in this region. Many customers have asked us, why haven’t we become QSA (Qualified Security Assessor), considering the amount of PCI work we have been involved in, as well as the PCI-DSS knowledge that we are having?

The answer is simply – we choose not to.

Don’t get me wrong. QSAs certainly have their place in our world, and the fact that we work closely with one, as well as representing them in our country states the importance of having a solid auditing foundation in every project that we go in.

But here are the main reasons why we have decided that being a QSA would hinder us, rather than assist us:

a) Conflict of Interest

This is a huge reason why we maintain our consulting and implementation practice, while choosing not to become an auditor. Our business is not just PCI-DSS. We have a huge chunk of consulting practices in ISMS (ISO27001), training as well as upcoming compliances like SOC1,2, Personal Data Protection Act etc. QSAs and the question conflict of interest has been around for a long time. It is also addressed in Provision 2.2.2 in the PCI-DSS validation requirements for QSA

The QSA must describe the company’s practices to maintain and assure auditor independence, including, but not limited to, practices, organizational structure/separation, and employee education in place to prevent conflicts of
interest in a variety of scenarios, such as the following:

The QSA customer uses products or applications developed or manufactured by the QSA company.
The QSA customer uses products or applications managed or configured by the QSA company.
The description must include details with respect to compliance with the Specified Independence Requirements called out in Section 2.1 above.

The thing is, we do a fair bit of work for our clients – including development of policies, reviewing their security, implementing policies and logging products etc – because we are good at it. Before PCI, we were operational guys, guiding SOCs and NOCs, troubleshooting routers and switches, deploying firewalls and SIEMs etc. We weren’t bred as auditors from the start, so most of us have an inherent instinct to just go in and get the job done for our clients. Now, the problem is once we do wear the auditor’s hat, there are a lot of grey areas. We make this demarcation very distinct in our IT general Controls audit – the moment we implement something for our client, we cannot audit or assess it. We can’t audit our own work. This is not just for PCI, this goes across the board for anything we do.

PCI gets around this by ensuring that the QSA has proper internal segregation – meaning it is generally accepted that policies be put into place that mandate a separation of duties between QSA Auditors and QSAs, or other individuals within a QSA certified company who provide remediation support. So generally, any QSA company should have its consulting group separated from its audit group. Now, PCI-SSC doesn’t specifically state that QSA Companies cannot provide remediative services – after all, if the QSAs know what it takes to pass PCI-DSS wouldn’t they be the best source of knowledge to clients after all (and they often are) – but QSAs need to be very aware that they cannot push their products or services as the only option for compliance. Customers must have the options on the table, the knowledge that there are other options in order for them to make informed decisions.

It’s made trickier due to our DNA as a CPA company. PKF wasn’t born an IT company or a security firm – our roots are in accounting and auditing, and most of our partners hail from Big 4 (PWC, KPMG, EY, Deloitte) and even ex-AA. In fact, I am the only non-audit guy in the partner table and my jokes are often not understood. Due to this background, inherently we have this default position whereby if there are any grey areas, it’s safer to err on the side of caution and not do it unless proper conditions are clear. So while in PCI the arrangement of QSACs providing remediation works are allowed with certain conditions, the very memory of how an 89 year old accounting firm had to surrender its CPA license due to the largest auditing scandal in history still lives on in our industry.

b) We Hate Auditing

Well not really. We are auditors after all! We do have a fair bit of audit and assessments as part of our work. But boy, have you ever been in an audit as an auditor? Everyone just hates you. I remember auditing for a very large BPO company for their IT general controls and software development. The head of software looked like he was going to put live electric eels down our pants halfway through our interview. And we weren’t even antagonistic. Asking for documentation of his software practices was like asking for the what Edward Snowden had. Another company had their head of operations sit with us in the room for 1 hour and throughout the entire session, he refused to answer anything without legal in the same room. It was like we were interrogating him for murder instead of just asking if he had a change management procedure. It’s not all like this of course, we do have excellent clients who are on the same page as us mostly and we do feel the whole auditing process is enriching to our professional lives. Really. Even with that, the follow up audits, the report writing and quality assurance process etc, the evidence gathering and formatting into the proper report, the cycle of obtaining management comments etc. It’s just very taxing on the guys. Report writing takes up a chunk. And guess what – in PCI, a normal Report on Compliance (ROC) for level 1 onsite assessments can stretch up to a thousand pages. Yes. A. Thousand. Or more. It’s like asking us to become Leo Tolstoy and start writing War and Peace every single assignment.

c) Cost vs Benefit

Being a QSA is a great achievement. But there is a huge outlay for the company as well. Not only there are fees you need to pay to become QSA, there are fees you need to pay to operate in particular regions as well. Then you have training fees for your QSAs, yearly maintenance etc. It’s a lot of money to run a QSA company and because of that, you need to get your bacon from all over. For instance, if you have license in Asia-Pacific, then you probably want to tackle the China market. Or else, focus on the SEA region and get your QSAs to fly between countries. Focusing on a single country isn’t going to make up for the cost of maintaining your QSA company, at least from our point of view and our brief calculations. Now because of this, we need to fan out. To fan out, we need to expand the company. To expand, we need to hire and get jobs. I’m all for it, but its a matter of being a big fish in a small pond or a small fish in a big pond. As of this moment, our strategy is not to overstretch ourselves too much and to establish ourselves with the clients we have. It’s not as if PKF is in a hurry to IPO or go anywhere. We’re here for the long run, and in Standard Chartered slogan: We are here for good.

d) Stretching is not fun

We tried it before.

As in not physically, but in terms of a company. We grew our tiny little professional services firm to 16 people once upon a time, with dedicated R&D and Project Management group only to get kicked in the butt by a guy called “No Jobs”. We grew so fast, we didn’t get the sales in to keep up and after the initial projects were done, we were left with a lot of people on the bench playing Pokemon-go. We stretched. But we over did it. It’s not to say we are now not being ambitious. We still are, but we need to be realistic with our goals. If we target to get 10 – 15 tier one customers to keep our benefit more than our cost – how many QSAs do we need to do that? After that, how many consultants to do the remediation work?

Additionally, even if we had 10 QSAs for instance, these guys will be scrambling all over the region doing audits. They won’t have time for operational work. They won’t have time for consulting or providing technical services. They will either be auditing a customer, or they will be on a plane somewhere, or they will be writing or reviewing one of those 1000 pages tomes called the ROC.

e) We Want to Stick with our Customers

The bottom line is this. If we hadn’t found a trusted QSA whom we can work with and who are mostly on the same page as us, we would have gone and gotten our QSA ourselves and went another direction. I think we have enough legs and enough entrenchment in the region and global to do that. But we found a great partner. We found a QSA that we could work with and didn’t do any BS work. We found a QSA that had similar philosophies (although we are still working in synching our concept of deadlines, but hey, that’s like marriage, ain’t it) – and for 7 years, we have been working great together. They like what we do, that they can hands off a lot of the remediation advisory to us and don’t have to get on conference calls all the time or have to fly in and out of our client’s offices for weekly meetings. We like that we can work with our customer, look after our client’s interest and not worry to much about whether we are overstepping our limits as advisors or consultants versus auditors. We can stick with our customers and give them all we have. We can spend a whole day in our customer’s premise working with them without worrying that we need to head off for an audit for 2 weeks in Timbaktu. We don’t have to fly in and out of countries or tell our clients we can only meet 2 weeks later. If you want us within 24 hours, we will have someone there. Best of all, it’s very clear that once auditing starts, we are sitting on the side of our client, and ensuring that our client have what it takes to pass PCI-DSS.

Of course, this is simply our view at this current time. We are well aware of the flowing and ebbing of different forces in our industry and it might come a time whereby this model doesn’t work anymore. But for now, honestly, we just want to get cracking at troubleshooting your Cisco ASA as opposed to writing a War and Peace Novel. Drop us a note at pcidss@pkfmalaysia.com for more information!

« Older posts Newer posts »

© 2024 PKF AvantEdge

— Up ↑