Documentation Of PCI Compliance Processes? No Thanks! How Logging And FIM technologies Can Augment (Or Replace) Process And Procedure

Small Company PCI Compliance

For many Merchants subject to the PCI DSS, September is always a significant deadline for proving that compliance with the security measures of the PCI DSS has been met.

Unless you are a Tier 1 merchant (transacting in excess of 6 million card sales each year) and being audited by a PCI Security Standards Council QSA (Qualified Security Assessor) then you will be using the Self-Assessment route. SAQ D is the most commonly used Self Assessment Questionnaire for medium to large scale merchants.

Regardless of which type of Merchant your organization is classified as, the issues are firstly to put measures in place to meet compliance with the requirements, (so either install some security technology, e.g. a file integrity monitor, or define and document security procedures), and secondly, to prove that the measures are effective.

For smaller merchants, processes are typically not documented because there has previously been no need to do so. It stands to reason that for a small-scale IT Department, processes are commensurately simple to explain and operate, and as such, wont have needed to be documented. This being the case, however, it could also be argued that the documentation of processes, and proving that they work, is also very simple.

For instance, the change management process may be as simple as ‘if any of us need to make a change, we discuss it or just send an email to the others for their information, then enter details onto a shared spreadsheet document’.

Clearly there is ample potential for human error in a process like this and for an ‘inside man’ hack to be perpetrated, even if the risk is low and the subsequent identification of the perpetrator straightforward.

So in this case, documenting the process is easy, but proving that it is infallible is another matter. There are too many scenarios where the process can fail, principally due to human error, but this also makes it inadequate as a means of ensuring changes cannot be made without detection. This is why many small companies lose sleep over PCI Compliance, worrying how far measures need to be taken and just how much security is enough?

Process Checks and Balances – Automated

PCI DSS Requirement 10 mandates the logging of all significant security events from the PCI estate, while PCI DSS Requirement 11.5 mandates the use of File-Integrity Monitoring technology. For many organizations taking a ‘checkbox’ approach to PCI Compliance, the implementation of both technologies is seen as just another hassle to get through for the sake of the PCI DSS.

However, take a step back and look at the PCI DSS as a whole. The emphasis is on good security measures with sound best practices. In other words, for each dimension of security advocated by the PCI DSS there is a need to document and test related processes.

It therefore becomes clear that logging and FIM are not just overlay technologies to plug gaps left by the firewalling, hardening and antivirus measures, but integral means of verifying that your net security stance is effective.

Any file change or configuration change reported should be investigated and verified then acknowledged as an approved change. The process is automated, but simple and robust.

Similarly, a new account or privilege being assigned will be reported via your log management system, prompting an investigation and ultimately a record of the acknowledgment.

As such, implementation of event log management and file integrity checker technologies can actually provide the processes needed for PCI DSS compliance. You could have a whole shelf full of change management processes and procedures, or alternatively, simply refer to your log management and FIM reporting system.

If you want to short-cut boring documentation of processes for PCI compliance then talk to us about how we can help - support@nntws.com