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. 

Ha IT oldalról nézzük, a GDPR-ban két technológia kerül nevesítésre, minden más technológiára csak burkolt célzást tartalmaz a 32. cikk.

Az álnevesítés és a titkosítás rossz nyelvek szerint azért került konkrétan megnevezésre, mert a 6 évig a GDPR szövegén dolgozó jogászok együttesen és mindösszesen ennek a két technológiának a nevével voltak tisztában.

Nézzük tehát a titkosítást

Az ESET vírusvédelmi gyártó szerint a titkosítás:

A titkosítás az információ oly módon történő kódolása, hogy azt illetéktelen személyek ne legyenek képesek elolvasni. (https://encryption.eset.com/hu/mi-az-a-titkositas/ )

A több oldalról is borzasztóan pongyola megfogalmazás (és szeretném a kriptós kollégákat megkérni, hogy ne köpjenek le mert idézem), de alighanem ezt értették meg a GDPR rendelet megalkotói, ezért szerintem fogadjuk el ezt a definíciót – de kicsit megfordítva.

A titkosítás az információ oly módon történő kódolása, hogy azt csak az arra jogosult személyek legyenek képesek elolvasni.

A titkosítás ugyanis a GDPR 32. cikk b. pontjában szereplő „bizalmas jelleg” – azaz a bizalmasság teljesülésének feltételét biztosítja. Az információt csak az olvashatja el, aki arra jogosult (mert rendelkezik olyan eszközzel/eljárással/jelszóval/kulccsal, amely ezt lehetővé teszi a számára).

Mikor kell a GDPR szerint titkosítást alkalmazni?

A GDPR egyáltalán nem rendelkezik erről konkrétan.

A 32. cikk 1-es pontja beszél arról, hogy az adatkezelés kockázatait figyelembe véve kell a megfelelő biztonsági szintet meghatározni.

Tehát, ha úgy gondolod (ne gondold, mérd fel, és írd le!), hogy az adott adatkezelési folyamatot nem fenyegeti olyan mértékű kockázat, hogy indokolt lenne részedről (a költség és egyéb vonzatokra tekintve) titkosítást alkalmazni – akkor ne alkalmazz titkosítást.

Nézzünk erre példát (DPIA/BIA-s kollégák szintén ne köpjenek le, próbálom közérthetően megfogalmazni).

A CRM/ERP rendszerben kell-e titkosítanod?

Működés:

A CRM/ERP rendszer nálatok működik, a sarokban búgó szerveren. Gyula, a rendszergazda hetente egyszer néz rá (távolról), mert egyébként van neki főállása is valahol, de mivel a főnök unokatestvérének volt kollégiumi szobatársa, ezért ő a külsős rendszergazda.

Nem tudjuk, Gyula hogy néz rá a szerverre, de a cucc működik vagy 12 éve, és még soha nem volt vele semmi gond (Gyula jó rendszergazda!).

A kollégáiddal a böngészőből éritek el, tök kényelmes az egész, beírod a címet, kér egy nevet meg egy jelszót (már nem emlékszel mi a jelszavad, 12 éve állította be Gyula, de a böngésződ emlékszik rá szerencsére). Mostanában kicsit macerásabb, mert a Chrome meg a Firefox valami olyat kiabál, hogy nem titkosított a kapcsolat, ezért inkább a régi Internet Explorert használod, Gyula abba is beállította neked a jelszót és az IE jól működik, problémamentes a belépés.

Mind a 10 sales kolléga eléri a szervert és az összes adatot látja benne.

Milyen személyes adatokat tárol:

Hááááát 12 évre visszamenőleg minden ügyfél, kapcsolat, célpont nevét, címét, telefonszámát, lábméretét, szülinapját, anyja nevét, ha ügyfél akkor a szerződést, a személyigazolványa másolatát, a születési anyakönyvi kivonatát, stb. A jó sales MINDENT tud az ügyfeleiről, és még többet tud a LEENDŐ ügyfeleiről.

Jelenlegi biztonsági intézkedések:

Már most is túlzók. A szervert csak a cégen belülről lehet elérni. Amúgy a céges TPLINK-típusú tűzfal minden kibertámadást kivéd, hiszen soha nem volt semmilyen gond vele, úgyhogy ez szerinted túlzás, jó lenne otthonról is elérni, mert van, amikor otthonról kell dolgoznod, de megoldod végülis, mert az esti melóhoz szükséges adatokat hazaküldöd a Gmailedre és abból dolgozol.  

Gyula azt mondja, hogy a szerver meg van védve a kibertámadásoktól, a mentésről meg ő gondoskodik, mert otthonra le tudja menteni (mert ő bezzeg eléri!!) az adatbázist, és le is szokta havonta menteni, de tök felesleges, még soha nem kellett visszaállítani, mert minden működik. Jó, néha, amikor a böngésző elfelejti a jelszót, akkor Gyula szokott segíti, megnézi a legutóbbi mentést az otthoni gépén, és abból meg tudja mondani a jelszót a feledékeny kollégának (miért nem írja fel az ilyen!!).

Van szünetmentes USP eszköz a szerveren, amitől a szerver szünet nélkül működik.

Kockázatok:

Szerinted semmi, a rendszer működik, atomstabil (és egyébként tényleg!).

Volt valami IT felmérés (a főnök akarta, hogy legyen, Gyula egyik haverja a Béla jött el felmérni, de pont előtte balhézott össze a Gyulával, úgyhogy egy csomó sületlenséget írt le, kár volt kidobni rá a pénzt. 

1. A szerver elérése titkosítatlan HTTP protokolon keresztül történik. A Chrome és a Firefox ugyan szól érte és figyelmezet, de Gyula mitigálta a problémát azzal, hogy minden felhasználó használjon Explorert, hát az van benne a Windózba, az jobb.
   
   
2. Jelszócsere 12 éve nem volt, mindenki a böngészőben elmentve tárolja a belépési adatokat. Állítólag azt a vírus el tudja lopni, de hülyeség, a TPLINK-típusú tűzfal megállítja a kibertámadásokat.
   
   
3. A belépéshez szükséges jelszó az adatbázisban nem titkosítottan tárolódik, hiszen Gyula a szofisztikált mentésből ki tudja olvasni a jelszót.
   
   
4. A szofisztikált mentés konkrétan azt jelenti, hogy az adatbázis és abban tartott személyes adatok Gyula otthoni gépére tárolódnak (tök rendes tőle, és nem számít fel tárolási díjat se!!).
   
   
5. Gyula valamilyen módon eléri a szervert távolról, Béla leírta, hogy Gyula egy „Port Forward” nevű programot használ erre a célra amit a tűzfalra telepített (??! – nem is vettünk ilyet, tök rendes Gyulától, hogy a sajátját használja, főleg úgy, hogy egyébként nincs is szerződés vele aláírva), meg állítólag nem csak Gyula éri el, de más is, de biztos hazudik.
   
   
6. A felhasználók a személyes adatokat máshol is kezelik, nem csak a rendeltetési helyen, hiszen pl. Te is hazaküldöd a Gmailedre, és az otthoni gépeden dolgozol az adatokkal. Legalább egy csomóról van mentés nálad is, ha valami baj lenne Bála gépével.

És így tovább.. (esküszöm, nem nagyon túlzok, a példa életből vett)

Szóval, hol kell akkor titkosítani?

Hát jelen esetben majdnem tökmindegy, de egyébként:

• A bejelentkezéshez szükséges jelszót (megfelelően) titkosítva kell az adatbázisban tárolni, ez alapvető biztonsági intézkedés, amely az adatokhoz való hozzáférést szabályozza.
  
  
• Mivel a rendszer nagymennyiségű személyes (és egyébként más, üzleti-bizalmas, titkos, fontos, szenzitív) adatot tárol, az adatok elérésének titkosított kapcsolaton keresztül kellene történnie. Alapvető biztonsági intézkedés, amely az adatokhoz való hozzáférést szabályozza (bizalmasság, sértetlenség).
  
  
• Ha hazaküldöd az adatokat magadnak akkor az adat rendeltetési helyétől eltérő helyen valósul meg az adatkezelés. Ez csak abban az esetben történhet, ha a másik helyen működő rendszerben „megfelelő technikai és szervezési intézkedéseket hajt(ottak) végre annak érdekében, hogy a kockázat mértékének megfelelő szintű adatbiztonságot garantálja” – ez pedig az otthoni gépedre nem igaz (jelen esetben mondjuk a céges és az otthoni között nemigazan van biztonsági szint különbség, de elvekről van szó és nem gyakorlatról :)). És még ebben az esetben is problémás, hiszen nem dokumentált adatkezelés, feldolgozás történik. Ráadásul a Gugli postafiókodban a cég által kezelt személyes adatok lesznek megtalálhatók.
  
  
• Gyula mentési eljárása látszólag megfelel a rendelkezésre állás elvárásának, azonban a személyes adatok rendeltetési helyüktől eltérő helyen kerülnek tárolásra, megfelelő védelmi intézkedések és szabályzások nélkül. A tárolt adatok megismerhetővé válhatnak, hiszen Gyula gépéhez mások is hozzáférhetnek (nagyi, tesó, iráni hekker). Gyula, mint SaaS Backup Service gondoskodjon a megfelelő, titkosított tárolásról :) És persze legyen megfelelő szerződés.
  
  
• A „Port Forward program” használata elérhetővé teszi nem titkosított csatornán (HTTP) keresztül az szerver elérését, ez a bizalmasság, sértetlenség és rendelkezésre állás hármas egységét is sérti. Kicsit jobb lenne a helyzet, ha Gyula átállítaná a rendszert a HTTPS kapcsolatra, mert akkor legalább az alapvető (titkosított kapcsolat) elvárások szűk szeletkéjét ki lehetne pipálni. Egyébként a rendszerhez kívülről mások is hozzáférnek (iráni, pakisztáni, líbiai hekker)

A vicces példából egy nagyon fontos dolog derül ki. Maguknak a személyes adatoknak nem kell titkosítva tárolódniuk az adatbázisban.

Számos ponton jöhet be a titkosítás a képbe, de az adatokat magukat nem szükséges titkosítani, amennyiben a megfelelő védelmi intézkedések (pl a kapcsolat titkosítása, a hozzáféréshez szükséges jelszó titkosítása, stb.) garantálják, hogy a rendszerben csak az arra jogosult személyek férhessenek hozzá az adatokhoz.

Kitárolt adatok

Egy csomó esetben az adatbázisban tárolt adatok megjelennek másol is, munkaállomásokon, fájlszervereken, adathordozókon, levelezésben.

Ilyen esetekben viszont el kell gondolkodni az adatok titkosításán, hiszen az adatok a védett (?) rendszerből kikerülve hozzáférhetőve válhatnak jogosulatlan személyek számára is.

Néhány tipp:

• Fájlszerveren nem szükséges a személyes adatokat titkosítani, ha a jogosultság-kezelés és a hozzáférés védelem biztosítja, hogy csak a jogosult személyek férhessenek hozzá az adatokhoz. (rendszergazdák kíméljenek)
  
  
• Laptop esetében az adatokat nem feltétlen kell titkosítani, ha maga a laptop titkosítva van (full disk encryption). Egyszerűbb a teljes laptopot titkosítani, mint egyes fájlokat.
  
  
• Ha emailben küldünk személyes adatokat (és itt arra gondolok, hogy nagymennyiségű személyes adatot), akkor szükséges a titkosítás bevezetése. Nyilván 1-1 adatcsoport esetében nem kell titkosítani, de szerintem, ha fájlokat küldünk amelyben bizalmas adatok vannak, akkor nem árt a titkosítás. Erre akár egy jelszóvédett ZIP is megfelelő, csak a jelszót ne emailbe küldjük, hanem egy másik csatornán, pl. SMS-ben.
  
  
• USB adathordozón szintén szükséges a titkosítást használni, részegen elhagyni egy pendrájvot igen könnyű. De ez sem a GDPR-al jön be a képbe, általános biztonsági intézkedés az adatok bizalmasságának biztosítására. Itt is lehet csak a személyes adatokat tartalmazó fájlt titkosítani (jelszóvédett ZIP), vagy az egész adathordozót.