Too many companies are neglecting to keep up to date with the standards required for accepting electronic payments, even though compliance is easily achieved by following three simple rules, according to Securus Global senior security consultant Steven Surdich.
(Credit Card image by Thomas Kohler, CC BY-SA 2.0)
Surdich said that in his experience, companies are treating Payment Card Industry Digital Security Standard (PCI DSS) like a once-per-year obligation.
PCI DSS, often referred to as just PCI or PCI compliance, is a security standard developed by the Payment Card Industry Security Standards Council (of which credit providers like Visa, MasterCard and American Express are members). It consists of 12 overarching requirements, which, when implemented correctly, are meant to better protect cardholder data and thus reduce credit card fraud.
To ensure that these requirements are continually met, organisations that handle large numbers of transactions are audited by an external Qualified Security Assessor (QSA) annually, but, according to Surdich, the annual check-up has resulted in organisations forgetting about or neglecting PCI compliance until the audit date.
He said that symptoms of such behaviour include seeing an increase in last-minute activity, or an apparent spontaneous outbreak of patching behaviour as the audit date approaches.
"We'll see service tickets labelled 'patching for PCI'. It's pretty obvious how some companies approach it," Surdich said.
Despite this behaviour, PCI compliance is meant to be a year-round effort to ensure that customer payment details are constantly protected, and not just in a single, once-off activity. Surdich highlighted companies' obligations as stated in their Attestation of Compliance: "The merchant has read the PCI DSS, and recognises that they must maintain full PCI DSS compliance at all times".
Although many companies appear to be having difficulty in doing so, Surdich said it is simple if they follow the three basic rules: controlling changes to the cardholder environment; maintaining oversight of their activities; and simplifying compliance processes.
Read on to page two to see Surdich's tips for guarding the cardholder environment.
In any business that handles payment details, there will be systems that are not related to those that handle cardholder data, Surdich said. But, according to him, there will be systems, such as email servers and end-user machines used for web browsing, that should be de-scoped from the cardholder environment to better allow those within the cardholder environment to be managed for ongoing PCI compliance. While the most common ways to do so are through network segmentation by applying internal firewalls, Surdich warned that these can easily become a hidden danger.
"We need to actually review the firewall config, and make sure the segmentation is actually done properly, so it's restricting things down to source, destination, IP, down to ports, and it's not too confusing," he said.
It is important to ensure that this segmentation, like any changes to the cardholder environment, is heavily guarded.
"The environment that was certified as PCI compliant; that needs to be protected from unauthorised changes. You want to make sure that you understand the environment, and that you're actually part of the change process in some capacity," Surdich said.
He said that a typical example of where this could go wrong is where a third-party project manager attempts to implement a new system outside of the scope of the cardholder environment, but it fails user-acceptance testing due to the restrictive rules of the internal firewalls.
"Pretty soon after you see a change request come through: 'We want to, just temporarily, just take off those firewall rules ... just for troubleshooting purposes'. Firewall rules are [then set to] any/any, so it's letting all the traffic through between the corporate LAN and the cardholder environment, and then the project manager is saying, 'Well, we've got a time-precious situation ... so it needs to go into production'.
"It goes into production, and obviously trying to reverse firewall rules once they're into production is a pretty hard thing. The project manager? He's gone. He's done. His system is deployed, and he's probably working at one of your competitors now."
Surdich warned that such incidents result in the entire corporate LAN falling into the scope of an audit, which he said becomes extremely messy, since the rest of the network is usually not kept up to the same standard as the cardholder environment.
To combat such problems, Surdich said that the organisation needs to ensure that any new piece of equipment connected to the network meets certain conditions as set out in a system-acceptance process, and that the organisation keeps its network diagrams up to date in order to know its environment well.
"Knowing your environment is probably the most important thing," Surdich said, because it is impossible to make decisions about change requests or requests to add new equipment without it.
He also said that at the time that a new server is deployed, it should be hardened for the cardholder environment, scanned for vulnerabilities, have antivirus installed and its audit logs turned on. While admitting that these are basic security measures, Surdich explained that it is much more difficult to put these measures into place after the fact.
Surdich also advocates giving the organisation's QSA a call or email to double check whether a particular system is completely PCI compliant, rather than finding out after the process that there are significant additional costs to bring it up to standard. He also noted that although a third-party provider of services may list itself as being PCI compliant, the reality is that often, it is only partly compliant. A QSA will normally be able to advise what else the organisation will need to do to meet full compliance.
Read on to page three to see Surdich's tips for oversight of compliance activities.
In order to ensure that the cardholder environment is secure, Surdich said that it needs to be someone's job to scrutinise and oversee all activities relating to the compliance and the organisation's network environment.
"If you don't have one person or a team of people that have a vested interest in maintaining PCI compliance and overseeing that all the activities are actually happening, it just basically falls into a hole. Someone needs to own that responsibility," he said.
These activities include doing regular spot checks, and completing vulnerability scans of systems. Surdich stressed that there are certain tasks that are time sensitive.
"Quarterly scans, for instance — if it doesn't happen, then obviously it's not going to be there for the evidence trail. Some of this stuff needs to happen at particular times.
"If you miss the boat, you've missed the boat."
He suggested extracting the required scans from the PCI standard, and scheduling them in to the company's ticketing schedule to ensure that they are recorded. Those responsible for the oversight of these activities then have the ability to sign off on tasks as they are completed, or raise red flags when they are overdue.
"Get it in there with events. Actually schedule it in there, so that way it doesn't drop off the radar. It's pretty important that this stuff happens, and someone needs to own the oversight ... otherwise, things will fall into the cracks; guaranteed."
Whoever is in charge of overseeing the cardholder environment should also be involved in any environment-change meetings that medium and large enterprises should have each week, according to Surdich. He said that it is always good to have a security-minded person in the meetings, so that even if new items are added to the environment, come the time of the audit, there would be no nasty surprises.
Read on to page four for Surdich's tips on automating processes.
For organisations that have been through the compliance process before, Surdich said that there is often room for improvement.
"A lot of companies make things a lot harder for themselves. For the first time, when you're actually achieving PCI compliance, you tend to get a process in and live with whatever's been put in place. There are a lot of areas that you can actually streamline. What we find is that if a process is too hard, often it doesn't get done."
In particular, he said that patching is a common source of pain for most companies. While the end-user PCs are usually set to automatically update, he said that servers need to be prioritised and scheduled to avoid unnecessary downtime. He said that when doing vulnerability scans on computers in the network, administrators should add business information to provide some context around whether a particular PC requires immediate attention because it is critical to the business, or whether it could be tackled at a later date, due to it being more protected, for example, by the network environment.
He also advocates adding change-request numbers and expiry dates for particular rules in firewall settings in order to make life easier for system administrators.
"Just making it easier for whoever needs to do the review to go actually through there and say, 'Yep, that was for a protected system that's expired. I can just delete it.'"
Surdich also offered some advice on further automating processes and making existing systems work better for the organisation. Organisations should spend time fine tuning their systems to cut back on the number of false positives found in their intrusion detection/prevention systems and file integrity systems, he said, adding that if the organisations haven't already, they should stop manually leafing through audit logs.
"Rather than trawling through logs, which is basically a waste of time, set up exception results ... so you're actually extracting data from the log session.
"It's just some common-sense sort of stuff, but all these things just simplify the whole process of maintaining compliance and there's a lot better chance that things are going to actually get done."