Security lessons from a car park worm

A news item about an NZ car park card payment system being infected with the Conficker worm, and potentially compromising customers' credit cards, is a classic example of the potential fallout from an incident that probably would not have occurred if the company concerned had been proactively tracking the appropriate information security metrics.

According to Stuff.co.nz's article "Car park hack puts credit cards at risk":
"Hundreds of parking machines used by thousands of motorists a week may be infected with a virus allowing hackers to harvest credit card numbers.  A compromised machine in Wilson Parking's Alexandra St car park in Hamilton prompted security experts to warn motorists to check their credit card statements if they've recently used a machine at one of the company's 276 car parks across the country.  But Wilson Parking says there is no problem with the system.  The Hamilton machine was displaying an error message on Monday and Tuesday warning it was infected with the Conficker virus, the same virus which disabled Waikato District Health Board's 3000 computers in 2009."
The article makes a right muddle of virus, worm, hacking and identity theft/credit card fraud, but that aside, it seems clear that Wilson Parking has fallen seriously behind with their patching of public-access systems that are processing credit cards, meaning they handle personal and financial data.  In information security risk terms, this was an eminently predictable incident that should have been avoided. 

The incident might have avoided or at least ameliorated using controls such as:
  • Patch management, keeping all their distributed and office systems reasonably up-to-date with patches and especially the critical security patches;
  • Periodic security reviews, audits and tests of the systems, which should have identified this issue long ago;
  • Antivirus software, again maintained up-to-date with virus signatures and periodically checked/tested; and
  • Strong incident identification, management and response policies and procedures, reinforced by security awareness and training (their management should probably have known about the incident before the journalist called, should already have been well on top of the response, and should have known to refer inquiries to someone trained to deal with the press).
All of those I would have thought would be a routine part of their information security arrangements, particularly if they are subject to the requirements of PCI-DSS and other compliance obligations (e.g. privacy laws), let alone good security practices such as ISO27k.

At a higher level, Wilson Parking's management should have known there was trouble brewing through a number of management-level controls and information flows (including suitable metrics, naturally!), hinting at a possible governance failure here.  A simple metric such as 'patch status' or even 'unpatched vulnerabilities' should have indicated in bright red that they were way behind, and the security and risk people should have been clamouring for attention and corrective action as a result.  In theory.

However, let me be clear: I am only guessing at what really went on in this case, based on the very limited and perhaps misleading and inaccurate information in the news article.  I have no further knowledge of Wilson Parking's security arrangements, metrics, controls or risks, nor should I - it's not my business.  It is conceivable that they have simply been caught out by a one-off fluke and a journalist prone to hyperbole.  As far as I can tell, Conficker is more likely to have been sending spam than stealing credit card numbers.  It is vaguely possible that management deliberately and consciously accepted this risk for genuine business reasons (such as the practical difficulties of managing, updating, testing and maintaining physically distributed and hardened IT systems) ... although that begs further awkward questions about their risk/security management and contingency planning!

The real point is to learn what we can from incidents like this, the better to avoid ending up in the same situation ourselves.

Would YOUR security controls have avoided something along these lines?

Would YOUR security metrics have made the accumulating risk obvious to management?

What do YOU need to do to check and perhaps update YOUR information security arrangements?

Think on.