If an organization is undergoing an audit, then it could most likely be because the organization is doing it voluntarily, or because they might have been ordered to do so due to the recent incident of a data breach.
PCI DSS audit is a mandate for organizations processing, storing, and transmitting cardholder data. It is a mandate by major credit card companies, and failure to comply has dire consequences for the organization.
As a QSA having audited over 100 companies for PCI DSS, I have personally observed that only 25-30% of companies remain compliant even a year after achieving PCI DSS Compliance. Thereafter, they simply drift into complacency. Achieving compliance is one aspect, but ensuring compliance consistently every year has always been a challenge for most organizations. It is observed that once an organization achieves compliance, it neglects the process in the preceding years, eventually resulting in non-compliance and potential data breach.
In today’s article, I have listed down a few most common compliance mistakes or negligence that I observed over the years committed by organizations. These mistakes or negligence have cost a fortune for many organizations. But for the benefit of my readers I have listed the common mistakes and also suggested ways to avoid them. Read through the article and learn how your organization can stay compliant and prevent a data breach.
Common PCI Compliance mistakes or negligence
1) Annual Audits & Assessment–
Annual assessments or audit is essential in PCI compliance for every merchant, regardless of the level. It is expected that organizations conduct a regular internal audit at least once a year. However, in most cases, especially with small merchants, an audit is a consequence of a data breach and a mandate from a major credit card company or bank. Not just that, even those organizations that perform an annual audit, do not include all the technical controls and do it only for the documentation and many times by the internal team instead of external professionals just as an eyewash. This often results in flaws and loopholes in the system which leads to non-compliance and data breach. Consequently, organizations get slapped with hefty fines, suffer damage to their brand and reputation, and stringent audit process.
Compliance is an ongoing process for any organization. Having achieved PCI DSS Compliance does not suggest the end of the process. Rather it is the beginning of building a strong and secure payment Infrastructure and processes. Having said that, I suggest organizations to consider performing thorough audits regularly not just for the sake of documentation, but for securing cardholder data which is a basic necessity to secure data and prevent a data breach. If possible, please take external support.
2) Cardholder Data Scan-
Cardholder data scan should be a part of your regular assessment process to rapidly assess the IT server or workstation environment. This is essential for tracing sensitive and unprotected cardholder data in the environment. The scan suggested should ideally be performed every quarter to identify any weak areas or loopholes in the system that could possibly lead to a data breach. Organizations often fail to understand the significance of such an assessment process and rarely perform CDH Scan even once a year. This is when the organization gets exposed to risks and data breaches.
As a qualified auditor, I suggest the organization to perform CDH Scans every quarter to review their environment and ensure necessary security controls are in place. Additionally, I suggest that the scan should also include systems and networks that are not in scope to check for the possibility of data leakage
3) File-integrity or Change Detection software-
Integration of file-integrity monitoring or change-detection software on logs is a PCI DSS Compliance mandate. Organizations are advised to integrate these tools or software with the SIEM to ensure that existing log data does not just change without generating alerts. Moreover, the FIM should also monitor application software directories including platform files and folders and not just the OS and platform level files and folders. We have seen systems raising hundreds and thousands of false-positive alerts. There should also be incident management controls, policies, and procedures in place for the alerts raised in the system. The tool helps organizations track changes and identify missing elements and unplanned changes. However, often these requirements are neglected and typically not implemented by organizations
It is essential for organizations to verify, change, and delete actions of files as any change significantly impacts and compromises the security of systems and the environment. By changes I mean organizations should look out for changes to file attributes and the size of the file. It is important to note that Trojans are designed to impersonate existing system files and appear like the original driver file, executable, or link with some unwanted and malicious additions. For Linux and UNIX the /etc/ and /usr/bin/ locations, all files should be checked and monitored for its integrity with all relevant application configuration files. Most importantly, ensure that even the application files and folders are monitored. You also need to ensure that only essential alerts are flagged with few to no false positives.
4) Not documenting significant changes
Significant changes within an environment are often overlooked by organizations. This usually happens because PCI has given organizations the liberty to independently determine and decide what a significant change is. The most common significant changes may include major security redesigns, architectural changes or additions, modification to firewall rules within the CDE, product upgrades, changes to encryption keys to name a few. Organizations often overlook these changes and avoid documenting the same.
The best way to address this issue and avoid mistakes of significant changes is by clearly defining the term “significant change” in the policy. Further, it should draw out details on how to apply the policy to the cardholder data environments. Thereafter a penetration test must be performed on those changes to ensure complete security.
5) Management of Cryptographic Keys
Management of cryptographic keys is critical for businesses as there is a huge possibility of the key being misused, re-used, over-used, and inappropriately stored. Organizations should have in place key management systems that address these issues. Very often we see organizations that have not kept among other things: Inventory of keys, key expiry/retention/revocation processes, and split/dual controls of keys. Organizations often look through these issues and neglect implementing necessary measures to protect sensitive keys. This could in turn lead to an insider threat and security breach.
The most effective way to mitigate insider threats is to have a dedicated electronic key management system in place. Organizations should ensure they have a mature, proven solution from a reputable provider for cryptographic key management. The Cryptographic Key management system should use a hardware security module (HSM) for generating and protecting keys, and to further underpin the security of the whole system.
6) “Fixation” for exclusion or out of scope –
Considering what should be in scope and out of scope is crucial for business. While reducing the scope for limiting the organization’s risk exposure is a good step, but deciding to completely disown the responsibility is equally dangerous. Organizations need to understand that getting things out of scope and shrugging off their responsibilities completely on the third party will be a great disservice to themselves and their clients. Most organizations put systems out of scope and forget to manage risk which eventually brings them down heavily. The best example for this would be merchants re-directing customers to a new page for payments to reduce their scope. However, the merchant’s e-commerce server could be compromised by the hacker and may create a fake redirect page in place to steal cardholder data. Making the process of getting things out of scope more important than addressing the real issue can greatly impact the organization’s security. Organizations need to understand that “out of scope” does not mean “out of mind”. Hackers look for opportunities and if systems or data can be compromised, they will be. Risk mitigation should be the organization’s top priority. After all, that is the whole point of having PCI Standards in the first place.
As suggested earlier, putting things out of scope should not be the priority. Even if you plan to outsource your services to the third party, ensure the third-party is PCI Compliant not just on documents but also in their processes and controls. Having said that, organizations too should ensure they have necessary applications, and controls in place to secure data and infrastructure.
Organizations should not Outsource Ownership or Accountability. As much as you are tempted to put most of your systems out of scope, you must ensure that you and the third-party have all the necessary security controls in place to address the above-mentioned issues. Putting things out of scope should at no cost compromise the security of systems and sensitive data. This is important because it is ultimately your organization that is responsible for everything when it comes to compliance. So, even if you decide to outsource certain elements of compliance, you should never brush off all your responsibility completely on the third party. Moreover, if you can avoid the above listed common mistakes, your organization will be well on track to achieve PCI compliance
The best thing about PCI DSS which also proves to be the bane for most organizations is that PCI DSS is very precise in its requirements. This makes it very difficult for organizations to squirm out of audit findings citing a comma or a full stop. There is no way around it other than to periodically check the scope and conduct internal audits for compliance. The listing above can be made quite exhaustive with audit issues in the way the VA/PT is done, Firewall reviews, backup and restoration of card data, additional requirements, and signoffs by service providers and their clients. I believe the worst thing an organization can do is to cram for evidence at the last minute, just before the audit. Bear in mind that there are many evidences in PCI DSS such as ASV reports, VA/PT reports, SIEM reports, Incident Alerts that cannot even be backdated.