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“.

I on occasion get asked whether the data that is stored in call center systems, such as audio recordings and screenshots, is also regulated. Lately I have been asked if there is some way to easily find just the sensitive information in audio or video files and encrypt or hash it without affecting the rest of the data.

At first I thought this a strange question. It is the kind of question where I have to wonder if the person asking already has the answer but they hope for some kind of miracle or change in the laws of physics that will save them a huge headache. Then I came to hear about a massive breach that involved 57 hard drives with call center data.

The Blue Cross Blue Shield story is tragic. The Eastgate Hard Drive Theft has cost over $7 million thus far and required nearly six months of dedicated forensics work to clarify who is affected. A press release from BCBS revealed more than a half million customers had their information on the drives.

As of February 18, 2010, the total number of current and former members having been identified remains at 521,761, with 220,133 members in the Tier 3 category and 301,628 members in the Tier 2 category.

The tiers are set by risk level, meaning the amount of data exposed. Tier 3 is the highest risk with name, social security, date of birth and address.

Throughout the press releases, stories, and official breach letter it is hard not to see a clear theme of encryption. Although some may have continued to question how best to secure call center data up until now, this breach essentially puts the discussion in a whole new light. The use of drive or full database encryption for systems with audio and help files like screen-shots will from this point on have a much more clear risk profile. In fact, it now will no longer be sufficient to encrypt. I expect pressure now to rise to remove sensitive information from the audio files altogether, or prevent it from being archived. The PCI security standard under Requirement 3.2 is already headed this direction.

This also reminds me of the RAF incident last year.

The breach involves audio recordings with high-ranking air force officers who were being interviewed in-depth for a security clearance. In the interviews, the officers disclosed information about extra-marital affairs, drug abuse, visits to prostitutes, medical conditions, criminal convictions and debt histories — information the military needed to determine their security risk. The recordings were stored on three unencrypted hard drives that disappeared last year.

Time to raise the bar and introduce better controls for media storage.

The curious thing about the ticket sales model is authorization. Ticketmaster was authorized to sell tickets, but when a group bought all the tickets and resold them for profit, they fell into trouble with the law. SFGate reports on the Alameda man charged in ticket-hacking scam:

Lowson and Kirsch were part owners of Wiseguys, while Stevenson was the company’s chief computer programmer and Nahdi was chief financial officer, authorities said. The men created computer programs that bombarded online ticket vendors including Ticketmaster.com and purchased tickets automatically by impersonating individual visitors, investigators said.

Joel Stevenson faces a 43-count indictment and charges of wire fraud — his work earned an estimated $25 million.