Few things strike fear into the hearts of consumers and businesses more than a breach of financial information. Why? Because it hits us where we’re most sensitive: our pocket books! Long gone are the “good ol’ days” when hackers were motivated by the challenge of breaking through security. While arguably no less troubling, a guarded admiration and respect was earned as a result of the intelligence and creativity exhibited by those early individuals. After all, these cyber-battles often pitted the little guy against “the Man.” The more impenetrable the defenses, the greater the respect garnered by the individual who was able to break in.
While modern underground hacktivist groups like Anonymous still claim to access—and publicly expose—information on practices they feel contravene the public’s best interests, modern hackers often seek far more basic information such as consumer e-mail addresses, Social Security numbers, and passwords. This information is subsequently used to gain access to websites, or to facilitate social engineering attacks.
Nowadays, financial gain is often the primary motivation. The majority of the world’s business transactions are conducted electronically, opening up new opportunities for criminals. It didn’t take long for organized crime to realize that vast amounts of money could be made using and abusing the technology we all rely on. The borderless nature of the Internet means that computer crimes are not restricted to a neighborhood, region, or even country. Compromised data is often resold many times, commencing only a matter of moments after it has been obtained.
Many credit card issuers protect customers with “zero liability” for fraudulent transactions, however any breach or abuse impacts us all regardless of how the data was obtained or used. In 2006, in response to the explosion of credit card-related crimes, five major issuers: MasterCard, Visa, American Express, Discover, and JCB International—known collectively as the Payment Card Industry (PCI)—formed the Security Standards Council (SSC). The SSC designed a framework of six categories with twelve primary requirements, and a comprehensive assessment and penalty process as represented in Table 1 below.
|Build and Maintain a Secure Network|
|Install and maintain a firewall configuration to protect cardholder data|
|Do not use vendor-supplied defaults for system passwords and other security parameters|
|Protect Cardholder Data|
|Protect stored cardholder data|
|Encrypt transmission of cardholder data across open, public networks|
|Maintain a Vulnerability Management Program|
|Use and regularly update anti-virus software or programs|
|Develop and maintain secure systems and applications|
|Implement Strong Access Control Measures|
|Restrict access to cardholder data by business need to know|
|Assign a unique ID to each person with computer access|
|Restrict physical access to cardholder data|
|Regularly Monitor and Test Networks|
|Track and monitor all access to network resources and cardholder data|
|Regularly test security systems and processes|
|Maintain an Information Security Policy|
|Maintain a policy that addresses information security for all personnel|
Compared to other regulatory or legislative standards, PCI’s Data Security Standard (DSS) remains one of the least challenging for IBM i security officers to interpret. It does, however, still require resources to remediate. Most of the requirements are well-served by commercial security applications. For example, Requirement 1 can be addressed by implementing a transactional firewall, such as Powertech Exit Point Manager for IBM i, and Requirement 5 can be satisfied by deploying Powertech Antivirus for IBM i. But there’s no “silver bullet” to achieving PCI compliance, and most requirements involve utilization of IBM i’s integrated security controls.
Admittedly, PCI DSS is far from perfect. It often relies on “self certification” that systems and practices truly are (and remain) compliant. This is prone to abuse and misunderstanding. In fact, the recent data breach at Global Payments of 1.5 million credit card numbers has brought about speculation that the company wasn’t PCI compliant. Not surprisingly, they’ve been dropped by Visa from the list of PCI-compliant companies. Regardless, compliance is not a guarantee that a server isn’t vulnerable to attack. If PCI DSS is taken too literally, there’s the potential that organizations will be lulled into a false sense of security. PCI is not the be-all and end-all of security. Rather, it outlines a set of base requirements that a company should meet in order to have any chance of protecting critical data.
Despite its obvious shortcomings, I’d offer that all companies should consider adhering to the PCI DSS directive as part of their best security practices. In fact, if you replace “cardholder data” with “application data” in Table 1, you get a mandate that helps direct the protection of all organizations, regardless of the type of data they store. Far too often companies do the minimum necessary as it supposedly costs less and takes less effort. As Global Payments is now finding out—and they are certainly not alone—the reality can prove to be far different in the long run.
Unfortunately, many of the firms certified to conduct PCI audits remain unfamiliar with IBM i and its uniquely integrated database and security controls. As a result, recommendations often make no sense to those who have experience working with the platform. This lack of familiarity also increases the risk that data will be compromised, as there’s a very real likelihood that serious configuration vulnerabilities will be missed.
HelpSystems, a leading security and compliance solution provider, has published a guide discussing how PCI DSS requirements impact servers running IBM i. The document includes ways that the HelpSystems Powertech suite of security solutions can assist in achieving and maintaining PCI compliance. If your organization stores or processes data subject to regulation—such as credit card numbers—then this document is a must-read resource.