Az adatszivárgások korát éljük, szemléletváltás kell a szoftveriparban

Az adatszivárgásokat valószínűleg manapság már senkinek nem kell bemutatni, aki olvas híreket. Tavaly novemberben például a KRÉTA fejlesztőjének feltörése borzolta a kedélyeket Magyarországon, nemzetközi szinten pedig hetente befut egy újabb, több tízmillió embert érintő szivárgás, és még az olyan nagy cégek sincsenek biztonságban, mint a Facebook. Az amerikai T-Mobile ügyfelei már régi ismerősként üdvözölhetik az ilyen ügyeket, a céget ugyanis 2018 óta nyolc támadás érte, melyek közül a legutóbbiról múlt pénteken számoltak be.

A cég hivatalos tájékoztatása szerint ezúttal 37 millió felhasználó adatai kerültek illetéktelen kezekbe, beleértve a nevüket, a születési idejüket és a telefonszámukat is.

A T-Mobile január 5-én vette észre, hogy az egyik alkalmazásprogramozási felületén (API) keresztül több mint egy hónappal korábban kompromittálták a rendszerüket. (Az API-kon keresztül tehetik a cégek külső fejlesztőknek elérhetővé a szolgáltatásaikat és lekérhetővé bizonyos adatokat, például azért, hogy össze lehessen kötni két különálló szolgáltatást.) A hibát még aznap kijavították, és kiemelték, hogy érzékeny adatokhoz nem fértek hozzá a támadók, az amerikai távközlési hatóság (FCC) azonban így is vizsgálatot indított az ügyben.

Az API-biztonság manapság kiemelten fontos téma, nemcsak a potenciális áldozatoknak, hanem az olyan IT-biztonsági cégeknek is, mint a Balasys. Most a cég információbiztonságot népszerűsítő szakértőjével, Pfeiffer Szilárddal vettük végig, hogy mit tehetett volna a T-Mobile, hogy elkerüljön egy hasonló incidenst.

A szakértő szerint az adatszivárgások korát éljük, annak ellenére azonban, hogy az érintettek minden incidens után megesküsznek, hogy az információbiztonság kiemelten fontos nekik, ha az adatok kiszivárogtak, akkor már csak a károk enyhítésére van lehetőség. Mint Pfeiffer írta, ha bekövetkezik egy ilyen incidens, a legtöbb, amit a cégek tehetnek, az, hogy a problémát a lehető leghamarabb észlelik, és az adatok további szivárgását megakadályozzák. Ez persze nem könnyű: ha egy adatszivárgás már észrevehető nyomot hagy, addigra jellemzően késő. Éppen emiatt észlelni sem egyszerű, ezért az ilyen ügyeknél elsősorban a prevencióra kellene fektetni a hangsúlyt.

A mostani esetben a 37 millió pórul járt ügyfél adatai legfeljebb pár tucat gigabájtot foglalnak, vagyis komolyabb sávszélesség mellett akár néhány perc alatt is le lehetne tölteni őket. A támadók viszont szintén próbálják a lehető legkevesebb nyomot hagyni a rendszerben, például úgy, hogy a méretéhez viszonyítottan kis számú lekérdezéssel folyatják ki az adatokat. Az adatáramlás sebességének masszív korlátozásával ez ellen lehet védekezni, de ha egyszerre több gépről intézik a kéréseket párhuzamosan, ezt is ki lehet kerülni. Mint Pfeiffer írta, ha száz gép csak 10 másodpercenként kérdez le újabb adatot, hogy minél kisebb legyen a lebukás veszélye,

bő egy hónap alatt le lehet nyúlni ennyi adatot, és mint látszik, az áldozat ez idő alatt nem feltétlenül észleli a hibát.

A szakértő szerint teljes körű megoldást csak az IT-rendszerekben bekövetkező gyökeres gondolati változás hozhat. Mint írta, a „mindent szabad, ami nincs közvetlenül tiltva” helyett a „semmit sem szabad, ami nincs közvetlenül engedélyezve” elvet kellene követni, még ha rendkívül költséges és fáradságos feladat is egy informatikai rendszer minden belépési pontjára meghatározni, hogy kik és milyen feltételekkel léphetnek be, majd mindezt ki is kényszeríteni. Nem véletlen, hogy a mind az Egyesült Államokban, mind Európában egyre nagyobb teret hódító Zero Trust biztonsági modell is pontosan ezt írja elő.

Itt a konkrét esetben a problémát épp az okozta, hogy a felhasználói adatokhoz a jogosultságok ellenőrzése nélkül lehetett hozzáférni, ami nyilvánvalóan könnyebben fordulhat elő egy olyan esetben, amikor az adatokhoz való hozzáférés alapvetően megengedő. A hozzáférési szabályok meghatározása viszont csak az első lépés, ezután kellene jönnie a negatív tesztelésnek. Ilyenkor nem azt próbáljuk kideríteni, hogy az adott funkció – például a felhasználói adatok lekérdezése – működik-e a megfelelő jogosultságokkal, hanem arról bizonyosodunk meg, hogy nem működik azok hiányában. Az ilyen tesztek folyamatos futtatása garanciát adhat arra, hogy nem történhetnek illetéktelen hozzáférések, még akkor sem, ha a rendszer közben változik.

Pfeiffer szerint szervezeti oldalon számos módszer és dedikált API-biztonsági megoldás kínálkozik az ilyen incidensek elkerülésére, felhasználói oldalról viszont sokkal kevesebb annak ellenőrzésére, hogy alkalmazzák-e ezeket a megoldásokat. Itt érdemes egyébként megemlíteni, hogy magánszemélyként bárki ellenőrizheti, hogy érintett volt-e egy adatszivárgásban, például a a Have I Been Pwned? nevű ingyenes szolgáltatás segítségével, amely értesítést küld, ha az emailcímünk érintett, és azt is közli, hogy a személyes adatainkon túl kiszivárgott-e például a jelszavunk – ha igen, akkor ideje megváltoztatni mindenhol, ahol addig használtuk. (És ha már szóba került: egyébként sem tanácsos ugyanazt a jelszót több helyen használni, mert ha egy helyről kiszivárog, máshol is visszaélhetnek vele.)

A szakértő végül azt írta, a konkrét esettől függetlenül egyre égetőbb kérdés, hogy a máshol – például az élelmiszer- vagy a gyógyszeriparban – megszokott eljárások, mint a gyártási folyamatok garantálása vagy az összetevők nyilvánossá tétele, hogyan adaptálható a szoftveriparra, amely egyre nagyobb részét határozza meg a mindennapjainknak, és amelyen keresztül egyúttal egyre nagyobb károkat is szenvedünk el.