Nem Equifaxnak való vidék

2019. április 15. 14:05 - Csizmazia Darab István [Rambo]

Ha valaki esetleg nem emlékezne rá, egy érdekes incidensről számoltak be a portálok még 2017. szeptemberében. A hitelminősítéssel foglalkozó Equifax cég informatikai incidenst szenvedett el, amelynek során 143 millió személyes adat kiszivárgott ki, köztük banki adatok is.

Annyira nagyon nem lepődött meg senki, hiszen hosszú volt már a sor: 2011-ben betörés a Diginotar rendszerébe, 2012-ben LinkedIn: 6.5 millió ügyféladat bánta a feltörést, 2013-ban Adobe került sorra: 150 millió ügyféladat, 3.2 millió bankkártya adat, forráskódok estek áldozatul, és szintén 2013-ban Target áruházlánc következett: 110 millió ügyféladat, 40 millió bankkártya, 290 millió USD kár. 2014-ben Sony elleni 20 támadás, 24 milliárd dolláros össz veszteséggel, és még bőven sorolhatnánk, de minek.

Az biztos, hogy a csőddel végződő 2011-es Diginotar eset messze kiemelkedő, és méltán képviseli az "amit csak rosszul lehet csinálni, azt mi készséggel megtesszük" darwini kategória abszolút győztesét, benne a helytelen kommunikáció, az incidens kezdeti tagadása, később jelentéktelennek való beállítása mind-mind az informatikai incidensek állatorvosi lovává avatták, mit és hogyan ne tegyünk hasonló helyzetben.

Aztán később különösen érdekes lett az Equifaxos történet, hiszen szeptemberben derültek ki a részletek: maga az eset a cég részéről július 29-én került felfedezésre, ám az utólagos vizsgálatok szerint a sorozatos jogosulatlan hozzáférések már sokkal korábban, május 13-tól egészen július 30-ig következtek be.

Az adatszivárgás során 143 millió személyes adat: elsősorban nevek, társadalombiztosítási számok, születési dátumok, címek, és bizonyos esetekben jogosítvány számok. Ezen felül pedig 209 ezer amerikai ügyfél hitelkártya adata is illetéktelen kezekbe került.

Sokan úgy gondolják, ahol pénz, paripa, fegyver ilyen volumenben rendelkezésre áll egy IT security büdzsénél, na meg ahol pénzügyi szolgáltatásokat végeznek, ott biztosan odafigyelnek, auditálnak, stb., ám ennek ellentmondott az a tény, hogy a kritikus besorolású, távoli kódfuttatást lehetővé tevő CVE-2017-5638 sérülékenység hibajavítás futtatásának elmaradása nagyban befolyásolta az adatlopást.

Bár az Apache Struts sebezhetőségre kiadott javítófolt már 2017. március 7-én megjelent, a hibajavítás elvégzése hónapokig nem történt meg. Érdekesség, hogy 2018-as februári RSA konferencián is foglalkoztak ezzel a témával, bemutatva, milyen sok további javítatlan Apache Struts fut még világszerte.

Később aztán elemzések sora látott napvilágot, és az ezzel foglalkozó 67 oldalas szenátusi jelentés arról számolt be, hogy az eset, melynek során amerikai fogyasztók személyes adatai tömegesen estek áldozatul, egyértelműen megelőzhető lett volna, ha az Equifax az általa ismert biztonsági hiányosságokat idejében orvosolja. 2015. előtt egyáltalán nem is létezett vállalati előírás a hibajavításokkal kapcsolatban feladatokkal-felelősségekkel, és a későbbi úgynevezett Equifax Patch Management Policy finoman fogalmazva is erősen hiányos volt.

Pedig ez az egyik a három legnagyobb hitelminősítő ügynökség közül, ahol ügyfelek millióinak adózási adata, béradata, hitelfelvétellel kapcsolatos személyes információi, munkaügyi és hiteltörlesztési adata is nap mint nap kezelésre, tárolásra került.

Legfrissebb fejlemény pedig az, hogy az incidens kapcsán az amerikai szenátus azt javasolja, az USA is készítsen az európai GDPR-hoz hasonló adatvédelmi rendeletet. Az új törvény a tervek szerint a vállalkozások által kezelt személyes ügyféladatok biztonságát lenne majd hivatva biztosítani, kötelező értesítéssel az ügyfelek és a hatóság részére, a mulasztókat pedig az EU-s törvényhez hasonlóan szigorú szankciókkal sújtaná.

Meglátjuk majd, mi valósul meg mindebből, mindenesetre hajrá előre.

Szólj hozzá!

A bejegyzés trackback címe:

https://antivirus.blog.hu/api/trackback/id/tr3714765266

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.