RackForest-hack: a tájékoztatás és eseménykezelés iskolapéldája

rackforest-breach.png

Még április 26-án feltörték az egyik legnépszerűbb hazai hosting- és tárhelyszolgáltató, a RackForest ügyfélportálját (portal.rackforest.com).

A támadók hozzáfértek a portálhoz tartozó bejelentkezési adatokhoz, illetve azokhoz az alapértelmezett jelszavakhoz, amelyeket a különféle szolgáltatások létrehozásakor állít be a rendszer automatikusan, a support ticketekben esetlegesen előforduló jelszavakhoz, illetve az ott szereplő egyéb adatokhoz.

Nem magáról a támadásról akarok azonban írni.

Nincs tökéletesen védett rendszer, és nyilván a RackForest ügyfélportálja sem volt tökéletes. Amiről írni akarok, az a csapat reagálása a bekövetkezett eseményre, amely röviden összefoglalva: iskolapélda. Így kell csinálni.

Sok esetben tapasztalom (ez nem olyan, mint amikor a vlogger azzal kezdi, hogy „sokan kérdeztétek”), hogy a GDPR nyomasztó matériája alatt is jellemzően az a szervezetek reagálása, hogy megpróbálják elsikálni, elleplezni a bekövetkező eseményt, illetve ha már elkezdenek valamit csinálni, akkor csak a maszatolás és ködösítés megy.

Ilyen esetekben csak a nyilvánosság, egy esetleges nagyobb botrány szokta „őszinteségi” rohamba lovallni a cégeket, amikor már a bekövetkezett kár többszörösét szenvedi el a szervezet reputációban, és évek múlva is szerepelni fognak a presalesek előadásaiban.

Ezért volt lelkesítő a RackForest hozzáállása a történtekhez.

Bevallom, büszke RackForest ügyfél vagyok. Nem a partvonalról beszélek, ügyfélként és érintettként mondom, hogy egyetlen rossz gondolatom sem volt, amikor megkaptam a RackForest első értesítését az eseményről.

Sokat foglalkozom adatszivárgási eseményekkel illetve kezelésükkel, így nem az volt az első és második gondolatom az értesítőt olvasva, hogy „menjenek a fenébe, töketlenek ezek is” – ellenkezőleg, nagyon nagyra értékeltem azt a korrekt eljárást, amelyet a RackForest az eseménykezelésben, és főleg a tájékoztatásban nyújtott.

Így nézett ki az ominózus első tájékoztatás:

1_1.png

Miért jó ez a tájékoztató? 

  • Mert van. Nem 3 nappal később találom meg az elvitt adatbázist egy orosz fórumban 200USD-ért meghirdetve.
  • Rövid, tömör, informatív. Nem tartalmazza ugyan, hogy pontosan mi és hogyan történt, de itt még nem is kell, a kivizsgálás még folyamatban van.
  • Nagyon tetszik a „akár hétvégén is” beszúrás, úgy érzem, hogy valóban fontosnak tartják a tájékoztatásomat. Nagyon ügyfélbarát!
  • Tartalmazza, hogy az észlelés után mit tettek annak érdekében, hogy csökkentsék a kárt, illetve tartalmazza, hogy nekem mit kell tennem.
  • Előremutató fejlesztést vetnek fel, amellyel növelni akarják a biztonságot.

 3 nappal később megérkezett a részletes tájékoztatás is:

2_1.png

Miért jó ez a tájékoztatás?

  • Mert minden szükséges információt tartalmaz: mi történt, mikor történt, pontosan mihez fértek hozzá a támadók, mit tett a csapat annak érdekében, hogy minimalizálja a kárt, mit tett a csapat annak érdekében, hogy kisebb valószínűséggel következzen be hasonló esemény, milyen további biztonsági fejlesztések várhatók a közeljövőben.
  • Tájékoztatnak, hogy nem elégedtek meg csak a jelszócsere felhívással, külön ellenőrzést hajtottak végre, és aki magától nem változtatott jelszót, annak megváltoztatták a jelszavait, illetve kikényszerítették a jelszócserét.
  • Tájékoztatnak, hogy megtörtént az esemény hivatalos lejelentése a NAIH felé.

A post-breach eljárások, azaz az ilyen jellegű incidensek bekövetkezte után elinduló folyamatok egyre nagyobb hangsúlyt kapnak. Kicsit abból is ered a dolog, hogy egyre inkább bebizonyosodik, nem lehet a rendszereket mindig megvédeni, így a bekövetkezett kár minimalizálására érdemes, szükséges, kell erőforrást fordítani.

Látható, hogy itt nem volt mismásolás, nem akarták elhallgatni az eseményt, arra törekedtek, hogy megoldják a problémát, és biztonságosabbá tegyék a rendszert. A folyamatba bevonták az ügyfeleket, és ha az ügyfél nem tudott időben reagálni, akkor az ügyfél érdekében elvégezték a szükséges jelszócseréket az ügyfelek helyett.

Nekem ez nagyon tettszik.

Persze, sajnálom, hogy a RackForest-nek végig kellett vinnie egy ilyen folyamatot, de ahogy végig vitték, engem arról győzött meg, hogy továbbra is ügyfelük maradok.

Lehetne ezt ügyfél oldalon úgy lereagálni, hogy nem bízom meg bennük többé, hiszen feltörték a szolgáltatást – de sajnos minden szolgáltatásnak vannak sérülékenységei, és akkor már inkább bízom olyan szolgáltatóban, akinek a szakmai tisztessége egy ilyen esemény kapcsán sem ingott meg, sőt, példát mutattak arra, hogyan is kell ezt jól csinálni. (De azért srácok, remélem jó ideig nem kapok Tőletek ilyen leveleket! :))

Számomra a RackForest-példa tanulsága, hogy az incidenskezelés a jó kommunikációval kezdődik, és a reputációs károk nagymértékben csökkenthetők azzal, ha a szervezet megfelelően tájékoztatja az ügyfeleket egy ilyen esemény bekövetkeztekor, valamint a helyreállás után. 

(A végén kiemelném, hogy Nabil Atiyeh, a RackForest vezetője hozzájárult a post közzétételéhez, mivel ő is azt gondolja, hogy a példájuk jó tanulságokkal szolgálhat más szervezetek számára)