The intent of the PCI standard is really quite simple: To safeguard the information of payment card holders as it makes its way through the network. But things get complex in execution, as the information crosses many touchpoints in the delivery infrastructure.
PCI compliance requires a strategy that considers every one of these touchpoints, as well as all the applications that manage secure data – HR systems, payroll systems, and other business applications. PCI fits in the middle of all this. The challenge is to address the applications that are part of the delivery infrastructure and to put specific security controls around those critical business processes.
Legacy systems, new challenges
The greatest risk to PCI compliance is in the legacy systems used along the transmission route – equipment or applications that have “hooks” into PCI compliance systems.
After a recent pre-audit (the audit before the PCI auditors come in) of a customer’s main system, the chief finding was that the retailer was blissfully unaware a secondary system had access into the main system, and that the two were using a shared user name and password. Unfortunately, many once-secure systems continue to develop and scale over time, and a lot of the “ins and outs” aren’t well understood by either security personnel or administrators.
Because of all the vulnerabilities involving risks at multiple touchpoints, and because of the growing number of internal breaches and malicious hacker attacks, PCI compliance has to become an ongoing, diligent activity integral to an organization’s DNA. It doesn’t stop when you get your official stamp of certification. That’s when it starts.
The best practice? Design strategy into the system before you ever build or rearchitect the system. When you look at rolling out a new business application, look at the business requirements and ask “Is there sensitive business data involved?” “Is there PCI data?” “Is there HIPAA data, etc.?” That’s the opposite of the reactionary approach in which companies bolt security on at the back end before the auditors arrive, or after a breach occurs.
Technicians may understand the challenges and complexity, but surprisingly the CIO and senior management often need more persuasion. Now, however, is the time to get them on board. Breaches can be well-planned, methodically executed attempts by hackers to pillage a system for social security numbers, credit card data or other personal information. They come in low and slow, they hide their tracks, and can eluding IPSs (intrusion prevention systems) and IDSs (intrusion detection systems).
Wireless access points are a special circumstance. Wireless access points are continually being updated, but some legacy devices that connect to them don’t support the latest encryption technology or authentication mechanisms. So that means security IT personnel end up “dumbing down” those access points – essentially configuring them to support legacy devices, and thereby exposing security risks.
Here again is where the pre-audit can help. This involves network scanning, external penetration testing, application security testing, viewing authentication and authorization mechanisms, scanning web applications – all with the aim of demonstrating to the PCI auditor that the company has done its due diligence, and that any deficiencies identified have a plan attached whereby they will come into compliance.
There is a story of an energy company that had experienced a number of security breaches during the previous year. The pre-audit resulted in a recommendation to add several new controls immediately to eliminate known risks. This company had lacked robust auditing and logging infrastructure, and the pre-audit led to a 12-month plan for deploying firewalls, IPSs and network segmentation, and to do auditing and logging on the back end. The PCI audit is never a breeze, but with the known risks and a plan to overcome those risks in place, the company was in position to pass the audit without incident.
Partially hosted models
Especially complex situations arise when a retailer that has previously outsourced its credit card processing, scales up to the point where it decides to bring pieces of the system (or the entire system) in-house. In another story, an e-retailer outsourced its systems to a hosting company. As business grew, the e-retailer decided to bring parts of its network inside. As the project rolled out, each server coming in-house was placed in a “DMZ environment,” with robust IPSs protecting those servers. Such a partially hosted model makes PCI compliance more complex, as the end-to-end route from retailer to consumer takes on additional access points.
What’s simple in design can become complex in execution – but that just means there must be a best-practices overlay built into your strategy. For the e-retailer — from the auditor’s perspective — though he or she before had only to certify the third-party’s security controls, the e-retailer’s security controls must be certified also. With best practices for monitoring that environment and its processes, however, retailers can remain on solid ground.
Retailers are not alone in the challenge. The requirements for secure handling of patient data in healthcare (to name just one industry segment) are every bit as complex, and strategies for PCI compliance are every bit as critical in that industry. The overarching requirement to secure every touchpoint in the delivery infrastructure is the common denominator. Make that the centerpiece of a PCI strategy, and build a set of best practices to guide every effort.