Messaging security awareness

Our security awareness topic for June is electronic messaging - primarily email with some reference to online chat via Instant Messaging and cellphone SMS/TXT messages.

A lot of social interaction today occurs by electronic means, while organizations are increasingly adopting person-to-person messaging into their business processes for contacting employees, customers, suppliers and various others.  The days are long gone when email was merely a ‘nice-to-have’: email has all but replaced letters, FAXes and memos.

Aside from the email junkies constantly checking their inboxes, most of us start to feel socially isolated if (when!) the messaging technologies let us down (not least me, living and working in the glorious but remote countryside of rural New Zealand).  Availability is clearly an issue, but so too are integrity and confidentiality. Phishing and other social engineering scams assault us from all sides, while many a personal or corporate secret has slipped out in casual conversations via email, SMS/TXT or IM.

Amazon cloud incident a lesson in resilience and forensics

Amazon's EC2 cloud computing service suffered a serious incident on April 21st.  Given that it affected several customers using its EBS (Elastic Book Store) service, Amazon could hardly deny it and has now published an interesting paper explaining what went wrong.

The original trigger was a leeeetle mistake when reconfiguring network connectivity for some planned work.  Primary network traffic was redirected to a network with inadequate capacity, resulting in the servers losing the vital network connections they need to remain in synch as part of a cluster.  This in turn triggered the servers to try to re-synch, which exacerbated the network performance constraint until the house of cards fell.

It caught my eye that Amazon's cloud-based relational database service was impacted by the incident:

"In addition to the direct effect this EBS issue had on EC2 instances, it also impacted the Relational Database Service (“RDS”). RDS depends upon EBS for database and log storage, and as a result a portion of the RDS databases hosted in the primary affected Availability Zone became inaccessible."

It also caught my eye just how much resilience is built-in to Amazon's cloud architecture - and yet all that technical brilliance was foiled by a config error, presumably just an unfortunate typo by some network operator having A Bad Day (been there, done that!). These things happen, but designing architectures and processes to be resilient to such operator or indeed user errors is at least as challenging as taming the technology.

Finally, the level of detail in the post-incident report published by Amazon is telling. It is, I suspect, a somewhat sanitized version of a more detailed internal technical report. It describes a complex sequence of events that someone has had to reconstruct from the system logs, alarms and alerts, and no doubt a confession by a red-faced network op. It's an elegant example of the value of forensics. Thank you Amazon for sharing it with us. [If this level of humility and graphic detail from the suppliers turns out to be characteristic of information security incidents affecting cloud services, then cloud security has just gone up a notch in my estimation.]

The world didn't stop for Sony

Another news story of yet another privacy breach at Sony includes a handy timeline of their known breaches stretching back to mid-April.

The latest incident involved 8,500 user accounts at a Sony music site in Greece, which means its another database breach, which is what makes it newsworthy (along with the fact that it was Sony, of course).

Sony is a huge company with information assets all over the world.  Many of them are customer-facing, but many more are internal.  Sony is renowned for its business model of 'creating categories', in other words it constantly innovates, creating and launching hi-tech products aimed at satisfying previously unrecognized and untapped demand, and by the time the market category is wound up to speed, it moves on. Perhaps we'll soon see the Sony Database Security Station hit the streets?

Database security survey

Despite the headline stories about database hacks and privacy exposures, a survey of database users found that respondents particularly feared insider threats.  Many such attacks go unreported - in fact I strongly suspect many more go unrecognized.

Sony incident - yet more

Gene Spafford has told a congressional hearing that, months before the incident, Sony knew it was running old and unpatched software on its web servers ... implying that they were negligent in not patching or updating to address known security vulnerabilities. 

It's not quite so cut-n-dried in practice however as patching/updating production services is itself a risky business (not least because the patched/updated software may have yet more security vulnerabilities). Sony evidently had other/compensating controls in place, since they at least detected the latest breach through their network security monitoring.

Unfortunately, this happened too late to stop the hacker/s extracting personal information probably including credit card numbers.

LastPass database compromised

Brian Krebs' excellent blog alerted me to a probable database compromise at LastPass.com

LastPass.com ("The last password you'll have to remember!") is an online database or vault for users' passwords and other confidential user information.  Naturally the user information is encrypted, using a 'master password' and a salt to generate the cryptographic key.  It appears that hackers may have broken the site's security to access and steal encrypted data from the database, possibly including the salts.  They are presumably hard at work brute-forcing those master passwords right now, so the race is on for users of LastPass to login and change their master passwords before the crackers access all their stored data - and then go on a rampage though users' accounts on other systems using the stored passwords.

This is exactly the kind of compromise that sites such as LastPass seek to avoid at all costs.  They do so through a process of examining their information security risks and mitigating them, normally through the use of information security controls such as database encryption, server hardening, application security, logging and alerting.  The compromise was initially spotted as a network traffic anomaly sounding the alarm on their network/security monitoring software.

LastPass, to their credit, have been quick to notify users about the breach and encourage them to change their master passwords ASAP.  Hopefully they will also have diagnosed and of course fixed whatever vulnerabilities were exploited by the hackers, otherwise they may just come back for another bite at the cherry.  LastPass customers are likely to be rather wary of continuing to use the service, but their options are limited - they could try remembering and managing all their passwords themselves (in the hope that they can do so more securely than LastPass) or they may be looking at other password vault options and trying to evaluate their security arrangements (not easy as companies are naturally reluctant to divulge all their security arrangements in public).

If you're interested, Google knows about loads of password vault options.  Unfortunately, it doesn't really know how secure they are. Given that you intend to store some of the most confidential information you have, consider your own risks carefully before proceeding.

Sony incident - more

According to the LA Times, Sony has now confirmed that 10 million credit card numbers may have been stolen in the PlayStation network hack. 

The credit card numbers were evidently hashed rather than encrypted, which is potentially a good thing.  A strong hashing scheme works like a bit like a non-return valve:credit card numbers feed in at one end, are processed through an algorithm into a hash value, and that gets stored on disk.  However, there is [almost] no way to push the hash value backwards through the algorithm to regenerate the credit card number.  If they had been encrypted, the crypto key would have unlocked all 10 million card numbers.

Hashing is normally used for passwords.  Having initially created and stored a hash of someone's password, the next time they login, the password they present is hashed in the same way and the hash values are compared for a match, indicating that the original password (or, strictly speaking, a password that gave the same hash value) has been presented by the user.  Since the password itself is not stored on disk, a hacker who steals the password file does not immediately have access to the passwords.

Unfortunately, there are several potential flaws with hashing:

1. The security depends heavily on the strength of the particular hashing algorithm used, in two main respects:  firstly that it cannot be reversed mechanistically, and secondly that the chances of two different inputs generating the same hash output are vanishingly small, making "hash collisions" extremely unlikely.  It is vital that a suitable algorithm is chosen.  MD5 has been popular for nearly 20 years but the algorithm is now deprecated in favor of the SHA-2 family.  [We don't know which one Sony used.]
   
   
2. Brute force attacks are possible, hashing either random inputs or specific strings and searching for a match.  In the case of credit card numbers, the first few digits are limited to the codes used by the credit card companies and banks that issue the cards, leaving the remaining digits to be found.  That's not a huge range of valid inputs to check.  What's more, with a file containing 10 million hashed card numbers to check each generated hash against, a cracker is far more likely to find a match somewhere in that pool than if he was looking for a match to a single hash value (a statistical oddity known as the birthday paradox).
   
   
3. Hash values on a single system are often 'salted' with a pseudo-random value to make the cracker's job harder again: he now has to guess not only the correct input string but also the salt.  The input range is much larger - provided he cannot simply obtain the salt by some direct method.  If the hacker had full unrestricted access to the Sony database, he may well have had unrestricted or privileged access to the system, and may perhaps have been able to steal the salt from disk or even observe it in live memory (seems unlikely).

Anyway, the consequence for anyone who has used their credit card on the PlayStation website, or whose children might have done so, is that they should treat the card as compromised and call the issuer to cancel it immediately - hopefully before the hacker and his cracker friends break the code.  The clock is ticking.

Security firm's database hacked

According to The Register:

"Try this for irony: The website of web application security provider Barracuda Networks has sustained an attack that appears to have exposed sensitive data concerning the company's partners and employee login credentials, according to an anonymous post."

Barracuda's own application firewall appliance was offline for maintenance at the time, and hence failed to block the SQL injection attack.

"Bugger" said Barracuda's management.

Sony database security incident - a hot awareness topic

Anyone who has seen the huge furore in the press and the blogoshpere over the Sony PlayStation hack will surely agree that database security is a hot topic right now, so it's timely for us to release a thoroughly updated, revised and expanded awareness module on database security.

We've used the Sony incident as a topical case study to illustrate the materials. We're hoping that customers will use the materials straight away, helping their employees make the link between the news coverage, their own privacy, and the privacy of other people whose personal information they may well be handling at work.