Security and Risk Management Strategies Blog

Is PCI compliance creating a false sense of security?

Blogger: Randall Gamby

I was going to write a blog on small to medium businesses (SMBs) getting PCI compliant, but last week a breach changed all that.  Last Monday, Scarborough, Maine-based Hannaford Brothers Co., a regional Grocery Store chain the Northeast U.S. (and the store I shop at and pay using my debit card) had a breach that exposed up to 4.2 million credit and debit cardholders to potential fraud. 

The result of this breach so far has been about 1,800 instances of fraud as reported by company officials, all company information has been removed from their website (I’m assuming while they reevaluate their transaction strategy and architecture) except for a news brief from the CEO, http://www.hannaford.com/Contents/News_Events/News/News.shtml and the page containing their privacy statements, including their PCI compliance statement:

Hannaford Supermarkets has been certified as compliant with the Payment Card Industry Data Security Standard (PCI DSS). The PCI DSS is recognized as the accepted industry security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. This comprehensive standard is intended to help organizations protect customer credit and debit card account data.

So the question has to be asked, “Are we putting too much faith in PCI compliance to really reduce our risk of exposure?”  Apparently in the unfortunate case of Hannaford, whatever PCI compliance measures were taken to protect cardholder information weren’t enough to keep attackers from infiltrating the organization and stealing this valuable data.  Plus the question has to be asked, “What is a grocery store chain that mainly does Point-of-Sale (POS) transactions doing storing this information anyway?”  It’s not like cardholders have future payment options like they might have at Amazon.com--where their full credit card or debit card information is stored for checking out at a later date.  I guess believing that shopping at a PCI compliant merchant, over a merchant that isn’t PCI compliant, will reduce your chance of having your credit card data stolen isn’t always accurate.

Now I’m not saying PCI isn’t important, after all this breach may have never been found if PCI measures weren’t put in place, but enterprises have to look beyond the task of being compliance and take whatever additional steps may be needed to secure their data against breaches.   

In addition, on 22 January 2008, Visa released statistics on merchant compliance with PCI. Visa reported that as of the end of 2007, 77% of large merchants were PCI compliant (compared with 12% in March 2006) and that 62% of midsize merchants were compliant (compared with 15% at the end of 2006). These two merchant categories represent approximately two-thirds of Visa's transaction volume.  With other credit card issuers lagging, it seems that there’s still a lot of risk in using your credit/debit card out there in the big consumer marketplace.  So the warning of the week is to stay diligent in watching those credit and debit card statements and keep your guard up, whether the merchant has the PCI stamp of approval or not.  In the meantime, I’ll be getting a new debit card (my magnetic strip was wearing out anyway).

Trust, NAC, and the Art of Ceasing Operations

Blogger: Eric Maiwald

In the security world, we talk a lot about trust – the assured reliance on character, ability, or strength of someone or something (according to Webster). We place confidence in products, mechanisms, processes, companies, and people to act in a particular way. The trust that we have in something or someone directly affects how we view the risks associated with various activities.

Our trust may be based on any number of things – who the person is, their reputation, testing done on a product or mechanism, etc. In the network world, knowing who is coming on to the network seems to be an important consideration. The Security and Risk Management Strategies Service (SRMS) at Burton is working on a project to learn how the network fits into an overall enterprise security architecture. This project seeks to learn whether enterprises are currently using or planning to deploy an overlay style of architecture, and whether defenses are being shifted to the endpoints, application systems, information systems, and data centers. It will also challenge the messaging that vendors use to justify their NAC products and their strategy for building security intelligence into networks by tracking recent customer experience with NAC projects and gain an understanding of how network security architecture is evolving in enterprise customer networks. So far in our research, the idea of placing a control to limit the access of unknown people or clients to the network is appearing regularly. It appears that enterprises have a desire (and sometimes a need) to at least find out who is connecting to the network. Maybe that is the basis for identifying how far the enterprise will trust the individual or the client system and maybe that trust forms the basis for a perceived risk.

If there is a need to know who is coming on to my network, does that imply that NAC (network admission or access control) is important? (In a previous blog entry, I talked about the confusion in the NAC market and what NAC actually is) Well, at least identity seems to be important. Enterprises are using the identity of individuals and client systems to make decisions on entry to the network and access to resources once on the network. Other preliminary indications in our research show that the configuration and status of the client system are less important than whether the client system belongs to the enterprise or not and whether the individual is an employee or not. So maybe it is that some type of control over the network is important.

The failure of Lockdown Networks this past week is seen by some as an indication that NAC has failed. I think that goes too far. Our research indicates that some type of control over who enters or connects to the network is important to enterprises. However, trust has another part to play in the success of vendors who offer this type of control. Customers have to have confidence that the vendor can provide the product as advertised and that the vendor will do well enough to provide the necessary support for the product over the long haul. It seems that Lockdown did not inspire the necessary confidence in the market. Perhaps Lockdown offered a product that didn’t fit into what the enterprise customers were looking for or perhaps Lockdown’s financial future was sufficient secure for enterprise customers to take a change on a small vendor.

We will be finalizing our research and presenting the findings from our network architecture research at Catalyst North America in San Diego. Come join us there in June!

Financial Services Roundtable Promotes Information Sharing

Blogger: Dan Blum

Just as King Arthur’s knights gathered around their roundtable to try and divine the future intentions of invaders and other threats to the realm, financial services and other enterprise organizations have a critical need to share information about emerging cybercrime threats and attacks. So it was that one day this Fall in New York, I found myself at a private Wall Street roundtable meeting with leading thinkers from a number of large financial institutions (FIs).

Whereas the previous roundtable meeting I blogged about in the summer concerned general issues, the second meeting addressed predictive threat analysis. Attending were a number of Wall Street firms, National Cyber Forensics and Training Alliance’s (NCFTA), FBI and Burton Group.

The meeting started with a general introduction noting the evolution of the threat from script kiddies to organized crime to state sponsored industrial espionage or low grade information warfare activities. For example, the Russian Business Network (since gone underground, apparently) was a front for organized crime, a one stop shop allegedly tolerated by the Russian government as long it kept its attacks external. The speaker also noted that:

• China, France, Japan, Israel, Germany are similar in that they make no distinction between industrial espionage and national espionage. Some would argue the US is the same. Welcome to globalization!
• There has been good news and bad news for vulnerability management. iDefense says that OS vulnerabilities are generally down. On the other hand, there is now a thriving marketplace for vulnerabilities and the bad guys can find them.
• One thing hasn't changed - 85% of threats are still internal. One financial service had to surveil senior management after finding increased "rolodex activity" after executive departures. The company is working on ways to discourage or stop this behavior.
• Not all solutions are purely technical. With bad guys turning to pump and dump schemes against penny stocks, E*Trade lost $18M. But application developers at one bank were tapped to change the code on the web site so that customers have to call in low priced stocks trades, which are in any case a low revenue source for the company. This procedural solution was a decisive win against pump and dump schemes.

The NCFTA, a non-profit member-supported organization, described “Stock-Aid”, an information sharing service it provides for financial
services facing pump & dump attacks. Through NCFTA, the banks share feeds with the bad guys’ IP addresses and the names of stocks that are being attacked.

Could the industry do more than just block cyberattacks and perhaps shut down the botnets they’re coming from down? In the game of whack-a-mole NCFTA provides a hammer. And the FBI’s Botroast operation took down two large botnets. But new botnets keep emerging.

A more productive approach is to catch criminals by following the money: NCFTA noted that eGold gave over all their data, PayPal cooperates, and so do many other organizations that have been used for money laundering. Unfortunately criminals keep finding new places to hide in the money game; the latest ploy is to move money through online games like World of Warcraft.

The issue of information sharing is important to all industries, not just financial services. That’s why it’s so beneficial to participate in ISACA, BITS, I4 and other organizations. The warriors of information protection can either band together and share information like King Arthur’s knights, or risk falling into a dark age of cybercrime.

Policy-based Management Tools Unite!

Blogger: Randall Gamby

I’ve recently moved over to the SRMS Analyst team from Burton Group’s Consulting organization. Before moving over to the team I spent almost nine years in the field as a Burton Group Principal Consultant. Over these years I’ve worked one-on-one with many of our clients in both North America and Europe, and one of the topics that has always been an issue, and still is in many enterprises, is the process of implementing the enterprise’s policies in technology.

In the Identity Management (IdM) arena everything is moving to “roles-based” management controls. While roles-based controls are a subset of an enterprise’s policies and deal well with access rights for individuals and groups, in the security world “policies” are much more in-depth than just access. Not only do policies govern the actions of individuals, they also deal with data (whether in motion or at rest) and systems. But it seems that every security control system in the market is developing its own policy-based management interface. So the question is, “How many policy-based management interfaces do we need to configure?”

Historically, most enterprises have taken many years to create a relatively consolidated user identity repository (a vast majority of enterprises I’ve worked with use Microsoft’s Active Directory). However, as we move up the food chain to enforcement and compliance tools, products typically don’t--or can’t--read the LDAP user and group information. This forces the enterprise to go back to a siloed approach of creating and interpreting policies.

Think about it. I have a client that has firewalls being run by its Network Group, secure messaging run by a specialized IT group, host intrusion and prevention system (HIPS) being run by Security, and enterprise Active Directory deployment run by its directory team. Each product has policies about users, groups, and resources but barely recognizes the existence of the others; and each claims to have done policy “right.” Are they consistent? Maybe. Are they genuinely doing their best? Of course. Is there a risk to the organization that something has been overlooked? Very probably.

So what has to be done?

I think the first thing that needs to be done is for enterprises to review their policies. In the field many enterprise security managers (confidentially) have expressed a concern that the brave new world of security enforcement has invalidated, or provided scenarios that were never considered, in their original enterprise security policies. Next, I think vendors have to recognize that while policy-based management is a great ideal, it can’t be done in a vacuum. Managing policy enforcement for your set of tools that addresses only a part of an enterprise’s security front, without considering how you can share this with other sets of vendors’ tools working on other fronts, increases the chance of a hole in the defenses. Finally, I know you hear Burton Group say this all the time, but we need a standard to represent “policies” within a set of tools and a central repository--probably “virtual” if you ask the IdM people--that can store these values for the consumption and update of the tools. If a vendor can create a policy-based management interface that works across its suite of products (and some have), why can’t this framework be standardized for a similar group of tools, or even across all security enforcement technologies?

In the end, it will be the market that will determine whether policy-based management will be something that is a tool requirement or an enterprise requirement. If security managers aren’t educated on the “risk” in their current enforcement technologies; if vendors don’t hear from their clients that they’re tired of interpreting their new, and updated, policies for each of their policy-based enforcement technologies; and if standards can’t be created to make this all “consistent” within an enterprise, then efforts to go out and purchase expensive tools to manage their risk may be in vain.