Sharky szakmai blogja IT biztonság, információvédelem, adatvédelem, GDPR témában

Kiberblog

Brutál magyar-leak update

gaming.png

Egy kis állapotjelentés a kiszivárgott magyar hozzáférésekkel kapcsolatban

A legtöbb szervezett visszajelentkezett ma, megköszönték az értesítést – nyilván ez azt jelenteti, hogy korábban nem tudtak arról, hogy valami történt a felhasználói adatbázisukkal.

Érdekes közjáték, hogy amikor felhívtam ma reggel az egyik szervezetet, a beszélgetés végén a kolléga megkérdezte, hogy miért szóltam nekik, mi a célom azzal, hogy szóltam, valamint, hogy akkor ezt ingyen csinálom? :)

Megpróbáltam elmagyarázni, hogy szakmai kötelesség, meg minden, hááát, nem tudom mennyire sikerült :)

Tegnap már igen álmos voltam amikor posztoltam, és nem nyomoztam sok mindennek utána. Ma már rájöttem, hogy az Euronote kikerült adatbázisával kapcsolatban már bőven voltak nyomok, most meg is találtam, hogy a publikálás dátuma idén februári (azt nem lehet tudni, hogy mikor vitték el).

Tegnap már nem volt erőm átnézni a kicsit összehányt részeket a listákból, de most jobban megnézve, alighanem a java még hátravan. Rengeteg játék oldal (kb 100), randi oldalak (Badoo, Zoosk) és lehetne sorolni, alighanem ezek jó része már régebbi (pl. Badoo breach 2016 – 122 MILLIÓ rekord, Zoosk breach 2016, 54 MILLIÓ rekord) – és pl. a Dump listában benne van az Euronote is, szóval már itt is lesznek ismétlődések.

Úgyhogy megpróbálok azokkal a listákkal foglalkozni, amelyekben van valamilyen magyar érintettség, az is éppen elegendő lesz szerintem :)

És a legfontosabb hír a végére, amit ma mindenki megkérdezett: NEM, nem voltak politikai pártok, vagy kormányzati felhasználók a pornó adatbázisban (legalább is hivatalos címmel nem :))

2018\05\08 snwx 8 komment

Többszázezer magyar felhasználó jelszava szivárgott ki

Nyugi, nem egyszerre, és nem most.

Egy orosz fórumon előkerült egy brutális mennyiségű felhasználó nevet és jelszót tartalmazó, kategórizált breach lista, amelyben többszázezer magyar felhasználó is szerepel. A szuperül összegyűjtött, könyvtárakba rendezett lista egy úgynevezett „kombó”, amelyben sok rendszerből kiszivárgott hozzáférések találhatók.

leak.png

A kombó összerendezője gondosan kategóriákba szervezte a hozzáféréseket tartalmazó fájlokat, pornó, shopping, trading, gaming, money, stb. kategóriák alá csoportosította az állományokat, illetőleg található egy Other folder meg egy Dump, amelyben ömlesztve a mangarajongóktól (MangaTraders) a Zoosk randioldalig minden nyalánkság megtalálható.

Külön érdekesség, hogy néhány magyar site is szerepel az étlapon

hazai.png

www.aktrecords.hu - (1180 rekord) esetében a felhasználó név mellé jelszó hashek (pucér MD5) kerültek ki, hashkiller oldalakon triviális...Az oldal működik.

www.cfoto.hu - (1239 rekord) esetében a felhasználó név mellé jelszó hashek (pucér MD5) kerültek ki. Érdekesség, hogy a listában jól látszik az SQL injection eredménye. Az oldal működik.

www.euronote.hu - (817 488 rekord) az oldal már nem működik, jobb is, cleartext jelszavak kerültek ki,

www.kszemle.hu - (19 769 rekord) esetében a felhasználó név mellé jelszó hashek (pucér MD5) kerültek ki. Az oldal működik.

www.matarka.hu - (32 296 rekord) esetében cleartext jelszavak kerültek ki, az oldal működik.

www.mbarat.hu - (24 162 rekord) esetében is jelszó hashek (pucér MD5) kerültek ki. A pucér kifejezés az oldal tartalmához viszonyítva megállja a helyét.

Nyilván nagyon nehéz a kategóriákban (kivéve a magyar siteok esetén) magyar felhasználókat keresni. Az alábbiakban álljon itt még néhány elrettentő szám:

Pornó:

Annunci69.it [527k].txt:78422

Расшифровка AnyWhere.xxx [272k].txt:29355

Расшифровка BDSMLibrary.org [60k].txt:60474

Расшифровка Brazzers.com [800k].txt:25783

Расшифровка BritishSexContacts.com [660k].txt:660270

Расшифровка HongFire.com [653k].txt:653290

Расшифровка Youporn.com [1.5kk].txt:31192

Расшифровка zTod.com [376k].txt:376557

Mi magyarok (ha csak a .hu domainre keresek rá) 5080 rekorddal képviseltetjük magunkat. Nyilván ez közelében sincs a valóságnak.

Shopping:

All_goods_S.txt:5642100

walmart_Goods.txt:309437

Расшифровка CashBackBoom [947].txt:947

Расшифровка Chanti.se [93k].txt:93114

Расшифровка E-Click.gr [46k].txt:46833

Расшифровка EuroNics.it [438k].txt:438592

Расшифровка FotoBoom.com [86k].txt:86369

Расшифровка FrancoBordo.com [7k].txt:7146

Расшифровка FutureShop.co.uk [13k].txt:13897

Расшифровка Groupon.co.id [972k].txt:972960

Расшифровка Habbo.st [270k].txt:270965

Расшифровка MagazineDee.com [107k].txt:107718

Расшифровка MindaCorporation.com [47k].txt:47843

Расшифровка MisterTao.com [158k].txt:158205

Расшифровка PubPit.com [51k].txt:51459

Расшифровка SmartHem.se [53k].txt:53985

Расшифровка TabakPfeife24.de [43k].txt:43594

Расшифровка TintenProfi.ch [90k].txt:90161

 A .hu érintettség 22 863 rekord.

Money

2kk[UK].txt:2166460

500+.txt:531046

mo_1.txt:1543122

mo_2.txt:1000000

mo_3.txt:227131

mo_4.txt:93826

mo_uk.txt:546861

money upd 1.11.2017_merge.txt:472414

Расшифровка Klerk.ru [151k].txt:151387

Расшифровка MMGP.ru [108k].txt:108552

Расшифровка MoneyBookers.com [1,7kk].txt:719745

Расшифровка Neteller.com [2kk] add pass.txt:1007999

A .hu érintettség 20 916 rekord

Hacking

Расшифровка BlackHatWorld.com [70k].txt:70650

Расшифровка D4tabase.com (Forum) [21k].txt:21286

Расшифровка DashHacks.com [149k].txt:149139

Расшифровка DemonForums.net [6k].txt:6749

Расшифровка FreeHack.com [25k].txt:25943

Расшифровка HackForums.net [120k].txt:120175

Расшифровка RootKit.com [63k].txt:63496

A .hu érintettség 514 rekord.

 Corporate

Összesen 5 033 198 rekordot tartalmaz, amelyben a .hu érintettség 22 055 rekord. (Önmagában is egy kombó lista).

A legérdekesebb Gaming kategóriát (105 breach lista) már nem volt erőm végignézni, az sokmillió rekordos játék lehet, szúrópróba szerűen megnéztem három fájlt, azokban 1678 .hu rekord volt, szerintem a teljes Gaming listában simán 50-80e lehet az összes  magyar-érintett rekord.  

gaming.png

Mivel a szaksajtó szereti felkapni ezeket a híreket, és hajlamos kijelenteni, hogy „megtörték a T-Online-t mert nagyon sok t-online.hu cím van a listákban!” leszögezném, hogy leszámítva a felsorolt magyar siteokat, az összes többi (kivéve még a Corporate listát, aminek a forrása ismeretlen) kiszivárgott hozzáférés jól beazonosítható: szerintem direkt a sajtó miatt nevezték el breach forrás szerint az állományokat (www.valami.com).

Az érintett magyar oldalakat (amelyek még működnek, illetve van legalább valami alap kontakt cím) értesítettem, mivel a fene tudja, hogy mikori történet ez (bár gyanús, hogy 2017-es események, plusz a Corporate listában szerepló .hu-s címek jó része is megtalálható más listákban).

Kicsit tartok attól, hogy a magyar siteok nemigen értesítették a felhasználóikat, és a jelszavak jó része még működik. Ahol MD5 hashek voltak, tucatnyit megnéztem online hashkiller oldalakon, nyilván már szerepelnek bennük, szóval azokat már visszatörték valamikor (ebből gondolom, hogy 2017-es és korábbi listákból rakták össze a jelenlegit).

Egyébként 17 nap van hátra a megváltó GDPR-ig :)

A GDPR szakértők balladája  

Hányjál savat és fakóra erjedt répát,
És hetes köpetet, tokokgörcsöt kapva;
Sárga kalapviaszt, lágyat, folyóst,
Lóvizelettel és tarjékkal elkavarva,
(Hackerek piszkát is hozzá kaparva;)
Vedd Bill bácsi szürke lábmosó levét,
Zuckerberg gatyájának izzadt ülepét
Egy szajha havi vérébe mártva;
Tégy hozzá öklendes, ecetes epét,
- A GDPR szakértőt ebbe főzd puhára!

Engedd Bezos testnedveit
Egy rozsdás bökővel a szabadba;
Csorgasd bele egy szaros vödörbe ,
És okádj utána fulladozva,
(E vágy már sok ember lelkét nyomta)
S kell hozzá még némi jogi-hordalék:
Zugügyvéd vérbő orrhegyén
Lecsorgó mutáns csimpánz nyála,
Nincs más e honban ízes, büszke pép,
- A GDPR szakértőt ebbe főzd puhára!

Virgonc Nadella savanyú köldöklevét
Lafatyold nyelveddel díszes ónkupába,
Fűszerezd Ebay-ről vet Himalája-sóval,
(Nem keverve, de jól összerázva,)
- Színe legyen vörös, felejtős a sárga:
Adj hozzá két egységnyi farpofa-lét,
Hajléktalanról férges koszt, sebet, fekélyt,
Egy fogorvos öblítő-vizébe hányva,
(Nem járt fogorvosnál, ki nem ízlelte még,)
- A GDPR szakértőt ebbe főzd puhára!

Ajánlás:

Péterfalvi Úr, törd át mind e csemegét,
Ha felkészülni nem volt idő elég,
Kipállott talpú zoknidon, vigyázva,
(némi bírsággal is ízesítsd azért) -
- A GDPR szakértőt ebbe főzd puhára

Címkék: GDPR jff

GDPR Hasznos Holmik – Helyreállíthatatlan adattörlés

A sorozat következő részében a végletes, helyreállíthatatlan adattörlést fogjuk kicsit közelebbről megnézni, azon belül egy kedves kis programot, a Jetico BCWipe alkalmazását.

Nézzük először a GDPR oldaláról, hogyan mit mond a rendelet az adattörlésekkel kapcsolatban.

Nem meglepően, technológiai oldalról egyáltalán nem beszél arról, hogyan kell nekünk törölni, nem beszél arról, hogy diszk wipe, file shredder vagy adatbázis szinten milyen alkalmazásokkal és funkciókkal kell nekünk törölni az adatokat.

Sokkal inkább arról beszél, hogy a magánszemélyeknek joga van töröltetni a róluk tárolt személyes adatokat (törléshez, elfeledtetéshez való jog), figyelembe véve a különféle jogalapok által előírt tárolási időket (hiszen vannak olyan személyes adatok, olyan adatkezelés, ahonnan akkor sem töröltethetünk adatot, ha földhöz verjük magunkat, ilyenek az egyéb, ágazati törvények által előírt adatkezelések és megőrzési idők, pl. nyugdíj, tb, stb.).

A 2011 óta hatályos Infotv. sokkal markánsabban beszél az adattörlés mivoltáról: kerek-perec kimondja, hogy az számít adattörlésnek, amely után az adat már nem helyreállítható többé – ez pedig igen erős célzás a végletes, helyreállíthatatlan adattörlés folyamatára.

A disk wipe és file shredder alkalmazások a fájlok, USB adathordozók vagy merevlemezek valamilyen biztonságos metódus szerinti adattörlését valósítják meg, olyan módon, hogy a fájlt vagy a merevlemezen tárolt összes adatot többszörösen, véletlenszerű vagy előre meghatározott adatmintákkal felülírják, ezáltal lehetetlenné teszik az adatok helyreállítását.

bcwipe.jpg

A következő videóban a Jetico BCWipe file shredder megoldását mutatjuk be, amely nem csak a fájlokat, könyvtárakat tudja biztonságosan törölni, de a böngészők és a Windows operációs rendszer „lábnyomait” is el tudja tüntetni – ezért nem csak vállalati célokra, de otthon is, a saját privacy terünknek védelmére is használható.

A videóban egyébként van egy még érdekesebb rész, hogyan, és mit lehet előkaparni egy felhasználó böngészési szokásaiból és adataiból (forensic).

Ha tetszik a videó és a sorozat, kérlek iratkozz fel a Jutub csatornánkra :) ITT

(Természetesen felmerül a kérdés, hogy mi van az adatbázisokkal, archivumokkal kapcsolatban, erre megpróbáltunk válaszolni a bevezető cikkben.)

Hogyan válasszunk adattörlő megoldást?

Amikor megmutattam a videót néhány ismerősnek, felmerült a kérdés, hogy jó-jó, nagyon sok cég kínál helyreállíthatatlan adattörlésre alkalmas szoftvereket, sőt még brutál durva vinyó darálót is, de hogyan lehet kiválasztani, hogy melyiket használjuk?

Erre nehéz válaszolni, ha a jogi/compliance oldalt nézzük, akkor az itthon elterjedt Blancco pontosan ugyanolyan jó, mint az itthon még ismeretlenebb WhiteCanyon, vagy akár a Jetico HDD wipe-oló alkalmazása 

  • A nap végén arról kell meggyőződnünk, hogy a kiválasztandó megoldás törlési metódusai megfelelnek-e az elvárásainknak, kellően biztonságosak-e, és rendelkeznek-e számunkra elfogadható nemzetközi minősítésekkel,
  • Képesek hivatalos és auditálható törlési jegyzőkönyveket készíteni,
  • És persze, valóban letörölik helyreállíthatatlanul az adatokat nem csak HDD, de SSD esetében is.

Szóval, ha a szoftver minősítései rendben vannak, jó és auditálható jegyzőkönyveket készít a törlésről, akkor nagyon melléfogni nem lehet, se a NAIH-ot, sem pedig más hivatalt nem fogja érdekelni, hogy Blancco-t vagy WhiteCanyont használunk: megnézik a törlési jegyzőkönyveket, riportokat, a törlési folyamat szabályozását – és ezzel kész, nekik teljesen mindegy milyen alkalmazást használtunk.

Ennek fényében azt kell megvásárolni, amely teljesíti az alapvető kritériumokat, és nem kerül rohadt sokba J

Mi van az ingyenes DBAN-al?

Korábban megkérdezték, hogy a DBAN (a Blancco ingyenes megoldása) alkalmazható-e a GDPR-érában a merevlemezek törlésére.

A DBAN baromi jó, és mivel ingyenes, olcsó megoldás J. Támogatja a nemzetközileg elfogadott DoD-5220.22-M szabvány szerinti törlési metódust (háromszoros felülírás, egy  bináris mintával, majd az első minta reversével, végül egy random mintával) , bár pl. az USA ezt a metódust már nem ajánlja, és kivette a biztonságos adattörlési metódusok közül.

Ettől függetlenül a legtöbb hazai vállalat (kivéve a nagyon speciális intézményeket) számára a DoD-5220.22-M szabvány szerinti törlési metódus teljesen elfogadható és vállalható – és tökéletesen megfelel a GDPR-ban nem leírt műszaki elvárásnak J.

A DBAN azonban más sebből vérzik: amellett, hogy nem tud UEFI-s rendszerrel dolgozni és nem támogatja az SSD-k biztonságos törlését, nem tud auditálható riportot és jegyzőkönyvet készíteni.

Mit lehet tenni? Mivel a GDPR igazából nem rendelkezik ezzel kapcsolatban, szerintem megfelelő kisvállalati megoldás, hogy a DBAN használatát némi adminisztratív funkcióval kiegészítve használjuk: készüljön fénykép a törlés sikeres befejezéséről (látszódjon a kezdés és vége dátum), valamint mentsük el a törlésről készült naplófájlt.

Ha elkészítünk egy saját jegyzőkönyvet, amelyben a naplófájl és a fotó is szerepel (a naplófájlban a törlés visszaellenőrzése is látszik), akkor ezt a jegyzőkönyvet, hacsak nem a TEK vagyunk vagy egy sokszáz/ezer fős bank – a Hatóság el fogja fogadni, mégpedig azért, mert a kockázatot figyelembe véve olyan megoldást alkalmaztunk, amely arányos a kockázatokkal ÉS figyelembe veszi az adott cég lehetőségét, erőforrásait.

Mert a GDPR egyik fontos elve, hogy nem vár el (többnyire) olyan védelmet, amely a kockázat és a költség, illetve más erőforrás tekintetében túlmutat az adott Szervezet lehetőségein.

GDPR Hasznos Holmik - Jogosultságok ellenőrzése

Szerintem a legfontosabb hozadéka a GDPR-nak, hogy át kell gondolnunk, a személyes adatokhoz (és más, bizalmas, számunkra fontos és értékes adatokhoz) pontosan ki férhet hozzá?

Nyilván jelen esetben a fájlrendszerben tárolt adatokra gondolok, aki már üzemeltetett Windows szerver környezetet, és állított már be könyvtár-jogosultságokat (különös tekintettel az öröklésekre), az már küszködött ezzel a problémával. Egy idő után igen átláthatatlanná válhat a történet, főleg, ha az örökléseket megtörve esetleg külön, egyedi jogosultságokat osztogatunk folderekhez és/vagy fájlokhoz.

Permission Reporter – jogosultságok vizsgálata, elemzése

Egy nagyon kellemes kis cuccról van szó, tökéletesen alkalmas arra, hogy a fájlszervereken olyan vizsgálatokat végezzünk, amelyek megmutatják, milyen folderekhez kinek és milyen jogosultsága van, illetve olyan anomáliákat keressünk, amelyeknek nem kellene úgy lennie a jogosultságkiosztásban.

ntfs-permissions-analyzer.png

Nem csak auditra alkalmas, folyamatos üzemben akár napi riportot kaphatunk arról, mijen jogosultságbéli változások történtek a fájlszerveren, ki kapott új hozzáférést és mihez, kinek változott esetleg jogosultsága.

Arra is remekül alkalmas, hogy automatikus riportokat kapjunk, akár arról is, hogy egy-egy fájlon milyen jogosultság-változás következett be.

Az alábbi videóban bemutatásre kerülnek a fontosabb funkciók, illetve az eszköz használatához is kaphattok kis segítséget.

Videó itt: https://www.youtube.com/watch?v=p0_luljnshU&t

Ha tetszik a kezdeményezés és a videó, kérlek, hogy iratkozz fel a csatornára :)

GDPR Hasznos Holmik - bevezető gondolatok

GDPR Hasznos Holmik – bevezető gondolatok

gdpr.png

Elindítottunk egy kis videó-sorozatot, ahol olyan eszközöket szeretnénk bemutatni, amelyek nem csillagháborús rendszerek, egy-egy jól körülhatárolható problémára fókuszálnak, és amelyekkel növelhető az általános IT- és információbiztonsági felkészültség.

Na meg persze, jók GDPR ellen is arra, hogy a GDPR szempontjából releváns IT- és üzemeltetési folyamatokat kicsit meg tudjátok erősíteni.

Hol szerepel az IT biztonság a GDPR-ban?

Legmarkánsabban a 32. cikk foglalkozik vele, minden konkrétum nélkül. Ezt azért fontos kimondani, mert amikor az IT sales (nem te) megkezdi udvarlását, sűrűn emlegeti a GDPR-nak való megfelelőséget (hiszen ma semmit nem lehet eladni, ami nem jó „GDPR ellen”).

Lássuk, mi minden jó tehát a GDPR ellen (Jellemzően ezek újonnan beszerzendő eszközök, ha van meglévő eszköz, az lehet, hogy nem jó, és ha nem jó, akkor kockáztatod a 20 millió EUR büntetést :)) 

  • Tűzfal,
  • IDS/IPS
  • Vírusvédelem
  • Privilégizált felhasználók felügyelete
  • Fejlett malware- és APT védelem
  • DLP
  • Wi-Fi
  • Storage
  • Adatbázis
  • Titkosítás
  • Mentés/archiválás
  • Naplózás
  • Beléptetés
  • Több faktor
  • Ticketing
  • Bármi, amiben van Mesterséges Intelligencia

 Szóval igazából mintha minden új eszköz jó lenne a GDPR megfelelőség eléréséhez.

Nézzük azt a 32. Cikkelyt:

Az adatkezelés biztonsága

(1)   Az adatkezelő és az adatfeldolgozó a tudomány és technológia állása és a megvalósítás költségei, továbbá az adatkezelés jellege, hatóköre, körülményei és céljai, valamint a természetes személyek jogaira és szabadságaira jelentett, változó valószínűségű és súlyosságú kockázat figyelembevételével megfelelő technikai és szervezési intézkedéseket hajt végre annak érdekében, hogy a kockázat mértékének megfelelő szintű adatbiztonságot garantálja, ideértve, többek között, adott esetben:

 a) a személyes adatok álnevesítését és titkosítását;

b) a személyes adatok kezelésére használt rendszerek és szolgáltatások folyamatos bizalmas jellegének biztosítását, integritását, rendelkezésre állását és ellenálló képességét;

c) fizikai vagy műszaki incidens esetén az arra való képességet, hogy a személyes adatokhoz való hozzáférést és az adatok rendelkezésre állását kellő időben vissza lehet állítani;

d) az adatkezelés biztonságának garantálására hozott technikai és szervezési intézkedések hatékonyságának rendszeres tesztelésére, felmérésére és értékelésére szolgáló eljárást.

(2)   A biztonság megfelelő szintjének meghatározásakor kifejezetten figyelembe kell venni az adatkezelésből eredő olyan kockázatokat, amelyek különösen a továbbított, tárolt vagy más módon kezelt személyes adatok véletlen vagy jogellenes megsemmisítéséből, elvesztéséből, megváltoztatásából, jogosulatlan nyilvánosságra hozatalából vagy az azokhoz való jogosulatlan hozzáférésből erednek.

 Fordítsuk le kicsit a jogi szöveget, hogy halandó IT-s is megértse

 (1)   Ha tárolsz és kezelsz személyes adatot, a tevékenységed és a tevékenységedet fenyegető kockázatok (és mellékhatások) figyelembe vételével alkalmazz (üzemeltess, használj, szerezz be, fejlessz) műszaki és adminisztratív védelmet és valósíts meg átlátható folyamatokat annak érdekében, hogy a kezelt adatok biztonságban legyenek. Ilyen védelmek lehetnek pl:

a) a személyes adatok álnevesítése és titkosítása (hiszen, ha már nem következtethető belőle ki a személy, akkor már nem személyes adat)

b) Gondoskodj az adatok sértetlenségének, rendelkezésre állásának és bizalmasságának feltételeiről (ahogyan azt egyébként a saját tulajdonú titkos, bizalmas, érzékeny adataiddal amúgy is teszed!)

c) Rendelkezz olyan műszaki képességgel, hogy ha valami baj történik, pl. elszállnak az adatok, akkor helyre tudj állni, és a személyes adatok újra rendelkezésre álljanak a kellő időben (ahogyan a saját tulajdonú adataid esetében amúgy is rendelkezel ilyen képességgel)

d) Ha már valami műszaki védelmet alkalmazol, vagy folyamatokat használsz, nem árt meggyőződni arról (és rögzíteni az eredményeket), hogy a műszaki védelem egyáltalán működik, illetve a folyamat valóban azt az eredményt hozza, emit elvártál amikor megtervezted a folyamatot.

(2)  Amikor műszaki vagy adminisztratív védelmet tervezel, mérd fel a kockázatokat, tartsd szem előtt a bizalmasság, sértetlenség és rendelkezésre állás elveit, minden folyamatban (tárolás, hozzáférés, továbbítás, kezelés, stb.) tedd fel a kérdést, hogy az adott lépés milyen hatással van az adat bizalmasságára, sértetlenségére és rendelkezésre állására.

Mintha ismerős lenne

Ha megnézzük a rögtönzött fordítást, az a rémisztő gondolat juthat eszünkbe, hogy baszki, annyira nagyon meglepő dolgokat nem is vár tőlünk ebben a pontban, sőt, mintha a sima IT- és információvédelem is ugyanezeket várná el tőlünk: a számunkra fontos adatok sértetlenségének, rendelkezésre állásának és bizalmasságának biztosítását.

Ezen a szálon tovább lépve belátható, hogy a GDPR és a hatókörébe tartozó személyes adatok nem jelentenek új adatosztályt a számunkra, inkább a „Bizalmas” adatosztályon belül egy adatminőséget, adatjellemzőt jelentenek – rájuk vonatkozó kontroll intézkedésekkel.

Nade a „Bizalmas” adatosztályhoz tartozó adatokat nem véletlenül soroltuk be "Bizalmasnak", azokra (elvileg) kontroll intézkedéseket hoztunk, legalább azt, hogy ész nélkül ne küldözgessük/publikáljuk/továbbítsuk – csak oda és akkor, amikor és ahova kell.

Szóval akkor felmerülhet a kérdés, hogy ha már eleve védjük a "Bizalmas" adatokat, akkor miért is kellene új eszközöket beszerezni egy már meglévő és most is védett adatosztályhoz tartozó adat védelmére?

Na?

Kivétel erősíti...

Természetesen azért nem teljesen ilyen egyszerű a kép, van néhány „elmebeteg” – és emiatt technológiailag vagy irdatlan költség mellett, vagy egyáltalán nem megvalósítható dolog a GDPR-ban.

Ennek ékes példája a törlésekkel kapcsolatos rendelkezés, pontosabban „A törléshez való jog („az elfeledtetéshez való jog”) – 17. cikk.“. Most hagyjuk, hogy vannak adatok, amiket azért nem lehet törölni, mert törvényi előírás az 5-10-25-50 éves megőrzés, amit ilyenkor fel szoktak hozni, hogy akkor ez azt jelenti, hogy ha valaki kéri a törlést, akkor nekem elő kell szedni az archivált szalagokat és az adatbázisokból ki kell törölni a vonatkozó személyes adatokat?

Igen azt jelentené, de ez technológiailag több okból sem megvalósítható.

Egyrészt az alkalmazások nem így lettek fejlesztve, ha adatbázisból kitörölnek adatokat, az az egész adatbázis integritására káros hatással lehet, másrészt meg egy ilyen művelet időben és munkafolyamatban is aránytalan terhet jelent a Szervezetre.

Én a magam részéről azt gondolom (és erre célozgat a GDPR is), hogy ha valami nem, vagy csak aránytalan költség mellett megvalósítható, akkor sajnos azt maradványkockázatként viselni kell (nyilván azzal, hogy akkor meghozunk olyan adminisztratív intézkedéseket, amelyekkel csökkenthető a kockázat). Meg kell tenni, amit lehet, de amit nem lehet, vagy nem vagyunk képesek megtenni, azzal nincs értelme foglalkozni.

A Hatóság (szerintem) amúgy sem ezt fogja vizsgálni, ennek műszaki ellenőrzésére semmiféle lehetősége nincs, és szerintem nem is lesz. Ráadásul értelme sincs ezt vizsgálni, amikor ezer más sebből véreznek a Szervezetek, minek ezzel bajmolódni, amikor egy NAIH kolléga néhány kiló papír bekérése és elolvasása után amúgy is bőven talál megállapítani valót (és akkor ne beszéljünk arról, hogy távolról egy weboldal átnézése, egy ügyfélszolgálat felhívásával bőven talál(hat) megállapítani valót).

Nyilván ennek a szélsőséges archiválásos/mentéses példának is lehetne műszaki megoldása – ha a rendszereket már eleve így fejlesztették volna. Egyébként azt viszont markánsan elvárja a GDPR, hogy az új fejlesztésű rendszereknél már a tervezéskor figyelembe kell venni ezeket az elveket, szóval ott már nemigazán menthető a dolog, de a meglévő rendszerek esetében szerintem ezt a példát el kell engedni.

(A példánál maradva, ha nem tudjuk törölni az archiválásból a személyes adatot, akkor biztosítsuk, hogy a szalagokhoz csak a megfelelő személy, csak felügyelet mellett, csak adminisztrálva, visszakereshetően, ellenőrzötten férhessen hozzá, ne állíthasson helyre csak ellenőrzötten adatokat a szalagról. Ez nem oldja meg a problémát, de csökkenti a bizalmasságra leselkedő kockázatot, és a nap végén a NAIH azt fogja vizsgálni, mit tettél annak érdekében, hogy az adatok biztonságban legyenek, és mit tettél annak érdekében, hogy megvédd az adatot).

Összefoglalva: néhány szélsőséges (és szerintem nem átgondolt) rendelkezés/elvárás kivételével, az IT oldalról a GDPR „megfelelőség” a legegyszerűbben úgy értelmezhető, hogy a személyes adatokra biztosítani kell a bizalmasság, sértetlenség és rendelkezésre állás szent hármasát – pontosan ugyanúgy, ahogyan azt a saját, szenzitív adatainkkal kapcsolatban is meg kell(ene) tennünk.

A GDPR előnye...

Készül az új céges weboldal. Minden egyes pillanatát utálom.

Párás szemmel sírom vissza a Lynx-et meg a Minuet-et: a régi, szép időkben nem kellett ennyi baromsággal foglalkozni, ha információ kellett, akkor ott volt, stabilan, reszponzívan, meg ami kell :)

minuett.gif

A legstabilabb browser, ever

 

Ehhez képest Noé küldött ma nekem egy levelet, amiben részletezte, miket kell javítani az új, céges weboldalon.

Legjobban azt hiányolta, hogy nincs kontakt form, a láblécben lévő generál email címre meg azt mondta, senki nem fogja megkeresni, és kell a kontakt form, de nagyon – ha valaki kommunikálni akar, ne kelljen már emailt írnia, klikk a formra, üzenet, és boldogság.

Zsigerileg utálom a kontakt formokat, bevallom. Rossz is a tapasztalatom velük, kitöltöm – oszt ennyi, nincs meg annak az érzése, hogy akkor én most felvettem a kapcsolatot.

Drága, boldogult emlékezetű főnököm egyszer azt mondta arra, hogy írtam egy cégnek a kontakt formjukon, hogy: „Jó, de írtál nekik emailt is?” – Tök igaza volt, a legtöbb form esetében nem küldenek vissza automatikus emailt arról, hogy „Tökikém, megkaptuk, láttuk, ezt és ezt írtad nekünk, majd válaszolunk, ha úri kedvünk tartja”.

Bevallom, nekem az email szent. Szeretem, na.

Próbálkoztam Noénak elmondani, de nem sikerült jó érvet találnom, amíg..hopp...megvan!

A GDPR!

Nézzük csak meg a kontakt formokat GDPR-szemüvegen keresztül.

Marha jól kinéző formok vannak különben, szolgáltatják cloudból, meg SaaS, meg egyéb 21. századi hívószóval, néhány dollárért, a hülyének is megéri! JavaScript, beilleszt, működik, floating, reszponzív, stb.

Nade, ha valaki kitölti és elküldi – az adatok a form-rendszer szolgáltatójához fognak kerülni. Oké, hogy megjön emailben is, de tárolódik a szolgáltatónál. Ami az esetek többségében amerikai. Mondom is Noénak: 

- Figyi, kéne valaki, aki leprogramozza a formba bevitt adatok elküldését. Nem értek hozzá, időm sincs (a nem értek hozzá nem kizáró ok!), pénzbe kerülne, meg macerás valakit megkérni, hogy csinálja meg. Ráadásul mi van, ha hülye és mindenféle sérülékeny dolgokat kódol bele...

- Jó, de lehet ilyet bérelni, adják szolgáltatásként is!

(ohóóó, most jövök én a hátulról mellbe módszerrel!)

- Ne haragudj, de GDPR-okokból nem lesz SaaS kontakt form az oldalon. Adatfeldolgozás lenne, kellene szabályozni meg dokumentálni, az adatvédelmi nyilvántartásba is kéne rögzíteni kellene, plusz kiemelten kell kezelni mert EU-n kívülre továbbít adatot.

Inkább nem mondom meg mi volt a válasz.

Ugyanezen gondolatsorra építve aztán megszüntettem mindenféle hírlevélküldést, amit szintén utáltam.

Végre valami előnyt is lehet élvezni a GDPR miatt.

Címkék: gdpr GDPR jff

Tiszta ész kritikája – a GDPR és a Panda Adaptive Defense margójára

Már előre várom, mikor kapom meg, hogy nem csak a magyar DLP-piac hanem az éppen fejlődésnek induló EDR-piac tönkretétele is személyesen hozzám fűződik. Jó az, ha az ember ott hagyja keze nyomát a világban :)

Megjelent egy „cikk” a Sysadmin Fórum hasábján (Már a címe is tetszik: Fizetett belső ellenségek - mit vessünk be ellenük), amely oly mértékben baszta ki nálam a biztosítékot, hogy átütve lustaságom betonbunkerét, arra késztet, hogy kiírjam magamból a mérgemet.

UPDATE: nem az EDR-ről beszél a cikk elsősorban, inkább globálisan az Adaptive Defense-ről és annak egy moduljáról. Szóval inkább úgy olvassátok, hogy az Adaptive Defense és/vagy BÁRMELY más vírusvédelmi megoldás (csak mellé lesz egy kis EDR :)

EDR nagyon dióhélyban

Az EDR az Endpoint Detection and Response csodálatos rövidítése, amely gyakran a Next Generation AntiVirus (NextGenAV), vagy a szignatúra-mentes AV néven is említésre kerül.

Az EDR megoldások nem a malwarek és más, káros kódok, alkalmazások, tartalmak szignatúra-alapú felismerésére teszik a hangsúlyt, azaz nem azért ismernek fel egy káros tartalmat, mert a kód lenyomata (szignatúrája) megtalálható a szignatúra adatbázisukban.

Az EDR nem más, mint egy alacsony erőforrásokat felemésztő (lightweight) modul, amely a munkaállomásokon fut. A modul többféleképpen működik, de a jobb rendszerek esetében a munkaállomáson érdemi felismerő tevékenységet nem végez, hanem a munkaállomáson bekövetkező minden egyes változást elküld a központi menedzsment eszközének, ahol ezek az információk korrelálódnak és tárolódnak.

Endpoint Detect

Nézzünk egy triviális példát. A felhasználó megnéz egy weboldalt.

Változás áll be a munkaállomáson, hiszen beírta a böngészőjébe a weboldal címét, elindult az oldal letöltése, TCP 80/443 hálózati forgalom történik, fájlok töltődnek le a munkaállomásra, a fájlok betöltődnek a böngészőbe és végül megjelenik a weboldal. Ez a folyamat rengeteg változást indikál, a fájlletöltés, a fájlok létrejötte és tárolódása a cache-be, a megjelenő weboldal, az elinduló JS vagy más aktív kódok – mind-mind változást okoznak a munkaállomáson.

De ilyen változás lehet az is, hogy a felhasználó csatlakoztat egy pedrive eszközt, az eszközkezelőben megjelenik az eszköz, felcsatolódik meghajtóként, állományok másolódnak be róla vagy íródnak ki rá.

Az EDR ezeket az adatokat, a változásokat továbbítja a központi feldolgozó eszközének, ahol ezen a rengeteg adaton „big data” elemzések történnek. Az EDR menedzsment központja az agy, ott tárolódnak azok az ismert káros folyamatok tevékenységi listái, hashek, stb.

Szóval koncepcionálisan az EDR tök jó, a folyamatokat, változásokat, processzeket, írás-olvasási műveleteket, API hívásokat, hálózati kommunikációkat korrelálja – tehát sokkal több adatból „jósol”, mint egy hagyományos vrusvédelmi megoldás.

A pendrive-os példát folytatva, ha egy pendrive-ról bemásol egy fájlt valaki a munkaállomására, elindítja, majd a fájl elkezd valamit csinálni viselkedni, akkor azért fog riasztani meg beavatkozni a rendszer, mert látta:

  • Felcsatolásra került egy pendrive,
  • Egy adott fájlt olvasott a felhasználó Explorer processze,
  • Majd ezt a fájlt átírta a munkaállomásra az Explorer,
  • A fájl elindult, processzt hozott létre.
  • A fájl vagy a processz tallózgatja a hálózatot, elkezd más fájlokhoz hozzáférni,
  • Crypto API hívásokat használ,
  • Sok írási/módosítási műveletet végez,

 ezért ez a fájl gyanús, nagy eséllyel ransomware, riasztás, beavatkozás.

Hogy honnan szedi a menedzsment/központ/brain a gyanús tevékenységek, viselkedések, folyamatok, stb-k jellemzőit?

Természetesen a Cyber Threat Intelligence a megoldás, azaz a CTI! :)

A jobb EDR rendszerekben a gyártó beletette amit tudott, viszont hogy a rendszer minnél több információval rendelkezzen a kibertér veszélyeiről, ezért más gyártók intelligenciája is becsatornázható az EDR rendszerbe, szóval a tudást nem csak a gyártó, hanem sok gyártó képes átadni az EDR rendszernek.

Az EDR másik nagy területe az R-betű, a Response.

A beavatkozás rengeteg mindent jelenthet az adott EDR megoldás képességeitől függően, gyanús tevékenységek blokkolása, riasztások, a munkaállomás izolációja a hálózattól, a teljes gyanús folyamat root-cause megjelenítése, miből mi következett vagy történt, milyen folyamatok milyen műveleteket csináltak, amelyekből az adott gyanús esemény következett be.

carbonblack-rootcause1.png

 EDR "root cause"

 carbonblack-rootcause2.jpg

EDR "root cause"

Szintén kiváló képesség, hogy az EDR rendszerek nagyon sok funkcióval támogatják a gyanús események kivizsgálását, akvizitálhatják a munkaállomás memóriaképét, a teljes merevlemez képet (online vagy offline), azokon is vizsgálatokat tudnak végezni.

Szóval összefoglalva, az EDR baromi jó dolog. Nem új hanem 4-5-6 éve létező terület (idekívánkozik, hogy a Carbon Black volt az első, tényleg jó használható és sokáig egyeduralkodó EDR megoldás), de önállóan valahogy soha nem tudott megkapaszkodni és elterjedni, talán mert az ezer éve berögzült „Legyen helyi AV/AM a munkaállomáson” elvvel szembe megy, és nem tudta megtörni a hagyományos vírusvédelem dominanciáját.

Most az látszik, hogy a hagyományos vírusvédelem eszi meg a területet, ennek jele, hogy mind a Panda, mind a Bitdefender végponti AV/AM termékek elkezdtek EDR funkciókat beintegrálni a szolgáltatásaikba. Nincs is ezzel semmi baj, sőt, örülök neki.

GDPR és Panda Adaptive Defense

Ami kibaszta nálam a biztosítékot (és ez nem a Panda és nem a Sysadmin Forum hibája, hanem túl sok hasonló, GDPR-t meglovagoló marketing cikk jelenik meg mostanában), hogy a cikk önmagával is ellentmondásos.

„Természetesen minden adatkezelőnek arányosan meg kell tennie mindent az adatok védelméért, de a legkeményebb büntetéseket várhatóan nem is azokra szabják ki, akiknél betörés vagy adatszivárgás történik, hanem akik ezt nem időben vagy nem megfelelően dokumentált módon jelentik be. A szabály szerint a vállalatnak a biztonsági esemény megtörténte vagy a tudomására jutása után 72 órája van, hogy a hatóságokhoz forduljon. Minden olyan történést jelenteni kell, amely európai uniós állampolgárok személyes adatait érintheti, és a jelentésnek tartalmaznia kell azt is, hány polgár milyen adatai kerültek illetéktelen kezekbe vagy veszélybe.„

 Mit mond a cikk ebben a tételblokkban?

  • Arányosan kell védekezni (kockázatarányosan)
  • Nem azt fogják nagyon megbüntetni, akinél betörés vagy szivárgás történik, hanem aki nem dokumentálja és jelenti le megfelelően az incidenst. 

Ebben még igaza is van a cikknek, és tűpontosan rámutat, hogy a GDPR nem technológiai-jellegű elvárásokat fogalmaz meg elsősorban, hanem adminisztratív és jogi folyamatokat.

Nézzük tovább a cikket.

Blablabla-blablabla-blablabla, mindent IS tud, és „Így nemcsak rögzíti a történéseket, így segítséget nyújt a végponti incidensek utólagos felderítésében, de támadás esetén riaszt is. Így nemcsak megelőzni segít a bajt, de akkor is elkerülhetjük a GDPR által kilátásba helyezett szigorú büntetéseket, ha megtörténik a legrosszabb és a bűnözők sikeresen ellopják tőlünk az adatokat.”

Majd megint blablabla-blablabla-blablabla, nindent IS tud, és „Így segít, hogy a vállalat sikerrel meg tudjon felelni a májustól kötelező érvényű GDPR szabályozásnak, és ne kelljen szigorú büntetésektől tartani.”

Na most akkor ezzel, hogy?

A cikk saját magával szembe menve, a tökéletes antinómiát megvalósítva jelenti ki, hogy nem csak minden ellen IS jó a Panda, de a Panda-t használva a vállalat sikerrel meg tud felelni a GDPR-nak és nem kell büntetéstől tartani.

Kanttal élve, jelen esetben a tiszta és nem gyakorlati-ész, a transzcendentális analitika és annak a vágya, hogy eladjunk Panda megoldásokat, nemigazán kapcsolódik a szemlélet (személyes adatok védelme) és a fogalom (GDPR) kettőséhez. A cikk szerzője jobban tette volna, ha saját köldökébe tekintve mélyen elgondolkodik és a GDPR – valóság viszonyában dependenciát, inherenciát és kauzalitást keres.

A Panda Adaptive Defense (Akár az EDR, akár a Panda Advanced Reporting Tool) semmiképpen és semmiképpen nem egyedi módon nem járul hozzá ahhoz, hogy egy szervezet megfeleljen a GDPR adminisztratív, jogi és adatkezelési elvárásainak, mivel ezek nem technológiai igényeket vagy védelmeket fogalmaznak meg, tehát nem tapasztalatból és érzékelésből származó, hanem az EU (Isten) létezéséből fakadó priori, szükségszerű és kellően általános ideák.

A Panda Adaptive Defense (EDR vagy Panda Advanced Reporting Tool funkcióval) tehát pontosan annyira illik a GDPR világképébe, mint bármely más Anti-Vírus megoldás.

De hogy a kis eszmefuttatás ne csak a levegőben lógjon, nézzük meg, mi az, amit a vállalatnak vírusvédelem esetén (amellyel amúgy is rendelkezik) GDRP-szempontból „megfelelően” kell tartania.

A "GDPR-ellen védő" vírusvédelmi megoldás, szolgáltatás:

 

  • Rendszeres és automatikus szignatúra-frissítés a végponti AV/AM eszközben,
  • Legyen hetenként legalább egyszer full/deep scan a munkaállomásokon végig tolva (Hogy az esetleg bejött, de akkor még nem felismert káros cuccokat is megtalálja, valamint nem minden AV/AM szoftver használja a teljes szignatúra adatbázisát a real-time védelemhez),
  • Az üzemeltetők értesüljenek a vírus/malware/egyéb és gyanús tevékenységekről – tehát legyen riasztás, értesítés beállítva!
  • Az üzemeltetők legalább hetente egyszer tekintsék át a héten bekövetkező eseményeket (heti riport), és ha kell, akkor további felderítő tevékenységet végezzenek az áttekintés alapján (gyanús esetek vizsgálata, logok összenézése, felhasználó letolása, stb.),
  • Vezetés felé készítsenek legalább havonta összefoglaló jelentéseket a vírus- és malware eseményekről, beavatkozásokról, arról, hogy pontosan mit csináltak, stb.
  • Lehetőleg a vírusvédelmi eszköz a keletkező logokat és naplóállományokat továbbítsa központi loggyűjtésbe vagy SIEM-be, korrelációra (hopp, nicsak!),
  • Legyen mentés J - ez különösen fontos, és lehessen visszaállni belőle,
  • Legyen valamilyen terv, eljárásrend, playbook arra az esetre, ha fertőzés, adatvesztés, vagy más, malware-indikált incidens történik, hogy az üzemeltetők tervszerűen, gyakorlatiasan, hatékonyan be tudjanak avatkozni és csökkenteni tudják a keletkezett kárt, majd eltakarítva a romokat, helyre kellő időn belül tudják állítani a kieső szolgáltatásokat, és vissza tudják állítani az adatokat (személyest és nem személyest is).

Szóval, ha termékcsere, bevezetés és plusz költségek NÉLKÜL, egyszerűen csak nem hagyják magára a vírusvédelmet, karbantartják, frissítik, monitorozzák és ellenőrzik – az AntiVírus/AntiMalware oldal tökéletesen meg fog felelni a GDPR technológiákkal kapcsolatosan megfogalmazott minimális elvárásainak.

Nyilván ennél lehet többet is tenni – de ha már ezt biztosítják, túl nagy baj ezzel nem lesz a Hatóság oldaláról, hiszen bizonyíthatóan megfelelő gondossággal jártak el.

Természetesen, ahogy a kockázat arányos védelem szellemében csak abban az esetben kell bármilyen extra védelem (sandbox, APT-védelem, EDR, vagy más „csillagháborús” megoldás), ha azt a kockázat mértéke igazolja, és a kockázat csillapítására bevezetett intézkedések vagy megoldások költsége arányos a kockázattal és annak lehetséges kárértékével.

A GDPR elvárásának megsértése – egy GDPR felkészülést segítő termékben

Amikor a szakértő és a marketinges nem ért egyet...abból igen vicces dolgok kerekedhetnek ki.

Így járt ezzel a Cookiebot nevű szolgáltató, akinek a megoldása lehetővé teszi a website-okon belüli cookie és tracking kódok vizsgálatát, nyilvántartását (és jópár egyéb igen hasznos funkciót).

A Cookiebot ingyenesen lehetővé teszi „kipróbálási célzattal” a saját weboldalunk vizsgálatát „Free GDPR/ePR test” néven, amelyhez meg kell adnunk a website címét – valamint az email címünket, ahova a riport eredményt továbbítja.

A vicc ebben csak az, hogy nem próbálhatjuk ki a vizsgálatot (scan-t), amíg nem kattintjuk be a hírlevélre történő feliratkozást! Hatalmas megalol!!!!!!!!!

cookiebot.png

A GDPR ugyanis kerek-perec kimondja, hogy az adatkezelés hozzájáruláson alapul, a hozzájárulásnak nemcsak önkéntesnek kell lennie, de a hozzájárulás megtagadása nem válhat az érintett kárára – azaz a hozzájárulás megtagadása nem lehet indoka a szolgáltatás megtagadásának.

“42 - A hozzájárulás megadása nem tekinthető önkéntesnek, ha az érintett nem rendelkezik valós vagy szabad választási lehetőséggel, és nem áll módjában a hozzájárulás anélküli megtagadása vagy visszavonása, hogy ez kárára válna.”

„(7/4)   Annak megállapítása során, hogy a hozzájárulás önkéntes-e, a lehető legnagyobb mértékben figyelembe kell venni azt a tényt, egyebek mellett, hogy a szerződés teljesítésének – beleértve a szolgáltatások nyújtását is – feltételéül szabták-e az olyan személyes adatok kezeléséhez való hozzájárulást, amelyek nem szükségesek a szerződés teljesítéséhez.”

Szóval az a gyakorlat, hogy a Cookiebot nem engedi a kipróbálás célú scannelést – erősen ütközik a GDPR 42-es pontjával és a 7-es cikk 4-es pontjával (mindamellett, hogy egyébként semmiféle tájékoztatást nem ad ilyenkor a cég az adatkezelésről, amelyet a GDPR szintén elvárna ugye).

Szóval ez kimondottan vicces. Itt egy szolgáltatás, amely szándéka szerint segíti a GDPR felkészülést/betartást – de igazából GDPR-sértő módon követeli ki magának a hírlevelekre való feliratkozást – különben ki sem tudod próbálni.

Címkék: gdpr
2018\03\04 snwx 1 komment

„Egyre többet látsz a titkos háborúból” - Snowden style!

Megérkezett az „Egy hacker élete” websorozat új epizódja!

A sorozatot fiatalok számára a NUPS CyberSec – azaz a Nemzeti Közszolgálati Egyetemen működő kiberbiztonsággal foglalkozó Kutatóműhely készíti abból a célból, hogy a fiatalok megismerhessék a kibertámadások és kiberaktivitások hátterét, módszereit – és következményeit.

Aki esetleg lemaradt volna a korábbi epizódokról, az a Hogyvoltban elolvashatja illetve természetesen meg is nézheti az epizódokat.

Az előző epizódnak ott lett vége egy ütős kliffbarnszal, hogy Samu a Nemzeti Kiberbiztonsági Hivatal főtisztjeként egyre többet lát a titkos háborúból.

Lelki válságot él át, hiszen a Hivatal már mindent és mindenkit megfigyel. Samunak ugyan nagyon tetszik a technológia, és hisz abban, hogy ez segíti a Hivatal munkáját, de azt is látja, hogy a főnökei – az Ezredessel az élen – nemigazán próbálnak határt szabni a megfigyeléseknek.

Samuban az évek alatt egyre gyűlnek a kétségek. Vajon minden állampolgár minden adatát be kell gyűjteni?! Bármilyen megfigyelést el lehet rendelni?

Nos nem akarom elspoilerezni az epizódot, de semmi váratlan nem fog történni. Sajnos az epizód nem nő fel a korábbiakhoz :(

Az előző rész lezárása brutálisan ütősre sikerült, tényleg ott a körömrágós kérdés, vajon Samu a lelkiismeretére hallgat, vagy pedig jó tisztként tovább szolgál. A jelen epizódban viszont semmi extra nincs: monoton dramaturgia mellett Samu akcióba lép.

Az akció meglehetősen klisés, a szivárogtatás módszere igen amatőrre sikerül, majd az egész menekülési akció is fáradt és letargikus. A végjátékban Samut utoléri az elkerülhetetlen – én pedig végig azon gondolkodtam, hogy ez az ötlettelen lezárás mennyire írható a dramaturg és mennyire az „elvárás – jogos bűnhődés számlájára.

Megmondom őszintén, kissé csalódott vagyok, ennél sokkal de sokkal többet kellett volna beletenni a részbe. Szomorú is vagyok, mert amilyen poénos és dinamikus volt a korábbi pár epizód, olyan halovány lett a végjáték. Kár.

De azért...

Nem szabad leírni a sorozatot, mert váratlanul méltóan újszerűt húzott az alkotógárda!!!! Megjelent egy alternatív epizód, azaz egy „mi lett volna ha” rész! Igen, ez frankó!

Emlékszünk, Samu barátunk merészet kockáztatott, amikor nem csak a szerelmét vallotta be Bettynek, de azt is elmondta, hogy ő törte fel az iskolai e-naplót, ezzel megmentve Bettyt a bukástól.

Betty az eredeti idővonalon természetesen értékelte Samu önfeláldozó tettét, ebben az alternatív részben azonban nem hogy nem értékeli, de egyenesen feljelenti Samut az osztályfőnöknél!

Innentől kezdve Samu korábbi világa megsemmisül, az alternatív idővonalon a kicsapást a gyorséttermi munka és az éjszakai hackelések követik. Samu nappal éttermezik, éjszaka  azonban az Anonymous hacktivista csoport ászaként korrupt politikust üldöz és vadászik le.

Természetesen a sorozat alkotói itt is odafigyeltek a következményekre – Samu az alternatív történetben is elnyeri méltó büntetését.

A börtöncellába lépve, a 150 kilós, agyonvarrt, pokolangyala-kinézetű (félmigráns) cellatárs rádörren Samura:

- Itten én vagyok a főtökös, csíra, a te neved meg ezentúl Betty!

 

Címkék: jff
süti beállítások módosítása