A SQL injection attack successfully breached the brokerage firm Davidson & Co in 2007 and exposed nearly 200K customer records.

Investigators followed a trail that led to the arrest of three Latvians in the Netherlands. The suspects allegedly were to pick up money from the company in an extortion plot in which D.A. Davidson initially was advised to send the money to Russia.

The Financial Industry Regulatory Authority (FINRA) has just announced a fine of $375K with Davidson to settle the matter.

Davidson had argued that the attack was “new at the time” and “relatively sophisticated”. They also claimed extensive security procedures in place during the intrusion such as “regular review” of logs for the firewall protecting the breached database. Davidson hired a third-party auditor just before the breach who was unable to penetrate. The regulators countered that an audit a year prior had recommended a network intrusion detection system but it had not been installed. The regulators also faulted Davidson for not encrypting the database information, for leaving the database with a default vendor password on a web server that was connected directly to the Internet.

Taken altogether, Davidson’s claims about sophistication and attacker stealth pale in comparison to the apparent lack of network intrusion detection in 2007, lack of proper segmentation of the database and use of a default password.

Clearly regulators and and the law (e.g. cases in Illinois and Michigan) are turning up the heat on information security management.

Hear more details about why this breach is significant, as well as others, in my Top Ten Breaches webcast for the RSA Conference next week.

April 20th I will be presenting a webcast: Top 10 Security Breaches

This encore session from RSA Conference 2010 reviews current breach data, illustrates trends and offers predictions of future threats. Davi Ottenheimer pulls out all the stops and goes deep with technical analysis of how and why breaches were successful as well as broad, with strategies to use in enterprise and even national risk management.

It starts with a high-level review of how to prepare for breaches and concludes with technical details and concrete steps for prevention.

This is a repeat of my sold-out presentation at the Conference in March. Hope you can join us. Thank you to everyone who has attended already.

One of the surprises for me at the RSA conference this week has been how many security experts are harshing on Google.

Perhaps because they are an industry-leader they are more prone to being given a giant black eye. The beating continues. One researcher said flatly that no one should use Google Chrome, while another said fuzzing bugs in Google code is like shooting fish in a barrel. The overwhelming trend in the security group discussion, and perhaps the larger IT professional groups, seemed to be that Google prefers to re-invent the wheel under the guise of innovation. This ends predictably with merely opaque products that have known bugs. An interesting discussion with some ex-Microsoft folks was that they see Google now make classic mistakes of a young Microsoft.

The start of one conversation full of groans was “remember how two DLLs could have the same filename and version yet different checksums and operate differently…”. Google is said to be releasing code changes under the same version as before without notation of fixes. They are silently patching, in other words, but acting as though no one needs to know details for Android as well as Chrome. Innovation and nimble development should not require this.

Two nights ago a security expert argued that it was the nature of a constant beta mentality to shy from the burden/overhead of accountability, but the overwhelming retort in the group was it is a no-brainer to still use release notes and version numbers to ensure bug fixes are captured and…transparent. Do you want to know that your data has been secured and that it was exposed up until now? Easy to see why that conversation then turned to the trust model of clouds and service providers.

With all the harsh commentary I have been witness to this week it is interesting to see Google make a move into critical infrastructure space with their PowerMeter API:

Today we’re excited to introduce the Google PowerMeter API on code.google.com, for developers interested in integrating with Google PowerMeter. This API will allow device manufacturers to build home energy monitoring devices that work with Google PowerMeter. We’re launching this API in order to help build the ecosystem of innovative developers working towards making energy information more widely available to consumers.

I am happy for Google and how they can get so excited about functionality but it also would be nice to hear that they are ready to accept flaws and openly explain their fixes. Their move into energy begs the question whether they can they maintain their current style of security communication:

“Unfortunately, I can’t share any more specific information about timelines or our plans for individual products since our actions will be shaped by what our data shows,” said a Google spokesman.

Fortunately Microsoft now does a fantastic job with their vulnerability announcement and release information. We can only hope, at this point, that Google will learn and eventually catch up. In the meantime, be wary and be wise to the risks of opaque services. Chris Whitener from HP called it “faith-based IT“.