LogBlog

« Survey Says: Log Management | Main | Introducing LogLogic 4 - The most advanced log management platform on the planet »

Computing Monocultures and PCI Compliance

A few years ago, the CTO of my former company (Dan Geer, @stake) was fired over a paper he co-authored on the Microsoft monoculture and its potentially disastrous consequences. The topic of computing monocultures in relation to security has cooled down a bit, but I think it's worthy to revisit the issue in light of today's increasingly regulated and compliance-driven IT environments.

To briefly summarize the debate, Dan's side of the argument (against monocultures) asserts that corporations and governments should diversify their computing environments to better ensure survivability in the event of widespread failures in common operating systems and applications. On the other side, supporters of monocultures tout the positive aspects of running a common computing environment, including economies of scale, enhanced supportability, and vendor leverage with pricing and licensing.

I see the merits of each side and tend to be pragmatic about platform and application selection, advocating solutions that work best for the given problem, with additional decision inputs around security, supportability and vendor relationships being considered based on organization-specific criteria and risk management approach .

When specifically considering Payment Card Industry (PCI) compliance and environments that process payment card data, however, the cost savings and efficiencies traditionally associated with computing monocultures become even more compelling. There are a number of specific requirements in the PCI Data Security Standard that are more costly to comply with as the diversity of the environment increases. Thus, there is a direct correlation between platform and application diversity and the cost and effort associated with achieving and maintaining compliance with the PCI Data Security Standard.

Consider PCI requirement 2.2, which requires secure configuration standards for all system components in the cardholder environment. This means that for every type of router, firewall, network device, operating system, etc. in your PCI-relevant environment (i.e. the environment where cardholder data is transmitted, processed, or stored), you need to develop, document, maintain, and implement system-specific configuration standards.

Back when I was performing PCI audits, I would validate this control by:


• Reviewing the specific configuration standards
• Reviewing the model and mechanism used to implement these standards (e.g. install scripts, gold disks, JumpStart or KickStart configurations, router configuration templates)
• Reviewing the actual configuration on the deployed system to ensure that the standards had been implemented, not just documented

The audit cost for assessing PCI requirement 2.2 goes up with each additional platform supported, and you can also see how the costs associated with creating, managing, and applying these standards increase as the environment becomes more diverse.

This cost to diversity relationship exists in many other PCI requirements - clear examples include:


• Requirement 6.1 - Requires that all in-scope components have the most recent security patches installed (within one month of release). More platforms to patch will often mean more patches to test, more change management requests to submit, more tools needed to apply the patches . . .
• Requirement 6.2 - Requires a process for monitoring vulnerabilities and security issues related to in-scope components. Also requires that configuration standards be updated as needed based on this new information.
• Requirements 11.2 and 11.3 - Require regular vulnerability scanning (quarterly and after significant changes) and penetration testing (annually and after significant changes). Having performed these services for a number of years as a security consultant, I can validate that the price associated with either of these endeavors increases as the number of platforms evaluated rises.

Of course, this doesn't mean I'm advising you to scrap your current credit card processing environment and standardize on a single vendor's solution. Retail and e-commerce card systems and applications are complex beasts and it is difficult or impossible to find a single platform to run all of the systems required (e.g. credit switches, point of sale, fraud monitoring and loss prevention, sales audit, loyalty and affinity marketing, etc.).

Instead, make sure you understand the effect that platform diversity has on the effort and cost that it takes to manage and maintain PCI compliance. Some questions to consider in this arena include:

• Have you done everything possible to limit the scope of PCI compliance (e.g. using network segmentation, limiting systems and applications that process in-scope data, outsourcing card processing functions as necessary)?
• Do you have the expertise to appropriately manage and secure the platforms and applications required?
• Do you have the tools needed to maintain these diverse platforms in a PCI-compliant manner (e.g. patch management systems, log management tools, file integrity monitoring software)?

In the end, maintenance costs (including those that are PCI-specific) should be an input to any important technology decision. Ensuring that these 'cost of complexity' considerations are included as a standard component of risk evaluation and decision making will help provide some basis of assessing the resource needs associated with managing PCI compliance for your chosen technologies.

Posted April 09, 2007 in Compliance | Permalink

TrackBack

TrackBack URL for this entry:
http://www.loglogic.com/mt/mt-tb.cgi/174

Post a comment

Visit loglogic.com

I ♥ Logs

Subscribe to this blog’s feed RSS

June 2008
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          
Categories
Archives
Blogroll
Blogroll
Compliance
Good Reading
LogLogic
LogLogic Partners
Sites We Watch