PKF AvantEdge

Category: PCI-DSS (Page 12 of 20)

IATA PCI-DSS: Is GDS Client software a browser? Part 1

September 1, 2017 / / 0 Comments

We are writing a fair bit on PCI-DSS for travel agencies simply because there is a deadline looming for them in March 2018 to become PCI compliant. While one might surmise there is still plenty of time, on the contrary, even merchant PCI programs will take a few months, and since the end of the year is pretty busy time for traveling, it’s best to get everything in order before the January – March months roll in next year.

So far, we know that the travel agencies are uniquely dealing with their PCI program whereby they have PCI obligations to their acquirer where most of them have card terminals merchant accounts with, and also IATA where they accept card through the “BSP channel”. They are both separate channels, because the BSP channel is actually acceptance of card IN BEHALF of airlines, not part of the agency’s own merchant flow.

So because of this, agencies have options to either fill in a full SAQ D-Mer and submit to acquiring banks and IATA, or to submit an SAQ B (or B-IP) to bank and SAQ C-VT (or C) to IATA. We are now looking into more details to the latter discussion – whether C or C-VT self assessment questionnaire should be filled.

Now before we start, we believe the answer to this is obvious. Ask IATA. We have. But we haven’t got any reasonable response. Next, they can ask the acquirer bank, which is what PCI-SSC suggests. Unfortunately for this channel, the merchant acquirer bank has no visibility over, so they don’t respond. Next, you could probably ask the GDS vendors. Which we also have. Only Amadeus have responded, when we queried whether we were correct in filing out SAQ C-VT: “Basically, if the payment is done via Amadeus and entered manually from a personal computer directly into the GDS – you have (the) right form for Amadeus agents and tick it off with confidence.”

Now it doesn’t really go out of the way to say it, because for this channel, technically, as long as no card data is stored electronically, we need to look at the eligibility of SAQ C vs SAQ C-VT. First of all, SAQ C has 162 questions. SAQ C-VT has 81 questions. More notably, SAQ C-VT does not have obligations for ASV scans whereas SAQ C has. Also, as an introduction for SAQ C, this is mainly designed for restaurants, fast food, franchisees with integrated Point of Sales. You know, the one we see at Oldtown Kopitiam whereby the point of sales system is like a desktop computer that has a LAN connectivity. The SAQ C-VT is designed for very small businesses who needs to enter manually the credit card number to a Virtual Terminal that connects to the acquirer through a ‘web-browser based connectivity’. Now these terms are very important to note, as we go into more details.

The question we have on the table is: Does your GDS channel qualify for SAQ C-VT?

First of all, if you store card data electronically, you can stop reading. You need to do SAQ D-Mer. Go. You have 332 questions to go through and we suggest you start! If not, then the idea here is whether SAQ C or SAQ C-VT is correct for your GDS channel. Now, these are obviously our own opinions, and some other consultants/QSAs might have a different idea or take on it. We do not represent the industry or IATA or PCI SSC in defining this…as and until someone from these parties decides to make a definitive statement of which SAQ needs to be done, this is our suggestion on why SAQ C-VT could be the correct SAQ for the GDS channel.

Now for SAQ C-VT there are a bunch of criteria. You can download the SAQ itself directly at

https://www.pcisecuritystandards.org/documents/PCI-DSS-v3_2-SAQ-C_VT.pdf

To save time, we are going to focus on the first three main eligibility points that define this SAQ conditions:

a) Your company’s only payment processing is via a virtual payment terminal accessed by an Internet connected web browser;

b) Your company’s virtual payment terminal solution is provided and hosted by a PCI DSS validated third-party service provider;

c) Your company accesses the PCI DSS-compliant virtual payment terminal solution via a computer that is isolated in a single location, and is not connected to other locations or systems within your environment (this can be achieved via a firewall or network segmentation to isolate the computer from other systems);

Now for A), the key here is “Internet Connected Web Browser”. The other part about ‘Your company’s ONLY payment processing is via a virtual payment terminal’ might mean that if you have any other channels such as internet of EDC (card terminals), you disqualify for this SAQ…but actually no, PCI-SSC states in their Article 1082 that as long as the channels are isolated from each other, you can go ahead and complete different sets of SAQ for different channels.

Now to understand the GDS connectivity, a majority of agencies are using either Sabre, Travelport or Amadeus. Each one of these are supposedly PCI compliant (so item Bcan be checked), and each of these provide a client solution that installs in your desktop and connects back to their main server for information and input. Sabre has their Sabre Red Workspace, Amadeus have their Selling Platform and Travelport have their Galileo Desktop. Some GDS now also offers direct web browser connectivity so that there is no need to install additional client, but for this article, we will be looking at the client application residing in the agent’s desktop. This is key, because if this is considered a stand alone payment application, then SAQ C-VT cannot be fulfilled.

It is this installation of additional client that some consultants have ventured to say that this is not a ‘web browser’, with web browser being what we know as Internet Explorer, Chrome, Safari, Firefox etc to name the popular ones. Without going into the history of web browser itself, the basic definition for the web browser is “a software that retrieves, present and traverse information resources on the internet”. These can also be used to access private web servers or private files in private servers. It is important to note that there must be a call to a web server, usually through encrypted transmissions and there is a dependency on information being posted/sent to this server and receiving a response. Basically, without internet connectivity (except if you have offline data), your web browser is basically non-functional.

So where does this leave us? Unfortunately PCI SSC is cryptic about this ‘Internet Connected Web Browser’ bit in SAQ C-VT. However, it does offer a bit more information about what constitutes a ‘Virtual Payment Terminal’ which is basically:

“Web-browser-based access to an acquirer, processor or third-party service provider website to authorize payment card transactions. Unlike physical terminals, virtual payment terminals do not read data directly from a payment card. The merchant manually enters payment card data via the securely connected web browser. Because payment card transactions are entered manually, virtual payment terminals are typically used instead of physical terminals in merchant environments with low transaction volumes.”

Now we are getting somewhere. So instead of saying Internet connected web browser, here it states a ‘web browser based access’ which might sound like the same thing, but it isn’t. It’s basically stating as long as the software accesses similarly like how a web browser access a resource, then it can be considered as SAQ C-VT qualified. Again in PCI SSC article 1063 in their FAQ:

” SAQ C-VT is for merchants who manually enter a single transaction at a time into an Internet-based virtual terminal solution provided by a PCI DSS validated service provider. “

In this case, it does away with the term ‘web browser’ completely and just states Internet based Virtual terminal.

So let’s establish a few assumptions here to approach this:

a) Software must be dependent on the internet. If there is no connectivity, there is no usage.

b) Like a browser, the software must send and receive information to and from a server

c) Like a web browser, the line should be encrypted if private information is being sent (this is technically more for security than functionality)

If the software can meet these requirements, then it can be considered an internet based virtual terminal. In order for us to really dig into this, we need to go down into the details: doing a packet capture.

We will look into this in more detail in Part 2 immediately after this, which is a separate article, since this one is already way past its word limit already!

IATA PCI-DSS: Approaching the BSP Channels

August 26, 2017 / / 0 Comments

First of all, Selamat Hari Merdeka (Independence Day), and congratulations Malaysia for hauling in a record number of SEA Games Gold Medals. So much so that our government has declared next Monday (4th September) as a holiday for….celebrating? I am all great with achievements, but at the risk of sounding like a spoil sport – aren’t we having a wee bit too many holidays? It’s great for morale I suppose, but it’s not so great for business due to the start-stop nature of things and worse, when we are chasing down a compliance deadline for our clients. In fact, approaching the end of the year, the amount of compliance work we are faced with is absolutely daunting.

Which is why it has taken so long for an update on this blog – not because it is low priority, but because we were just chasing so many deadlines in August, and now in September all the way to Christmas. It’s going to be a fun ride to the end of this year for sure.

Now as we approach our March 2018 deadline, we are getting more and more travel agencies calling us up on the IATA PCI-DSS requirements. While these are generally smaller agencies, we have come up with a standard package that addresses specific agencies with specific requirements.

a) No storage of PAN electronically

b) Only for Level 4 merchant levels (less than 1 million traditional transactions and less than 20K Ecommerce transactions)

c) Self signed SAQ by Merchant

d) GDS (Global Distribution System) Provider must be PCI Compliant

These are reasonable conditions for us to consistently approach each agency. See the problem is not so much that travel agencies are complicated – it’s because we have a whole lot of agencies with a very short deadline. We advocate that the whole industry and QSAs, Consultants or PCI experts all work together to get these agencies up to speed.

The first hurdle of cost prohibition is passed. Previously we all thought (based on the wordings) that IATA requires all agencies to have the QSA sign off on section 3c of the SAQ/AoC document, effectively rendering all Level 4 merchants to be Level 2. Obviously that would cost more as Mastercard requires Level 2 assessments from QSAs to be carried out onsite as opposed to remotely. That won’t be feasible due to the amount of agencies. Once it becomes more of a consultancy and advisory as opposed to an audit, it makes more sense. We are not saying QSAs should not get involved – we are saying now agencies have more options on their table – if QSA is affordable then by all means.

Secondly – storage of PAN. This is a real pain. Especially for travel agencies. You may think that you don’t store the PAN, the infamous Primary Account Number, that 16 digit on your credit card (remember, truncated PAN, or what we know as “First Six Last Four” or “Last Four” where the other numbers are X’ed out – this is NOT PAN)- even if you don’t formally store PAN as your process, the fact that you receive PAN in email, or Whatsapp or Skype or Wechat or QQ – anything at all – this translates to PAN being brought into your environment. Unless you are interested to secure your handheld devices and laptops and desktops and email servers – we suggest that you have only formal channels of card acceptance. Via Phone is one way. Through a secure portal is another way.

The problem is compounded due to Credit Card Approval Forms (CAF) or Credit Card Charge Forms (CCCF). These are formal forms either from the agency or from IATA to collect details of transactions, inclusive of credit card. IATA, however, has taken pains to ensure their channel is PCI certifiable and has since removed the requirement for CCCF to contain credit card information in full, as well as providing electronic alternative to CCCF submission via GDS. They are, in essence, securing their channels.

What about travel agencies own CAFs? This is not in any regulated form and even sometimes we see CVV information being required in these forms. This obviously is not allowed, to the genuine surprise of some agencies. Like the CCCF, either these forms need to be secured, or the channels in which information is provided needs to be secured. This is one of the challenges being faced.

Thirdly, the fact that IATA allows for self signed SAQ eases up the pressure of getting an audit in. However, in theory, the agency still needs to go through the same amount of due diligence to ensure they are fully compliant. Audit or no audit, there is no excuse of marking down “Compliant” in the SAQ for a question that you have no clue about. One client actually marked down compliant for “IDS” thinking this meant Internal Distribution System, which he thought was another name for GDS. Seriously. We don’t blame them. We blame the entire technology community for coming up with these acronyms that can sometimes be frustratingly flabbergasting for the general public to understand.

Lastly – the GDS. The ones we have experience with are Sabre, Travelport-Galileo and Amadeus. We come across some older ones but in general, these are the three main ones utilised by travel agencies. All of them as far as we know are PCI-compliant. We only have ever seen the AoC from Travelport. Sabre and Amadeus in turn provides our clients with some weird certificates by QSA or other documentation that is not AoC. Again, it’s just completely irritating when providers give these so called ‘certificates’ and argue with us that this is acceptable to PCI and we have no idea what we are talking about. It’s mind numbingly, teeth-gnashingly frustrating.

The GDS channel is general is secured. As long as credit card information is sent to the GDS mainframe you are more or less done. The problem is whether the desktop client is an actual application or just serves as a web gateway to the mainframe. This is where we are juggling between SAQ C or SAQ C-VT for this channel. We have gone through the Sabre Red Workspace and Galileo Desktop, and either of these cannot function without internet connectivity, and all information traverses through a TLS link to the mainframe of the GDS. We have done packet capture on these applications and while not traditionally considered as ‘web browsers’ in what we are used to, the functionality of it is similiar to a web based client. Even Travelport AoC states that the ‘travelport application client’ is covered under its compliance. In essence, these are virtual terminals in every understanding of the term.

While rare, the internet channel is probably the most straightforward, whereby an SAQ A should sufficiently cover most agencies, since they are utilising a payment gateway and not processing, transmitting or storing credit card information in their own environment.

In summary, the challenges faced mainly by agencies is not so much on the security of BSP or GDS channels, but their own. The credit card forms remain a pain, not so much of the forms itself but the channels in which the forms are sent or received. This forms a very real challenge in securing based on PCI-DSS requirements.

Of course, we have also recently encountered another massive hole in the travel agency PCI program – if you are doing “enhanced data services” with any of the card brands and exporting through a system like Sabre Powersuite, you have another headache in your hands: Clear PAN. We will go into this in a later post. Suffice to say, we have a lot to do, with little time to do so, so it’s time to get cracking.

Drop us an email at pcidss@pkfmalaysia.com and we will see how to get you started with your PCI-DSS program.

 

PCI-DSS IATA: Dissecting the New FAQs

July 13, 2017 / / 0 Comments

A few significant things occurred this week for the IATA PCI-DSS Program, summarised below:

a) We finally have a very clear way forward thanks to some clarifications direct from IATA, and in some parts due to our dogged persistence to get some answers

b) The new FAQs were published end of June and an updated version was done yesterday (11 July) and is now online at http://www.iata.org/services/finance/Documents/pci-dss-faqs.pdf

Firstly, the significant news.

IATA confirmed that Level 3 and Level 4 Merchants do not need a QSA to signoff their AoC/SAQ – which, to many agents, means they can do SAQ on their own, or using their own IT resources, or external consultants (not necessarily QSA, but if you prefer a QSA, by all means, go for it)

IATA also confirmed that they are considering exemptions for agencies that do not have any credit card transactions in their business channels.

These two clarifications address some long running questions agencies had for PCI-DSS. Do they need external consultants, do they need a QSA, do they need any compliance even if they don’t have credit card, etc etc.

Regarding point b) above, there was a quick iteration on the FAQs to clarify a few items. So here are some of the changes between the newest FAQ on 11 July and the one on the 29 June, and we can go through it.

The first 4 FAQ questions remain more or less the same although we do have a nitpick on 1, which is

FAQ#1 Who do I approach for PCI DSS compliance?
We suggest that you contact your acquirer.

Technically, this is correct, however, it’s not exactly complete. Because their (travel agents) acquirer wouldn’t have visibility over the agencies’ channel of credit card via GDS and BSP (or soon to be NGI – the new gen ISS). Acquirers have no idea of this because when the agents uses GDS credit card facility, they are doing in BEHALF of airlines! So even if they were to correspond with the payment brands directly as per FAQ#3, the brands wouldn’t know, nor care about the agency. Because in the GDS-BSP channel, the agency is not the merchant – it is the airline. (lightbulb).

Therefore, it must be the airlines who must be PCI compliant in that channel – however, because they make use of agents, the agents end up having to be compliant as well. But the airlines don’t deal directly with agents for this channel – they have an aggregator in between the agencies and airlines. And yes, this aggregator, this glue that holds everything together is the ecosystem of GDS-BSP/NGI. So if the agency connects to BSP, IATA is the ‘service provider’ offering this service – therefore, it is IATA that needs to clarify the requirements. Which they are doing – so technically FAQ 1 should read

FAQ#1 Who do I approach for PCI DSS compliance?
Yo, it’s us, man! That’s why you’re reading this on an IATA page!

In our clarification request, we didn’t point this out to IATA because our email at that point was already too long. It’s like we were writing the Titanic of emails, and we had to cut some scenes to fit into a readable email size.

Next, FAQ #6 is also important. Only for our own selfish self satisfaction.

FAQ #6 Are compliance certificates recognized for PCI DSS validation?
The answer to this question is no. Any sort of documentation which is not under the authority and validation of PCI DSS, will not be accepted for indicating the company’s compliance with PCI DSS.

And this is what we have been telling clients for YEARS. There is literally no such thing as a certification of compliance as far as PCI is concerned. Yet, everyone wants to see your ‘certificate’ and even go as far as to reject the AoC and RoC and SAQ documents. There is NO SUCH THING as a PCI-DSS compliance certificate. If someone prints a certificate out for you, it cannot bear any logo from the PCI-DSS council because it is not part of PCI. It’s a nice piece of paper to put up in your lobby but that’s it. When we work with our principal QSA, they also have this “certificate”, but we always make it clear that this is only issued as an aesthetic by the QSA and not considered acceptable to the PCI-DSS program formally. You MUST have the AoC and RoC/SAQ combination of documents at least – and also whatever ASV scans etc you might have. So, we would suggest not to go about calling yourself PCI-certified agency – just say you are compliant to PCI is enough. It sounds less sexy but those are more accurate terms to use.

FAQ#7 was corrected to refer to Question 14, instead of Question 13 as previous FAQ stated. Innocent error, of course, no harm done. It doesn’t mean that the writer of the FAQ can’t count.

FAQ#8 was also corrected whereby the previous FAQ stated (emphasis ours)

“The latter has to be completed as a declaration of the results of the service provider’s assessment with the Payment Card Industry Data Security Standard Requirements and Security Assessment Procedures (PCI DSS).”

and now correctly states

The latter has to be completed as a declaration of the results of the merchant (or travel agencies)’s assessment with the Payment Card Industry Data Security Standard Requirements and Security Assessment Procedures (PCI DSS).

Because technically, travel agents are merchants not service provider, so it might be just a copy and paste error.

FAQ#11 Can a QSA that is not listed in a specific country but listed in another country conduct a certification process in the non-listed country?

Originally it stated

“Yes. By definition, Qualified Security Assessor (QSA) companies are independent security organizations that have been qualified by the PCI Security Standards Council to validate an entity’s adherence to PCI DSS.”

This might not be exactly accurate as there are certain regional restrictions based on fees. So, the change became

“Overall speaking, yes. Nevertheless it should be noted that under the QSA program guide, section 6.3.1, there are qualified regions in which QSA can or cannot perform in as noted “QSA Companies are authorized to perform PCI DSS Assessments and QSA-related duties only in the geographic region(s) or country(s) for which they have paid the regional or country fees, and as indicated on the QSA List.”

Once again, that’s more accurate. And there are more words. And it has a quote from an official document from PCI, so it sounds very important.

FAQ#14 has the big change in the new FAQ version compared to the one in June, whereby under level 2 merchant column we have this “note” to clarify that level 2 merchants under Mastercard requires either an onsite ISA or onsite QSA to validate their SAQ. This is what we call “Validated SAQ”, and this is what Mastercard was telling us earlier, that this must be done by the QSA onsite (if they do not have an ISA – which is “internal security assessor”, which is as rare as an albino beluga whale).

FAQ#18 is the one applying to agencies without any credit card transactions. Now you do need to be careful. IATA does state that PCI applies to agencies processing credit card with the IATA GDS-BSP channel or any other channel (including your acquiring bank direct channel). This means if you have an EDC or POS device, or do internet transactions, you STILL need to undergo PCI-DSS. Who you send your AoC/SAQ to is another story, because IATA wouldn’t know much about your POS/EDC channel since you are not their merchant. Technically you send it to whoever you have a merchant account with – your acquirer. But again, your acquirer isn’t even asking for it! So. We suggest that you still do it, and keep it in case someone asks for it. We hear some cynical snorts in the background but we are going to ignore it. Be nice.

FAQ#23 – they decided to completely change this one. The previous answer seemed slightly confusing and in contradiction to FAQ#6 and FAQ#14. Previous FAQ in end June stated:

It should be noted that the third party should be authorized by the PCI DSS Council as a Qualified Security Assessor (QSA) to accept the PCI DSS compliance certificate. The scope shall cover the BSP card sale transactions.

a) Again, as FAQ#6 already confirmed – there is no such thing as a compliance certificate, so technically all compliance certificates issued by whoever, whether QSA, ISA, consultant or the Queen of England should not be accepted as formal documentation of PCI. One more time we hear this certificate of compliance being bandied around like its some sort of Ark of the Covenant, we are going to collectively walk out of our office and lie down on the main road in silent protest.

b) It’s sounds slightly confusing because it seems that this statement is saying a QSA is needed to be involved for all merchant level compliance as well which is contradicting FAQ#14.

To give them credit, their explanation to this was:

“We have had instances in which the agent was providing us with some sort of certificate issued by a third party, under the assumption that the certificate was issued by a QSA therefore we wanted to make clear that in the case an agent were to go this way they should be checking out the authorized QSA list available in PCI DSS council site.”

Yes, completely agreed. But not the certificate part. D@mn it, that’s it! We are headed out tomorrow and lying down on the street in protest!! Watch the news!

Anyways, now the current FAQ#23 reads a different:

Because most large merchants have complex IT environments, many hire a QSA to glean their specialized value for on-site security assessments required by PCI DSS. The QSA also makes it easier to develop and get approval for a compensating control. However, for Level 3 and Level 4, PCI DSS provides the option of doing an internal assessment with an officer sign-off if your acquirer and/or merchant bank agrees. Mid-sized and smaller merchants may use the Self-Assessment Questionnaire found on the PCI SSC Web site to assess themselves.

If this sounds familiar, it’s because it is. It’s lifted from Myth 6 in the famous PCI document at https://www.pcisecuritystandards.org/pdfs/pciscc_ten_common_myths.pdf

It’s certainly reads better, although, it doesn’t really answer the FAQ#23’s questions, but hey who cares? It makes sense!

So anyway, from this we learnt a few things

a) IATA is really keen to be on the ball on this PCI-DSS compliance and has put in effort in getting the right information out to the agencies – kudos to them and really impressed with their management’s response to queries.

b) The industry as a whole is still grappling a lot on PCI-DSS and needs to move forward with the right information and decision.

c) As QSAs, consultants, auditors, advisors or IT experts, we all need to work together to get our clients up to speed with the right information so they can make decisions and we can assist them.

PCI-DSS is never easy. Even those doing SAQ A-EP are having headaches, what more agents going through SAQ D-MER and all its 340++ questions. IATA seems to understand that and has PCI on their agenda.  We are willing to work with anyone on this – we have our clients who are travel agencies, but we also want to help other agencies get up to speed with PCI, what is required, and how to get compliant from the different validation requirements per PCI’s standpoint.

So to summarise this long winded post, from the horses’ mouth themselves:

a) There is no need for QSA involvement in Level 3 and level 4 merchant self assessment questionnaire (SAQ). Merchant officer signoff on section 3b is enough. However (and this is our opinion) if you can get assistance from QSA, ISA, consultants, IT experts, auditors,the Queen of England or even your own internal IT person familiar with PCI, go for it. You’ll need all the help you can get.

b) For those without credit card transactions in ALL channels (not just IATA), consider the exemption in FAQ#18. But please contact IATA on this as you should truly understand what might be the consequences in the future.

OK, that’s it for now. Drop us a note at pcidss@pkfmalaysia.com. We are preparing a complimentary talk on PCI-DSS specific to this travel agency industry soon, so stay tuned!

PCI-DSS v3.2 for ePetrol Services Sdn Bhd

July 12, 2017 / / 0 Comments

Congratulations to ePetrol Services Sdn Bhd for being certified PCI-DSS v3.2 Level 1!

ePetrol is a secure and reliable payment switch and service provider that offers a variety of payment solutions to a broad spectrum of industries encompassing oil and gas, finance, healthcare, retail, e-Government and telecommunications.

Founded in 2007, ePetrol – a subsidiary of Dialog Group Berhad – is a MSC status company which conceptualised and pioneered an innovative payment system which uses the Malaysian National ID Card (MyKad) as the payment instrument for purchases of goods and services. Their MyKad solution is also designed for welfare distribution and subsidy management.

Besides payment, ePetrol offers variety of IT solutions such as Loyalty Solution, Scheme and Entitlement Solution and Enterprise Management Solution to meet the client’s needs.

PKF and ePetrol actually had started the PCI journey together earlier, however due to the move from their old office to the current Dialog Tower, we then rebooted the process. We are happy to be part of the journey of PCI and the highs and lows we have had with the team. It has truly been a fulfilling experience in the project and we are looking forward to serving ePetrol for years to come.

Congratulations!

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 »

© 2025 PKF AvantEdge

— Up ↑