PKF AvantEdge

Tag: IT compliance

The Question of QSA Conflict

March 19, 2024 / / 0 Comments

An interesting conversation over coffee with a client today gave me something to mull over a little. The question brought to the table was how some assessors, while engaged in audit, brought up other services they offer like ASV, penetration testing and vulnerability scan and how this may look like a conflict of interest issue.

I will start first by proclaiming that we aren’t QSAs. We do have a myriad of certifications such as ISO and other personal certs in information security, but this article isn’t about our resume. It’s the ever important question of the role of the QSA and whether they should be providing advisory services.

Why we choose not to go the route of QSAs is for another article, but suffice to say, in the same regard we work with CBs for ISO projects, we employ the same business model for PCI or any other certification projects. We rabidly believe in the clear demarcation of those doing the audit and those doing the implementation and advisory. After all, we are in the DNAs of statutory auditors and every single customers or potential customers we have require a specific conflict check, in order to ensure independence and not provide consulting work that may jeopardize our opinions when it comes to audit. Does anyone recall Enron? Worldcom? Waste Management? Goodbye, 90 year old accounting firm.

We have worked with many QSAs in almost 14 years of doing PCI-DSS – and here, QSAs I mean by individuals as well as QSA-Cs (QSA Companies). Our group here is collectively made up of senior practitioners in information security and compliance, so we don’t have fresh graduates or juniors going about advising 20 years plus C level veterans on how to run their networks or business.

A QSA (Qualified Security Assessor) company in a nutshell is a company that is qualified by the PCI Security Standards Council (PCI SSC) to perform assessments of organization against the PCI standards. Take note of the word: QUALIFIED. This becomes important because there is a very strict re-qualification program from the PCI-SSC to ensure that the quality of QSAs are maintained. Essentially, QSAs are vouched by the PCI SSC to carry out assessment tasks. Are all QSAs created equal? Probaby not as based on our experience some are probably better than others in specific aspects of PCI-DSS. Even the PCI SSC has a special group of QSAs under their Global Executive Assessor Roundtable (GEAR), which we will touch on later.

The primary function of a QSA company is to evaluate and verify an organisation’s adherence to the PCI DSS requirements. This involves a thorough examination of the organisation’s cardholder data environment (CDE) — including its security systems, network architecture, access controls, and policies — to ensure that they meet the PCI requirements.

Following the assessment, the QSA company will then prepare a Report on Compliance (RoC) and an Attestation of Compliance (AoC), which are formal documents that certify the organization’s compliance status. Please don’t get me started on the dang certificate because I will lose another year of my life with high blood pressure. These OFFICIAL documents are critical for the organization to demonstrate the company’s commitment to security to partners, customers, and regulatory bodies. The certificate, however, can be framed to be hanged on the wall of your toilet, where it rightfully belongs. Right next to the toilet paper, which has probably a slightly higher value.

Anyway, QSAs have very specific roles defined by the SSC:

– Validating and confirming Cardholder Data Environment (CDE) scope as defined by the assessed entity.
– Selecting employees, facilities, systems, and system components accurately representing the assessed environment if sampling is employed.
– Being present onsite at the assessed entity for the duration of each PCI DSS Assessment or perform remote assessment activities in accordance with applicable PCI SSC assessment guidance.
– Evaluating compensating controls, as applicable.
– Identifying and documenting items noted for improvement, as applicable.
– Evaluating customized controls and deriving testing procedures to test those controls, as applicable.
– Providing an opinion about whether the assessed entity meets PCI DSS Requirements.
– Effectively using the PCI DSS ROC Template to produce Reports on Compliance.
– Validating and attesting as to an entity’s PCI DSS compliance status.
– Maintaining documents, workpapers, and interview notes that were collected during the PCI DSS Assessment and used to validate the findings.
– Applying and maintaining independent judgement in all PCI DSS Assessment decisions.
– Conducting follow-up assessments, as needed

QSA PROGRAM GUIDE 2023

You can see above, there is no advisory, recommendation, consultation, implementation work listed. It’s purely assessment and audit. What we do see are more often than not, QSAs do offer other services under separate entities. This isn’t disallowed specifically, but the SSC does recommend a healthy dose of independence:

The QSA Company must have separation of duties controls in place to ensure Assessor Employees conducting or assisting with PCI SSC Assessments are independent and not subject to any conflict of interest.

QSA Qualification requirements 2023

Its hard to adjudge this point, but the one providing the audit shouldn’t be the one providing the consultation and advisory services. Some companies get around this by having a separate arm providing special consultation. Which is where we step in, as without doing any gymnastics in organizational reference, we make a clear demarcation of who does the audit and who does the consultation and advisory role.

The next time you receive any proposal, be sure to ask the pertinent question: are they also providing support and advisory? Because a good part of the project is in that, not so much of the audit. We have actually seen cases where the engaged assessor flat out refused to provide any consultative or advisory or templates or anything to assist the customer due to conflict of interest, leaving the client hanging high and dry unless they engage another consultative project with them separately. Is that the assessor’s fault? In theory, the assessor is simply abiding with the requirements for independence. On the other hand, these things should have been mentioned before the engagement, that a bulk of the PCI project would be in the remediation part and definitely guidance and consultation would be needed! It might reek of being a little disingenuous. It’s frustrating for us when we get pulled in halfway through a project and we ask, well why haven’t you query your engaged QSA on this question? Well, because they want another sum of money for their consultative works, or they keep upselling us services that we are not sure we need unless we get their advisory in. What do you think their advisory is going to say? You can see whereas on paper, it might be easy to state that independence has been established, in reality, it’s often difficult to distinguish where the audit, recommendations, advisory and services all start or end as sometimes it’s all mashed. Like potatoes.

Here’s the another official reference to this issue in FAQ #1562 (shortened)

If a QSA Employee(s) recommends, designs, develops, provides, or implements controls for an entity, it is a conflict of interest for the same QSA Employee(s) to assess that control(s) or the requirement(s) impacted by the control(s).

Another QSA Employee of the same QSA Company (or subcontracted QSA) – not involved in designing, developing, or implementing the controls – may assess the effectiveness of the control(s) and/or the requirement(s) impacted by the control(s). The QSA Company must ensure adequate, documented, and defendable separation of duties is in place within its organization to prevent independence conflicts.

FAQ #1562

Again, this is fairly clear that QSAs providing both assessment and advisory/implementation services are not incorrect in doing so, but need to ensure that proper safeguards are in place, presumably to be checked thoroughly by their requalification requirements, under section 2.2 “Independence” of the QSA requalification document. To save you time on reading, there isn’t much prescriptive way to ensure this independence, so we’re left to how the company decides on their conflict of interest policies. Our service is to ensure with confidence that the advice you receive is indeed independent and as much as we know, to benefit the customer, not the assessor. We don’t have skin in their services.

In summary, QSAs can theoretically provide services but it should come separately from the audit, so ensure you get the right understanding before starting off your PCI journey. Furthermore and more concerningly, we’ve seen QSAs refused to validate the scope provided to them, citing that this constitute ‘consulting and advisory’ and needs additional payment. This is literally the first task a QSA does in their list of responsibility, so call them out on it or call us in and let us deal with them. These charlatans shouldn’t even be QSAs in the first place if this is what they are saying.

And finally, speaking on QSAs that are worth their salt – the primary one we often work with Controlcase has been included in the PCI SSC Global Executive Assessor Roundtable 2024 (GEAR 2024).

https://www.pcisecuritystandards.org/about_us/global_executive_assessor_roundtable/

These are nominated as an Executive Committee level advisory board comprising senior executives from PCI SSC assessor companies, that serves as a direct channel for communication between the senior leadership of payment security assessors and PCI SSC senior leadership.

In other words, if you want to know who the SSC looks to for PCI input, these are the guys. Personally, especially for complex level 1 certification, this would be the first group of QSAs I would start considering before approaching others, as these are nominated based on reputation, endeavor and commitment to the security standards — not companies that cough out money to sponsor events or conferences, or look prominent in their dazzling booths, give free gifts but is ultimately unable to deliver their projects properly to their clients.

Let us know via email to pcidss@pkfmalaysia.com if you have any queries on PCI-DSS, especially the new version 4.0 or any other compliances such as ISO27001, NIST, RMIT etc!

Zero Trust for 2024

January 3, 2024 / / 0 Comments

As we enter into the new year, lets start off with a topic that most cybersecurity denizens would have heard of and let’s clarify it a little.

Zero Trust.

It seems a good place as any, to start 2024 off with the pessimism that accompanied the end of last year – the spate of cybersecurity attacks in 2023 had given us a taste of what is to come – insurance company – check, social security – check, the app with our vaccination information – check. While breaking down the attacks is meant for another article, what we are approaching now for the coming year is not just more of the same, but much more and more advanced attacks are bound to happen.

While Zero Trust is simply a concept – one of many – to increase resistance to attacks or breach, it’s by no means a silver bullet. There is NO silver bullet to this. We are in a constant siege of information warfare and the constant need to balance the need for sharing and the need for protection. It is as they say; the safest place would be in a cave. But that’s now living, that’s surviving. If you need to go somewhere, you need to fly, you have information with the airlines. If you need to do banking, you have information with the banks. If you need to conduct your daily shopping online, you are entrusting these guys like Lazada et al the information that otherwise you may not likely provide.

So Zero Trust isn’t the fact that you conduct zero transaction, its basically a simple principle: Trust no one, Verify everything. Compare it to the more traditional “trust but verify” approach, which assumed that everything inside an organisation’s network should be trusted, even if we do have verifications of it. Here’s a breakdown of the concept, in hopefully simpler terms.

The Basic Premise: Imagine a company as a fortified castle. In the old days, once you were inside the castle walls, it was assumed you belonged there and could roam freely. At least this is based on the limited studies we have done by binge watching Game of Thrones. All historical facts of the middle ages can be verified through Game of Thrones, including the correct anatomy of a dragon.

Back to the analogy, what if an enemy disguised as a friend managed to get inside? They would potentially have access to everything. Zero Trust Architecture operates on the assumption that threats can exist both outside and inside the walls. Therefore, it verifies everyone’s identity and privileges, no matter where they are, before granting access to the castle’s resources. The 3 keys you can remember can be:

  1. Never Trust, Always Verify: Zero Trust means no implicit trust is granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned). Basically, we are saying, I don’t care where you are or who you are, you are not having access to this system until I can verify who you are.
  2. Least Privilege Access: Individuals or systems are given the minimum levels of access — or permissions — needed to perform their tasks. This limits the potential damage from incidents such as breaches or employee mistakes. We see this issue a lot, whereby a C level person insist on having access to everything even if he doesn’t necessarily know how to navigate a system without a mouse. When asked why, they say, well, because I am the boss. No. In Zero Trust, in fact, because you are the boss, you shouldn’t have access into a system that does not require your meddling. Get more sales and let the tech guys do their job!
  3. Micro-Segmentation: The network is broken into smaller zones to maintain separate access for separate parts of the network. If a hacker breaches one segment, they won’t have access to the entire network.

The steps you can follow to implement the concept of Zero Trust:

Identify Sensitive Data: Know where your critical data is stored and who has access to it. You can’t protect everything. Or at least not with the budget you are given, which for most IT groups, usually is slightly more than they allocate to upkeep the company’s cat. So data identification is a must-have. Find out what is the data that you most want to protect and spend your shoe-string budget to protect it!

Verify Identity Rigorously: Use multi-factor authentication (MFA) and identity verification for anyone trying to access resources, especially important resources like logging systems, firewalls, external webservers etc. This could mean something you know (password), something you have (a smartphone or token), or something you are (biometrics). It used to cost a mortgage to implement things like this but over the years, cheaper solutions which are just as good are now available.

Contextual Access: Access decisions should consider the context. For example, accessing sensitive data from a company laptop in the office might be okay, but trying to access the same data from a personal device in a coffee shop might not be. This may not be easy, because now with mobile devices, you are basically accessing top secret information via the same device that you watch the cat playing the piano. Its a nightmare for IT security – but again, this has to have discipline. If you honestly need to access the server from Starbucks , then implement key controls like MFA, VPN, layered security and from a locked-down system.

Inspect and Log Traffic: Continuously monitor and log traffic for suspicious activity. If something unusual is detected, access can be automatically restricted. SOAR and SIEM products have advanced considerably over the years and today we have many solutions that do not require you to sell a kidney to use. This is beneficial as small companies are usually targeted for attacks, especially if these smaller companies services larger companies.

At the end, it all comes down to what are the benefits to adopt this approach.

Enhanced Security: By verifying everything, Zero Trust minimizes the chances of unauthorised access, thereby enhancing overall security. Hopefully. Of course, we may still have those authorised but have malicious intent, which would be much harder to protect from.

Data Protection: Sensitive data is better protected when access is tightly controlled and monitored. This equates to less quarter given to threat players out there.

Adaptability: Zero Trust is not tied to any one technology or platform and can adapt to the changing IT environment and emerging threats.

On the downside, there are still some challenges we need to surmount:

Complexity: Implementing Zero Trust can be complex, requiring changes in technology and culture. It’s not a single product but a security strategy that might involve various tools and technologies. This is not just a technical challenge as well, but a process and cultural change that may take time to adapt to.

User Experience: If not implemented thoughtfully, Zero Trust can lead to a cumbersome user experience with repeated authentication requests and restricted access. This is a problem we see a lot, especially in finance and insurance – user experience is key – but efficiency and security are like oil and water. Eternal enemies. Vader and Skywalker. Lex and Supes. United and Liverpool. Pineapple and Pizza.

Continuous Monitoring: Zero Trust requires continuous monitoring and adjustment of security policies and systems, which can be resource-intensive. We’ve seen implementation of SIEM and SOAR products which are basically producing so many alerts and alarms that it makes no sense anymore. These all become noise and the effects of monitoring is diluted.

In summary, an era where cyber threats are increasingly sophisticated and insiders can pose as much of a threat as external attackers, Zero Trust Architecture offers a robust framework for protecting an organisation’s critical assets. It’s about making our security proactive rather than reactive and ensuring that the right people have the right access at the right times, and under the right conditions. It’s culturally difficult, especially in Malaysia, where I will have to admit, our innate trust of people and our sense of bringing up means we always almost would open the door for the guy behind us to walk in, especially if he is dressed like the boss. We hardly would turn around and ask, “Who are you?” because we are such nice people in this country.

But, adopt we must. For any organisation looking to bolster its cybersecurity posture, Zero Trust isn’t just an option; it’s becoming a necessity. In PKF we have several services and products promoting Zero Trust – contact us at avantedge@pkfmalaysia.com and find out more. Happy New Year!

Hardening Checklist

August 7, 2021 / / 0 Comments

Picture from https://guardiansafeandvault.com/

Requirement 2.2 has been often deliberated by customers undergoing PCI-DSS. To recap, the requirement states:

Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
Sources of industry-accepted system hardening standards may include, but are not limited to:
• Center for Internet Security (CIS)
• International Organization for Standardization (ISO)
• SysAdmin Audit Network Security (SANS) Institute
• National Institute of Standards Technology (NIST).

Requirement 2.2

So often, customers go ahead and download the CIS hardening documents at https://www.cisecurity.org/cis-benchmarks/ and copy lock stock and barrel into their policies and send it in. Now all this may be well and good, but now you have around 1,200 page tome with guidelines like 14 character alphanumeric password, as opposed to what PCI requires (7 Alphanumeric). This is where our customers get stuck, and some even send in a 1000 page hardening document to us to review, only for us to find that they have not implemented even 1% of what is noted in their hardening document.

After that, the hardening documents get re-jigged again until it meets a reasonable, practical standard that is implementable, usually in the form of a checklist. For a very quick hardening checklist, this is the initial one we often end up using, just to get our clients up to baseline speed, whether it’s PCI or not:

Hardening ItemServersNetwork DevicesDatabases
Assign individual server for each critical role (App, Web, DB, AD, AV, Patching etc)YNAY
Disable/Rename/Remove default user accountsYYY
Assign role based access to usersYYY
Disable insesure or unnecessary servicesYYNA
Use Secure Versions of Remote Access Services (SSH, RDP over SSL)YYY
Install well known Anti Virus with latest signaturesYNANA
Install latest OS / Firmware / Software security patchesYYY
Disable inactive users automatically after 90 daysYYY
Ensure Following Password Policies –
1. Use Complex Password with 7 characters or more
2. Remember minimum last 4 Passwords
3. Require passsword change within 90 days
4. Require password change upon password reset and first logon		YYY
Ensure following account policies –
1. Account lockout threshold – Max 6 attempts
2. Account lockdout duration – 30 mins or until admin unlocks
3. Idle Session Timeout – 15 Mins or less		YYY
Ensure passwords are stored securely with encryptionYYY
Enable Audit logging to Capture at minimum following events –
1. Successful Login
2. Failed Login
3. Administrative Actions
4. User Creation
5. User Deletion
6. User Updates
7. Escalation of Privileges
8. Access to Audit Trails
9. Initialization or stopping auditing		YYY
Configure NTP and time syncronizationYYY
Implement File Integrity Monitoring`YYY

Now obviously this doesn’t cover all the requirements of PCI (testing, scans, retention etc) but this should give us a fair idea of how ready our systems are for an audit or assessment.

If you have any queries on PCI or ISMS or any other security related standard, drop us a message at avantedge@pkfmalaysia.com.

PCI Delta Assessments

July 16, 2021 / / 0 Comments
pci-compliance

Let’s start off by saying this isn’t a way for us to make light of the current situation by using the word ‘Delta’ here. We all know how dangerous and virulent the current strain of COVID is and this isn’t a matter of writing an article simply to get a search hit on that word.

That being said, this is a topic that seemed a bit obscure, even to us who have been doing PCI-DSS for more than a decade now.

So the question that can sometimes pop up would be: Great, we got our PCI-DSS certification now, everyone is celebrating and patting each other on the back. In 2 weeks time after our AoC/RoC has been produced, our product management rolls out a new Application XYZ which deals with credit card information along with a new environment, database, systems etc. Is this Application XYZ included in our current PCI-DSS certification or not?

It’s a good question. Because the fact is that many view PCI-DSS as a point in time audit, whereby the audit is done at a certain time and not over a period of time. One might argue that during the audit itself, sampling will be done over a 12 month period, therefore it cannot be categorised as a strictly point in time assessment. Regardless how you categorise it, at the end of the audit, there is the big result: a compliant AoC/RoC pair. Don’t get us started on the dreaded Certificate of Compliance or CoC, or CoC-n-Bull in our terms. Enough of that certificate nonsense. As for the AoC/RoC pair, the scope is stated clearly in it, defining the audit scope, the boundaries, the applications scoped in, locations etc. So this is great. When we get a new application onboard, we just add in that application into the AoC, right?

Right?

Unfortunately, at this point, the QSA will say, not really. Once the AoC is out, it’s out. Unless you want to re-do the audit or to recertify, then yes, that new application can be added in.

Now, we’ve faced such a situation before. And in fact PCI-DSS addresses it nicely at this wonderful piece of work: https://www.pcisecuritystandards.org/documents/PCI_DSS_V2.0_Best_Practices_for_Maintaining_PCI_DSS_Compliance.pdf

In item 3.10.3 it states:

Any change to the network architecture or infrastructures directly related to or supporting the CDE should be reviewed prior to implementation. Examples of such changes include, but are not limited to, the deployment of new systems or applications, changes in system or network configurations, and changes in overall system topologies.

PCI reminding us to stay focus!

So in this case, application XYZ falls under new application. The point of PCI-DSS is that, just because you deploy a new thing or new firewall or new application doesn’t mean you are no longer compliant to PCI-DSS. After all, PCI encompass the practice and process as well, so the council understands and advice that these changes be implemented into the PCI program and PCI processes ensures that this stays compliant. So in short, if you have application XYZ coming in, make sure the PCI controls apply to it and it will then be reviewed under the next audit and included into the PCI AoC of the coming year. Let’s just update the current Aoc and we all go home now, right?

Right?

But wait, you aren’t listening, says the auditor, you still can’t update the current AoC. The AoC is already fixed for that year, unless you want to do an audit. Again. Like a month after you have done and dusted your recertification audit for that year.

In most cases, these changes for our clients go through the maintenance cycle without and issue and the following AoC simply gets updated to include it. But what if the customer insist on having the CURRENT AoC updated? This could be due to requirements from their client, regulatory or what not. How do we put that application into the current AoC without spinning off the whole audit all over again?

In short, you can’t. You either wait it out for the next year audit OR you re-do your certification audit and nullify the previous one. However, this is where that little obscurity comes in. Delta assessment.

Now I’ve heard of Delta assessment for PCI, but it’s almost invariably related to PA-DSS (SSF now), PCI PTS, P2PE where basically, vendors who had completed, let’s say their SSF, can validate low risk changes to their application and do a delta assessment. In PTS, the delta is done by the PTS Lab, but for SSF, the SLC vendor can basically do a self attestation. However, we don’t see any such item or recourse for PCI-DSS.

Discussing with the auditors, we find that indeed, there are possibilities of a delta assessment to be done, although rare, and not exactly cost effective, since whatever the delta is doing, it’s would just have a short lifespan before the changes get swallowed up by the main PCI program once the yearly audit cycle rolls in. That’s why we rarely see this done. But I rarely see a tapir doing a jig in a tutu, but that doesn’t mean it doesn’t exist.

So what happens is that the auditor will formally audit this application and its environment and go through the certification process as would normally be done – except that this is limited to the application and systems. Once assessed, a formal delta AoC/Roc pair is released to supplement the existing AoC/RoC pair. And so that’s it, these supplement documents can then be shown together with the current AoC/Roc for verification purpose and in the next cycle, it’s consolidated back into the main RoC.

Now, this is fairly new to us. The logic of it is still beyond us somewhat because the whole point of PCI is for an environment to be able to handle changes and not have it audited everytime there is a significant change that occurs. Because every audit is costly and I’m sure every organisation has already got its hands full trying to sort out budgets during these times, without worrying about delta assessments.

The above is basically what we gather from discussions with auditor and not really from experience, because at the end, once the proposal was put out, our client thought better of it and decided not to pursue. So really, it’s still in the realms of theory and we may not be accurate in our assumptions. However, it’s still something interesting to keep in mind, though rare – like the tapir in tutu – it helps to know that this option does possibly exist.

Drop us a note at pcidss@pkfmalaysia.com and we will try to address all your concerns on PCI or other compliance matters like ISO27001, ISO20000 etc!

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!

© 2024 PKF AvantEdge

— Up ↑