Category: PCI-DSS (Page 1 of 20)

Why QSAs Matter in your PCI-DSS

The questions we usually get asked, aside from why we prefer not to be a QSA (which, although it is fairly dated and need to be revised, have been answered), despite us doing PCI-DSS since 2012 in Malaysia, is why we hardly work with different QSAs in our PCI-DSS projects. Aren’t all QSAs the same? Aren’t all created equal?

Like everything in life, there are basis of variation. We are not here to say which is better, which is worse. It’s not in our culture to constantly provide a barrage of negative statements in regards to other companies and organizations, even with basis — because that’s not how we are wired.

That being said, we do have an internal list of companies (and QSAs) that we would perhaps have some less inclination to. This is due to either working firsthand with them, or mainly seeing some of the results of their work. Quite shocking some of the things we see. Additionally, we have also had clients who had suffered under their so called advisory and have asked us to step in for help.

So to the query on which QSA should you spend the next six months (or more) months with for your PCI Project? Let’s put a few options forward in a more quantifiable manner.

a) Experience

A question we get asked is why we generally don’t just work with local providers or assessors who are closer to home. It’s not because they are worse or better. It’s like comparing cars. They all have their pros and cons – we do not slag organizations off even if we would rather avoid some of them. But one way I would tell customers is, let’s look at experience first.

As of writing, we have 3065 PCI-DSS listed projects based on the Visa Provier List at The top 10 assessors on this list is as follows:

ControlCase 113
Compliance Control96
Coalfire Systems86
atsec 71

The top 10 assessors make up almost 35% of the projects listed. Those are heavy hitters. Suffice to say a lot of projects remain unlisted – level 2 Service providers, SAQ projects, Merchant projects etc. So actual projects (included non listed) for each assessor is probably a lot higher. To put in context, there are the following numbers of projects for assessors:

ProjectsNumber of Assessors

There are 200 Assessors out there with 10 or less projects listed. In defence, some of these are actually the same company under another name, so it’s not like 100% accurate in terms of this overview. So out of 262 assessors in that list that does PCI, 77% of them have 10 or less projects, showing that it’s not that easy to get that number to a 100 or more. Again I will reiterate, quantity doesn’t automatically means it’s better. Some may argue, the more projects you have, the more quality is suffered. That is a good point. And I have experience with some of the overseas QSAs in that smaller project number group that I would gladly give a project and have a beer with. They are really good and extremely passionate about PCI-DSS and I’ve learnt truckloads from them. We are just saying this is one starting indicator you may want to jump from because most service providers start off with this off the bat when they are presenting their services: how many customers ‘trust’ them.

b) Location

This is slightly misleading in a sense that the query we ask is: do we need a QSA who is local? Local here would mean they have an office in the country they are serving the customer in. This argument, while it seems to initial hold some credence, is actually self defeating. And a bit strange, when most organisations now prefer to be known as regional or global, instead of touting themselves as just local players. If they use this as a plus point, then by going to their overseas customers, they are technically disputing the same argument point they are advocating. Most QSAs won’t use this track because they know that a QSA company needs to at the very least operate regionally, or if you want to be focused on a country – then, fine, take USA. The reason why the service provider list does not have a breakdown of all 195 countries (or if you are a Malaysian Minister, then that would be 500 countries) of Earth is that being a QSA is tough work. The breakdown is in regions and the only countries listed there are US and Canada because US makes up almost 35% of the listed projects there.

Think about the last time you dealt with a QSA. Did you have access to that QSA through messages or call? Did you call for a meeting and that QSA came as required? Did that QSA respond quicker? Was that QSA able to reply your queries, technical or otherwise related to your compliance in clear and consistent manner? Did they insist on you paying them more for advisory or delayed your project? Did they upsell more services to you that was unplanned and unknown? Think about the positives and negative experience you had.

Those are more pertinent queries than deciding someone to be ‘local’. That point is actually really moot. Because in almost all projects, the bulk of the work will be handled by a consultant. QSAs by definition should be global or regional anyway. In the economics of being a QSA (explored in another article), being a QSA operating in a single country would probably not be cost sustainable. Especially in a country where the currency is slightly more than the value of a turnip. So the assessor will still have to be flying to other places anyway. Therefore, it doesn’t really matter whether its local, regional or global when it comes to being an assessor, the question is how accessible and communicable they are.

In that sense, we strike a balance – we are local to Malaysia, or any other country that we operate in (we have presence in 150 countries as a global network), and we provide the independent, technical advisory needed to be consultants. We are not QSAs so we don’t need to be pulled all over the place in other PCI projects all over helter-skelter. We are all certified in various certifications and more product certs that I can throw a stone at. We are operational people all with more than a decade of experience so you won’t have a wide-eyed associate with a checklist coming to you. We also have non-IT services as we are also tax advisors, corporate financiers, risk managers, compliance directors – we aren’t just an IT company aiming to push IT services or cybersecurity solutions for you – our DNA is in advisory and consulting.

Enough of blowing our own horn then. Which leads me to item 3:

c) Reference

It’s important to not just look at a list of customers. I have a client who gets annoyed with seeing a presentation with a list of logos without any context of the work. Some may list down large companies or merchants under their so called ‘Customer’ but without any context. You know what? Fine. I can list down all telcos, up to twenty PLCs, more than half a dozen of oil and gas and more banks than I can swing a bat at just because I have given them ‘training’. Come on.

Look past that veneer and look at actual references in the industry. Is there a positive experience? Is there someone out there willing to endorse good will? Are there any bad experiences? Another area I got asked is, if the assessor has been involved in a breach before. This almost needs a new article to explore. Look, we all know PCI doesn’t guarantee non-breach. It’s not a panacea to world hunger. Its more important to note that what is the outcome of the investigation or forensics before we go witch hunting. It’s meaningless to state for instance, the top QSAs would never experience any breaches in their existence. For sure, some of them would need to deal with this one way or another and to see if indeed there was an oversight. If there’s none, then the breach could be down to myriad of reasons outside of PCI-DSS control. Remember – assessors are not operational. They enter an audit in good faith. Witchunting a QSA just because of a breach involvement without context or having the final conclusion is a narrow minded, irresponsible approach to assessing capability (or culpability). If the QSA is truly to blame, wouldn’t they be put in remediation by the Council? There you go.

One thing you will never catch us doing is giving an opinion about certain things that we don’t have the full context on. It’s simply not something we are comfortable at. If we see some issue with a report from other QSAs, even if it looks strange, the reply is always: what is the context of this, and there must be a reason why it was interpreted as such. So that gives us a more balanced view and not just mouth off without understanding. As the proverbs say: “The more talk, the less truth; the wise measure their words. “

d) Cost and Resources

Most PCI projects have the conflicting pull of cost and resources. A QSA with a lot of resources and consultants will be very useful. The last thing you want to see is a QSA not responding and after 3 months rushes you for evidences. Cost still plays a huge role in PCI-DSS and it’s not as if things are getting cheaper. With version 4.0, there is more work for QSAs to do and they likely will pass down some of these costs to the customers. This still remains a very subjective item in this filtering exercise — a QSA charging your liver and kidney for PCI isn’t ideal, but if a QSA comes in with a price that resembles a popsicle in a flea market, I would likely stay away as well. We all know how much effort PCI is. We don’t want a situation where halfway through, the bulk of invisible costs comes pouring in like the army of Mordor, or else things will not be done. If you want to build your house, have most of the materials cost sorted out. If there is a VO, don’t let it cross a threshold of percentage of your initial cost. Having a QSA who understands this and is willing to negotiate is important. Even if the cost is not lowered (because to be fair, QSA work is not trivial), then negotiate for future services, or better payment terms – anything else to meet in the middle.

e) Stamp of Trust

Are there any stamps of trust for QSAs?

No, there isn’t. At least not officially. However, I would like to highlight there is this thing called Global Executive Assessor Roundtable (GEAR) found here:

There are 28 QSAs in the GEAR currently, with the purpose below:

The Roundtable is an Executive Committee level advisory board comprised of senior executives from PCI SSC assessor companies. The 2022-2024 GEAR consists of 28 organizations, with the Roundtable term running 1 September 2022 – 31 August 2024.

“The Council depends on the input of a wide range of stakeholders to provide PCI SSC with valuable insights,” said PCI SSC Executive Director Lance J. Johnson.” With the release of version 4.0 of our PCI Data Security Standard this year, it is even more important to have active representation from every corner of the globe from an assessor perspective. Assessors are critical in assisting the Council with our effort to improve and evolve payment data security.”


The QSA we often work with, Controlcase is one of them, and have been reappointed, pointing out that in terms of reference, the Council considers their input as ‘valuable insights’. This is one of the list we look at, especially when requested about QSAs. Are they involved in GEAR?


Like choosing a car, there is really no guarantees actually that your experience will be immaculate when it comes to PCI-DSS considerations. The above are just possible filters you can decide on when it comes to choosing your next QSA partner to embark your journey on. Or you can roll a dice or consult with the gods. Disclaimer of course is that we have not worked with ALL QSAs yet, so this still remains a rudimentary filter when you are thinking of a QSA. Find a QSA that can actually do the hard yards and have proven themselves with Project references and quality, Global Reach and experience, Positive Customer feedback and respect from the industry and finally, seen as an invaluable assistant to the almighty PCI Council themselves. In our personal opinion, it’s a start to look at these metrics and springboard from there. Because anyone can give a nice presentation or dress in a suit or talk negatively about other companies — but what are their numbers, references and contribution to the PCI council?

Drop us an email at to learn more about PCI and other compliances like ISMS or ITSM or SOC!

The Question of QSA Conflict

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


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).

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 if you have any queries on PCI-DSS, especially the new version 4.0 or any other compliances such as ISO27001, NIST, RMIT etc!

Major Changes of PCI v4

So now as we approach the final throes of PCI-DSS v3.2.1, the remaining 3 weeks is all that is left of this venerable standard before we say farewell once and for all.

PCI-DSS V4.0 is a relative youngster and we are already doing hours of updates with our customers on the things they need to prepare for. Don’t underestimate v4.0! While its not a time to panic, it’s also not a time to just lie back and think that v4.0 is not significant. It is.

Below is a table that provides an insight of the major changes we are facing in v4.0.

Bearing in mind that most of the requirements now start off with keeping policies updated and document roles and responsibilities, the major changes are worth a little bit of focus. In the next series of articles, we will go through each one as thoroughly as we can and try to understand the context in which it exists on.

Let’s start off the one on the top bin. Requirement 3.4.2.

Req. 3.4.2: When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel, except for those with documented, explicit authorization and a legitimate, defined business need

PCI v4.0

Ok, we have underlined and emphasized a few key points in this statement. Because we feel that is important. Let’s start with what 3.4.2 applies to.

It applies to: Remote Access

It requires: Technical Controls


Of the subject matter: Full Primary Account Number

In v3.2.1 this was found in section 12.3.10 with slightly different wordings.

Req 12.3.10 For personnel accessing cardholder data via remote-access technologies, prohibit the copying, moving, and storage of cardholder data onto local hard drives and removable electronic media, unless explicitly authorized for a defined business need. Where there is an authorized business need, the usage policies must require the data be protected in accordance with all applicable PCI DSS Requirements.

PCI v3.2.1

I think 4.0, aside from the relocation of the requirement to the more relevant requirement 3 (as opposed to requirement 12, which we call the homeless requirement for any controls that don’t seem to fall into any other earlier requirements), reads better. Firstly, putting it in requirement 3 puts the onus on the reader to consider this as part of protection of storage of account data which is the point of Requirement 3. Furthermore, digging into the sub-requirement, 3.4 section header states: Access to displays of full PAN and ability to copy PAN is restricted.

This is the context of it, where we find the child of this 3.4 section called 3.4.2 and we need to understand it first, before we go out and start shopping for the first DLP system on the market and yell out “WE ARE COMPLIANT!”

3.4 talks about displays of FULL PAN. So we aren’t talking about truncated, or encrypted PAN here. So in theory, if you copy out a truncated PAN or encrypted PAN, you shouldn’t trigger 3.4.2. Its specific to full PAN. While we are at it, we aren’t even talking about cardholder data. A PAN is part of cardholder data, while not all cardholder data is PAN. Like the Hulk is part of the Avengers but not all Avengers are the Hulk. So if you want to copy the cardholder name or expiration date for whatever reasons like data analysis, behavioural prediction, stalking etc…this isn’t the requirement you are looking for.

Perhaps this is a good time to remind ourselves what is Account Data, Card Holder Data and Sensitive Authentication Data (SAD).

The previous v3.2.1 doesn’t actually state ‘technical controls’, which goes to say that if it’s a documentary controls, or a policy control, or something in the Acceptable Use Policy, it can also pass off as compliant. V4.0 removes that ambiguity. Of course, the policy should be there, but technical controls are specific. It has to be technical. It can’t be, oh wait, I have a nice paragraph in section 145.54(d)(i)(iii)(ab)(2.4601) in my information security acceptance document that stated this!

So these technical control(s) must PREVENT copying and relocation. Firstly just to be clear, copy is Ctrl-C and Ctrl-V somewhere else. Relocation is Ctrl-X and Ctrl-V somewhere else. Both has its problem. In copying, we will end up PAN having multiple locations of existence. In relocation, the PAN is moved, and now systems accessing the previous location will throw up an error – causing system integrity and performance issues. Suffice to say, v4.0 demands the prevention of both happening to PAN. Unless you have a need that is:





When a business need is both “documented” and “defined,” it means that the requirement has been both precisely articulated (defined) and recorded in an official capacity (documented). So a list of people with access is needed for the who, why they legitimately need to access/copy/relocate PAN in terms of their business, explicitly authorized by proper authority (not themselves, obviously).

Finally, let’s talk about technical controls. Now, remember, this applies to REMOTE ACCESS. I’ve heard of clients who says, hey no worries, we have logging and monitoring in place for internal users. Or we have web application firewall in place. Or we have cloudflare in place. Or we have a thermonuclear rocket in place to release in case we get attacked. This control already implies ‘remote access’ into the environment. The users have passed the perimeter. It implies they are already trusted personnel, or contractors or service providers with properly authorized REMOTE ACCESS. Also, note that the authorization here is NOT for remote access, it is for the explicit action of copy/relocating PAN. In this case, most people would probably not have a business reason of copying/relocating PAN to their own systems unless for very specific business flow requirements. This means, only very few people in your organization should have this applied to them, under very specific circumstances. An actual real life example would be for an insurance client we have, they had to copy all transaction information, including card details in an encrypted format and put it into a removable media (like a CD-ROM) and then send it over to the Ombudsman for Financial Services as part of a regulatory requirement. That’s pretty specific.

So what passess off as a ‘technical control’? A Technical control may be as simple as to completely prevent copy/paste or cut/paste ability when accessing via remote access. This can be done in RDP or disable clipboard via SSLVPN. While I am not the most expert product specialist in remote access technologies, I can venture to say its fairly common to have these controls inbuilt into the remote access product. So, there may not be a need for DLP in that sense, as the goal here is to prevent the copying and relocation of PAN.

Now that being said, an umbrella disallow of copy and paste may not go well with some suits or C-levels who want to copy stuff to their drive to work while they are in the Bahamas. Of course. You could provide certain granular controls, depending on your VPN product or which part of the network they access. If a granular control cannot be agreed on, then a possible way is to enforce proper control via DLP (Data Loss Prevention) in endpoint protection. Or control access to CDE/PAN via a hardened jump server that has local policy locked down. So the general VPN into company resources may be more lax, but the moment access to PAN is required, 3.4.2 technical controls come in play.

At the end, how you justify your technical controls could be through a myriad of ways. The importance is of course, cost and efficiency. It has to make cost sense and it must not require your users to jump through hoops like a circus monkey.

So there you have it, a break down of 3.4.2. We are hopping into the next one in the next article so stay tuned. If you have any queries on PCI-DSS v4.0 or other related cybersecurity needs, be it SOC1 or 2, ISO27001, ISO20000, NIST or whether Apollo 11 really landed on the moon in 1969, drop us a note at and we will get back to you!

What the FIM is going on

If you have been doing PCI-DSS for some years, you have probably come across this term called FIM (File Integrity Montioring), which sometimes absolutely befuddles our customers. They generally think this is part of a wider SIEM or SOAR solution but not necessarily so. We’ll explore a little on why FIM is important, how it impacts PCI-DSS, some examples on configuration and what alternatives are there (if any). Here we go!

File Integrity Monitoring is the process of validating the integrity of operating system and application software files. It ensures that files have not been altered or compromised, whether maliciously or accidentally.

  1. Detecting Unauthorized Changes: FIM helps in detecting unauthorized changes to critical system files, configurations, and content files. These changes could be indicative of a breach, malware infection, or insider threat.
  2. Compliance Requirements: Many regulatory standards, such as PCI-DSS, HIPAA, and SOX, require FIM as part of their compliance criteria. It ensures that sensitive data is protected and that the integrity of the system is maintained.
  3. Preventing Data Breaches: By monitoring file changes, FIM can provide early warning signs of a potential data breach. It allows organizations to take proactive measures to prevent unauthorized access to sensitive information.
  4. Enhancing Forensic Analysis: FIM provides detailed logs of file changes, aiding in forensic analysis. It helps in understanding the nature of an attack, the affected files, and the potential impact.

Let’s pause for now and see if common Antivirus/antimalware can take over this compliance requirement without deploying a specific FIM. Why? Because all companies generally have some sort of anti-virus running in their systems and all companies are stingy in their compliance spending, so part of our job is to see if current technology can be sufficient to address compliance requirements. The difference between Anti virus and FIM boils down to the reason of their existence, their meaning to life and everything. Its 42!

While FIM focuses on monitoring the integrity of files, antivirus and antimalware solutions are designed to detect and remove malicious software.

  • Antivirus: Primarily targets known viruses and relies on signature-based detection. It may not detect unauthorized changes to files unless they are associated with a known virus signature.
  • Antimalware: Broader in scope, antimalware solutions target various malicious software, including viruses, spyware, and ransomware. Like antivirus, it may not detect subtle unauthorized file changes.

FIM complements these solutions by providing an additional layer of security, focusing on the integrity of files rather than just malicious content.

FIM also differs from Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) solutions. That being said, its common that these systems are bundled along with FIM solutions so while it’s possible that SIEM may have FIM, it might not be true that FIM has SIEM. They are like, maybe a dysfunctional family who sometimes get together over Chinese New Year reunions.

  • SIEM: SIEM solutions collect and analyze log data from various sources to provide real-time analysis of security alerts. While SIEM can include FIM as a component, it encompasses a broader range of security monitoring functions.
  • SOAR: SOAR solutions focus on automating and orchestrating security operations. They help in coordinating various security tools and processes. Unlike FIM, which is more focused on file integrity, SOAR aims to streamline security operations and response.

FIM makes its appearance in PCI-DSS v4.0 in requirement 10, specifically 10.2, 10.3,10.4,10.5,10.7 and further on in 11.5, 12.10 and A3.5.1.

In 10.2, PCI basically wants FIM to be part of the logging requirements in terms of what to capture, retention, response and so on. Make sure your FIM is configured to monitor the critical files, and the details of the FIM logs has user and process details, who is responsible for the change event and captured in real time. Ensure alerts are generated for change events by privileged accounts which can be further correlated to create an automated incident. Also, make sure changes to log file security settings or removal of log files triggers real time alerts, with exhaustive event details. All creation and deletion activities are captured as well, and all event details must be as per 10.2.2 for the FIM log files.

10.3.4 makes specific mention of FIM but there is some confusion to this requirement ” File integrity monitoring or change-detection mechanisms is used on audit logs to ensure that existing log data cannot be changed without generating alerts. “. Obviously if you try to monitor for changes in a log file and alert everytime that file is changed, your SIEM or SOAR will light up like Christmas. Because of the nature of log files, it is supposed to change! So to avoid the noise, ensure log files are monitored for changes in security settings, like permissions or ownership. If a log file is deleted, that is also an anomaly. And for those logs that are archived or digitally signed, if any changes are made to these, then your FIM should be able to detect it.

Requirement 11 doesn’t change much for V4.0 — it is the main portion for FIM in 11.5.2 and it remains pretty much the same. Requirement 12.10.5 does provide an explicit requirement to include FIM alerts into incident management and response. But you know that already, right?

There are plenty of FIM solutions out there. The common ones we see is OSSEC which is deployed together with Alienvault previously. Tripwire is also a well known name in the FIM arena. If you want to explore the inbuilt Linux version of FIM, auditd might be worth your time. For those unfamiliar with auditd, it’s a component that provides auditing functionality for the Linux kernel. It’s widely used for security monitoring, system troubleshooting, and compliance reporting. Configuring auditd might be intimidating to some at first, but here’s some rules to get you started, found in this link

In summary, it covers the following areas (config has been omitted in this article, you can go to the site to get the details)

  1. User Access Linking (10.1): Implicitly met by the audit system.
  2. User Access to Cardholder Data (10.2.1): Requires a watch on the database, excluding daemon access. (Path to the database must be specified.)
  3. Logging Administrative Actions (10.2.2): Enable tty logging for su and sudo. Special cases for systemd-run and pkexec are included.
  4. Monitoring Privilege Escalation Configuration (10.2.2): Watches changes to /etc/sudoers and /etc/sudoers.d/.
  5. Access to Audit Trails (10.2.3): Monitors access to /var/log/audit/ and specific audit commands.
  6. Invalid Logical Access Attempts (10.2.4): Naturally met by PAM.
  7. Logging of Identification & Authentication (I&A) Mechanisms (10.2.5.a): Handled by PAM.
  8. Logging of Privilege Elevation (10.2.5.b): Monitors specific syscalls related to privilege elevation.
  9. Logging Account Changes (10.2.5.c): Watches changes to account-related files like /etc/group, /etc/passwd, etc.
  10. Time Data Protection (10.4.2b): Places rules to check time synchronization.
  11. Securing Audit Trails (10.5): Includes various measures to protect audit logs, limit viewing, prevent unauthorized modifications, back up files, and monitor log modifications.

So, there you go. Lastly, though since PCI v4.0 came out, the council seem to have made distinction of change detection mechanisms vs File integrity monitoring, stating that FIM is part of CDM, sort of like a subset. I suppose this gives a little more leeway for companies to implement other types of CDM other than FIM, although FIM is probably the only one that can address all the above requirements comprehensively and without any need for compensating controls. But just for some ideas, the below may be a list of other CDMs that can possibly address the FIM functionalities in part, automated or manual:

  1. Version Control Systems: These systems track changes to files and code within a development environment. They allow developers to see what was changed, who changed it, and why. Tools like Git, Subversion, and Mercurial are examples of version control systems that provide change detection.
  2. Database Monitoring Tools: These tools monitor changes to database schemas, configurations, and content. They can alert administrators to unauthorized alterations, additions, or deletions within the database. Tools like Redgate SQL Monitor or Oracle Audit Vault are examples.
  3. Configuration Management Tools: Configuration management tools like Ansible, Puppet, and Chef can detect changes in system configurations. They ensure that systems are consistently configured according to predefined policies and can alert administrators to unauthorized changes.
  4. Network Anomaly Detection Systems: These systems monitor network behavior and alert to changes that may indicate a security threat. They can detect changes in traffic patterns, unusual login attempts, or alterations to network configurations.
  5. Endpoint Detection and Response (EDR) Solutions: EDR solutions monitor endpoints for signs of malicious activities and changes. They can detect changes in system behavior, file activities, and registry settings, providing a broader view of potential security incidents.
  6. Log Monitoring and Analysis Tools: Tools like Splunk or LogRhythm analyze log files from various sources to detect changes in system behavior, user activities, or security settings. They can provide real-time alerts for suspicious changes.
  7. Digital Signature Verification: Some systems use digital signatures to verify the integrity of files and data. Any alteration to the digitally signed content would cause a verification failure, alerting to a potential unauthorized change.
  8. Cloud Security Tools: With the rise of cloud computing, tools like AWS Config or Azure Security Center provide change detection for cloud resources. They monitor configurations, permissions, and activities within the cloud environment.

Again, we would highly recommend that a FIM be used, but in the case where it is not possible in that environment, for instance Cloud environment, then other CDMs can be possible. If you need to know more about FIM and PCI or any compliance in general, drop us a note at and we will get back to you immediately!

An Ode to the Invalid Certificate

Once upon a time, in a not-so-faraway land of PeaCeEye, merchants, credit card transactions, online payments, payment gateways, POS terminals all lived in harmony. In this land, all citizens carry a trust symbol, held together by validation documents, called the Citizen Badge. However, PeaCeEye is now facing an existential threat. A threat shrouded in the cloak of validation, a false symbol of security and trust – called the Certificate. But, dear reader, beware! For this tale of caution and deception, and the Certificate, much like the elusive unicorn, while tangible, carries a false value – nothing more than a fabrication. A figment of imagination, conjured up by the minds of its idle creators, the Qessays.

You see, in the kingdom of PeaCeEye, there exists a council – a council of wise men and women who determine the rules and regulations that govern this realm. This council, known as the Secret Sorceror Council (SSC), has decreed that only three sacred documents hold the key to validation for the Citizen Badge – the Attestation of Compliance (AoC), the Report on Compliance (RoC), and the Self-Assessment Questionnaires (SAQs). Yet, despite the council’s resolute stance on this matter, a mysterious fourth document continues to emerge from the shadows – the Certificate.

Ah, the Certificate, a work of art crafted by the Qessays. You see, these Qessays were charged by the council to uphold what is truthful and right, and to ensure that all Citizens of PeaCeEye are identifiable by their Citizen Badges – The AoC, Roc and/or the SAQs. However, over the years, some of these noble Qessays have turned to the darkside and the sinister art of producing corrupted documentation, called the 4th deception, or the Certificate as it is now known. These dark Qessays have mastered the art of illusion, conjuring certificates out of thin air to dazzle their customers. They’ve become modern-day alchemists, turning mere paper and ink into a symbol of validation, which, in reality, is as weightless as a feather and as useful as a chocolate teapot. Or a fork and spoon when eating Chapati. It’s a thing of beauty, destined to hang on the walls of businesses, gracing them with its shimmering falsehoods.

But why do these Qessays continue to spin their webs of deception, offering their customers a document that has no merit in the eyes of the SSC? Something that even invalid citizens to PeaCeEye can procure? To unravel this mystery, we must dive into the murky depths of human nature. For, you see, people are drawn to shiny, pretty things, much like moths to a flame. A certificate, with its elegant calligraphy and embossed seal, is a testament to the allure of appearance over substance. It is a tangible representation of validation, regardless of its actual worth.

Moreover, the Certificate serves as a placebo, a sugar pill of sorts, which instills in businesses a false sense of security. It is a talisman that they cling to, convincing themselves that they are protected from the malicious forces of the World beyond PeaCeEye – the World called Cyberattacks. And, in the process, they become blind to the fact that the true power of validation lies in the sacred trio of documents – the AoC, RoC, and SAQs.

Now, one might argue that those who peddle these invalid certificates are merely fulfilling a demand. After all, the customer is always right, and if they desire a shiny piece of paper to adorn their walls, who are we to deny them? But, as the saying goes, “With great power comes great responsibility.” And these Qessays, as the gatekeepers of the citizenship of PeaCeEye, must hold themselves to a higher standard.

By offering these overvalued and useless certificates-that even the SSC had themselves admonished and had announced to the citizens to not place any value to them- these certificates not only betray the trust of customers but also undermine the very foundation of Citizen Badge. They turn the realm of PeaCeEye into a farce, a stage where pretenders masquerade as protectors, and businesses are lulled into a false sense of security. There are even Qessays who are not even involved in the process of validating an SAQ being answered; luring their customers to portals with questionnaires answered by the citizen themselves and then conjuring these certificates that look as if it has been validated by the Qessays, but instead are just self aggrandizing papers that has been only self validated by the person answering their own questions! In other words, the person becomes their own judge and jury and are able to produce a Certificate that looks as if they have been properly validated by a third-party Qessays. Amazing art! An ostentatious object of grandeur and magnificence, yet with all the actual value of a discarded banana peel withering in the Sahara sun.

But, dear reader, do not despair, for there is hope. You see, the truth has a funny way of revealing itself, much like the sun breaking through the clouds after a storm. And, as the truth about the invalidity of these Certificates spreads, businesses will begin to see through the veil of deception, and the demand for these counterfeit documents will wane. Qessays who persist in peddling these worthless certificates will find themselves exposed, their credibility crumbling like a house of cards.

In the meantime, we must not sit idly by, complacent in the face of falsehoods. Instead, we must raise our voices and spread the word, educating businesses on the true path to Citizen validation. We must sing the praises of the AoC, RoC, and SAQs, enlightening those who have been led astray by the allure of the invalid certificate. For it is only through knowledge that we can pierce the veil of deception and lay the mythical beast of the Certificate to rest.

So, let us embark on this crusade together, wielding the sword of truth and the shield of knowledge. As we march forward on this noble journey, let us remember the wise words of the SSC: “Trust, but verify.” Let us tear down the great wall of this Certificate, brick by brick, and replace it with a fortress built on the solid foundation of the council’s sacred trio of documents. And as we watch the last remnants of the Certificate crumble to dust, we will know that we have triumphed over the forces of deception.

We bid farewell to this Certificate, and to welcome a new era of transparency, security, and trust. An era where the mythical beast of the Certificate is relegated to the annals of history, and where the true power of validation is embraced, in all its glorious, council-approved forms. May the sacred trio of documents – the AoC, RoC, and SAQs – guide us on our path to a brighter, more secure future, and may the Certificate forever remain a cautionary tale of the perils of deception and the triumph of truth.*

** The above is written obviously in satire and tongue-in-cheek with absolute no journalistic value nor based on any real world reimagination and solely based on our absolute frustration at the continuous dependence and insistence from acquirers or banks to have our customers produce them ‘certificates’. In addition, some clients even go through self-service portals provided by QSAs and answer SAQ questions on their own, at the end of this process of self answering, a certificate is produced. Granted, the certificates do come with disclaimers in small prints stating that the certificate is actually based on self assessment and even admits that it isn’t recognised by the council.

But in reality, who actually reads the fine print?

In the end, anyone having gone through these ‘compliance’ portals, answering affirmative to everything would be able to procure these certificates and remarkably, some acquirers even accept them as proof of third party audit (which they are clearly NOT). Again, we are not stating that QSAs providing this service is doing anything wrong. There is nothing essentially wrong with certificates on its own, or QSAs providing these certificates as a simple means to show a company has undergone PCI-DSS compliance. But where it becomes a gray area is when there is too much dependence placed on these certificates to the point where even the AoC is rejected and acquirers insist on every company showing them these certificates. In this case, QSAs who are willing to provide so called certificates to companies without having undergone any assessment and only answering questions from the SAQ based on their own knowledge or whim – unless the QSA is willing to go through each question of each customer and validate these through evidence submission and review (the process called audit); then these creation of self signed certificates should be stopped. It’s akin to a banking website issuing a self-signed SSL cert on their own website and tell everyone to trust it. Does this happen in the world of e-commerce? No, it’s absurd. Then why is it different in the world of compliance? Why is this practice still allowed to prosper? How do we stop this practice?

We have been advocating removing certificates for years now from the PCI-DSS landscape and to have a more consistent and acceptable way to show PCI validation. Unfortunately, unlike the satirical tale above, this still eludes us. Drop us an email at if you have any ideas and comments to this!

« Older posts

© 2024 PKF AvantEdge

Up ↑