A tavalyi, 2017-es egészen jó év volt ha a kiszivárgott adatok mennyiségét nézzük. Legalábbis az idei augusztushoz képest bizonyosan.

A kezembe került az IT Governance által kiadott infógrafika, amely összefoglalja a 2017-es esztendőt adatszivárgási szempontból: 488 észlelt adatszivárgási eseményből 826,526,181 (Nemzeti Alaptanterven nevelkedettek számára 826 millió) adatrekord szivárgott ki.

Nem is akármilyen adatszivárgások voltak ezek: 146 eseményben egészségügyi, 33 eseményben a financiális szektor, 67 eseményben technológiai szektor volt érintett. Érdekesség, hogy 64 eseményben valamilyen oktatási szolgáltatással kapcsolatos adatok kerültek ki, és a listában a telkó és a védelmi ipar is képviselteti magát 8, illetve 3 „szerény” eseménnyel.

Szép év volt, de vajon hogy állhatunk most? A kibertér óceánján, a GDPR paradicsomi boldogságában vajon merre tart velünk a Harland and Wolff gyárában szerelt, rekeszes törzsű „elsüllyeszthetetlen” hajó?

Nézzük az elmúlt hónapokat:

Összesen tehát most, 2018 verőfényes szeptemberének elején 621 millió adatrekordnál járunk, amelyet valamilyen adatszivárgással kapcsolatos incidens érintett.

Nem rossz, 2017-ben összesen 826 millió, idén pedig eddig 621 millió rekord volt érintett - és még hátravan 4 hónap az évből.  Mondhatni, majdnem arányosan rosszul állunk, és ezen a június-július-augusztus sem segített, pedig ugye már a GDPR paradicsomában vagyunk.

Brutális ezeket a számokat látni. 2017-ben 5 olyan hónap is volt amikor legalább 50 millió rekord kompromittálódott, és 2018-ban már 4 ilyen hónappal is megvagyunk.  

Na és a GDPR?

Egy másik szemüveget felvéve azt lehet mondani, hogy az összefoglaló alapján jól látható (de csak ezzel a szemüveggel), hogy miért van szükség az adatvédelemre és miért van szükség a GDPR-ra, még akkor is, ha a GDPR erőfeszítései nem az idei év statisztikájában fognak jelentős javulást hozni.

A 2017-es évben közel 58 millió rekord biztonsági problémák miatt kompromittálódott, míg majdnem 8 millió rekord valamiféle hibás beállítás miatt került rossz kezekbe. 274 millió rekord bizalmassága sérült valamilyen belső, hibás folyamat miatt, 4.5 millió rekordot pedig egyszerűen csak elhagytak.

Azt gondolom, hogy a GDPR és a farvizén megvalósított műszaki védelmi intézkedések csökkenteni fogják ezeket a számokat, de abban is biztos vagyok, hogy nem idén, és talán nem is jövőre.  

De valaminek meg kell változnia, mert a Harland and Wolff gyárában szerelt, rekeszes törzsű „elsüllyeszthetetlen” hajón (talán már kitaláltátok, a Titanicról van szó) Frederic Fleet őrszem 23:40-kor meghúzta a vészharangot.

UPDATE: a Veeam szeptemberi 445 millió rekordos breach-ével lenyomtuk a 2017-et, tehát idén szeptemberig már túlteljesítettük a 2017-es évet :)

A „Schrödinger macskája” gondolatkísérlet elég régóta foglalkoztatja az embereket és főleg a tudós elméket, akiknek egyébként nincs jobb dolguk, mint ilyesmiken gondolkodni.

A kísérlet nagyon egyszerűen arról szól, hogy egy képzeletbeli dobozba zárt macska atombomlás-indikálta cianidmérgezés következtében élő vagy hol állapotban létezik, avagy a macska egyszerre élő és holt mindaddig, amíg valaki ki nem nyitja a dobozt és ezzel eldől, mely állapotában létezik a macska a dobozban.

Évek óta szórakoztató mémek tucatjai jelentek meg már az elméletről és a híres macskáról, de én nem tudok arról, hogy az esetet a macska szempontjából bárki is vizsgálta volna. Pedig kellene, hiszen a macska szempontjából áttekintve a dolgot a helyzet összetettebb és sokkal több teljesen felesleges gondolkozásra tudja sarkallni az unatkozó tudós elmét.

A macska szempontjából ugyanis Schrödinger létbeli állapota négy dologtól függ:

• Ha a macska saját maga mászott a dobozba (a macskák valamiért nagyon vonzódnak a zacskókba és dobozokba bújáshoz), Schrödinger bár a macska számára a következő etetésig teljes mértékben érdektelen, így Schrödinger a macska számára egyszerre lehet élő és halott.
• Amennyiben Schrödinger saját kezűleg erőltette a macskát a dobozba, akkor Schrödinger a macska számára HALOTT.
• Ha a dobozba cián helyett szaftos macskatáp kerül, a macska számára Schrödinger ismét érdektelen, és a doboz kinyitása után a macska számára a következő etetésig egyszerre lehet élő vagy halott.
• (és természetesen, ha a macska halott, akkor a macska számára Schrödinger teljesen érdektelen, egyszerre lehet élő vagy halott, mert halott macska leszarja.)

Szóval lehet, hogy nem árt egy problémát vagy gondolatkísérletet más szempontok alapján is értelmezni.

A tanulság ebből az, hogy ha macskát zársz egy dobozba, a végén a hullámfüggvényed egyszerre fogja élő és halott valód hullámfüggvényét tartalmazni.

Hát megtörtént.

Alig 2 hónapja az EU parlament határozatban mondta ki, hogy a Kaspersky vírusvédelmi és végpontbiztonsági megoldása(i) szerinte potenciálisan veszélyesnek – pontosabban arról hozott határozatot, hogy az EU intézmények nézzék át az infrastruktúrájukat és távolítsák el a rosszindulatú, veszélyes alkalmazásokat, mint pl. a Kaspersy Lab („such as Kaspersky Lab”).

Tegnap (08.13) csendben megjelent egy magyar kormányhatározat, amely a Kormány irányítása és felügyelete alá tartozó szervek és vállalkozások esetében már a Kaspersy megoldások kiszűrését és elhárítását írja elő.

Nem akarok belemenni abba, hogy mi állhat az Amerikából elindult, és a Kaspersky-t bedaráló döntések hátterében (egyesek tényleg orosz kémeket és az FSZB-t látják a termékben, mások a Kaspersy piaci részesedésének megszerzését említik), de annyi bizonyos, hogy ezzel Magyarországon (is) vége a Kaspersky-nek. Lehet, hogy otthoni vagy kisvállalati verziókban még egy ideig meg-megjelenik, de vállalati és kormányzati szinten innentől kezdve a Kaspersky használata tilos.

Ami valakinek keserű, az másnak bizony édes: alig várom, hogy elinduljanak a pl. „Cseréld a Kaspersky-t Minden Ellen Védő Sárga Vírusgyilkosra” reklámkampányok.

Nyugodj békében Kaspersky!

Local Admin occidere nolite timere bonum est si omnes consentiunt ego non contradico, azaz “a lokáladmint megölni nem kell félnetek jó lesz ha mindenki egyetért én nem ellenzem” - mondhatta volna a kétértelműség hazai apostola Merániai János érsek, ha II. András idejében királynő helyett a lokális adminisztrátor keserítette volna meg a magyarok életét.

A felhasználókhoz delegált lokális adminisztrátori jogosultság ugyanúgy kihozza a sodrából az egyszeri szekuritist, ahogy II. András idejében Bánk Bánt bőszítette fel a neje megbecstelenítése: a lokális adminisztrátori privilégium a szépen kidolgozott jogosultsági rendszer inzultálása, amire egy vérbeli szekuritis minimum megszurkálná azt, aki kitalálta, hogy a felhasználónak legyen ilyen privilégiuma.

A lokális adminisztrátori jogosultság egy saját magára fogott töltött fegyver a felhasználó kezében, kibiztosítva. Az első, akit a felhasználó el fog találni, az saját maga lesz, aztán meg lehet a utána takarítani.

A lokális adminisztrátori jogosultság ugyanis tökéletesen képes bármilyen műszaki intézkedés védelmi értékét a nullára degradálni: a privilégium bírtokában bármely (a legtöbb) műszaki védelmi intézkedés megkerülhető, kikapcsolható, vagy működésében korlátozható.

Egy másik, és nem elhanyagolható probléma, hogy a (lokális) adminisztrátori jogosultsággal futtatott alkalmazások eleve veszélyesek: a malware és exploit szeretettcsomagok tipikusan örülnek az ilyesminek, hiszen az alkalmazásból kitörve már nem is kell privilégiumot emelniük, a legtöbb esetben eleve admin joggal tudnak futni.

Nyilván, ha valaki a felhasználói tevékenységét eleve admin jogkörrel végzi, a nevében és jogosultságával elinduló alkalmazások (akár malware kódok) is eleve adminisztrátori jogosultsággal fognak futni. Az admin joggal futó malwarek aztán nagyon csúnya munkát tudnak végezni, gyakorlatilag nem csak az adott munkaállomást kompromittálják, de a teljes hálózatra is potenciális veszélyt jelentenek.

Ezért alap, hogy egy normálisan menedzselt hálózatban a lokális adminisztrátori jogosultság coki!

Illetve...

Hát igen. Sajnos mindig vannak kivételek.

Nem csak az ügyvezető, manager, kisfőnök, nagyfőnök – ezeket még egy rátermettebb biztonságis csak-csak el tudja tántorítani a jogosultságtól, nade...a fejlesztők...a devopsok...a rendszergazdák...a tudj isten kicsodák nagy hanggal és sajnos jogos igénnyel!

Pl. egy fejlesztő esetében roppant nehéz megoldani, hogy el tudja a munkáját végezni admin jog nélkül. Sajnos sok esetben naponta 58 komponenst telepítenek, törölnek, állítanak, fordítanak, stb. – szóval ha nincs lokál admin joguk, a munkavégzésük fog meghiúsulni.

Persze vannak alternatív lehetőségek, hogy a fejlesztőket mondjuk nem engedjük fel az éles hálózatra, karanténozzuk őket, akár két munkaállomásuk van, stb. – de ezt egyre nehezebb megtenni, és sok esetben ez sem fog megoldást jelenteni.

Aztán ott vannak a kisebb szervezetek, ahol az sem működőképes, hogy a 20-30 felhasználó alkalmazás-telepítési igényeit azonnal kiszolgálja az outsource rendszergazda, a felhasználók meg sok mindent nem szeretnek, de várni aztán biztosan nem.

Auditorként nagyon sok esetben találkozom ezzel a problémával, tele van a cég permanens lokális (rosszabb esetben domain) adminokkal, és a rendszergazda meg a biztonságis legfeljebb a vállukat tudják megvonni: - Tudjuk, de nem vonhatjuk meg a jogosultságot, mert akkor nem tudnak dolgozni.

A felhasználó adminisztrátori jogosultságának problémákra jelent jó megoldást az AdminByRequest.

AdminByRequest

A cucc röviden arra alkalmas, hogy egy felhasználó meg tudja igényelni a kiemelt privilégiumot, amely egy időablakban ítélődik oda neki, majd automatikusan, az időablak végén visszavonásra kerül.

Tehát ha Gyula szeretne egy alkalmazást telepíteni, amelynek elvégzéséhez admin privilégiumra van szüksége, Gyula meg tudja igényelni a jogosultságot 30 percre, el tudja végezni a tevékenységét, majd a jogosultsága automatikusan visszavonásra kerül. A felhasználónak nem kell permanens adminisztrátori jogosultsággal rendelkeznie, hiszen csak a telepítés (vagy más tevékenység) idejére van szükség a jogosultságra, azt és arra az időre pedig megkapja, ha megigényli.

Gyula megigényli a jogosultságot

Az adminisztrátor email értesítést kap az igénylésről, majd a menedzsment felületen jóváhagyja az igénylést

Gyula megkapta a jogosultságot, most már bármilyen kiemelt privilégiumú tevékenységet el tud végezni, ha a Windows bekéri az admin felhasználót és jelszót, a saját felhasználó nevével és jelszavával el tudja végezni a tevékenységet. 30 perc után a jogosultság visszavonásra kerül. 

Arra is van lehetőség, hogy egyes alkalmazásokhoz meg se kelljen igényelnie a jogosultságot, az alkalmazás elindításakor az már adminisztrátori jogosultsággal fog elindulni.

A rendszer működéséhez egy agent programot kell a munkaállomásokra telepíteni, a szabályrendszerek és logok a megoldás cloud-alapú menedzsment felületében találhatóak, és állíthatók be.

(Aki nem szereti a cloud megoldásokat, van olyan termék, amely onprem működésű és közel ugyanezt tudja).

A rendszer lehetőséget biztosít scoped policy kialakítására, azaz mindenkire érvényes egy alapértelmezett szabályrendszer, de felhasználói csoportonként akár eltérő szabályrendszerek is kialakíthatóak. Pl. a felhasználók jelentős részénél egy humán személynek (már amennyire egy rendszergazda ma még humánnak minősöl) jóvá kell hagyni az igénylést, de pl. egy kiemelt felhasználó esetében a jogosultságigényléshez nem kell a rendszergazdai jóváhagyás, ha megigényli, automatikusan meg is kapja az admin jogot.

A rendszer minden jogosultság-igénylést lenaplóz, és még azt is megmutatja, hogy mit csinált és mit telepített fel vagy indított el a felhasználó, amíg birtokolta a kiemelt privilégiumot.

A felhasználó ezeket a programokat indította el kiemelt privilégiummal

Ha a felhasználó éppen nem rendelkezik Internet kapcsolattal, és nem tudja megigényelni a jogosultságot (mert pl. az agent nem éri el a cloud menedzsment felületet), akkor is van lehetőség kiemelt jogot biztosítani a szerencsétlen usernek, ehhez minden felhasználóhoz egy napig érvényes PIN-kódot biztosít a rendszer. Azaz, ha a user legalább a rendszergazdát fel tudja hívni, az meg tudja nézni az adott user napi PIN-kódját, amelyet lediktálhat a felhasználónak, így az egy napig offline is megigényelheti a kiemelt privilégiumot.

Összefoglalás

Az AdminByRequest igen jól és egyszerűen használható megoldás, amely megszüntetheti a felhasználói permanens adminisztrátori jogosultságokból adódó kockázatokat. Nem kell állandóan admin jogosultság a felhasználóknak, csak akkor kapják meg a privilégiumot ha szükségük van rá, megígénylik és ha valaki jóvá is hagyja (vagy akár automatikusan jóváhagyódik).

Még arra is gondoltak, hogy egyes rafinált userek az ideiglenes jogosultságból megpróbálhatnak állandó jogosultságot csinálni, azaz az admin joggal hozzáadnák magukat a lokális adminisztrátori csoporthoz. Nyilván ezt megtiltani nem lehet, de az agent a munkaállomás következő újraindításakor kitakarítja az adminisztrátori csoportot, azaz ha a trükkös felhasználó újra indítja a gépét, az általa felvett felhasználó már nem lesz lokális adminisztrátor.

Az AdminByRequest egészen megfizethető árú cucc, érdemes kipróbálni és eljátszogatni vele. Akit a cloud menedzsment riasztana, annak a Basic Byte Access Director Enterprise lehet, hogy jobban fog tetszeni, talán  drágább megoldás, de teljesen onprem.

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.!!)