PCI

Lessons in Due Diligence

Posted in Business and Security, PCI on December 2nd, 2009 by Paul – Be the first to comment

An article by Kim Zetter on Wired.com caught my attention:  “Restaurants Sue Vendor for Unsecured Card Processor”.

The gist is that several restaurants purchased Point-of-Sale (POS) systems from a particular vendor.  These POS systems that were sold were apparently not Payment Card Industry – Data Security Standard (PCI-DSS) compliant and that resulted in a breach costing the restaurants a hefty sum.

One issue comes from unpatched, poorly configured remote access and the other alleged problem came from default login administrator userID and passwords.  From the article:

Visa also sent out a bulletin in November 2006 warning that one of the most frequent vectors for hackers to penetrate POS systems was through poorly configured or unpatched remote-access software (.pdf) and default passwords. Nonetheless, the restaurants say, Radiant and Computer World sold them a product that was neither PCI-compliant nor secured against a known attack.

So, the vendor sold them the product that was known to have these flaws but on the flip side, the restaurants bought these systems that are known to have these flaws.   I can certainly see the case here but from a security perspective there are some lessons learned when it comes to due diligence and basic security practices.

1.  If you blindly believe marketing slicks about the “state-of-the-art” product you’re purchasing that can do everything including cooking your dinner and washing dishes…well… you get the point.   Visa had produced a bulletin regarding the flaws with the product a year before one of the restaurants bought the product.   A little due diligence in the selection process would have gone a long way.

2.  So, you buy a product and install it.  It has remote access capabilities.  You leave the default administrator ID and password that is well known to anybody who can grab an online manual.  You’re breached.   If you install a new software product for Pete’s sake, change the default account passwords.  If your bank gives everybody a password of “password” to their online banking, would you change yours or just leave it?  (BTW, they don’t do that… just an illustration).

3.  Implementing a system with known flaws and not updating it is pretty bad.  It’s like installing a Microsoft server and not applying security patches for a year.  You get breached because of a vulnerability that should have been fixed a year ago.  Good luck blaming Microsoft for that one.   Patch management is essential.

By no means am I blaming the victim in this case.  They are chefs and restaurant managers, not IT or InfoSec people.  They relied on the vendor to provide them a product that was up to snuff with PCI requirements and trusted them to sell a product that protected their customer’s information.  When we examine and extended this into our own business and technology implementations, their experience provides some lessons for all of us.  Hopefully we can learn from this and apply due diligence to all of our vendor interactions and purchases.

Using a Framework to Navigate Regulatory Compliance

Posted in Business and Security, National and State Privacy/Security Law, PCI on October 21st, 2009 by Paul – Be the first to comment

The regulatory environment overseeing the protection of sensitive information is incredibly crowded.  Sarbanes-Oxley (SOX), Graham-Leach-Bliley (GLB), the Health Insurance Portability and Accountability Act (HIPAA), HITECH, Red Flags, Payment Card Industry Data Security Standard (PCI-DSS), among a host of state laws and audit guidelines seems to provide the Fort Know of IT risk management if organizations would comply.   The reality is the complexity and costs of compliance may be a contributing factor in the overall risk management failings that appear above the fold in your local newspaper.

While large companies are better equipped to deal with the additional costs for infrastructure, tools, staff, auditors, and third-party vulnerability scanners, the small or medium sized businesses can quickly become stretched to the point of ineffective security.  There may be some paralysis when deciphering multiple regulatory obligations that often overlap or even conflict.    There are opportunity costs when small business executives spend more time dealing with compliance issues than dealing with business strategy.

The solution is not to avoid regulatory obligations.  The solution is to better manage information security and deploy best practices as simply part of the organizational culture.   The way to get there isn’t to go through check boxes for every compliance item that comes your way.  That will drive any person insane and lead to a tangled mess of interwoven security policies, procedures, technologies, etc.   What I believe is a more effective approach to compliance is the implementation of an information security management system following a framework such as ISO 27001/27002.  Many of the controls within 27002 align with the requirements in many of the compliance items so building a consolidated program based on a series of best practices will help meet compliance obligations.

ISO 27001/27002 is simply a framework that defines a security code of practice and best practices across twelve areas.  These include:  Risk assessment, security policy, governance, asset management, human resources, physical and environmental, communications and operations, access control, acquisition, development and maintenance, incident management, business continuity, and compliance.  Pay particular attention to the last one and note that compliance is just one piece of the framework of best practices.   This leads back to a previous post that risk management and information security must go beyond the simple yes or no check boxes of regulatory compliance in order to be effective.

The ability to protect sensitive information is a process that requires ongoing care and feeding in order to protect against the expensive financial and reputation damages of a  breach.  Using a framework such as ISO 27001/27002 allows for a consistent baseline which to measure and certify against.  This minimizes confusion and complexity and goes a long way toward achieving compliance across a wide-array of regulatory requirements while effectively using both technical and human resources to maximize benefit and reduce unnecessary cost.

Small Business – a Target

Posted in Business and Security, PCI, Should Have Known Better on August 26th, 2009 by Paul – Be the first to comment

Organized cyber-gangs in Eastern Europe are increasingly preying on small and mid-size companies in the United States, setting off a multimillion-dollar online crime wave that has begun to worry the nation’s largest financial institutions.

European Cyber-Gangs Target Small U.S. Firms”  Washington Post August 25th

Launching these attacks from “safe havens” against organizations that tend to have limited information security postures is a cash cow for these criminal outfits.  This should be a wake up call to small and mid-size businesses who may not have the knowledge to adequately protect themselves, that some information security help may be needed if they want to stay in business.

If you think this can’t happen to you then understand these attacks are simple and ignoring the threat doesn’t make it go away.  Ask yourself if your company can survive if if its ability to process credit cards is taken away?  If the answer no then perhaps an evaluation of your security posture is in order.

Surprising move by MasterCard

Posted in PCI on July 10th, 2009 by Paul – Be the first to comment

MasterCard made a decision not to allow remote key injection capabilities that allows merchants to install new encryption keys on point-of-sale devices.  Now these merchants are stuck doing this work manually at an off-site facility.  Organizations that are trying to comply with the Payment Card Industry – Data Security Standard are now hamstrung in their implementation capability, especially those who may have hundreds or even thousands of such devices.

It is unknown why MasterCard has taken this route but it certainly is a step backward in securing credit card information in transit and an increase in expense for merchants trying to comply.  This expense somehow will be passed along to consumers.

Considering the goal is to improve security by increasing the level of encryption, it is difficult to comprehend why automating this process would be a problem.  Considering a lot of money has gone into R&D for RKI research and it is designed to reduce the burden on merchants while improving security, I think MasterCard should have to publicly detail why they think that is bad.  There may very well be a reason behind this but as it sits, this is a defeat for secure credit card transactions.