Blog

3 dingen om te leren van de grote pincode-inbraak bij de Monzo bank

Eerder deze week kondigde de nieuwe Britse bank Monzo via zijn blog aan dat ze ongeveer 20 procent van de pincodes van gebruikers verkeerd hadden opgeslagen. Dit kwam door de manier waarop het systeem was ontworpen wanneer je een paar verschillende acties binnen de applicatie uitvoerde.

De media sprak al snel over een "breach", maar naar mijn mening was dit symptomatisch door de meest voorkomende oorzaak van beveiligingsproblemen: Mensen. Hoe we met dat probleem omgaan is tegenwoordig een van de meest urgente en relevante uitdagingen voor Cyber ​​Security.

Monzo beweert dat in wezen bepaalde onderdelen van de applicatie de PIN-nummers in de logbestanden opsloegen. Gewoonlijk worden deze opgeslagen in een "bijzonder veilig" gedeelte van hun systeem (vermoedelijk een PCI-zone - zoals voorgeschreven door regelgeving), maar in dit geval waren ze dat niet. Het is onwaarschijnlijk dat dit opzettelijk is geweest, maar eerder een coderingsfout die de verkeerde informatie naar de verkeerde plaats heeft gestuurd.

Zodra Monzo deze fout ontdektte, bewogen ze snel om dit op te lossen. Binnen 24 uur hadden ze de applicatie geüpdatet, waardoor vermoedelijk het aanmaken van nieuwe logs met pincodes gestopt werd. Binnen 48 uur was de gevonden informatie verwijderd.

Als grote fan van het NIST Cyber ​​Security Framework wilde ik zien hoe deze gebeurtenis in de 5 fasen ingedeeld kan worden:

  1. Identificeer - De assets en data - Monzo had dit gedaan en zou (vanwege PCI-regelgeving) gegevens opslaan in een aparte zone - als de start!
  2. Beschermen - Je kan er 99,999% zeker van zijn dat een firewall deze PCI-zone beschermt (omdat dit wederom verplicht is) en de logboeken waren gecodeerd
  3. Detecteren - Monzo geeft niet aan hoe lang het duurde om dit probleem te ontdekken, hoewel The Guardian in een artikel aangeeft te vermoeden dat het 6 maanden was. Dit is onmogelijk te verifiëren maar het zou geen ongewoon tijdsbestek zijn
  4. Reageren - het valt niet te ontkennen dat Monzo snel heeft gehandeld om zowel getroffen klanten te informeren als passende maatregelen te nemen om de breach te stoppen. Dit is eveneens belangrijk onder de AVG, waarbij bedrijven een dergelijke rbeach binnen 72 uur na ontdekking moeten melden.
  5. Herstellen - Uit de blogpost van Monzo blijkt dat de betreffende logboeken verwijderd zijn. Hoewel ze verklaren dat ze zich niet bewust zijn van het gebruik van deze gegevens, is dat relatief moeilijk om zeker van te zijn, tenzij iedereen van de 480.000 klanten elke betaling voor de afgelopen 6 maanden op hun account controleert! Dat gezegd hebbende zijn ze snel teruggekeerd naar een situatie waarbij dergelijke gevoelige gegevens niet langer meer blootgesteld worden aan onbevoegde gebruikers en dit moet worden toegejuicht.

Op het eerste gezicht zou je denken dat dit een geval is van uitstekende controle-mechanismen waar niet omheen gewerkt is, maar die eerder zijn vergeten door een mens die gewoon een klus moest klaren met waarschijnlijk geen kwaadwillende bedoelingen. Hetzelfde kan ook gezegd worden van elke openbare Amazon S3-bucket die gevoelige bedrijfsinformatie bevat, maar die er is omdat de persoon die het daar plaatste niet wist dat het verkeerd was of die voor hen simpelweg gemakkelijker maakte om zijn of haar werk te doen.

Dit voorbeeld is een herinnering voor ons allemaal dat cyber security besturingselementen niet statisch zijn, net zoals gebruikersgedrag dat niet is. Cyberbeveiliging controls moeten zich aanpassen aan reële omstandigheden en niet aan gesimuleerde, gecontroleerde scenario's. Het is heel goed mogelijk dat Monzo een zeer veilige enclave voor deze data heeft gemaakt, maar dat in de loop van de tijd sommige van deze gegevens onjuist zijn opgeslagen omdat de toepassingen zich verder ontwikkelden. Ze lijken geen mogelijkheid te hebben gehad om dit buiten de PCI-zone te detecteren, omdat ze vermoedelijk van mening waren dat de gegevens zich altijd binnen deze zone zouden bevinden.

Er is veel te veronderstellen in dit stadium, maar ik denk dat we drie belangrijke leerpunten van de gebeurtenis kunnen benadrukken:

  1. Detectietijden moeten verbeterd worden - Monzo zou dit eventueel al een tijdje niet gedetecteerd * kunnen hebben * (mogelijk 6 maanden) - dat is niet ongebruikelijk, maar vormt mijns inziens de grootste bedreigingsfactor. Mensen zullen altijd fouten maken; we moeten ze alleen eerder detecteren en beschermen. Was het juist de codering van deze logbestanden die ervoor zorgde dat ze niet werden gescand door een Data Loss Prevention (DLP) -tool, die pincodes in een onjuiste beveiligingszone had moeten spotten?
  2. Communicatie is key - Ik wil Monzo applaudisseren voor de manier waarop zij klanten snel informeerden en voor de wijze waarop zij met de situatie om zijn gegaan. Ze hebben de boel niet vertraagd en ze hebben geen spin gegeven aan het verhaal - ze gaven een feitelijke reactie en verontschuldigden zich. Ik geloof dat dit de angel uit de boodschap haalde die ze moesten zenden.
  3. Controles, processen en trainingen moeten continu geëvalueerd worden - Zou correct geïmplementeerde DLP dit probleem eerder hebben kunnen opvangen? Had de persoon die verantwoordelijk was voor het logboek veilig codeeradvies gekregen? En zo ja, was dat nog recent? Was er een regelmatige audit van alle bestanden en gegevens? We moeten de vragen stellen, maar vervolgens ook de wijzigingen aanbrengen om ons voortdurend aan te passen en te verbeteren.

Het belangrijkste is dat we als mensen altijd fouten blijven maken. Dus zorg ervoor dat je beleid, controles en processen daar rekening mee houden.

Stuart Bates - 13 augustus 2019

Pagina delen:

Deze website maakt gebruik van cookies. Door verder te gaan op de site ga je akkoord met ons gebruik van cookies. Lees meer