Evernote data breach: lessons to be learned

Lesson 2: All data that is worth something to somebody should be encrypted

What Evernote should have done was put less emphasis on the password reset as the solution to the problem, according to MacLeod, who believes it actually served as a sticking plaster for a symptom rather than a cure for the cause. Instead Evernote should have taken the opportunity to explain that it had learned from its mistake and stress, in future, all customer data would be encrypted in order to lesson the reputational impact.

Customers are generally clever enough to recognise it's a good thing when a company admits to errors and explains how they are being fixed.

David Emm, a senior security researcher with Kaspersky Lab, is generally quite happy with the way that Evernote handled the breach disclosure. He insists that it's a good thing to see such companies quantify and specify the nature of a breach, as well as provide an explanation on how the company is addressing the situation.

"Regardless of whether an organisation has a 'template statement' or not," Emm told IT Pro. "The key is to provide a measured response."

If an organisation goes out and categorically states that there has not been any leak of information, but two weeks later it is discovered that there was, the damage to reputation could be significant.

Lesson 3: Don't under-disclose

"In my opinion it is better to put something out quickly to ensure customers are aware than to not respond and to get caught out," Emm insists. "If a statement is rushed and errors are made, then at least the company can explain that they wanted to alert customers as soon as possible. But, if an organisation is criticised for not telling customers soon enough, this will be a much harder corner to fight."

Ross Brewer, vice president at LogRhythm, has a slightly different perspective on the Evernote disclosure statement that. He suggests that this is "a prime example of a blanket breach notification and perfectly illustrates the problem of over-disclosure."

Brewer defines over-disclosure as being "when organisations are forced to reveal more information than is strictly necessary."

For example, they may have to notify every individual who might have been affected by a breach rather than just those who definitely were as in Evernote's case. If they don't have a clear grasp of exactly what information has been lost, it may also force them to overstate the severity of an incident to victims.

Lesson 4: Do not over-disclose

"The issuing of blanket breach notifications in this way will inevitably have negative repercussions for the affected organisation," Brewer warns. "It could lead to a loss of confidence amongst potential and existing customers. Furthermore, every consumer interaction incurs a cost, so it is absolutely vital that firms only tell those who they know are truly affected by a breach."

Rajesh Ganesan, director at ManageEngine, focuses his attention on that obfuscated password reset link. If you look at the email all that you will see is a live link pointing to evernote.com but that is just the anchor text. An anchor is the visible text link that gets displayed using HTML and not the actual link that it points to.

In the case of the Evernote disclosure the actual link was pointing to a site called mkt5371.com and not Evernote itself. Now this type of redirection is common practice, and was probably just being used so as to track the numbers responding and resetting passwords, but to the end user it also looked identical to the type of obfuscated link trickery employed by those who would steal your credentials.

Lesson 5: Clarity is king

"It was definitely a mistake by Evernote to send out the obfuscated password link," Ganesan says. "Hindsight is a great thing, but probably the best way this could have been handled was to expire the passwords of all the users as soon as the scale of the breach was known. This could have meant that any subsequent access attempt by users would have prompted a password reset."

A caveat to this approach would be if the hacker already had got hold of some of the passwords and attempted to change them before the user could. However, this is easily overcome by having a reset mechanism in place with enough provisions to ascertain the identity of the user without solely relying on identifying the correct' old password.