Nemrég belefutottam a filter:max Kft. egyik ATO-val kapcsolatos anyagába, amely az Account Takeover-elleni védekezés tévhiteit veszi sorba. Meg is örültem az anyagnak, igaz, hogy fordították a SpyCloud doksijából, de alapjaiban egészen jól összefoglalják a dolgot.

Van néhány szempont, amely nem kapott hangsúlyt (vagy promó anyagként más hangsúlyt kapott), vagy pedig meg sem említették a cikkben, viszont szerintem érdemes róla beszélni.

Account Takeover (ATO)

Több helyen credential stuffing vagy credential breach néven hivatkoznak rá, gyakorlatilag arról van szó, hogy a támadó valamilyen módon (jellemzően valamilyen alkalmazás, szolgáltatás meghekkelésével megszerzi a felhasználói adatbázist) hozzájut egy vagy több felhasználó jelszavához, és a megszerzett jelszóval további visszaéléseket követhet el.

Ha cégről, szervezetről beszélünk (és korrekt definíciót akarunk), akkor az ATO a Szervezethez kapcsolódó, a Szervezet felhasználói által igénybe vett belső és/vagy külső szolgáltatások hozzáféréseinek kompromittálódását jelenti. Az ATO incidens során egy vagy több, külső vagy belső rendszerhez hozzáférő felhasználó bejelentkezési azonosítója és jelszava illetéktelen kézbe jut, bizalmassága súlyosan sérül.

A kétfaktor nem jó védelem?

A filter:max cikkében az szerepel, hogy „1. tévhit: a többfaktoros hitelesítés mindent megold, ha ATO-ról van szó” – és egy kissé elferdítve, a cím azt sugallja, hogy a kétfaktoros hitelesítés nem jó megoldás, hiszen:

• Kevesen használják
• Probléma lehet az SMS vagy más kódok bevitelével (WTF??)
• A nyilvános profilokból összerakhatók a biztonsági kérdések (WTF2?)

Nekem az a véleményem, hogy a kétfaktor mindenképpen jó és hatékony védelemnek számít.

A filter:max-nak abban tökéletesen igaza van abban, hogy kevesen használják – nade attól, hogy kevesen használják a biztonsági övet, attól a biztonsági öv még kiváló védelmi intézkedés. Nyilván, ha mindenki és mindenhol kétfaktoros hitelesítést használna, az esetlegesen megszerzett jelszót nem lehetne felhasználni.

Vagy mégis?

Hopp, hát, de. A napokban indult el megint egy jó zsaroló kampány, ahol a zsaroló levél hitelesítéséhez pont kiszivárgott jelszavakat használnak.

Szóval sajnos a kétfaktor lehet hogy a lopott jelszóval történő bejelentkezést megakadályozza, de a jelszóval való egyéb visszaélést nem.

Jelszókezelők használata

„2. tévhit: Ha jelszókezelő rendszert használsz, nyugodtan hatra dőlhetsz” – emeli ki a filter:max második tévhitként a jelszókezelők használatát.

Nem is akarok foglalkozni azzal, hogy miért tartja a filter:max tévhitnek a dolgot, inkább azt hiányolom, hogy az az egyszerű tény nem szerepel az összefoglalásban, hogy hiába tárolja a random generált jelszót jelszókezelőben a felhasználó, és hiába használ minden alkalmazásban eltérő jelszavakat – ha pl a támadó egy sérülékeny webes alkalmazásból szerezi meg a jelszavakat.

Ebben az esetben az fog megvalósulni, hogy a random generált es 29 karakter hosszú „biztonságos” jelszót a felhasználó nem tudja (miért is tudná, azért van jelszókezelő, hogy az tudja), ellenben a támadó tudja, hiszen megszerezte, ott van nála.

Nyilván ennek a megoldása nem a felhasználó oldalán, hanem a webes alkalmazás gazdájánál és fejlesztőjénél van: neki kell megfelelően tárolnia a jelszavakat, és nyilván meg kellene akadályozni, hogy a támadó elvigye a felhasználói adatbázist.

Egy másik ablak ugyanerre a térre, sajnos hiába van jelszókezelő és hiába kerül bele a böngészőbe automatikusan a jelszókezelőből a jelszó, ha a gépen olyan malware működik, amelynek a célja a jelszó- és más, hasznos adatok ellopása (pl Azorult Botnet, Cred/Info Stealer, stb.). Sajnos ezek a malwarek nicsenek tekintettel a jelszókezelőre, adatként el fogják vinni az autopastolt, POST-olt jelszót.

Scraping vs HUMINT

Az ötödik pont „5. tévhit: Deep & Dark webes szkennerek gyorsan felfedezik a visszaéléseket” a kedvencem. Való igaz, hogy ATO esetében a lopott hozzáférések publikálása és eladása általában nem az első lépés.  

A lopott adatok először csak egy nagyon szűk körben kerülnek felhasználásra, nyilvánvaló, hogy csak a „tej lefölözése” után kerülnek ki ezek az adatok a nagyobb nyilvánosságra és piacterekre. Az automata szkennerek és crawlerek már csak akkor férnek hozzá ezekhez az adatokhoz, ha azokat kipakolják a nagyobb nyilvánosság elé (még mindig a DarkNet fórumairól beszélünk).

A jobb ATO-megoldások azért a „favágó” automata scraper robotok mellett HUMINT műveleteket is végeznek, megpróbálnak beépülni az egyes szűkkörű csoportokba és közösségekbe, hiszen ha ott megszerzik a lopott adatokat mielőtt az még a nyilvános piactéren landol, akkor képesek értesíteni az érintett áldozatokat.

Biztonságtudatosság

Az utolsó ponttal „6. tévhit: Ha van vállalati policy, akkor már jók vagyun ATO szempontból” kapcsolatban is igazat kell adnom a filter:max cikkének. Személyes tapasztalat, hogy ezzel a területtel igen kevés cégnél foglalkoznak megfelelően.

Sajnos, hiába írják le a szabályzatokba, hogy tilos vállalati címmel külső szolgáltatásokba regisztrálni, és tilos olyan jelszóval regisztrálni, amelyet a felhasználó belül is használ, ez nem több, mint egy reménytelen próbálkozás.

20-25 ATO vizsgálat után ki merem jelenteni, hogy a felhasználónak ez mit sem számít: ha regisztrálni akar a randi oldalra, akkor regisztrálni fog a randi oldalra. Es a céges email címével fogja megtenni.

Mitől is tartana? Jobb esetben ez ki sem derül. És ha mégis? Akkor sem lesz belőle semmi.

Nyilván nem csak a felhasználóval van a baj.

Ha a szervezet nem érteti (tanítja) meg a felhasználókkal az egyes védelmi intézkedések értelmét és célját (biztonságtudatosság), akkor nemigazán várhatja el, hogy az intézkedést betartsák. A képzés, fejlesztés, oktatás a legolcsóbb és leghatékonyabb védelmi intézkedés!

A másik oldal, hogy a szervezetek az ATO problémának csak a „password reuse” kockázatát látják, a többivel egyáltalán nem foglalkoznak (nagyon helytelenül egyébként, mivel az ATO számos egyéb kockázatot is jelent, nem utolsó sorban, hogy a kiszivárgott adatok mind a személyes adatok köréhez tartoznak).

Szóval alapjában véve érdemes a filter:max cikkét elolvasni a témával kapcsolatban,   még akkor is, ha csak a felszínt karcolgatja az anyag, és hát kissé marketing ízű :)

A kiszivárgott jelszavak segítségével nem csak arra van lehetősége a támadónak, hogy hozzáférjen a felhasználó adataihoz. Igen „ötletes” zsaroló kampány indult a napokban (az első jelzések csütörtökön jelentek meg), amely a kiszivárgott jelszavakat ötvözi zsarolással és a pszichológiai nyomásgyakorlással.

Az áldozat olyan levelet kap, amelyben a támadó értesíti arról, hogy pornónézés közben malware került az áldozat gépére, és a malware segítségével hozzáfért az áldozat gépéhez.

OMG

A levél szerint a támadó az áldozat webkamerájához is hozzáfért, és felvette, amint az áldozat jól érzi magát a filmnézés közben, és amennyiben az áldozat nem küld neki pénzt (változatok szerint 1000-2000USD, BitCoinban fizetve), a támadó megosztja a megnézett pornó videót és az örömködésről felvett videót az áldozat címlistáján szereplő kontaktokkal.

Önmagában ez a levél nem lenne kiemelkedő a sok hasonló blackmail közül, azonban hogy a támadó hitelesítse a sztorit, a levél tartalmazza a felhasználó egyik jelszavát. Ez a tuti nagy ötlet!

I know that, XXXXXXXXX, is your pass word. you do not know me and you are probably thinking why you're getting this e mail, correct?

In fact, I actually installed a malware on the adult videos (pornography) and there's more, you visited this website to experience fun (you know what I mean). When you were watching video clips, your internet browser started out working as a Rdp (Remote control desktop) having a keylogger which provided me with accessibility to your display screen and web cam. Right after that, my software program collected your complete contacts from messenger, facebook, and email.

What exactly did I do?
I've made a double-screen video. 1st part displays the video you were watching (you have a good taste lmao), and second part shows the recording of your cam.

Exactly what should you do?
Well, I believe, $1200 is a fair price for our little secret. You will make the payment through Bitcoin (if you do not know this, search "how to buy bitcoin" in google).

BTC ADDRESS: 12F8h5FLA5TNXHKxcVdNQHScehsVd8C1mM
(It's cASe sensitive, so copy and paste it)

Note:
You have one day in order to make the payment. (I've a specific pixel within this email, and now I know that you have read through this email). If I don't receive the Bitcoin, I definitely will send out your video to all of your contacts including relatives, co-workers, and many others. having said that, if I receive the payment, I will destroy the video immediately. If you want to have evidence, reply with "yes!" and I will send your video recording to your 13 contacts. It is a non negotiable one time offer, so please do not ruin my personal time & yours by responding to this email.

Zseniális

A levélben szereplő jelszó sokkoló hatású („Úristen, tényleg van ilyen jelszavam!”).

Főleg azok számára, akik nemigazán vannak azzal tisztában, hogy kb. 10 milliárd felhasználói jelszó kering a specifikus fórumokban, valamint a DarkNet bugyraiban úgy adják-veszik a felhasználónév és jelszólistákat, mint a leárazott Zarra és Guccsi táskákat a kínai piacon.

A levél ötletesen és jó érzékkel szerkesztett.

A jelszó „bizonyíték” mellett a támadó leírja, hogy egy láthatatlan pixel van elhelyezve a levélben, tehát ő már tudja, hogy az áldozat elolvasta a levelet, tehát he nem fizet, publikálja a videókat.

Szintén aranyos, hogy a támadó felajánlja, hogy ha több bizonyítékre van szükség, nagyon szívesen elküldi a felvételeket 13 személynek az áldozat címlistájáról. Vajon ki akarna ilyen bizonyítékot?

Sok esetben védekeznek azzal, hogy az ilyen kiszivárgott jelszavak már esetleg lejártak, nem lehet velük belépni az alkalmazásokba, de a levélből jól látszik, hogy a kiszivárgott jelszónak nem csak műszaki (login, password reuse) vonatkozásai is vannak.

Kiválóan fel lehet használni a régen lejárt vagy már nem érvényes jelszavakat a phishing/blackmail/scam/ransom jellegű támadásokban szereplő sztorik hitelességének bizonyítására („OMG, ha ez a szemét tudja a jelszavamat, akkor...”).

Ez a levél egy tökéletes példa arra, hogyan lehet az Account Takeover – a felhasználói adatok kiszivárgása és megszerzése,- eseményeket és a klasszikus ransom és blackmail (sociel engineering) trükköket ötvözni.

Hogyan lehet védekezni?

A leghasznosabb tanács, hogy pornó nézés közben (is) legyen letakarva a webkamera :)

Erre mindenféle „webcam cover” alkalmas, lehet venni néhány forintért a kamera elé ragasztható, elcsúsztatható fedőlapot, amelyet csak akkor érdemes kinyitni, ha az ember tényleg használja a webkamerát.

Nyilván nagyon hasznos, ha a felhasználó biztonságtudatos, tisztában van a kiszivárgott jelszavak problémájával, valamint tudja, hogy ha valamiben bizonytalan, jobb megkérdezni, mint ész nélkül, pánikból cselekedni.

Érdemes a HIBP (https://haveibeenpwned.com/) oldalon ellenőrizgetni, hogy van-e az email címünkhöz tartozó, kiszivárgott jelszó a köztudatban, egyébként a HIBP oldalon arra is van lehetőség, hogy riasztást kapjunk, ha esetleg nyilvánosságra kerül valamilyen jelszavunk. (Bár attól, hogy lecseréltük a kiszivárgott jelszót, a levél még ugyanolyan riasztó lehet)

(Komment: a HIBP ellenőrzés csak megnyugtatásra jó, sajnos messze nem teljes az adatbázisa, a felét sem tartalmazza a kiszivárgott adatoknak - viszont mivel ingyenes, és egy felhasználónak nagyon más lehetősége nincsen, érdemes ellenőrizni az email címünket)

A legfontosabb, hogy nyugodtan gondoljuk át a történetet, és ne kapkodjunk, ne pánikoljunk. Ha valaki utána keres a levél szövegének, meggyőződhet arról, hogy zsaroló kampányról van szó, tehát ha nem fizet, akkor sem történik semmi baj.

Mindenki sír, hogy nehéz jó munkaerőt, képzett és lojális munkaerőt felvenni. A jók már elmentek, és külföldön keresik degeszre magukat, a középkategória most készül elhagyni az országot – lassan csak az alja marad, azzal meg mire megyünk?

Hát igen, nehéz dolog jó munkaerőt felvenni.

De így alighanem nehéz is: kiváló és hozzáértő „fejvadász” cégeken keresztül operálni nem feltétlenül kifizetődő:

A héten szép csendesen elfogadásra került az Infotv. módosítása, a legfontosabb viszont az, hogy a NAIH a módosításban megkapta a felhatalmazását, szóval már mindenki nyugodtan eszegetheti a hekket, ihatja a fröccsöt, van már nekünk Hatóságunk! Hú, ez olyan, mint egy népdal, hogy aszongya:

Hátéde van már nékünk Hatóságunk, csuhajja!

Péterfalvi a heréket csavarja,

Addig nyúzza, addig töri a lelket,

A GDPR az őrületbe kerget.

 

Leszóllott a magas lóról Attila,

Hun van kérem az incidens papírja?

Ha nem jött meg időre a jelentés,

Abból lészen rózsám bíz a büntetés.

Na, de visszaugorva az időben, kb. egy éve poénkodtam TT barátommal, hogy már alig várjuk a GDPR elleni biztosítások megjelenését, hát kérem, veszek is egy lottószelvényt izibe, merthogy megjelentek az említett biztosítási termékek a piacon.

Hogyan működnek?

Általában „adatvédelmi felelősségbiztosítás” néven futnak, de természetesen mindenféle csodálatos nevet is rájuk aggatnak a biztosítók és az alkuszok, talán a két legismertebb a Cyber-Risk Biztosítás és a CyberEdge Biztosítás (két külön biztosító terméke).

 A biztosítók elvárnak bizonyos alapvető intézkedéseket, szóval ezek a biztosítások sem mentesítik a szervezetet attól, hogy az adatvédelemmel foglalkozzanak. Kicsit hasonló ahhoz, hogy a lakásbiztosítások is elvárnak (értéktől függő) védelmi intézkedéseket, egyetlen biztosító sem fog fizetni, ha nincs ajtó, hevederzár, rács, riasztó, stb. a lakásban.

A biztosítás megkötéséhez ki kell tölteni egy kérdőívet, amelyben meg kell adni, hogy milyen személyes adatokat és milyen célból kezelünk (különleges adatok, pl. EÜ, vallás, stb. kizárva), illetőleg nyilatkozni kell a védelmi intézkedésekről is (elég alapszintű műszaki védelmet várnak el, tűzfal, vírusvédelem, jelszavak kezelése, patchelés, stb. – viszont ezek hiányában a biztosító nem fog szerződést kötni).

Még egyszer: minden biztosító el fogja várni, hogy alapvető intézkedések és megfelelő adatkezelési körülmények legyenek nálunk biztosítva. Amennyiben nem a valóságot nyilatkozzuk, úgy, ha esemény történik, és kiderül, hogy nemigazán úgy működtünk, ahogy azt nyilatkoztuk (vagy szándékos, súlyos gondatlanság vélelme merül fel), egy vasat sem fogunk kapni.

Szintén meg kell határoznunk a kockázatátvállalás összegét, tehát meg kell mondanunk, hogy pl. évi 2 millió ft kárra szeretnénk biztosítást kötni – erre fogja a biztosító majd a biztosítási díjat kiszabni.

Érdekes, hogy egy csomó területet kizárnak a biztosítók, azaz bizonyos tevékenységek esetén nem lehet biztosítást kötni:

• humán egészségügyi és szociális ellátás;
• telekommunikáció (internet, webhosting, felhő szolgáltatás stb.),
• közművek, villamos energia, gáz, víz szolgáltatók;
• pénzügyi / banki és pénzforgalmi szolgáltatások nyújtása;
• biztosítási és biztosításközvetítői szolgáltatások;
• közigazgatás (állami és helyi hatóságok, valamint állami hivatalok);
• légitársaságok és légiközlekedéssel bármely módon kapcsolatba hozható tevékenység;
• szerencsejáték, közösségi oldalak.

Ami marad, az nem sok :), de valahol logikus, az ezeken a területeken bekövetkező adatvédelmi incidensek olyan összegekre rúghatnak, amelyeket a biztosítók nemigen kívánnak fedezni, az ügyfeleknek meg nem érné meg az óriási biztosítási díjat megfizetni.

Megéri?

Alapból nem. De alapból egyetlen biztosítás sem éri meg, kivéve, ha történik valami – mert akkor nagyon is megérheti.

Éves szinten 100-200E Ft-ról indulnak a biztosítási díjak, viszont ami elgondolkodtató, hogy a biztosító fedez(het)i a kárenyhítés, helyreállás költségeit.

Szóval nem csak arról van szó, hogy kifizeti helyettünk a NAIH-nak az esetlegesen megállapított bírságot (vagy az adatvédelmi incidensből származott kártérítést az érintetteknek), hanem az incidens feltárásának, kivizsgálásának, helyreállításnak a költségeit a biztosító a saját szakértőin keresztül támogatja, bizonyos esetekben elvégzi, ezeknek díját pedig fedezi.

Vélemény

Szakmailag rendkívül felháborít ezeknek a biztosításoknak a megjelenése (hasonló ez ahhoz, amikor egy szervezet nem a védelembe fektet be, hanem mondjuk budgetel évi 5-6 ransomware kifizetésének költségét), de bizonyos esetekben ez a biztosítás akár még jó is lehet.

Főleg, ha nem arra használjuk (nem az a teljes cél), hogy a NAIH bírságokat fedezzük, hanem arra, hogy ha esetleg valami incidens történik, akkor a biztosító segítségével az esemény megfelelően kezelve legyen, és megtörténjen a korrekt elemzés és helyreállás.

Tehát ambivalens érzéseim vannak ezzel kapcsolatban, annyit megér a történet, hogy akit érdekel, kicsit jobban utána nézzen, árakat kérjen be – de azt semmi esetre nem tudom tanácsolni, hogy bárki a biztosítással váltsa ki a GDPR felkészülést. Tegyen meg mindent, amit meg tud tenni, és ha úgy érzi, még maradtak olyan kockázatok, amelyeket nem tud csillapítani, és esetleg előfordulhat, hogy ezekből valamilyen adatvédelmi esemény történik, akkor érdemes lehet ilyen biztosításon elgondolkodni.

Az elfogadható (vagy hihető) tagadás (plausable deniability) elve évszázadok, évezredek óta is létezett, de talán a TrueCrypt titkosított konténerekkel együtt épült be a szakmai köztudatba. Az elv abból indul ki, hogy ha tudsz valamit, amiről hihetően letagadod, hogy tudod, akkor a másik fél szempontjából valójában nem tudod.

Ez persze nagyon pongyola értelmezése az elvnek, de nincs kedvem hosszas filozófiai vitákba keveredni. Persze a bölcsészvér felserken bennem és kikívánkozik belőlem, hogy hasonlatos ez a régi bölcsész-művészettörténész vitához, ahol azon megy a vita, hogy ha Pompeiben megalkotják a világtörténelem legtökéletesebb, abszolút értelembe vett legszebb műtárgyát, amelyet aztán belepett és örök időkre ellepett a vulkáni törmelék, akkor valójában a legtökéletesebb szépség létezik-e, ha senki nem tud róla. Kicsit hasonlatos Schrödinger macskájához, aki egyszerre élő vagy holt, attól függően, hogy kinyitjuk-e a dobozt vagy sem.

Számos esetben a GDPR megfelelőség(?!) leghatékonyabb módja, ha az elfogadható tagadás elvét alkalmazzuk. Az egyik adatvédelmi fórumon indult útjára egy vita, amely szerintem jól példázza, hogy mikor és hogyan kell az elfogadható tagadást alkalmazni – nyakatekert, menedzselhetetlen és mindenképpen költséges megoldások helyett.

Nézzünk ezekre néhány példát.

Kilépett munkavállaló adatainak megőrzése

Sok esetben bevett gyakorlat, hogy a kilépett munkavállaló levelezését, munkaállomásán tárolt adatait, vagy a szerverekre mentett adatait learchiválják, és meglehetősen hosszan megőrzik. Ennek oka, hogy akár évek múlva is előkerülhetnek olyan ügyek, amely miatt szükséges lehet előszedni ezeket az adatokat, valamiféle vizsgálathoz, ügyrendezéshez, stb. információt gyűjteni.

A GDPR nemigen tolerálja ezt, hiszen a felhasználó adatai között lehetnek személyes adatok, személyes dokumentumok stb. Szóval GDPR-szerűen a távozáskor együtt kéne átnézni a tárolt adatokat, kitörölgetni azt, amely mondjuk nem céges, és csak azt megőrizni, amely biztosan céges adat. Ez borzasztóan időrabló (ergó költséges), és néha nehezen megvalósítható történet, ezért a gyakorlat az, hogy mindent learchiválunk, aztán ha kell, akkor majd előszedjük és használjuk az adatokat.

Ilyen esetben javasolt az elfogadható tagadást alkalmazni: ha valaki megkérdezi, hogy jár el ilyen esetben a szervezet, azt kell mondani, hogy nem őrizzük meg a kilépett munkavállalók anyagait. A tényleges gyakorlat viszont az lesz, hogy a kimentett adatokat a rendszertől függetlenül egy offline (és hogy azért jó legyen) titkosított diszken eltároljuk mondjuk a nagyfőnök páncélszekrényében. Ott fog szépen gyűlni az online rendszerektől függetlenül a távozott munkavállalók adatairól készült mentés – ugyan ki tudná ezt ellenőrizni?

(advanced mód, amikor a vezetők nem akarnak tudni és emiatt nem is tudnak arról, hogy az IT így gyűjti az adatokat, ez talán a leghihetőbb tagadás: a felsővezetés tényleg nem tud róla, az IT meg nem beszél és ha mégis valaki megkérdezi, akkor letagadja).

Ugyanez érvényes a mentésekre, archívumokra is. A GDPR alapján ugye indokolatlan késedelem nélkül kellene kérésre az érdekelt adatait törölni, az önmagában is probléma, hát még ha arra gondolunk, hogy mentésekből, éves archívumokból meg eleve nemigen lehet törölni.

Sok megoldás létezik, de a legegyszerűbb az, ha elfogadjuk, a mentésekből előbb-utóbb (ciklusa válogatja) úgy is eltűnnek az adatok, az archiválással kapcsolatban pedig ki kell jelenteni: mi nem archiválunk semmit (kivéve, ha törvényi előírás van rá, de az meg ugye más tészta), és az archivumokat a rendszertől és folyamatoktól függetlenül offline tároljuk.

Néhány további gyakorlat:

- Kedves Cég, Önök monitorozzák, és ellenőrzik a munkavállalók böngészését és Internet használatát?

- Mi soha nem csinálunk ilyet!

- Kedves Cég, Önök ellenőrzik a munkavállalók levelezését?

- Mi soha nem csinálunk ilyet!

- Kedves Cég, Önök ellenőrzik az állásra pályázók közösségi média tevékenységét?

- Mi soha nem csinálunk ilyet!

- Kedves Cég, Önök ellenőrzik a munkavállalók közösségi média tevékenységét?

- Mi soha nem csinálunk ilyet!

- Kedves Cég, Önök ellenőrzik az egyébként magáncélra is használható mobilkészülékek híváslistáit?

- Mi soha nem csinálunk ilyet!

- Kedves Cég, Önök ellenőrzik a céges, de magánútra is használható személyautók GPS adatait?

- Mi soha nem csinálunk ilyet!

Az elfogadható, vagy hihető tagadáson nagyon nehéz megbukni, és jellemzően akkor lehet megbukni, ha valaki fecseg (megbocsáthatatlan bűn!). Ezért, ha valaki ilyen elvet alkalmaz, gondoskodnia kell arról, hogy csak a legszűkebb (és legmegbízhatóbb) kör tudjon a valós folyamatokról.

Sok helyen a felsővezetés el is várja az elfogadható vagy hihető tagadás alkalmazását, ezt egy okos középvezető tudja és fel is ismeri a nagyfőnökök „Nem akarok tudni róla” kijelentéseiből és úgy intézi, hogy valóban ne is tudjanak róla, hiszen csak ebben az esetben tudja a vezetés hihetően és elfogadhatóan letagadni a dolgokat.

Szintén fontos kérdés, hogy mire és hogyan használjuk fel az így gyűjtött, tárolt adatokat? A hazai joggyakorlat megengedi az illegálisan/nem törvényesen gyűjtött bizonyítékok felhasználását bírósági eljárásokban – ha egyébként a bizonyítékot másképpen nem, vagy csak nagyon nehezen tudtad volna megszerezni.

Azonban azt figyelembe kell venni, hogy ilyen esetekben a másik fél szintén peres eljárást kezdeményezhet, attól függetlenül, hogy az első perben mondjuk a bizonyítékaid miatt elmarasztalják, hiszen jogszerűtlenül gyűjtöttél róla adatokat. Szóval ilyen esetekben is mérlegelni kell, hogyan és mire használod fel az elfogadható vagy hihető tagadás palástja mögött gyűjtött, tárolt, kezelt adatokat.

Hol nem működik a plausable deniability elve?

Nem tudom ki, hogy van vele, de nálunk a feleségem esetében az elv alkalmazására semmi esélyem :)

Egyébként, ha valamire van ésszerű, alkalmazható megoldás – amelynek költségvonzatát is elviseli a szervezet, hát javasolt azt a megoldást választani, nem pedig az elfogadható vagy hihető tagadás mögé rejteni a folyamatokat. Ha a szabályozás költsége és bonyolultsága kevesebb kockázattal jár, akkor tessék tényleges megoldást bevezetni.

- Kedves Cég, Önök alkalmazzák a plausable deniability elvét?

- Mi soha nem csinálunk ilyet!

Van az úgy, hogy a legjobb szándék ellenére is félresiklik valami. Az igazi harcos ilyenkor sem adja fel!

„Neither snow nor rain nor heat nor gloom of night stays these couriers from the swift completion of their appointed rounds”.

Szóval csak nyugi, az Igazi Postás megfelelően kézbesíteni fogja az adategyeztető levelet!

 (Köszi Cs.A.!!)

Pár napig téma volt, hogy az IBM letiltotta az USB adattároló eszközök (pendrive, diszk) csatlakoztatási lehetőségét, azaz, hogy az IBM világában élő munkavállalók már semmilyen USB adattárolót nem tudnak használni a munkaállomásaikon.

Elég vegyes reakciók és kommentek jelentek meg a témában, úgyhogy azt gondoltam, talán nem ártana megnézni egy kicsit szakmai szemmel az esetet, nem feltétlenül GDPR szemüvegen keresztül, de sokkal inkább információ- és IT biztonság vonatkozásában.

Milyen kockázatai vannak a külső, USB (adattároló) eszközöknek?

Adatszivárgás

Talán a legvilágosabban látható probléma, hogy a munkavállalók arra használják ezeket az eszközöket, amire valók: adatokat tárolnak el rajtuk.

Rendeltetésszerű használat során a felhasználók adatokat mentenek ki ezekre az eszközökre, amelyeket aztán hordozhatnak, áthelyezhetnek más munkaállomásokra, elvihetnek szervezeten kívülre, de akár besörözve el is hagyhatnak (Megvan még, hogy valaki elhagyta a pendrive eszközét, rajta a Heathrow reptér biztonsági intézkedéseivel, tervrajzaival, stb.? Ha nincs: https://www.cnet.com/news/usb-stick-detailing-heathrow-airport-security-found-in-london-street/)

Nyilván elsőre műszaki védelmi intézkedésként az adatszivárgás-elleni védelem jön szóba, a védelmi rendszer ismerje fel, hogy az adott fájl vagy adat kimásolható-e ARRA az USB adattároló eszközre (azaz az adott információt az adott felhasználó az adott USB eszközre kimásolhatja-e?).

Aztán ott van a titkosítás, ha az információ szenzitív (GDPR, személyes adat, ugye?), csak titkosított USB eszközre másolható ki, vagy pedig másolás során magát az adatot kell a rendszernek titkosítottan tároltatni az adathordozón, pontosan azért, hogy ha a kimásolás szabályok szerint történik és engedélyezett, attól még illetéktelen személyeknek nem szabad a kitárolt adathoz hozzáférnie (nem feltétlenül az volt a baj, hogy valaki kimásolta a reptéri adatokat, hiszen lehet, hogy arra jogosult volt, viszont nem lett volna szabad az eszközt vagy a rámásolt adatokat titkosítás nélkül hagyni, hogy bárki hozzáférhessen).

IBM-szinten egy végponti DLP rendszer költsége számunkra nem értelmezhető, százezernyi munkaállomásról van szó, csak a szoftverlicensz költségek millió dollárokra rúghatnak, és akkor még nem beszéltünk arról, hogy a komponenseket telepíteni kell a munkaállomásokra, és minden újabb agent/komponens problémát okoz: lassulások, összeakadások (pl. DLP vs vírusvédelem) – ha csak 4-5% munkaállomás esetében lép fel probléma, ekkora kliensszámnál az már kezelhetetlen és óriási költséget emészthet fel.

Ha eleve titkosított adattárolókat kell beszerezni, a projekt (kinek kell egyáltalán, milyet vegyenek, mekkora tárkapacitással, szoftveres vagy hardveres titkosítás, stb.) szintén borzasztóan költséges projekt lett volna az IBM esetében.

Összefoglalva, a védelmi intézkedés – a külső adattárolók használatának letiltása – nullára csökkenti az adathordozókon keresztül bekövetkezhető adatszivárgás kockázatát, gyakorlatilag nulla bevezetési költség mellett (jó, annak is volt költsége, hogy letiltották a munkaállomásokon, de az elenyésző a komplett DLP projekt költsége mellett).

Ilyen intézkedés mellett azonban nem szabad elfeledkezni arról, hogy csak akkor szabad meglépni ezt a „drasztikus” lépést, ha az adatcserékre (ki- és bejövő oldalon) alternatív, és jól kontrollálható lehetőséget biztosít a szervezet.

Malware

Malware védelmi szempontból is indokolható az IBM lépése. Az USB adathordozókon behurcolt állományokat csak a végpontvédelmi rendszer (vírusvédelem) ellenőrzi egyetlen AV/AM motorral, amely a jelenlegi malware-helyzetben igen csak kevésnek bizonyul.

Egyetlen motor sem képes az összes malware felismerésére, nem véletlen, hogy a vállalati malware védelem több motorra is támaszkodik (jó esetben), a jobb (?) tűzfalrendszerekben is működik átjáró-szintű malware védelem (tehát egy webről letöltött állományt a tűzfal/webszűrő, illetve a végpontvédelem motorja is ellenőriz, lehetőleg ugye két különböző vírusvédelmi gyártó két, különböző motorja).

Aztán a fejlettebb szervezeteknél működhetnek még sandbox-rendszerek, APT védelem, szóval ki lehet mondani, hogy legalább 2-3-4 vírus és malware-védelmi rétegen halad keresztül a belépő állomány.

Ha az USB adathordozók csatlakoztatása letiltásra kerül, az igen hatékony védelem, hiszen nem lehet semmiféle állományt bemásolni a munkaállomásra, az USB csatornán keresztül tehát nem juthat malware a munkaállomásra.

Összefoglalva, a védelmi intézkedés – a külső adattárolók használatának letiltása – nullára csökkenti az adathordozókon keresztül bekövetkezhető malware fertőzés kockázatát, végpontvédelmi szempontból tehát az egyik legköltséghatékonyabb és legbiztonságosabb intézkedésnek minősül.

Shadow IT

A nagyobb szervezeteknél meglehetősen erős szoftver-policy működik (már ahol, ugye), azaz a felhasználók csak a szervezet által engedélyezett, támogatott szoftvereket használhatják, amelyeket csak az IT/admin/szoftvergazda személyek vagy csoportok telepíthetnek a munkaállomásokra.

A shadow IT probléma a portable alkalmazásokkal együtt jelent meg, azaz egy csomó alkalmazást nem szükséges már telepíteni, olyan összeállításban is elérhetők, amelyeket egyáltalán nem szükséges telepíteni (Photoshoptól kezdve a szinkronizáló klienseken keresztül lassan már minden elérhető portable formában).

Ez indikálja a shadow IT megjelenését, azaz olyan alkalmazások megjelenését a szervezeten belül, amelyek a szoftverszabályozáson kívül léteznek, jellemzően a szervezet tudta, akarata és ellenőrzése nélkül.

USB adathordozókon kiválóan behozhatók ilyen alkalmazások, míg webről letölteni (jó esetben) nem lehet futtatható állományokat, addig az adathordozókról nem csak bemásolni, de elindítani is el lehet őket.

Erre ugyan megoldást jelenthetne az applikáció-szűrés (application control), amikor olyan biztonsági eszköz működik a szervezeten belül, amely csak az engedélyezett állományokat engedi elindítani – de az ilyen projektek költsége és erőforrás-szükséglete a DLP bevezetésen is túlmutathat (brutális).

Szintén lenne lehetőség arra, hogy a megfelelő végpontvédelmi szoftver ne engedjen futtatható állományt külső adathordozóról bemásolni a munkaállomásra (filetype control), de ezek az eszközök viszonylag könnyen kijátszhatók (pl. jelszóvédett zip – amelyet sokkal nehezebb letiltani, lévén, hogy a legtöbb helyen teljesen normális üzleti folyamat, ha titkosítással védett információval dolgoznak a felhasználók).

Összefoglalva, a védelmi intézkedés – a külső adattárolók használatának letiltása – igen költséghatékonyan, nullára csökkenti az adathordozókon keresztül bemásolt portable alkalmazások használatából eredő kockázatot (amennyiben ezek letiltásra kerülnek az email és web határvédelemben).

Speciális USB-alapú fenyegetettségek

Az egyetlen terület, ahol a külső adattárolók használatának letiltása nem jelent védelmet, a BAD USB-jellegű fenyegetettségek, azaz olyan támadó eszközök csatlakoztatása a munkaállomáshoz, amelyek USB eszközöknek álcázzák magukat.

Erre a legjobb példák a Rubber Ducky és társai, olyan eszközök, amelyek USB billentyűzetnek álcázzák magukat, de a beépített tárolójukról támadó scripteket küldenek billentyűzet leütésenként a munkaállomásnak, amelyet aztán a szerencsétlen gép végre is fog hajtani. Szintén jó példa a Mouse Jack/Key Jack támadás, ahol egy pár dolláros drónvezérlő vagy SDR eszközzel lehet machinálni a wireless egereket és billentyűzeteket, hasonló eredménnyel, mint a Rubber Ducky.

Mivel csak az USB storage/tároló eszközök kerültek letiltásra, a BAD USB-attack továbbra is fenyegetést jelent, ez ellen az intézkedés nem tud védelmet nyújtani.

Konklúzió

A példákat végig nézve, és az egyes kockázatok elleni alternatív intézkedési lehetőségeket megvizsgálva kimondható, hogy ha az adatcserére és adatmozgatásra az IBM egyéb lehetőségeket kínált a felhasználóinak, akkor a legköltséghatékonyabb és legegyszerűbben implementálható védelmi intézkedést hajtotta végre, amely a legtöbb, USB adattároló-alapú kockázatot hatékonyan és olcsón mitigálta.

Az adatvédelmi nyilatkozat célja, hogy megfelelően, részletesen, érthetően tájékoztassa az érintetteket az adatkezelésről, módjáról, megőrzési időkről, tiltakozási lehetőségekről, az érintettek jogairól és lehetőségeiről, stb. 

Pár nappal a GDPR-éra beköszönte után világosan látszik, hogy a BKV valósította meg a legtisztább, és a vállalat szellemiségét tökéletesen nyilatkozatba öntő tájékoztatást az érintettek jogairól és lehetőségeiről.

Ime:

Semmi felesleges cicoma, semmi érthetetlen jogi maszlag! Aki ezt nem érti, annak kár volt a GDPR-t kitalálni is!

(Cs.A. köszönöm! )

Talán sokan ismerik a régi viccet, amelyet szerintem ideje volt egy kicsit aktualizálni. 

Ma dömping van, a 47. „Adatvédelmi hozzájárulás kérése (GDPR)” levél esett be a postafiókomba.

Érdeklődve olvasom őket, kattintgatok és megerősítem, hogy továbbra is kezelhetik az adataimat – de bizony egy részükről nem is tudtam, hogy regisztráltam volna valamilyen hírlevelükre (ezekre természetesen nem kattintok).

(Ugyanitt megjegyzem, hogy mekkora malware terjesztést lehetne csinálni – csak a malware-t „Adatvédelmi hozzájárulás kérése (GDPR).docx” dokumentumba kell tenni, mindenki nyitná, mint az állat).

Szóval mi van azokkal, akikről biztosan tudom, hogy nem adtam meg nekik az adataimat?

Na kérem, ezt úgy hívják, hogy „kimosdatás” – azaz a korábban aggályos (értsd: hozzájárulás nélkül gyűjtött, vásárolt, fene-se-tudja-honnan-van, stb.) módon beszerzett címeket lehet vele kifehéríteni.

A trükk az, hogy úgy kell megírni a megerősítés kérését, mintha korábban az illető megadta volna az engedélyt, és csak a b*zi GDPR miatt újra be kell kérni.

Szorri, nem akarunk mi zavarni, csak tudod, a GDPR...Lécci, hát erősítsed már meg, amit már annó megtettél, tudod, hogy feliratkoztál...Emlékszel, ugyi? Na, lééééccci! HüjeGDPR!

És persze sokan vannak, akik meg is erősítik, hiszen itt a GDPR, mi is szop*nk vele, a szerencsétlen is, hát miért ne segítsünk. A másik, hogy tényleg a fene se emléxik, lehet megadtam, jelentkeztem, biztos fontos volt, ez meg megbízható amúgy is, látszik törődik az adataimmal meg a GDPR-al.

A kimosdatásnak a legszebb példája az, aki csak email címet harvestelt korábban, és amúgy lövése sincs arról, hogy hívják az illetőt.

Ilyenkor a profi kvázi újra regisztráltatja az illetőt, és nem csak megerősítését kér arról, hogy tárolhatja és kezelheti az adatot, hanem bekéri „újra” a nevét, címét, stb. – hiszen a GDPR elvárja, hogy a tárolt adatok pontosak és naprakészek legyenek. YEAHH!

Az ilyen – tulajdonképp regisztráció mögé bújtatott – hozzájárulás akkor tud a leghatékonyabb lenni, ha az email címet már nem kéri el, hanem meg jeleníti a „Megerősítés” lapon („már úgy is tudjuk, hiszen korábban már te magad adtad meg, most csak a hüje GDPR miatt kell ezeket az adatokat ÚJRA megerősítened”).

Szóval ötletes megoldás a GDPR hisztériát arra felhasználni, hogy kifehérítsük a szürke vagy fekete listáinkat, és olyanoktól is beszerezzük a hozzájárulást (és meg csomó, korábban nem tárolt adatot), aki egyébként korábban sem adtak hozzájárulást és engedélyt. Nice job.