The 'security standards dilemma': Network segmentation and PCI Compliance
Stephen Cobb, Contributor
Rating: -4.00- (out of 5)
|
While the exact details of the Hannaford Bros. data security breach may always be called into question, we do know that criminal hackers accessed as many as 4.2 million credit and debit card numbers by installing malware on the servers of more than 270 of the company's stores. The tactics used by the attackers raise serious questions for retailers and have equally serious implications for information assurance practices.
One of the questions that security professionals must ask is: "Could better network segmentation have prevented or limited the scope of the breach?" Some have also wondered whether the Payment Card Industry Data Security Standard (PCI DSS), with which Hannaford had been deemed compliant, adequately addresses the importance of that type of separation.
This tip will examine the practice of network segmentation; that is, building larger networks out of multiple and separate small networks or sub-networks, communications between which is strictly controlled.
Passing PCI
So, how did a breach of this scale occur at a company that was compliant with PCI DSS? Apparently, malware installed on company servers intercepted card data as it was transmitted from cash registers to credit card processors. The malware then stored the purloined data on store computers before forwarding it to servers located offshore; from there it could be collected and used for fraudulent purposes (some 1,800 cases of such fraud were reported).
Some security-savvy consumers were quick to ask why the card data was not encrypted. The PCI standard, after all, generally requires card data to be encrypted when at rest or in transit over public networks. However, the guidelines do not specifically require encryption at the time of capture. Not surprisingly, since the incident came to light, Hannaford has started encrypting card numbers from the moment they are swiped ...
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
at checkout counters. Many retailers already perform these actions as a best practice, although it is likely that many more currently do not.
Encryption on this scale can be expensive, both in terms of installation and of key management and maintenance, and even some security experts would agree that such a measure is overkill if certain other security measures are in place. The PCI DSS took this assumption into account. Contrary to some interpretations of the standard, PCI does not mandate encryption of card data at all times. In fact, the standard spells out how a company could avoid the use of encryption and still remain compliant through the use of "compensating controls" to protect data at rest. This approach is allowed "for companies unable to render cardholder data unreadable (for example, by encryption) due to technical constraints or business limitations."
The basis for such compensatory controls is spelled out in Appendix B of PCI DSS version 1.1, which makes it clear that "Only companies that have undertaken a risk analysis and have legitimate technological or documented business constraints can consider the use of compensating controls to achieve compliance." The standard goes on to make it clear that compensating controls consist of either a device or combination of devices, applications and controls that meet four very specific conditions:
1. Provide additional segmentation/abstraction (for example, at the network-layer)
2. Provide ability to restrict access to cardholder data or databases based on the following criteria:
IP address/Mac address
Application/service
User accounts/groups
Data type (packet filtering)
3. Restrict logical access to the database
Control logical access to the database independent of Active Directory or Lightweight Directory Access Protocol (LDAP)
4. Prevent/detect common application or database attacks (for example, SQL injection).
PCI on network segmentation
So here we have PCI DSS 1.1 addressing network segmentation, and this is not the only place that mentions the practice. In discussing the scope of the standard, the PCI DSS preface notes that "Adequate network segmentation, which isolates systems that store, process, or transmit cardholder data from those that do not, may reduce the scope of the cardholder data environment." In other words, if you segment your network and keep cardholder data within its own segment, you will not only make it safer, you may also reduce the burden of PCI compliance, which was never intended to apply to all networked devices within an organization, only those that store, process, or transmit cardholder data. The standard suggests, but does not mandate, that companies keep cardholder data on a separate network segment behind a firewall with proper user authentication and a properly configured ACL (access control list). In this scenario, the task of compliance is potentially contained to that network segment.
Of course, implementing a network architecture that enables this type of segmentation may not be easy for some organizations given the way that their systems have evolved over time. However, one has to wonder why network segmentation was not part of the original architecture; after all, it is hardly a new concept. For more than a decade, well-designed systems built with data protection in mind have split internal networks into sub-networks. Not only are performance benefits to be gained, but such segmentation can also limit the scope of a compromise, whether it is an internal or external attack, a malicious breach or even a non-malicious misconfiguration. The separation-of-duties requirement in financial systems often drives network segmentation.
Network segmentation means that each network exists within a "boundary of trust." Anything that crosses the boundary needs to be checked to make sure it can be trusted, whether they are devices, packets, protocols, applications or users. And the checks must be applied to both incoming and outbound traffic. We don't yet know how malware got onto all those Hannaford servers, but it seems likely that they were all part of the same network; there is nothing in PCI DSS to say that's not acceptable. But both PCI DSS and traditional network security thinking caution against putting all of those machines in the same network, particularly when, as in the Hannaford case, they were known to transmit targeted data in the clear. It seems that whatever trust boundary existed did not prevent card data from being sent out of the network to offshore servers.
Segmentation and the 'security standards dilemma'
What should the standard say about segmentation? This is the point at which we run into the "security standards dilemma." Make a security standard too broad and you risk making statements that boil down to something ridiculous like: "Protect all sensitive data at all times so that no attackers can possibly access it, ever." Get too detailed in prescribing specific technologies and you risk people saying things like: "Compliance does not require us to encrypt over non-public networks, so we don't" or "Network segmentation is not mandatory, so we don't use it."
The goal of any security standard is better security, but simply working to a standard cannot by itself create security. That result comes from smart system design, implementation and management, which weighs all of the risks, even as those risks evolve. If nothing else, the Hannaford breach teaches retailers that they need to up their game. Attackers are now well-funded and profit-driven. Simply getting certified as PCI-compliant will not protect against them (although it will protect against some finger-pointing and most of the fraudulent charges that result from attacks). It's important to note, too, that network segmentation is not a cure-all. A trusted user can always take advantage of that trust. However, by properly setting trust boundaries, you can limit that abuse.
About the author:
Stephen Cobb has nearly three decades of experience in computer audit, security, and data privacy. He authored a comprehensive manual of personal computer security in 1992 and has been a CISSP since 1996. One of the first analysts to predict that privacy concerns would become a leading driver of enterprise security, Stephen published a privacy handbook for businesses in 2002. A co-founder of two successful security startups, he helped develop ground-breaking network security technology acquired by Symantec in 2004. When he is not busy advising clients or conducting seminars, Stephen is an adjunct professor of Information Assurance at Norwich University, Vermont, where he helped create the curriculum for the award-winning Master of Science in Information Assurance degree.
|
|
|
|
|
|
