Profile

unixronin: Galen the technomage, from Babylon 5: Crusade (Default)
Unixronin

December 2012

S M T W T F S
      1
2345678
9101112131415
16171819202122
23242526272829
3031     

Most Popular Tags

Expand Cut Tags

No cut tags

May 5th, 2011

unixronin: A somewhat Borg-ish high-tech avatar (Techno/geekdom)
Thursday, May 5th, 2011 03:12 pm

We've all heard lots of examples of security breaches, most recently Sony's entire PSN gaming network getting totally 0wn3d and virtually every bit of user credential data stolen including credit card data.  Some companies handle it well.  Some handle it poorly.  Sony actually reacted relatively well this time, shutting down PSN until they'd cleaned and re-secured it, publicly owning up to the breach, and notifying all their customers.  After the Hannafords data breach a couple of years ago, RBS Citizens Bank pre-emptively replaced all customer debit cards that had been used at a Hannafords store, just in case they might have been compromised.  (This not only protected customers, it made sound business sense too; it's cheaper to preemptively replace a bunch of cards that would have been replaced in the next year or two anyway, than to clean up fraudulent transactions later and possibly eat losses of anywhere from hundreds to thousands of dollars per card.)

Other companies haven't handled it so well.  I'm not naming any names, but there have been companies which it has transpired have suffered massive customer data breaches and simply didn't bother to tell anyone until they were outed, and other companies that only notified their customers of breaches in states where the law forced them to do so.

Here's an example of doing it right.  Lastpass.com is an online password-keeper service.  On Tuesday morning, they noticed a network traffic anomaly during routine (for them) analysis of network traffic logs.  They couldn't be certain what it was; but they couldn't be 100% certain that it wasn't evidence of a breach.

So they played safe, and handled it as though it was.

In this case, we couldn't find that root cause.  After delving into the anomaly we found a similar but smaller matching traffic anomaly from one of our databases in the opposite direction (more traffic was sent from the database compared to what was received on the server).  Because we can't account for this anomaly either, we're going to be paranoid and assume the worst: that the data we stored in the database was somehow accessed.

A lot of their customers are complaining about being forced to change their master passwords.  But this is the right way to handle a possible security breach.  If you cannot rule out a breach, you study the evidence you have, you figure out the worst probable case consistent with the available evidence — and then you handle it as though that worst case happened.  Because in the long run, it's MUCH safer, and much less expensive, to assume you were breached and later find out that you were not, than to assume you were not breached ... and later find out that, actually, yes, you were.

unixronin: Very, very silly. (Goonish)
Thursday, May 5th, 2011 04:08 pm

(15:39:49) et: Any squirrelmail gurus around here ?

(15:53:22) Alaric: it's really hard to make mail out of squirrels.  They're furry and kinda squishy.  Makes it hard to link them together.

(15:54:55) Alaric: On the other hand, if you actually succeed, when you put your squirrelmail hauberk on you look like a Wookiee.

(15:55:33) dan: squeak havoc and let loose the squirrels of war

Tags: