Putting the ‘i’ Back Into PCI
January 9, 2008 Alex Woodie
|
When the folks at the major credit card companies created the Payment Card Industry (PCI) a few years back, they defined the information security specifications using terms and architectures they were most familiar with. As it turned out, that meant Windows and Unix. After some analysis by customers of IBM and IBM engineers, the PCI specification was updated to reflect two other architectures prevalent among retailers: System i and System z. Before he left IBM to found Group8 Security last month, Pat Botz worked with several groups involved in security, including a stint as security architect for i5/OS (formerly OS/400), analyzing information security on virtualized IBM servers, and working directly with large customers in IBM Lab Services. At some point along the way, Botz was called upon to look into the cardholder industry’s new PCI security standards, which aim to ensure that credit card numbers and other personal information are handled securely by retailers and the computer equipment they use to process credit card transactions. When he looked into the specifications, he realized it would be difficult for customers of large IBM servers–namely, System i (iSeries and AS/400) and System z (zSeries and S/390) mainframe–to comply with the security mandate as it was written in its first draft, he said during an interview last month. “It was obviously written by people who originally came from the PC or Unix environments,” he says. “Some of their wording the first time around assumed a Wintel or Unix network architecture. They had to go back and clean that up.” The problem had to do with how many applications can be running on a single server, and the necessary separation between applications running on other servers. In its first draft, PCI assumed that retailers would be running only one application per server–a common practice in the Windows world. But that obviously wouldn’t work with big iron. Many big-name retailers rely upon proprietary, multi-million-dollar System i and System z servers that scale from here to the moon to run ERP, MMS, and other critical business applications. In these architectures, virtualization is built-in and fully integrated with the rest of the system stack, providing a degree of security and reliability that virtualized Wintel environments have mostly lacked. “While the behavior they were trying to describe was valid, the wording implied that, in a Windows world, you’re going to run one application per Windows server, and therefore you need to do that one application per server regardless of what server,” Botz says. “They actually went back in and cleaned it up and clarified that because there are mainframes out there, there are multi-user computers like, oh, System i that were designed and have mechanisms built in so you can have the darn things run more than one business function.” While the change, which was made earlier this year, was necessary to prevent mass confusion on how System i and System z shops can institute PCI compliance, the issue actually helps illustrate (in a round-about sort of way) a broader point about information security and regulatory compliance–one that Botz is hoping to make with his new security consulting company, which we covered two weeks ago. The point, Botz says, is that PCI and other industry regulations like the Sarbanes-Oxley Act (SOX), were written to be platform- and process-neutral (SOX a little more so than PCI). While PCI, in its first draft, had some platform-specific deal-breakers (and is still more to-the-point from a technical point of view on how to institute compliance), the mandates are doing the right thing by laying out the security goals that customers must obtain, and mostly leaving it up to them on how to get there. Of course, customers and IT vendors have been railing for years against SOX for being vague in laying out the exact steps they need to take to comply with the regulation. But the law’s makers were doing exactly what they should have, Botz says. “Do you really expect the Congress of the United States to pass a law that includes all the system value settings, all the access control settings, for every different computer system, for every different application, including custom applications? It’s ludicrous,” he says. “But SOX does tell you what to do in an abstract, behavioral form. And in my opinion, it rightly leaves the best possible way of enforcing that abstract behavior up to you.” The source of this problem, Botz says, is a widespread misconception on what IT security is all about. People commonly mistake security processes and procedures–the platform-specific stuff dealing with settings and technology–with security policies, which primarily deals with the human- and business-level stuff of people, their roles, and what data they should be allowed to access. Mixing the two, or allowing the technologists to define security policies (quite common) or to allow business leaders to deal with procedures and technical settings (less common but perhaps more dangerous), results in wasted time and money, and lower overall security, according to Botz. It’s his goal at Group8 to help companies separate technical security procedure from the business-oriented security policy stuff. RELATED STORY Redefining Security the New Goal of Former i5/OS Security Architect
|
