Tag: security

PCI-DSS and Vendors

One of the things that advisors and consultants do, as part of our journey to get our clients to comply to PCI-DSS is the inevitable (and unenviable) task of dealing with vendors. A vendor can be classified as anyone or any company that is selling a service or a product to our client, that directly or indirectly relates or affect their PCI-DSS compliance. Examples include firewall vendors, encryption technology vendors, HSM vendors, server vendors, Virtual solution vendors, SIEM vendors, SOC providers, call center solution vendors, telemarketing services, hosting providers, cloud providers and the list goes on. Having dealt with hundreds of vendors over the course of the decade we have come across all kinds: some are understanding, some are hostile, some are dismissive, some are helpful and the list goes on.

But there is always a common denominator in vendors: They all start by justifying why their product or service is:

a) Not relevant to PCI-DSS compliance (because they don’t store card data, usually)

b) Why their product is PCI acceptable (but it’s really not, or when we have questions on certain aspects of it)

It always begins with these two start points and it can then branch off into a myriad of different plots, twists, turns and endings, very much like a prolonged Korean drama.

With this in mind, we recently had an interesting call with one of such vendor, who basically runs a fairly important PCI subsystem for one of our clients. The problem was that their logs and console had two things that we sometimes find: the combination of truncated and hashed values of a credit card information, grouped together.

Now, just a very quick recap:

a) Truncated card data – This is where you see parts of the card replaced by XXXX characters (or any character) where the full card number is not STOREDNow it must be noted that TRUNCATED and MASKED are treated differently, although oftentimes confused and used interchangeably. When we say something is MASKED, it generally means the PAN (Primary account number) is stored in full but not displayed in full on the console/application etc. This applies sometimes to call centers or outsourced services where full PAN is not required for back office operations but for reconciliation or references. TRUNCATED here means even in storage, the full PAN is not present.

b) Hashed Card Data – Hashing means its a one-way transformation of card data into a hash value with no way to reverse it (Unlike encryption). If we use a SHA-256 hash algorithm on a PAN, you get a fixed result. Fraud management systems may store this hash PAN in order to identify transactions by that particular card (after hashing), and not worry about the actual card data being stored. It’s like hashing of passwords where the actual password isn’t known.

It’s to be noted, when done properly, these two instances of data may even be considered entirely out of scope of PCI-DSS. The problem here is when you have both of these stored together and correlated together, it renders the data protection weaker than just having one control available. This is probably where the concept usually gets lost on clients implementing these controls, as we have seen many times before – for example, tokenized information being stored together with truncated values.

Even PCI-DSS itself states clearly in the standard item 3.4 in the Note, that “Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls must be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.”

To clarify, it doesn’t mean that it CANNOT be done, but additional controls must be in place. A further look at this is found in the Tokenization Product Security Guidelines Supplementary document:

IT 1A-3.b: Verify that the coexistence of a truncated PAN and a token does not provide a statistical advantage greater than the probably of correctly guessing the PAN based on the truncated value alone.

Further on:

…then the vendor provides documentation to validate the security strength (see Annex C – Minimum Key Sizes and Equivalent Key Strengths for Cryptographic Primitives) for each respective mechanism. The vendor should provide a truncated PAN and irreversible token sample for each.

And furthermore in Tokenization_Guidelines_Info_Supplement.pdf:

Note: If a token is generated as a result of using a hash function, then it is relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of the PAN. Where hashed and truncated versions of the same PAN are present in the environment, additional controls should be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.

So in short, at anytime we see there are hashed values and truncated value together, we need to validated further on the controls. A good writeup is found here at another blog which summarises the issues surrounding this.

However, as our call with this particular vendor continued on, he demonstrated just how vendors should or should NOT approach PCI-DSS compliance, which sort of inspired this post:

A) DON’T place yourself as the topical expert in PCI-DSS: Don’t. Not because you are not, but because you are representing a product or a service, so you always view certain things through a lense you have been trained on. I know, because I was with vendors for many years and most of our consultants are from vendor backgrounds. He immediately started by stating, he is extremely well verse with section 3.4 of PCI-DSS (which basically talks about the 4 options of protecting card holder data stored), and that he has gone through this conversation many times with consultants. This immediately sends the QSA red flags, once the vendor starts moving away from what they know (their product) to what they may think they know but generally may not (PCI-DSS), and in general we don’t want to put the auditor on defence once vendors sound defensive. It should be collaborative. DO state clearly that we are subject matter experts in our own field and we are open to discussions.

B) DON’T recover by going ‘technical’: In his eagerness to demonstrate his opinion on PCI, he insisted that we all should know what 3.4 is about. Concerning the four controls stated in PCI-DSS (token, truncation, hashing, encryption), he claimed that their product is superior to what we are used to because his product has implemented 3 out of 4 of these controls (hashing, truncation and encryption) and he claims this makes it even more compliant to PCI-DSS. At this point, someone is going to call you out, which is what we did reluctantly as we were all staring at each other quizzically. We had to emphasize we really can’t bring this to the auditor or justify this to our client who was also on the call, as this is an absolute misinterpretation of PCI-DSS, no matter what angle you spin. PCI never told us to implement as many of these options as possible. In fact, clearly stating if more than one of these are introduced, extra care must be taken in terms of controls that these cannot be correlated back to the PAN. We told him this was a clear misinterpretation to which his response was going into a long discourse of where we consultants were always ‘harping’ on impractical suggestions of security and where we always think it’s easy to crack hashes just because we know a little bit about ‘rainbow tables’. We call this “going technical”. As Herman Melville, the dude that wrote Moby Dick puts it:

“A man of true Science uses but few hard words and those only when none others will serve his purpose; whereas the smatterer in Science… thinks that by mouthing hard words he understands hard things”. – Dude that wrote Moby Dick.

Our job is really to uncomplicate things and not to make it sound MORE complicated, because there may always be someone in the room (or video conference) who knows a little more than what they let on.

DO avoid jargonizing the entire conversation as it is very awkward for everyone, especially for those who really know the subject. DO allow input from others and see from the point of view of the standard, whether you agree or disagree or not and keep in mind the goal is common: to make our client compliant.


C) DO find a solution together. As a vendor, we must remember, the team is with the client. The consultant is (usually) with the client. So its the same team. A good consultant will always want vendors to work together. We always try to work out an understanding if vendors cannot implement certain things, then let’s see what we can work on, and we can then talk to the the QSA and reason things out. Compensating controls etc. So the solution needs to be together, and finally, after all those awkward moments of mansplaining everything to us, we just went: “OK, let’s move on, these are the limitations, let’s see where the solution is.” And after around 5 minutes or so, we had a workaround sorted out. Done. No need to fuss. So next step is to get this workaround passed by the auditor for this round and if not, then we are back again to discuss, if yes, then done, everyone is moving out to other issues. Time is of essence, and the last thing we need is each of us trying to show the size of our brains to each other.

D) Don’t namedrop and look for shorter ways to resolve issues. One of the weirdest thing that was said in the conversation after all our solution discussion was when the vendor said that he knew who the QSA was and he dropped a few names and said, just tell the QSA it’s so and so, and we’ve worked together and he will understand. Firstly, it doesn’t work like that. Namedropping doesn’t allow you to pass PCI. Secondly, no matter how long you have worked with someone, remember, another guy in the room may know that someone longer than you. We’ve been working with the QSA since the day they were not even in the country and for a decade, so we know everyone there. If namedropping was going to pass PCI, we would be passing PCI to every Tom, Dick, Harry and Sally around the world. No, it doesn’t work that way, we need to resolve the issues.

So there you have it. This may sound like a rant, but the end of the conversation was actually somewhat amicable. Firstly, I was genuinely appreciative of the time he gave us. Some vendors don’t even get to the table to talk and the fact that he did, I really think its a good step forward and made our jobs easier. Secondly, we did find the workaround together and that he was willing to even agree to a workaround, that’s a hard battle won. Countless vendors have stood their ground and stubbornly refused to budge even when PCI non-compliance was screaming at their faces. Thirdly, I think, after all the “wayang“, I believe he actually truly believed in helping our client and really thought that his product was actually compliant in all aspects. Of course, his delivery was awkward, but the intention was never to make life difficult for everyone, but to be of assistance.

At the end, the experience was a positive one, given how many discussions with vendors go south. We knew more of their solution, we worked out a solution together and more importantly, we think this will pass PCI for our client. So everyone wins. In this case, the Korean Drama ended well!

For more information on PCI-DSS, drop us a line at pcidss@pkfmalaysia.com and we will get back to you immediately! Stay safe!

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

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!

© 2020 PKF AvantEdge

Theme by Anders NorenUp ↑