A shadow IT és az adatszivárgás kapcsolata - az MNB 8/2020 nagyítóján keresztül - (második rész)

Az első részben bemutatásra került a Shadow IT jelenség, illetve a Shadow IT és az adatszivárgási incidensek bekövetkezése közötti kapcsolat. A második részben a Shadow IT jelenségből fakadó, a felhasználói hozzáférések kiszivárgásával járó Credential Leak és Account Takeover jelenségeket vizsgáljuk meg közelebbről. 

Shadow IT, Credential Leak és Account Takeover

Ha a felhasználók engedéllyel vagy engedély nélkül külső alkalmazásokba regisztrálnak a vállalati hozzáféréseikkel, felmerül annak a lehetősége, hogy mi történik ezekkel az adatokkal, ha a külső szolgáltatás esetleg kompromittálódik és az adatok kiszivárognak? 

Olyan esetekben beszélhetünk Credential Leak incidensekről, amikor a felhasználói hozzáférések bizalmassága súlyosan sérül és a hozzáférések jogosulatlan személyek birtokába kerülnek. Ha a jogosulatlan személy a kiszivárgott adatokat fel is használja, az adatokkal be is jelentkezik az adott alkalmazásba vagy más rendszerekbe, Account Takeover incidensről beszélhetünk. 

A jogosulatlan hozzáférésekkel számos visszaélés és csalás elkövethető, tehát az ilyen események az IT security mellett már a különféle visszaélések felderítésével és megelőzésével foglalkozó fraud management területéhez is tartozhatnak. 

A SpyCloud Account Takeover monitorozó rendszere jelenleg 29 milliárd kiszivárgott email címet, 24.5 milliárd jelszót, 41.3 milliárd egyéb személyes adatrekordot tart nyilván. Ez a szám hétről hétre növekszik. 

A kiszivárgott adatok akkor válnak igazán problémássá, ha a felhasználói biztonságtudatosság hiányosságai miatt a felhasználók a külső alkalmazásokban a vállalati jelszót használják, ráadásul nem is egy helyen, hanem akár több alkalmazásban is.

A password reuse problémája sok esetben jelenik meg egyébként az egyes adatszivárgási események vizsgálatakor, hiába súlykolják a szakemberek, hogy a kétfaktoros hitelesítés csillapítja a kockázatot: a bekövetkezett események rámutatnak, hogy sajnos még mindig nagyon kevesen használnak kétfaktoros hitelesítést, és a különféle, összetett támadásokban a kétfaktoros hitelesítési kód is megszerezhető lehet. A kiszivárgott jelszavak a legtöbb nagyobb hírként felkapott eseményben is megjelennek, például a SolarWinds incidens bekövetkezésében is szerepet játszhatott egy kiszivárgott és nem mellesleg triviálisan gyenge jelszó. 

Persze hitelesítési adatok kiszivárgása nem csak az alkalmazások kompromittálásával történhet, a különféle, felhasználói eszközöket megfertőző információtolvaj (infostealer) malware családok szaporodása és terjedése soha nem látott adatszivárgási hullámhoz vezetett. 

A Russian Password Stealer információtolvaj malware alig több mint két év alatt több mint 60 millió breach rekordért felelős, de százával vannak hasonló kártevők, olyan nagy elődökkel, mint a Vidar Stealer vagy az Azorult. 

A kiszivárgott vagy ellopott hozzáférési adatokkal nem csak közvetlenül, a vállalati fiókokhoz lehet jogosulatlan hozzáférést szerezni.

Sentry MBA - kiszivárgott hozzáférések felhasználása (itt éppen Facebook account takeover)

A megszerzett hozzáférésekkel egy privát (akár Gmail) fiókban is lehet olyan szenzitív információkhoz hozzájutni (ugyancsak felhasználói biztonságtudatosság vagy akár konkrétan adatszivárgás elleni védelem hiányossága miatt), amelyekkel a magánszemély munkahelyi rendszere is kompromittálható, illetve például akár az ide érkező második faktoros hitelesítési kód is megszerezhető.

Kiemelten fontos tehát, hogy egy szervezet megfelelően szabályozza a külső rendszerekben, akár vállalati hozzáférésekkel történő regisztrációkat. Jelen pillanatban a külső rendszerek vakfoltot képeznek a szervezetek védelmi stratégiájában és rendszereiben, olyan nem ismert (és nem felmérhető) kockázatokat hordozva, amelyek ellen nagyon nehéz megfelelő védelmet biztosítani. 

MNB 8/2020, Shadow IT és Acount Takeover

Bár a külső - és akár felhősnek mondható - rendszerekkel kapcsolatban a Magyar Nemzeti Bank kiadott egy remek ajánlást, az MNB ugyancsak kiváló, 8/2020. (VI.22.) számú ajánlása az informatikai rendszer védelméről dokumentum alapján érdemes kicsit közelebbről is megvizsgálni a Shadow IT jelenségét. 

A Shadow IT jelenség esetén több problémás terület azonosítható:

9.2.1. Az intézmény a szükséges legkevesebb jogosultság elve alapján meghatározza és dokumentálja az üzleti és informatikai szerepkörökhöz tartozó hozzáférési szabályokat. Ennek során az intézmény teljeskörűen meghatározza és dokumentálja azokat a szerepköröket, amelyek egymással összeférhetetlenek.

A Shadow IT esetében ez a pont meglehetősen nehezen teljesíthető, mivel a szervezet a legtöbb esetben nem is tud arról, hogy a felhasználók olyan alkalmazásokat használnak, amelyek nincsenek rajta a szervezet alkalmazástérképén, azok felett nem gyakorol kontrollt és az ott tárolt adatokkal sincsen tisztában. A felhasználói szerepkörök, a hozzáférési szabályok így természetesen nem határozhatók meg és nem is dokumentálhatók. 

9.2.2. Az intézmény az informatikai biztonsági szabályozási rendszerében rendelkezik az informatikai rendszerekhez történő hozzáférés szabályozásáról.
9.2.3. Az intézmény az informatikai rendszerében technológiai megoldásokkal kikényszeríti a hozzáférési szabályok érvényesülését, beleértve az összeférhetetlen szerepkörök egyidejű alkalmazásának kizárását.

A külső, nem a szervezet felügyelete alatt álló alkalmazásokkal kapcsolatban a szervezet semmiféle hozzáférés szabályozást nem tud kialakítani, pláne nem tudja kikényszeríteni a szabályzatokban előírt hozzáférési szabályok érvényesülését. A legtöbb esetben sajnos az adott alkalmazás alapértelmezett és emiatt általánosságban sokkal gyengébb hozzáférés szabályozása működik, összeegyeztethetetlen módon a vállalati szabályozás előírásaival. 

Hiába alakít ki a szervezet központi címtár alapú, akár Single Sign On (SSO) hitelesítést és hozzáférés szabályozást a saját rendszereivel kapcsolatban, a Shadow IT-t "igénybevevő" felhasználók esetében a hitelesítés és a hozzáférés szabályozás szigetrendszerűen, a vállalattól teljesen függetlenül működik.

9.4.4. Az intézmény a felhasználói fiókok létrehozása és kiadása során biztosítja, hogy csak az a személy vehesse birtokba az azonosítót, akinek a részére azt létrehozták, és – az informatikai rendszeren belüli vagy önálló nyilvántartás vezetésével – biztosítja a felhasználói fiókok és a fiókok használatáért felelős felhasználók egyértelmű egymáshoz rendelését.

Ez nagyon szépen hangzik és a vállalat által kontrollált alkalmazások esetében ez tartható is, azonban a külső - pláne a Shadow IT-ként igénybe vett - alkalmazások esetében a Credential Leak és az Account Takeover incidensek bizonyítják, hogy a szervezet kontrollja nélkül működő alkalmazások lehetetlenné teszik az elvárásnak való megfelelést. A pont nyilván nem teljesíthető, ha a hitelesítő adatok kiszivároghatnak (és esetleg kiszivárogtak), a hitelesítő adatokkal pedig jogosulatlan személyek tudnak bejelentkezni az érintett rendszerekbe. 

A felhasználók (humán személyek) és a felhasználói fiókok egyértelmű összerendelése sem megvalósítható, ha a felhasználói hozzáférés létrehozása, illetve a hozzáférés felhasználása nem észlelhető és nem kezelhető a szervezet számára. A közösen használt hozzáférések (például: info@, hr@, cegnev@) esetében sem elmondható, hogy a jelenség visszaszorulóban lenne, az ilyen hozzáférések alatti jelszóváltoztatások pedig kiemelt fontontosságú, ha a hozzáférés egyik ismerője távozik a szervezettől.

9.4.5. Az intézmény gondoskodik arról, hogy az informatikai rendszerekben mindenkor csak az aktuálisan engedélyezett felhasználók rendelkeznek jogosultsággal, és hogy ennek ellenőrzése azonnal elvégezhető legyen.

Ez az elvárás még olyan esetekben is nehezen teljesíthető, ha a külső, nem a szervezet kontrollja alatt álló rendszert a felhasználó legálisan veszi igénybe. Erre talán a legjobb példák a különféle Google analitikai eszközök, hiszen például a marketing teljesen legálisan veszi ezeket igénybe, azonban mivel a rendszer nem része a hozzáférés menedzsment (például IDM) rendszereknek, egy marketinges kolléga távozásakor a hozzáférést manuálisan kell törölni. Sok esetben olyankor is elmaradnak a hozzáférések letiltásai, ha a szervezet egyébként folyamatszerűen viszi végig a kiléptetéseket, el lehet akkor képzelni, hogy a Shadow IT jelenség során mennyire képes a szervezet erre is odafigyelni. Semennyire.

9.4.6. Az intézmény a jelszó komplexitási és lejárati szabályokat az egyes rendszerekben a felhasználói fiókok használatával végezhető tevékenységek kockázataival arányosan, a felhasználók által kezelhető módon határozza meg.

Bármennyire is legyen frankón meghatározva a jelszóképzés és a jelszócsere szabálya, ha azokat a szervezet nem tudja kikényszeríteni egy tőle egyébként független rendszerben. Arról nem is beszélve, hogy ha egy felhasználó úgy vesz igénybe alkalmazást, hogy a szervezet arról nem is tud, ez pont egyáltalán nem teljesíthető és óriási kockázatokat hordoz. 

9.4.7. Az ügyféladatot és pénzügyi ágazati titkot tartalmazó rendszerekben alkalmazott azonosítók és jelszavak, eljárások és eszközök megválasztása során az intézmény figyelembe veszi a védendő érték, a lehetséges kockázatok és a szükséges ráfordítások körülményeit.

A Shadow IT egyik legnagyobb problémája, hogy a szervezetnek sejtelme sincsen arról, hogy a felhasználók milyen adatokat tárolnak, kezelnek vagy dolgoznak fel az ilyen módon igénybe vett külső rendszerekben és alkalmazásokban. A szervezet a nem látható és nem értékelhető kockázat kezelésére így aztán semmiféle csillapító intézkedést nem tud alkalmazni.

9.4.8. Az intézmény a felhasználói fiók be- és kilépés, jelszóváltoztatás és egyéb autentikációhoz kapcsolódó események adatait naplózza, azzal, hogy a jelszó sem a kritikus, sem más rendszerekben nem kerülhet naplózásra.

A Shadow IT jellemzőiből adódik, hogy az ilyen módon igénybevett rendszerek esetében a szervezet nem képes az elvárásoknak megfelelő naplózás megvalósítására, mivel a legtöbb esetben azt sem tudja, hogy a felhasználó ilyen szolgáltatást vagy alkalmazást vesz igénybe a tevékenysége elvégzéséhez. A belépésekről, kilépésekről, jelszócserékről nincsen tudomása, a jelszavak máshol történő felhasználásáról (password reuse) már nem is beszélve. Ez a pont még akkor is nehezen teljesíthető, ha a felhasználó legitim módon vesz igénybe külső alkalmazást, Shadow IT esetén pedig sehogyan nem teljesíthető. 

9.4.12. Az intézmény a kockázataival arányos módon gondoskodik az informatikai rendszereiben a jelszóra vonatkozóan az alábbi szabályok bevezetéséről: 

a) a jelszó minél több (min. 12, adminisztrátori vagy technikai szerepkörben min. 15.) karaktert vagy jelmondatot tartalmazzon,

b) a jelszó ne legyen szótár alapú,

c) a jelszó ne legyen könnyen kitalálható (ne utaljon a felhasználóra, rokonára, tulajdonára stb.)

Mivel nem a szervezet szabályozza a külső alkalmazásokat, ezért csak abban reménykedhet, hogy az alkalmazás a saját szabályainak megfelelően ellenőrzi a jelszóhasználatot. Sajnos általános hiba az alkalmazásokban, hogy igyekeznek "kényelmesek" lenni és nem terhelni a felhasználót a jelszókomplexitással. A szervezet a saját jelszókomplexitás elvárásait a legtöbb esetben nem tudja érvényesíteni a külső rendszerekben, a Shadow IT esetén pedig ez teljes mértékben a felhasználó biztonságtudatosságán múlik. 

Összefoglalás, lehetőségek

Talán láthatóvá vált, hogy a Shadow IT súlyos kockázatokat hordozhat. Az ellenőrzés és kontroll nélküli külső rendszerek és alkalmazások felhasználása olyan vakfolt a szervezetek számára, amely nem csak a megfelelőségeket (ideértve az MNB elvárásainak való megfelelést) lehetetleníti el, de közvetlenül és közvetetten is adatszivárgási incidenseket okozhat. 

A szervezeten belüli Shadow IT jelenségek felderítése és visszaszorítása elemi érdeke minden vállalatnak, azonban olyan technikai és adminisztratív kontrollok bevezetését igényli, amelyek nem csak költségesek, de jelentős üzemeltetési és ellenőrzési erőforrásokat igényelnek.

Ilyen lehetőségek lehetnek például:

  • Webes alkalmazások kontrolljának bevezetése (application control) például UTM vagy web gateway eszközökkel
  • Szigorú kliens oldali felügyelet (employee monitoring)
  • Adatszivárgás elleni védelem bevezetése (DLP)
  • Folyamatos szoftverleltár és kiértékelés
  • A szervezet által támogatott külsős rendszerek és a belső hitelesítési infrastruktúra összekapcsolása (például központi felhasználói adatbázisból SSO)
  • Adminisztratív szabályok bevezetése, ellenőrzések megvalósítása
  • Biztonságtudatossági oktatások (user awareness)

És persze nem lehet elmenni a hazai fejlesztésű Scirge megoldás mellett sem, amely pontosan a külső (és belső) webes alkalmazások felhasználását, hozzáférés kontrollját és persze jelszókezelését igyekszik átláthatóvá és kontrolálhatóvá tenni.