3 things we can learn from the Monzo PIN code breach
Earlier this week popular new UK challenger bank Monzo announced via its blog that they had been incorrectly storing approximately 20% of their users PIN numbers due to the way the system was designed when you performed a couple of different actions within their app.
The media has been quick to jump on this as a “breach” but to my mind this was symptomatic of the most common cause of security issues… humans. How we deal with that issue is one of the most pressing and pertinent issues with Cyber Security today.
Monzo state that essentially some parts of the applications were storing PIN numbers in their log files. Usually these are kept in a “particularly secure” part of their system (presumably a PCI zone – as mandated by regulation) but in this instance they were not. This is unlikely to have been deliberate but rather a coding error that sent the wrong information to the wrong place.
Once Monzo had discovered this error they moved swiftly to rectify the situation. Within 24 hours they had updated their app which presumably stopped new logs with PIN numbers being created and within 48 hours had deleted the information they had found.
As a big fan of the NIST Cyber Security Framework I wanted to see how this event maps into the 5 stages:
- Identify – your assets and data – Monzo had done this and would (due to PCI regulation) be storing data within a separate zone – as the start!
- Protect – you can be 99.999% certain there is a Firewall protecting this PCI zone (as again it’s mandated) and the logs were encrypted
- Detect – Monzo do not state how long it took them to discover this, though the guardian believe it was 6 months. This is impossible to verify but would not be an unusual timeframe
- Respond – You can’t deny that Monzo acted swiftly to both inform affected customers and take appropriate action to stop the breach. This is also important under GDPR that requires companies to report such a breach within 72 hours of discovering it.
- Recover – From their blog post it is clear that the affected logs have been deleted. Whilst they state they are not aware of any usage of this data that is relatively hard to be certain of unless everyone of the 480,000 customers checks every payment for the last 6 months in their account! That said they have moved back to a position whereby such sensitive data is no longer exposed to unauthorised users very quickly and this is to be applauded.
From a first glance you might think that this is a case of, probably, excellent controls in place that were not evaded as such but rather forgotten by a human who just needed to get a job done with probably no malicious intent at all. The same could also be said of every public Amazon S3 bucket that contains sensitive company information but is there because the person who put it there either didn’t know it was wrong or it was just easier for them to do their job.
This is a reminder to us all that cyber security controls are not static, just as user behaviours are not. They must adapt to meet real world conditions, not simulated, audited, scenarios. It is entirely possible that Monzo created a very secure enclave for this data but that, over time, as their applications developed some of this data got incorrectly stored. They do not appear to have had a way to detect this outside of the PCI zone, as presumably, they considered the data would always be inside this zone.
There is a lot of presumption at this stage but I think we can highlight three key learning points from the event:
- Detection times must improve - Monzo *may* have not detected this for some time (possibly 6 months) – this is not unusual but represents the biggest threat factor to me – humans will always make mistakes; we just need to detect and protect them earlier. Was it the very encryption of these log files that stopped them being scanned by a Data Loss Prevention (DLP) tool that should have spotted PIN numbers in an incorrect security zone?
- Communication is key – I would like to applaud Monzo for the way they quickly informed customers and dealt with the situation. They didn’t stall, they didn’t spin a story – they gave a factual response and apologised. I believe this took the sting out of the message they had to give
- Your controls, processes and training must be continually assessed – Could correctly deployed DLP have caught this sooner? Had the person responsible for the log been given secure coding advice? Was it recent? Was there a regular audit on all files and data? We must ask the questions but then make the changes to continually adapt and improve.
Most importantly – remember humans will never improve! We will always make mistakes so make sure your policies, controls and processes take that into account.