A KRÉTA adatvédelmi incidens tanulságai minden cég számára, avagy mit tanulhat egy vállalkozás egy 110 milliós adatvédelmi bírságból
A lényeg röviden
A KRÉTA rendszert üzemeltető céget 2022-ben informatikai támadás érte, aminek nyomán közel 60 millió személyes adat került veszélybe. Az adatvédelmi incidens végül 110 millió forintos bírsággal zárult. A történet több mint egy technikai kudarc. Tanulságos lecke minden cégnek arról, hogy mi történik, ha valaki nem veszi elég komolyan az adatbiztonságot. Ebben a cikkben végigveszem, mi történt, mit rontott el a cég, és mit tehet Ön, hogy elkerülje a hasonló helyzetet.
Mi történt? A KRÉTA adatvédelmi incidens röviden
2022. november 7-én a Telex számolt be arról, hogy a KRÉTA rendszert fejlesztő céget informatikai támadás érte, és súlyos adatvédelmi incidens következhetett be. A NAIH, vagyis a Nemzeti Adatvédelmi és Információszabadság Hatóság, nem késlekedett. Már másnap hatósági ellenőrzést, majd eljárást indított. Az eljárást lezáró határozat végül 110 millió forintos adatvédelmi bírságot rótt ki a mulasztó cégre.
A történet önmagában is tanulságos, de ami igazán fontossá teszi, az az, hogy szinte minden hibája általánosítható. Bármelyik cég elkövetheti ezeket, amely személyes adatokat kezel. Márpedig ma már gyakorlatilag minden cég ilyen.
Nézzük meg először, mekkora tétről van szó. A KRÉTA legismertebb funkciója az elektronikus napló, de emellett több mint húszféle modulja van, az e-ügyintézéstől az iskolai étkezésen át az egészségügyi adatokig. A rendszerben tanárok, diákok és szülők személyes adatai szerepelnek, köztük adóazonosító, TAJ szám és egészségügyi adatok is. A cég becslése szerint közel 60 millió személyes adat található a rendszerben.
Hogyan történt a támadás, ami az adatvédelmi incidenshez vezetett?
A történet ott kezdődött, hogy 2022. szeptember 15-én ismeretlenek adathalász támadást hajtottak végre. A cég egyik ügyfélszolgálati munkatársa megnyitott egy fertőzött elemet egy adathalász levélben. Ezzel a támadók megszerezték a jelszavait, és hozzáférést kaptak a rendszerhez.
És itt jön az első nagy tanulság. Ez a munkatárs minden hozzáférési jogosultsággal rendelkezett, mind a teszt, mind az éles rendszerhez. Ráadásul rendszeresen mentett le személyes adatokat a saját gépére. A támadás idején tizenkét oktatási intézmény teljes adatállománya volt a számítógépén.
A munkatárs csak napokkal később szólt a vezetésnek. A cég lecserélte a gépet, törölte a jogosultságokat, új jelszavakat adott, és az ügyet lezártnak tekintette. Aztán közel két hónappal később jött a fekete leves. A támadó a cég belső kommunikációs csatornáján közzétette, hogy feltörte a rendszert. Csak ekkor indult el egy alaposabb vizsgálat és az adatvédelmi incidens hatósági bejelentése.
Felmerül a kérdés, hogyan törhették fel újra a rendszert, ha a jelszavakat lecserélték. Két dolog játszott közre. Az egyik, hogy a munkatárs a Google fiókjában tárolta a belépési adatait, a Google pedig automatikusan szinkronizálta az új jelszavakat is. A másik, hogy egy nyitva maradt munkameneten keresztül a támadók továbbra is hozzáfértek a Google fiókhoz, így az új jelszavakat is könnyen megszerezték.
Mit állapított meg a hatóság az adatvédelmi incidens kapcsán?
A NAIH szerint a cég két ponton is jogszabályt sértett. Egyrészt nem tett megfelelő technikai és szervezési intézkedéseket, vagyis nem biztosította a megfelelő adatbiztonságot. Másrészt az adatvédelmi incidenst nem jelentette be késedelem nélkül, ahogy a GDPR előírja.
A hatóság a történteket két részre bontotta. A szeptemberi incidensnél bizonyíthatóan megvalósult az adatszivárgás, hiszen tizenkét intézmény adata volt a munkatárs gépén. A novemberi esetnél annyi volt megállapítható, hogy a támadók hozzáférhettek a teljes adatállományhoz. Azt nem sikerült bizonyítani, hogy ténylegesen le is mentették-e az adatokat.
A KRÉTA adatvédelmi incidens legfontosabb tanulságai cégeknek
Most jön a lényeg, ami miatt ez a cikk minden cégvezetőnek szól. A NAIH határozata gyakorlatilag egy checklista arról, hogy mit nem szabad csinálni. Vegyük sorra.
Az adatvédelmi incidenst késedelem nélkül be kell jelenteni
A hatóság szerint már a szeptemberi incidenst be kellett volna jelenteni, hiszen egyértelműen magas kockázatú volt. A bejelentés elmulasztása önmagában is jogsértés. Ha Önnél incidens történik, az órák számítanak, nem a napok.
A jelszavak böngészőbe mentése kockázatos
Érzékeny jelszavak Google fiókba vagy böngészőbe mentése mindig kockázatot hordoz. Ekkora mennyiségű és ennyire érzékeny adat esetében ez súlyos és elfogadhatatlan hiba. Léteznek biztonságosabb, a gépre telepített jelszókezelő megoldások.
Az automatikus kiléptetés nem luxus
Súlyos mulasztás volt, hogy a rendszer nem léptette ki automatikusan az inaktív munkameneteket. Épp egy ilyen nyitva maradt munkamenet tette lehetővé a második támadást.
Nem számít, hogy az adatokat ténylegesen felhasználták-e
A cég azzal védekezett, hogy a dark weben nem találta meg a kiszivárgott adatokat. A NAIH ezt helyesen figyelmen kívül hagyta. Az adatokkal a jövőben bármikor visszaélhetnek, tehát a tényleges felhasználás hiánya nem mentesít.
A felületes kivizsgálás nem elég
A szeptemberi támadás kivizsgálása nem volt teljes körű. A fiókok törlése és az új jelszavak nem elegendők. Egy alapos vizsgálat megelőzhette volna a helyzet súlyosbodását, például a hálózati forgalom figyelésével.
A naplózásnak alkalmasnak kell lennie a feltárásra
A cég naplózása nem segített kideríteni, mi történt. Mivel a támadó a munkatárs profiljával lépett be, a naplóból nem lehetett megállapítani, ki van jelen. A naplónak alkalmasnak kell lennie az incidens feltárására.
A kétfaktoros azonosítás alap, nem extra
A cég csak a második támadás után, 2022 novemberében vezette be a kétfaktoros azonosítást. Egy ekkora rendszernél ez az első naptól minimum elvárás lett volna.
Az emberi hiba és a felkészülés fontossága az adatvédelmi incidens megelőzésében
Van két tanulság, ami minden másnál fontosabb, és amit érdemes a falra vésni.
Az első az emberi hiba. Ahogy a mondás tartja, csak az nem hibázik, aki nem dolgozik. Egyetlen cég sem építhet arra, hogy a munkatársa úgysem fog hibázni. Olyan biztonsági rendszert kell építeni, amely egy emberi hiba esetén is képes megakadályozni a súlyos következményeket. Egy rossz kattintás nem vezethet 60 millió adat kiszivárgásához.
A második, hogy a támadásra számítani kell. Bizonyos esetekben, például nagy mennyiségű vagy érzékeny adat kezelésénél, kifejezetten elvárás, hogy a cég felkészüljön az informatikai támadásokra. Nem az a kérdés, hogy lesz-e támadás, hanem hogy mikor, és hogy fel van-e rá készülve.
Mit tehet Ön, hogy elkerülje a hasonló adatvédelmi incidenst?
Talán most azt gondolja, hogy ez az egész csak a nagy cégeket érinti. Sajnos ez tévedés. A GDPR ugyanúgy vonatkozik egy néhány fős kft.-re, mint egy országos rendszert üzemeltető cégre. A bírság mértéke lehet kisebb, de a jogsértés ugyanúgy megvalósul, és a NAIH ellenőrzések száma évről évre nő.
A jó hír az, hogy a legtöbb adatvédelmi incidens megelőzhető. A megfelelő dokumentáció, a világos belső szabályok, a kétfaktoros azonosítás és a munkatársak alapszintű képzése már önmagában sokat számít. Nem kell hozzá vagyont költeni, csak tudatosságot és egy kis előzetes gondolkodást.
Ha bizonytalan abban, hogy az Ön cége megfelel-e a GDPR követelményeinek, vagy ha nem tudja, mit kell tennie egy adatvédelmi incidens esetén, érdemes szakértővel átnézni a helyzetet. Egy előzetes adatvédelmi audit sokkal olcsóbb, mint egy utólagos bírság vagy egy elvesztett ügyfél bizalma.
Ha szeretné felmérni, hogy cége megfelel-e az adatvédelmi előírásoknak, vagy segítségre van szüksége egy adatvédelmi incidens kezelésében, keressen bizalommal. Foglaljon időpontot egy konzultációra, és együtt átnézzük, hol tart most a cége.