"We have conducted a review to ensure this never happens again"

There's a few common phrases that crop up in press releases and notifications about data breaches: "we take security very seriously" being one of the stock sentences which is often followed, in my mind at least, by "well that didn't work then".  I fully acknowledge, however, that a data breach or hack can happen to anyone and it's never going to be a pleasing experience to have to go public about your own breach.

The phrase that annoys me most though is "we've made changes to ensure this never happens again", or words to that effect.  Taking that phrase at its most literal there's no issue - the explicit incident that has already happened cannot happen again - but that's not what organisations are trying to convey.  The aim is to reassure customers that they'll be safe, lessons have been learned, we won't fall foul again.

But is it true?

In cyber security we generally consider that it's a case of when you'll be hacked, rather than if.  In my youth I had a shared web server running from my bedroom and the server was hacked.  At the time we suspected this was via telnet, which one of the group wanted leaving open.  Needless to say, after the attack it was closed!  Sadly I didn't know enough at the time to perform a full investigation.  I've also had a work web server hacked on my watch, many years ago, resulting in the loss of the organisation's main website.  I took the decision to dispose of the Windows 2003 Web Edition server, restoring from a known good copy of the website on a new Linux server [1].

Triaging events

In my day job I have to triage breach reports as they come in, determining if there has been a breach at all (we get sent some false positives) and who needs to deal with it.  On the internal reporting form there's a key question:

What steps have been taken to stop this from happening again?

Quite often the answer here is "email sent to the team to remind them to be careful" or "team member sent on further training".  Bear in mind I see a lot of the reports, and as you can imagine, given my dislike of "to ensure this doesn't happen again", this section is one I'm particularly interested in.   Over time I start to see patterns and after a while you start to wonder if the "email sent to the team" a) actually happened or b) has any affect.

Accidental breaches & making changes

It hopefully goes without saying that the required changes depend on the reason for the breach and what's been tried before.  I'm going to use a couple of examples here, one a breach made possible by the physical realm, and another one entirely digital.

First up the "physical breach".  Part of an organisation that I've worked for sends letters to customers, often in large batches.  A letter consists of:

• A printed mail-merged letter, sometimes multiple pages.  Where possible this is double sided to save paper and postage weight
• An envelope

There should be a 1:1 relationship here - one letter, of however many pages, goes in one envelope.  Sadly that's not always the case and multiple letters can end up in one envelope, resulting in one lucky recipient getting someone else's data.  Often there's no indication this has happened until the recipient contacts the organisation.

For this scenario, "double enveloping" often results in the business unit servicing the equipment - a sticky roller may pick up too many sheets to automatically put into an envelope.  There's only so many times this remedial action should be attempted though before the whole process is reviewed.  It would be much better if the correct number of envelopes were placed in the tray[2].  Any envelopes left at the end indicate a need to count the number of letters that have been prepared for posting.

Looking to a common issue in the digital realm there's the issue of a misdirected email.  There's only so many times you can remind people to be more careful before it's clear another control is needed.  If auto-complete is the reason for the problem, and let's face it, we've all picked the wrong entry, would turning auto-complete off mitigate the risk?  Sometimes though the issue is caused by the recipient providing their address incorrectly in the first place.  This could be resolved by requiring the recipient to confirm their email address by sending a verification email, yet it's frustrating how many systems don't require this.

Attacker caused breaches

So far I've only talked about breaches caused by human error, but we all know that's not the only source of a data breach.  Malicious actors will often look to compromise a system in order to harvest data to be used in an onward attack or to profit from immediately.  Consider the recent Twitter account takeover, where compromised accounts were used to tweet crypto currency scams.  Twitter is still working through the aftermath of the breach and you can read their statement online.

A breach caused by an attacker is much more difficult to clean up and to prevent a repeat occurrence.  For starters it can be difficult to know you've cleaned up completely, so a full rebuild of your systems may be necessary.  It's often that reports say the attack was "sophisticated": not always the case but it's better for public relations (PR) to say that.

Staff training can be a good move at this point but it's worth considering the issue may not have been caused by a staffing issue.  For example, where an attacker has exploited a zero day vulnerability[3] there would be little benefit to training (an already trained) staff - the problem would have occurred regardless.  In Twitter's recent case it's considered the attackers got in via social engineering.  As a result, providing training to help staff defend against social engineering would be beneficial.

Conclusion

I'm not sure I haven't lost my way as I wrote this post, but hopefully I've managed to convey the point that if you're going to say a "review has been conducted to ensure this never happens again" that you need to have conducted a useful review.  Further, the steps you take following that review need to be appropriate and proportionate.  It isn't enough to apply the same fix over and over again - clearly your "fix" isn't working and you need to take a different approach.

It's a dangerous world out there.  Stay safe!

Banner image: Personal data breach by hrkljus on OpenClipart.org

[1] Frustratingly I was planning to decommission the 2003 server anyway as it was costing the organisation a monthly fee.  Since the move to a faster connection at the offices there was no need to use a third party hosting firm.

[2] Clearly there's a margin for error here, as it's easy to lose count when you're working with hundreds of envelopes.  Measuring by weight would help alleviate this.

[3] A previously unknown vulnerability only discovered by defenders once it begins to be exploited in the wild.