Version 3 of the Payment Card Industry’s Data Security Standard (PCI-DSS) came into effect at the beginning of 2015 and continues to cause confusion and anxiety for many organisations. In this article, Redscan’s Simon Heron provides some helpful guidance. He outlines a number of ways companies can change their operations to comply with the new regulation and minimise the impact of the requirements. PCI-DSS compliance is getting harder. Version 3, which came into effect earlier this year, is a real step change in the standard, and it is obvious that continuous monitoring is where the PCI Council wants to focus. Many companies fear that version 3 will lead to a big increase in their IT security expenditure, but there are a number of approaches that can be adopted to reduce both business disruption and the cost of compliance.
One way is to outsource some functionality. However, where cardholder data passes through a function managed by a service provider, the service provider has to be PCI-DSS certified too. If they are, then that element of compliance can be offloaded, and the service provider must provide the relevant SAQ-D form to the assessor. One step Redscan has taken in the light of version 3 is to become PCI-DSS compliant. Our customers can therefore offload part of their PCI-DSS security to us, reducing their workload and enabling them to become compliant more quickly.
It is an important first action to try and limit what comes under the scope of PCI-DSS. There is obviously a cost associated with rearranging a network, but it can be a significant cost saving when compared to bringing too many machines into the scope and managing a larger estate within compliance. So look to ways of isolating the Cardholder Data Environment (CDE) either physically or with strategically placed firewalls. Another option is to see how much can be taken out of scope by the use of the appropriate technology. By using certified applications and devices, organisations can make certification easier and reduce their ongoing management and maintenance overheads. There is a list of validated devices and applications at: https://www.pcisecuritystandards.org/approved_companies_providers/validated_payment_applications.php?agree=true.
It is necessary to not only store logs from in-scope systems but also monitor them. To do this over a network can be very time consuming and inefficient with critical events being missed. By bringing all logs into a central store, the management becomes much easier and, with systems like Security Information and Event Management (SIEM), the monitoring can also be made much easier. Logs must be immediately available for 3 months and kept for 12. Naturally, it is an easier job to achieve this goal when all data is centralised as there is only one place to search (reducing forensics costs if required at any stage), one store to backup and one place to archive. Many SIEM systems will sign the data ensuring it is valid in a court of law. The use of a SIEM system makes a number of the PCI-DSS requirements much easier, especially when they are tied into Netflow analysis, intrusion detection systems, firewall logs, asset management and vulnerability scanning. Otherwise all these disparate sources become hard to manage resulting in failed audits.
Companies needing PCI compliance must list all assets that are located in a trusted zone. These assets must be monitored and should be reported on as a group, separate from those assets that are not in a trusted zone. By using an automated asset discovery system, you can provide a dynamic asset inventory and hence topology diagrams. Cardholder-related resources can be identified and monitored for unusual activity. It is also the case that accurate and automated asset inventory combined with the relevant security events accelerate incident response efforts and analysis. There are plenty of tools around to let you do this and many of them are powerful and free. Nmap is a good example of one such open source tool. The issue is collating the data, alerting on new assets joining and leaving the trusted zone and reporting in a coherent fashion so auditors are not forced to spend time searching through documents trying to see if compliance has been met.
File integrity monitoring (FIM)
PCI-DSS version 3 requires organisations to install file integrity monitoring software in order to pass the audit. It is very simple to install FIM; OSSEC is one free, open source solution. However, it isn’t the technology that is the problem. The issue is how to monitor, manage and store the information obtained. Obviously, if you have decided to implement SIEM, then this becomes the repository through which you can do these activities.
Scanning is the one issue that seems to catch everyone’s attention when they are trying to become PCI compliant. Yet, the need to have external scans carried out by a registered provider of vulnerability scans (or Approved Scanning Vendor (ASV)) is just one task that needs to be addressed. There is also the annual penetration test to be carried out via a recognised approach and by suitably trained and experience personnel. These tests are very useful for any organisation, but to be genuinely useful they need to generate a comprehensive and understandable report at the end. Be sure to ask for examples of test reports whenever you approach a company about penetration testing; it can tell you a lot about the service you will receive. Another requirement is scheduling the quarterly vulnerability scans for the internal network where all vulnerabilities returned as ‘High’ or above must be addressed. It is the addressing of the vulnerabilities that is the major work. One solution is to create a ticket system for the IT staff so they have a ‘task’ list, and managers can see the progress towards compliance: what has been identified as needing attention, what has been achieved and what is being worked on. This results in a faster audit and lower costs, as well as being good practice to heighten security.
As this article has shown, there are some relatively straight-forward steps that can be taken to simplify PCI-DSS compliance. However, one major issue nonetheless remains: how to have eyes on the screens and reports to make sense of what is being discovered and define the action that needs to be taken. The problem is that there isn’t a technical solution for this; it requires highly trained, qualified security professionals, who are a scarce and expensive resource to employ. What is more, if a 24/7 service is required the minimum team needed is seven which constitutes a substantial cost, far in excess of the cost of the software and hardware involved. One solution is to look at outsourcing this function. Look for Security Operation Centres able to install, manage and, most importantly, monitor the systems. This allows companies to effectively share security experts, reducing costs and offloading the recruiting, training, retention and replacement of the staff. There is no doubt that becoming and staying PCI-DSS compliant is now more difficult than it has ever been for financial, retail and eCommerce organisations. It is important to bear in mind, however, that these new requirements will make organisations safer and should minimise the number of breaches, reduce the time that companies are compromised and make it easier to remediate and remove threats. This could end up resulting in a net saving despite the initial outlay of funds required to meet the regulations. Simon Heron is chief technology officer at Redscan. For further information about PCI compliance go to www.redscan.com/compliance/pci-dss-v3-0/ or contact Simon on: firstname.lastname@example.org.