2020. május 18-án új hazai rekord született: a Nemzeti Adatvédelmi és Információszabadság Hatóság ezen a napon 100 millió forintos adatvédelmi bírság fizetésére kötelezte a Digi Távközlési és Szolgáltató Kft-t egy adatvédelmi incidens miatt.

Mielőtt elmélyülnénk a részletekben, idézzük fel:

• a korábbi 30 millió forintos rekordot a Sziget Kulturális Menedzser Iroda Zrt. „tartotta”
• 2019. évben (a teljes évben) a NAIH 87 millió forint bírságot szabott ki összesen.

100 millió forint adatvédelmi bírság egy incidensért?

A reakciók szélsőségesek, leegyszerűsítve:

• a Digi jól járt, mert a bírság árbevételének „csak” kb. 0,2%-a, holott a bírság maximuma az éves konszolidált árbevétel (47 299 383 ezer forint) 2%-a (kb. 1 milliárd forint), vagy 10 millió Euró (azaz kb. 3,5 milliárd forint) is lehetett volna;
• a Digi indokolatlanul lett büntetve, hiszen senkit sem ért kár.

Mi vezetett ide?

Lássuk, mi történt (dióhéjban –  a nyilvánosság számára elérhető bővebb információ a határozatban olvasható).

• A Digi létrehozott egy tesztadatbázist, amelybe betöltötte számos megrendelőjének és hírlevél-feliratkozójának személyes adatait, majd erről a vállalaton kívülről is elérhető tesztadatbázisról „elfelejtkezett”.
• Egy etikus hacker rátalált az adatbázisra és észlelte, hogy abban számos természetes személy neve, anyja neve, születési helye és ideje, lakcíme, személyi igazolványszáma (esetenként személyi száma), e-mail címe, vezetékes és mobil telefonszáma található. Bizonyítékként letöltött egy rekordot és a biztonsági hiányosságról értesítette a Digi Kft-t.
• A Digi a jogszabályi elvárásoknak megfelelően adatvédelmi incidensként kezelte az esetet: kivizsgálta azt, megszüntette a hiányosságot illetve az elvárt határidőn belül jelentette a NAIH felé, a történteket.
• A NAIH vizsgálatot indított és megállapította a hiányosságot, majd határozatot hozott : az eredmény új adatvédelmi bírság rekord, kerek 100 millió forint.

A cikk írásakor számos nyitott kérdés van: a határozat nem tért ki például arra, mennyi ügyfél (?) lehetett érintett az incidensben, és arra sem, hogy az etikus hackeren kívül bárki is hozzáfért-e az adatokhoz.

Nem ismert az sem, hogy a Digi belenyugszik-e a határozatba (és az adatvédelmi bírság mértékébe) vagy bíróságon támadja meg a határozatot (ahogyan a korábbi „rekorder” tette).

FRISSÍTÉS [2020.06.27 23:44]: A Digi kommentje alapján bíróságon fogja megtámadni a határozatot, azonban a bírósági eljárás elindításáról a frissítésben jelzett időpontig információ még nem áll rendelkezésre.

Hogyan reagált a „szakma”?

Az IT biztonsági  és adatvédelmi szakemberek nyilván elemezni fogják az esetet és várható, hogy születnek majd összehasonlítások egy korábbi, szintén etikus hacker által azonosított hiányossággal (amikor az etikus hacker a BKK elektronikus jegyrendszerét „törte fel” – annak a jutalma 10 millió forintos NAIH bírság volt).

FRISSÍTÉS [2020.06.17 22:51]:

Cikkünk publikálását követően elkezdtek sorjázni a szakmai oldalak cikkjei, például

• a HWSW cikke („Rekord mértékű adatvédelmi bírságot kapott a DIGI”),
• az Infostart cikke („Rekord mértékű GDPR-bírságot kapott a DIGI”),
• a Media1 cikke („100 milliós bírságot kapott a DIGI, mert rossz gazdája volt az ügyfelei adatainak”),
• a COMPUTERWORLD cikke („Durva összegű bírságot fizethet a DIGI”),
• a Jogaszvilag.hu cikke („100 milliós adatvédelmi bírságot kapott a DIGI”),
• az ITcafe cikke („Súlyos adatvédelmi bírságot kapott a DIGI”),
• a Pénzcentrum cikke („Lecsapott a hatóság: csúnya bírságot kapott a Digi”)

és sorolhatnánk – gyakorlatilag minden lényegi oldalon foglalkoztak a NAIH határozattal – nyilván a rekordösszegű bírság miatt.

FRISSÍTÉS [2020.06.27 23:44]:

A hír elérte a nem szakmai portálok, blogok ingerküszöbét is – mutatóba néhány észrevétel:

• origo („Rekordösszegű bírság az adatvédelmi hatóságtól Digi-ügyben”),
• kilonem100.blog.hu („A GDPR egy európai kafkai rémálom: az adatvédelmi szabályozás nem teszi jobbá a piacot, sőt”),
• borsod24 („Rekord nagyságú büntetést osztottak a DIGI-nek egy adatvédelmi hiba miatt, a cég perre megy”),
• pcx.hu („A DIGI százmilliós adatvédelmi bírságot kapott – Törvénysértésről ezúttal nincs szó, de a súlyos adatkezelési mulasztások miatt fizetniük kell Kilenc éve ismert biztonsági rést hagytak figyelmen kívül”),
• bitport.hu („100 milliójába kerül a DIGI-nek az elhanyagolt biztonsági rés”),
• hvg („Kikerültek az ügyfelek adatai, százmillió forintos bírságot kapott a DIGI”)

Az első kérdés:

Elkerülhető lett volna az adatvédelmi bírság?

A második kérdés:

Mit kell tenni, hogy Ön ne kapjon adatvédelmi bírságot?

Kezdjük pozitívan: a rendelkezésre álló információ alapján a Digi példamutatóan kezelte az incidenst, le a kalappal előttük – ez lehetne egy külön cikk témája, ahogyan az is, miért lett mégis adatvédelmi bírság rekord a határozatban, de most tekintsük át,

milyen hibák vezettek az elmarasztaláshoz,

ezekből már szinte elkerülhetetlenül következni fog, mit kellett volna másképpen tenni, illetve Önnek mit kell tenni, hogy ne kerüljön hasonló helyzetbe.

A magyarázatok, példák során túl fogok lépni a konkrét eseten, azon nyilvánvaló okból, hogy jelenleg nincsen a NAIH határozaton túlmutató információnk – nyilván egy szervezet sem szívesen osztja meg a számára hátrányos információt, különösen úgy, hogy lehetséges, bíróságon fog folytatódni az ügy és a perbeli érdekérvényesítést ronthatná, ha idő előtt kommunikálna a részletekről, álláspontjáról.

FRISSÍTÉS [2020.06.17 22:51]: Cikkünk publikálását követően érkezett információ: a Digi kommentje alapján bíróságon fogja megtámadni a határozatot.

Hangsúlyozom ezért, hogy a következő „magyarázatok” általános szakmai hibákat mutatnak be, és határozottan NEM a Digi hiányosságait (hacsak ezt kifejezetten nem írom). A határozatban bemutatotthoz HASONLÓ helyzet tehát akkor fordulhat elő, ha:

• valós üzemi („éles”) adatokat használnak tesztadatbázisban – ez sajnos gyakori, mert
  • „A valós életben előfordult problémák, hibák a legjobb tesztesetek!” netán
  • „A tesztadatokat állandóan frissíteni kellene, és nincs idő mindig személyteleníteni az üzemi adatbázisból áttöltött adatokat.”, vagy
  • „A tesztelés olyan komplex, hogy ahhoz nem lehetséges hasonló komplexitású tesztadatokat generálni, a projekt költségvetése és átfutási ideje nem bírná el.”.
• lehetséges, nem is tesztelésre, hanem egy üzemi adatbázis hibájának átmeneti javításáig a napi munkavégzés támogatására használják az adatokat – a jelenlegi határozatból ez gyanítható, azonban már a Digi sem emlékszik, milyen célra, mikor és hogyan kerültek a valós adatok a tesztadatbázisba, mert sem az üzleti, sem az informatikai oldalon nem tartották nyilván, abban a konkrét esetben mit és miért tettek az ügyféladatokkal – sajnos ez is gyakori szokott lenni, mert
  • „Az informatikusok tudják, mi kell a rendszerekhez, nem az üzleti felhasználók – hagyjuk őket dolgozni.”
  • „A tesztadatbázist úgyis el fogjuk dobni, arra a néhány napra nem kell ez a felesleges macera…”
  • „Csak próbálkozunk valami átmeneti megoldást összekalapálni, több ötletünk is van, nem kérhetünk mindegyikhez vezetői jóváhagyást, mert csak égő, hogy mi sem tudjuk, mi lesz nyerő elképzelés.”
• mivel az adatbázisban ügyféladatok és hírlevélre feliratkozók adatai együttesen szerepelnek, lehetséges, nem is kellett volna valamennyi adatot betölteni az adatbázisba, de
  • „Adatbázisból adatot nem törlünk, mert az csak felesleges hibalehetőség – megszűnik az adatok közötti konzisztencia.”
  • „Adatbázisból adatot nem törlünk, mert még nem tudjuk, mely rekordok kellenek majd nekünk.”
  • „Adatbázisból adatot nem törlünk, mert nincs rá idő – ha létrehozzuk az adatbázist, azonnal el kell kezdenünk használni, nem játszadozni akarunk!”
• az igénylési, jóváhagyási, végrehajtási és ellenőrzési funkciók nem működnek – erre az informatikusok általában legyinteni szoktak, vagy idegesek lesznek:
  • „Nincs nekünk időnk ennyi felesleges piszmogásra!” vagy
  • „Kevesen vagyunk, nincs lehetőségünk ennyi szerepkört kialakítani.” esetleg
  • „Nálunk univerzális szakemberek dolgoznak, akik tudják, mit és miért tesznek, önmagukat ellenőrzik.”
• az adatokat nem titkosítják, mert
  • „Ezt csak belsős kollégák használják, külsősök nem ismerik az elérési utat [szájhúzás, legyintés]”
  • „Ez csak egy gyenge tesztszerver, a titkosítás csak lassítaná a munkát [homlokkopogtatás]”
  • „Erre a néhány napra miért titkosítsunk, ez nem a NASA! [vállvonogatás]”
  • „Ezek csak nevek és címek, ha megnézik a cégnyilvántartást, egymillió ilyet találnak, hahaha… [össznépi kuncogás]”
• az adatok a vállalati környezeten kívülről is elérhetőek, mivel
  • „A külsős kollégáknak el kell valahogyan érniük a szervert, különben nem tudnak fejleszteni munkaidőn kívül”
  • „Nem lehet mindent korlátozni a tűzfalon, mert ha mellényúlunk, megállnak a rendszerek aztán kereshetjük a hibákat – ki tudja, melyik alkalmazáshoz milyen portot kell nyitva tartani.”
  • „Mindent tiltani és csak a szükségeseket engedélyezni? Hol élsz kisöreg, ki tudná, mi a szükséges?!?”
• a nyilvánosságra hozott sérülékenységeket nem szüntetik meg, a javítócsomagokat nem telepítik, mivel
  • „Ki akarna ide betörni, ez csak tesztadatbázis?”
  • „Honnan tudjuk, mikor, mihez adnak ki frissítést, nincs nekünk időnk ennyi marhaságot figyelni, a rendszernek ketyegnie kell, az a lényeg.”
  • „Nincs időablak a patchelésre, mert ennek a rendszernek mindig mennie kell.”
  • „Majd amikor leállítjuk a rendszert, patchelünk – szóljál, ha majd akkor eszedbe jut és még fontos lesz.”
• a szükségtelen adatbázisokat nem törlik, mert
  • „Örülünk, hogy létrehoztuk és végre tudjuk használni, dehogy töröljük!”
  • „Nekem kellene figyelni, hogy törölhető-e? Honnan tudjam, mikor lehet törölni? Még nem is dolgoztam itt, amikor létrehozták, azt sem tudom, ki kérte…”
  • Én aztán nem törlöm, senki sem meri kijelenteni, hogy már nem szükséges, én nem fogom a hátam tartani, hogy aztán majd rajtam verjék le, hogy valamit miattam nem tudnak megcsinálni!”
  • „Én csak üzemeltetek, nekem nem feladatom a törlés, az a biztonságiak dolga.”
  • „Én csak a biztonságért felelek, az adatbázisokat az üzemeltetők hozzák létre és tartják karban, nekik kell tudni, törölhető-e.”
• a külső hozzáféréskor nem kerül sor riasztásra, ugyanis
  • „Miért lett volna furcsa, hogy kívülről is hozzáfértek? Mindegyik fejlesztőnk kívülről dolgozik…”
  • „Nincs nyilvántartás a felhasználókról, a biztonságot az adja, hogy csak a munkavállalók ismerik az elérési utat.”
  • „Központi naplóállomány gyűjtő és elemző rendszer? Tudod Te, mennyibe kerül az és milyen sok ember kell, hogy működtesse?”
• a naplóállományokat nem megfelelően mentik, mert
  • „Mentés? Hova? Örülünk, hogy a szükséges adatoknak van hely: éles adatbázis, fejlesztői adatbázis, felhasználói teszt adatbázis… meg az az új valami, amin a most felvett emberek dolgoznak, amit nem is tudunk, micsoda…”
  • „Tesztadatbázist naplózni és menteni? Miért? Mi érdekes van egy tesztadatbázisban? Ja, nevek és címek – hát, tudod Te, mennyi Kovács úr létezik, nem mindegy, hogy itt vagy ott lakik?”
  • „Mentettük mi, de egy hét után felülírtuk, mert nem volt semmi probléma, akkor meg miért is kellene őrizgetnünk?”
• az informatikai környezetet nem ellenőrzik, mert
  • „Belső ellenőr? IT auditor? Penetrációs teszter? Aztán a pénzt ki adja rá?”
  • „Van ellenőrünk, de megmondtuk neki, ne zavarja a munkát, mert ő is abból kapja a fizetését, amit megtermelünk.”
  • „Annyi hatóság, felügyelet auditálgat bennünket, hogy nem hiányzik még egy belső ellenőr a vérünket szívni!”
  • „Sérülékenységvizsgálatot, hogy megfeküdjön a rendszerünk? Éjjel, amikor a mentések mennek?”

Ismételten hangsúlyozom, a fenti példák „általános informatikus szövegek” és határozottan NEM a Digi szakembereitől származnak és még határozottabban NEM a jelenlegi sajnálatos eset hátterét mutatják be – annak ellenére, hogy már mindegyiket hallottam különböző, auditált szervezeteknél, viszont ha Ön hasonló magyarázkodást hall munkatársaitól, határozottan kezdjen el félni, mert könnyen hasonló cipőbe léphet, mint a DIGI.

A sok okoskodás után:

Szeretné elkerülni, hogy Önöket is adatvédelmi bírság sújtsa?

Mit kellene tenni, hogy hasonló eset Önöknél ne forduljon elő?

Csodák nincsenek, szisztematikus, kitartó munkát kell végezni. Tisztelettel adózva Benedek Tibor emlékének felidézzük, mit tartott ő sikerei titkának:

„… ha legvégül össze kellene foglalnom a sikereim okát, csak annyit mondanék, hogy mindig én akartam jobban”

Minimálprogram

• fel kell mérni, felül kell vizsgálni a tesztadatokat tartalmazó adatbázisokat és
• amennyiben nem szükségesek, törölni kell őket teljes mértékben, dokumentáltan (!),
• amennyiben szükségesek:
  • meg kell akadályozni, hogy a Szervezeten kívülről elérjék a tesztadatbázisokat
    • ha ez bármi okból mégis szükséges, technológiai eszközökkel szabályozni és korlátozni szükséges, ki, mikor és hogyan érhető el az adatbázisokat (pl. ha a külső fejlesztő mindig éjjel dolgozik, számára nem indokolt a napközbeni hozzáférés, és fordítva: ha a tesztelők csak 6-12 óra között dolgoznak, számukra indokolatlan az ezen időszakon kívüli hozzáférés),
    • a „korlátot” a tesztadatbázistól „minél távolabb” kell felépíteni, és lehetőleg több szinten kell érvényesíteni (az IDS-ben, tűzfalban, VPN koncentrátorban  stb. korlátozni kell a felhasználót (le kell tiltani a távoli hozzáférését a mindig az irodában dolgozóknak), a belépés helyszínét (pl. a kizárólag Magyarországon munkálkodók esetében korlátozni kell az országon kívüli hozzáféréseket), valamint le kell tiltani a megbeszélt munkaidőn kívüli hozzáférési lehetőséget stb. – sőt, bármennyire is egyszerű, a MAC-address szűrés is lehet egy réteg,
  • a Szervezeten belüli tesztadatbázis-hozzáféréseket szintén a legszükségesebb személyekre kell korlátozni:
    • aki egy hónapig nem lép be az adatbázisba, attól meg kell vonni valamennyi hozzáférést (ha szükséges lesz, újra be lehet neki állítani),
    • a nevesítetlen vagy a több személy által használ felhasználókat meg kell szüntetni,
    • a szállító (gyártó) által létrehozott „beépített” felhasználókat lehetőleg át kell nevezni és a jogosultságaikat meg kell vonni,
    • ha lehetséges, be kell vezetni a kétfaktoros bejelentkezést valamennyi felhasználónál,
    • a különböző tesztadatbázisokban nem csak eltérő jelszavakat, de lehetőleg eltérő felhasználói azonosítót is kell adni a személyeknek (ha ugyanazon személy mindegyik tesztadatbázisban „Joska88” azonosítóval szerepel, innen csak egy lépés, hogy ugyanazt a jelszót is fogja használni),
    • kerülni kell a nyilvánvaló felhasználóneveket („teszt”, „testuser”, „user”, „admin”, „guest”, „backup”, security”, „external”, „treasury”, „zsirosdeszka” (igen, az informatikusok között ez is tipikus…),
  • a tesztadatbázisokhoz hozzáférők jogosultságait a minimálisan szükséges, de elégséges szintre kell korlátozni (olvasási jogosultságon felül csak annak kell bármi jogosultságot beállítani, aki ÍRÁSBAN meg tudja indokolni a szükségletet és azt a felettese, valamint a tesztadatbázis létrehozását kérelmező felhasználó, valamint az informatikai vezető (ennek hiányában a leginkább respektált szakember) egyaránt ÍRÁSBAN jóváhagy; a napi szintű törlési jogosultság pedig általában senkinek sem indokolt (adatot óvatos informatikus nem töröl, „csak” az elérhetőségét korlátozza – a GDPR megkövetelte adattörlés eseti szokott lenni), a „drop table” utasításhoz pedig senkinek sem kell ÁLLANDÓ jogosultság – amikor szükséges, arra a néhány percre kell csak beállítani, utána visszavonni),
  • jelszópolicy-t kell bevezetni:
    • az üzemi adatbázisokkal megegyező védelmet kell kapnia minden tesztadatbázisnak, amelyben valós üzemi adatok szerepelnek,
    • legfeljebb öt sikertelen belépési kísérletet követően zárolni kell az azonosítót – feloldani csak ÍRÁSOS kérést követően szabad,
  • ki kell törölni a tesztadatbázisokból a nem releváns adatokat (a nem releváns mezőket és a teszteléshez szükséges számosságon felüli rekordokat egyaránt)
  • lehetőleg titkosítani kell valamennyi tesztadatbázist (ha valós felhasználói és egyéb, személyhez kötődő adatokat tartalmaznak),
  • át kell gondolni, szükségesek-e valós (éles, üzemi) adatok a teszteléshez és lehetőleg kiváltani őket tényleges tesztadatokkal (Teszt Terézia stb.), de legalábbis egyes adatokat át kell írni „generált adatokra”, például:
    • a neveket, édesanyja neveket véletlen karakterekre,
    • a születési adatok közül legalább a napot véletlen karakterekre kell cserélni,
    • a lakcímnél legalább a házszámot véletlen számra kell cserélni,
    • az adóazonosítót és egyéb hatósági azonosítót a szintaktikai szabályok szerint generált számra, karaktersorozatra kell cserélni

Első lépés az adatvédelmi bírság megelőzése érdekében

A valós helyzetet megismerése és a lehetséges gyengeségek azonosítása érdekében készíteni kell egy nyilvántartást, amely tartalmazza

• valamennyi tesztadatbázis nevét, elérhetőségét, célját, létrehozási és utolsó használati idejét,
• valamennyi tesztadatbázis további fenntartásának indoklását és a fenntartási időszak várható végét, az ezt igénylő üzleti felhasználótól származó indoklással és a felhasználó nevével, beosztásával,
• valamennyi tesztadatbázis informatikai üzemeltetőjének nevét, beosztását, elérhetőségét,
• valamennyi tesztadatbázis valamennyi felhasználójának nevét és beosztását (különös tekintettel a Szervezeten kívüli személyekre és a nevesítetlen, valamint a többek által használt felhasználókra ),
• a tesztadatbázisokban tárolt adatok felsorolását (pl. milyen felhasználói és egyéb adatok találhatóak benne, meddig visszamenőleg, mikori állapot alapján készült, mely adatbázisból lett létrehozva stb.),
• a tesztadatbázisokban tárolt adatok számosságát (pl. mennyi felhasználónak, mennyi adata található benne),
• az egyes tesztadatbázis védelmére jelenleg alkalmazott megoldások leírását (különös tekintettel a felhasználói név és jelszó policy-re),
• a tesztadatbázisok védelmére bevezethető további intézkedések leírását és a bevezetés határidejét,
• a tesztadatbázis anominizálása érdekében alkalmazható intézkedéseket és azok határidejét,
• a harmadik fél (külső szervezet, partner, fejlesztő, üzemeltető stb.) által üzemeltetett tesztadatbázisok esetében a fentieken túl
  • a Szervezet és a harmadik fél Adatkezelési tájékoztatójában a Szervezet felhasználóinak/ munkavállalóinak/ partnereinek adatainak kezelésére vonatkozó leírást,
  • a harmadik fél szerződéses kötelezettségvállalását arra vonatkozóan, hogy milyen védelmi intézkedéseket tett, tesz meg a jogosulatlan hozzáférések és módosítások megelőzése, azonosítása érdekében,
  • a harmadik fél Adatkezelési tájékoztatójában a Szervezet felhasználóinak/munkavállalóinak/partnereinek adatainak kezelésére vonatkozó leírást (tájékoztatást).

További lépések az adatvédelmi bírság megelőzése érdekében

A további lépések részben attól is függenek, hogy mi az eredménye a felmérésnek.

Örömmel segítünk Önnek, kérjük ezért vegye fel velünk a kapcsolatot.

Általunk támogatott szervezet még nem kapott adatvédelmi bírságot, ami természetesen nem garancia arra, hogy ez a jövőben is így fog alakulni, de azért kedvező kiindulási alap a közös munkára.

A Adatvédelmi bírság bejegyzés először Jasipos IT biztonsági és audit kft-én jelent meg.

A GDPR (General Data Protection Regulation) a 2018. május 25-től valamennyi EU országban kötelezően alkalmazandó személyes adatvédelmi irányelv (pontos neve „Az Európai Parlament és a Tanács (EU) 2016/679-es rendelete”, amelyet 2016. április 27-re dátumozva hirdettek ki).

Még egy jogszabály a többi mellé – no és…

2016. április 27-ig az EU már 678 jogszabályt adott ki, azokkal nem foglalkozunk… ezzel pedig részletesen?!?

Miért kell erre az egy jogszabályra ennyi figyelmet fordítani?

Bevezetésként néhány „hatásvadász” érv:

• A GDPR-ban megfogalmazott elvárásokat nem teljesítőkre kiszabható bírság 10 / 20 millió EUR közötti lehet (pontosan: az éves bevétel 2, kirívó esetben 4 százaléka) ESETENKÉNT.
• Ha a bevétel 2/4 százaléka magasabb 10/20 millió EUR-nál, a magasabb érték lesz a büntetés.
• A bizonyítási teher fordított (azaz ha az adatkezelő nem tudja adott időn belül bizonyítani, hogy a GDPR-ban előírtak szerint jár(t) el, a jogsértés megállapítható).
• Valószínűsíthető, hogy
  • számos „megélhetési feljelentés” fog történni,
  • a felkészületlen szervezetet „meg fogják támadni„
  • az első megtámadott szervezetek mire feleszmélnek, pénzügyileg el fognak lehetetlenülni,
  • társadalmi felháborodás lehetséges az alapszolgáltatásokat ellátó szervezetek ellehetetlenülése esetén (amely a szervezeteken már nem fog segíteni)

Ha az adatkezelő nem megfelelően készül fel a GDPR előírásaira, lehetséges, hogy 2018. június 26-án (egy hónappal a GDPR bevezetését követően) még be tudnak menni szokott munkahelyükre a munkavállalók: az épület a helyén lesz, az energiaellátás még működik, az ügyfelek még telefonálnak, de a háttérben olyan hatósági, bírósági eljárások indulnak meg, hogy a biztos vég csak idő (egy-három év) kérdése.

Amikor az előadásban ezt említem, körbenézve látni szoktam néhány kétkedő tekintetet. Ilyenkor mindig nagyra becsült korábbi főnököm szokásos mondása jut eszembe: „Azt szokták mondani, hogy pesszimista vagyok, pedig utólag rendre kiderült, hogy optimista voltam…„

A GDPR-ra azért kell kiemelt figyelmet fordítani, mert

• komplex elvárásrendszernek kell megfelelni,
  • amely csak időben történő felkészüléssel lehetséges,
    • olyan kollégákkal, akik értik, mire és miért kell figyelni.
• Várhatóan számos megkeresés fog érkezni,
  • amelyekre határidőn belül reagálni kell,
    • mivel el szeretnénk kerülni a várható hatalmas büntetéseket és kártérítés fizetési kötelezettségeket.

2016-ban, az első hazai GDPR konferencián nyolcan voltunk: hét érdeklődő jogász és én, informatikus-közgazdász biztonsági szakemberként. Akkor még volt olyan jogász, aki csak legyintett az aggodalmakra: „Miért kell ezen annyit pörögni? Előbb-utóbb minden megoldódik…ez is egy jogszabály, majd lepapírozzuk, amit kell…„

Ez a hetvenedik emelet…

…még minden rendben

…nem kell izgulnom…

Ez az ötvenedik emelet

…még minden rendben

…

A személygépjárművet vezetni kívánó személy elméleti képzés, elméleti ismeretekből letett vizsga, rutingyakorlatok, vezetési gyakorlatok, újabb vizsgák sikeres teljesítését követően kap „licencet” gépkocsi vezetésére, a GDPR használatát ellenben nem oktatják, az alkalmazását nem tanítják.

Aki volt GDPR „képzésen”, tudja, miről beszélek: több napon keresztül olvassuk a jogszabályt – vagy rövidebb képzés esetén a jogszabály kiemelt paragrafusait és az előadó megmagyarázza, mit is jelent a leírt szöveg jogi szempontból. Az alkalmazással kapcsolatos tudásmegosztásra, kérdések feltételére már nem marad idő, az előadó – aki általában kiváló elméleti szakember, egyetemi oktató stb. – nem tér ki arra, hogy mit is jelentenek a leírtak gyakorlati szempontból. Volt olyan konferencia (szerencsére csak egy), ahol az egyik előadó (elismert jogtudós) felháborodott a GDPR gyakorlati alkalmazására irányul kérdésen, mondván, még nem kiforrott a jogi környezet. 

A résztvevőket pedig az érdekli, hogy…

• Megfelelő-e az ügyfélszolgálatunk kialakítása abban az esetben, ha…?
• Kell-e kamerát üzemeltetnünk akkor, ha …?
• Hogyan kell kezelnünk a kamerafelvételeket akkor, ha …?
• Az adatkezelés jogalapjaként elfogadott-e az, hogy …?
• Ha az ügyfélnek azt mondjuk, hogy …, az megfelelő tájékoztatás-e?
• Ha az ügyfeleket … szerint … soroljuk, az profilozás? Ha igen, akkor elegendő, ha …?
• Mit kell tennünk, ha … tartalmú megkeresést kapok levélben?
• Ugyanezt kell tennünk, ha a megkeresés e-mailben történik?
• Hogyan tudjuk bizonyítani, hogy az adatkezelésünk megfelelő?
• Mit kell tennünk előzetesen, hogy bírósági eljárás során a lehető legjobb pozícióban védhessük az érdekeinket?
• Ha a bíróság elmarasztaló ítéletet hoz, ki a felelős abban az esetben, ha…?

… és sorolhatnánk.

A felkészülést segítendő készítettünk egy gyakorlati szempontú, „hétköznapi szóhasználatú” kérdésgyűjteményt, amelyhez természetesen megadtuk a válaszokat is. 🙂 

Mire és kire vonatkozik a GDPR?

K: A GDPR csak a személyes adatok védelmére vonatkozik vagy a gazdasági társaságok üzleti adatait is a GDPR-nak megfelelően kell védeni?

V: A GDPR a személyes adatok védelmére vonatkozik, a gazdasági társaságok üzleti adatainak védelme nem tárgya az irányelvnek.

Személyes adat bármely olyan adat, ismeret, vagy akár adatok összessége, amely egy konkrét, élő természetes személlyel közvetlenül vagy akár közvetve kapcsolatba hozható, beazonosítható, valamint az adatból levonható, az érintett személyre vonatkozó következtetés.

név, cím, születési adat, igazolványok száma, TAJ szám, adóazonosító jel, végzettségre és képességre vonatkozó információ, magántelefonszám és e-mail cím, arcképmás, hang, kézjegy, IP cím, helyinformáció, notebook akkumulátor azonosító…

A személyes adat az adatkezelés során mindaddig megőrzi e minőségét, amíg kapcsolata az érintettel helyreállítható.

Különleges adat a személyes adatok azon része, amelyet a jogalkotó különleges védelemben részesít.

faji eredetre, a nemzeti és etnikai kisebbséghez tartozásra, a politikai véleményre vagy pártállásra, a vallásos vagy más világnézeti meggyőződésre, az érdekképviseleti szervezeti tagságra, a szexuális életre, az egészségi állapotra, a kóros szenvedélyre vonatkozó személyes adatok, a bűnügyi személyes adat (erkölcsi bizonyítvány tartalma is)…

K A GDPR csak az ügyfelek adatainak védelmét várja el?

V: A GDPR az adatkezelő által kezelt valamennyi személyes adatainak védelmét elvárja (ügyfelekét, munkavállalókét, partnerekét, érdeklődőkét stb.).

Mindenki adatkezelő?!?

K: A GDPR csak a gazdasági társaságok által kezelt személyes adatokra vonatkozik?

V: A GDPR attól függetlenül kötelezően betartandó, hogy a személyes adatokat gazdasági társaság, nonprofit társaság, állami szerv, egyház vagy másik magánszemély kezeli (az adatkezelő szervezeti minősége nem szempont).

K: Magánszemély mint adatkezelő? Mindenki adatkezelő?!?

V: Nagy valószínűséggel igen – beszéljük meg személyesen, miért!

A háztartási adatkezelés nem ide tartozik, viszont… (itt nem merülünk bele a részletekbe, mert elviszi a fókuszt, de személyesen állunk rendelkezésére).

K: Ha a társaságunk Magyarországon is folytat üzleti tevékenységet, de az EU-n kívül van bejegyezve, és valamennyi ügyviteli tevékenységet (adatkezelést) az EU-n kívül végez, a GDPR ugye nem vonatkozik rá?

V: A rendelet hatálya valamennyi adatkezelőre kiterjed, amely olyan személyes adatot kezel, amelynek „birtokosa” az EU-ban honos; függetlenül attól, hogy az adatkezelő az EU-ban honos vagy sem; illetve az adatkezelés az EU-ban történik vagy azon kívül. 

Előírások és büntetések

K: A GDPR enyhébb előírásokat fogalmaz meg a kisebb gazdasági súlyú szereplők számára – hiszen a GDPR-t leginkább a nagyvállalatok megbüntetésére találták ki?

V: A GDPR ugyanazokat az előírásokat fogalmazza meg valamennyi adatkezelő számára, függetlenül attól, hogy az mikrovállalkozás, egyház, multinacionális vállalat vagy a törzsvásárlói adatait kezelő őstermelő.

K: A GDPR előírásainak megszegésekor csak gazdasági társaságoknak kell büntetést fizetniük?

V: A GDPR előírásait megszegő valamennyi adatkezelőnek büntetést kell fizetnie.

K: A GDPR előírásainak első megszegésekor csak figyelmeztetés lesz a büntetés, az első nem-megfeleléskor még nem kell büntetést fizetni?

V: A GDPR előírásainak már az első megszegésekor is büntetést kell fizetni.

Az első alkalommal büntetés eltérő a poszt írásakor alkalmazott magyar előírásokhoz képest; ugyanis magánszemélyek, mikro- és kisvállalkozások esetében először előforduló szabálysértés illetve vétség esetén a hatóság nem pénzbüntetést szab ki, „mindössze” figyelmeztet és felszólít a jogszabályok előírásának megfelelő állapot helyreállítására. A GDPR ilyen toleranciát nem tartalmaz; ott már az előírások első megszegésekor is szankciókkal kell szembenézni.

K: A GDPR kötelező alkalmazási időszaka kezdetén enyhébb büntetést kell majd fizetni?

V: A GDPR kötelező alkalmazási időszakának első napján tapasztalt nem-megfelelés esetén ugyanolyan nagyságú büntetést kell fizetni, mintha a nem-megfelelésre több évvel később derült volna fény – sőt, az alkalmazási időszak elején (az első 4-6 évben) a jogalkotó szándéka szerint „példát kell statuálni”, azaz szigorúbb büntetéseket kell alkalmazni annak érdekében, hogy minél korábban a köztudatba ivódjon, hogy az adatvédelmi előírásokat komolyan kell venni, be kell tartani, mert különben…

K: A GDPR előírásainak megszegésekor a kisvállalatoknak csak kisebb büntetést kell fizetniük?

V: A büntetés mértéke a GDPR alapján vállalatnagyságtól független; azaz (például) a BMW AG és (például) Kovács Géza húszkörtefás őstermelő büntetése egyforma (lehet) (az éves bevétel 2/4 százaléka, illetve 10/20 millió Euro – a magasabb érték). A tényleges büntetés már eltérő (lehet): a magasabb éves bevétel magasabb büntetést jelent(het).

A NAIH (Nemzeti Adatvédelmi és Információszabadság Hatóság) elnökének több konferencián, előadáson elhangzott álláspontja szerint az EU-n belül egységesek az elvárások és ebből következően azok megszegése esetén egységes szankcióknak kell következniük, függetlenül attól, mennyire erős gazdaságú országban fordult elő a jogsértés, illetve mennyire erős gazdasági szempontból a jogsértést elkövető.

K: A GDPR előírásainak megsértésekor, ha azt magánszemély követi el, a büntetés enyhíthető?

V: A GDPR előírásainak megsértésekor a GDPR alapján a szankció független attól, hogy a jogsértést magánszemély, állami szerv vagy multinacionális vállalat követte el.

A szankciók mértékére nézve a 29-es munkacsoport (az EU adatvédelmi hatóságainak vezetőiből alakult munkacsoport) dolgozott ki ajánlásokat – erről majd később írunk. Fontos azonban kiemelni: ezek AJÁNLÁSOK, és nem a jogszabályba épített tartalom.

K: A GDPR előírásainak megsértésekor a közműcégeknek ugye nem kell büntetést fizetniük, mert a közszolgáltatásokat mindenképpen nyújtani kell a lakosságnak?

V: A GDPR nem tartalmaz enyhítő feltételt közműszolgáltatókra: azaz a vízműveknek, gázszolgáltatóknak, erőműveknek stb. ugyanúgy be kell tartaniuk a GDPR előírásait, s ha megszegik azokat, ugyanúgy szankcionálva lesznek.

K: Ha a GDPR előírásainak be nem tartása miatti büntetés a közműcéget ellehetetlenítené, a büntetést el fogják törölni vagy legalább csökkenteni fogják?

V: Adott társaság működésének ellehetetlenülése nem indok a büntetés csökkentésére, mérséklésére.

Példaként tekintsük a víziközmű szolgáltatókat. Magyarországon a poszt írásakor 42 víziközmű szolgáltató működik – Malévből egy volt.

Hol van most a Malév?

A Malév megszűnéséhez több ok vezetett, de a kegyelemdöfést az adta meg neki, hogy a cégnek vissza kellett volna fizetnie egy jelentős összeget, amelyet az EU jogtalan támogatásnak tekintett. A társaság ezt nem tudta megtenni saját erőből, az állam pedig nem tudott helyt állni helyette (több okból).

A lakosságnak és a vállalatoknak nyilván szükségük van vízre (a példánál maradva), de azt nem feltétlenül ugyanaz a társaság fogja nekik biztosítani, amelynek a működése ellehetetlenült a GDPR előírásainak be nem tartása miatt – s az új társaságnak nem feltétlenül azok lesznek a vezető tisztségviselői, mint a GDPR elvárások be nem tartása miatt kiszabott büntetést, kártérítést, kárenyhítést, sérelemdíjat stb. kifizetni kötelezett társaságnak.

Büntetés után az élet megy tovább?

K: Ha a GDPR előírásait megszegő kifizeti a büntetést, az ügy lezárul?

V: A nem-megfelelés miatt kirótt büntetés kifizetésével a szankcionálás (első köre) fejeződik be (valószínűleg), viszont

• a hatóság/bíróság intézkedési tervet fog megfogalmazni, amelyet végre kell hajtani – ha ez nem történik meg, ismételt büntetés valószínűsíthető. 
• a büntetés megfizetését követően a nem megfelelően kezelt adatok „birtokosai” kártérítés, kárenyhítés illetve sérelemdíj megfizetése iránti keresettel fordulhatnak a bírósághoz. A jogsértés korábban már ki lett mondva, azaz itt leginkább az összeg nagyságán fog csatázni a két fél.

A kártérítés, kárenyhítés, sérelemdíj összegére a jogszabály (GDPR) nem tartalmaz előírást, azonban valószínű, hogy a bírói gyakorlat azokat a büntetés mértékéhez fogja igazítani. Belegondolva, életszerűtlen is lenne, ha (például) 2,5 milliárd forintos büntetést követően a sérelemdíj 1342 forint lenne…

Egyszerűsítsük az életet!

K: Ez ugyanolyan megfelelés, mint az ISO … minősítésnél volt – miért kell ezt ennyire túlbonyolítani?

V: ISO minősítések esetében a felkészítőt és a megfelelést ellenőrző társaságot is Önök választották és Önök fizették. A GDPR megfelelésnél Önök „csak” a felkészítőt választhatják, a megfelelést a NAIH (Nemzeti Adatvédelmi és Információszabadság Hatóság) és az EU megfelelő hatóságai, szervezetei, bíróságai fogják ellenőrizni (az eljárást ők folytatják le), és a jogsértést valamint a bírságot is ők fogják megállapítani, ebben nem Önök, illetve az Önök által preferált szervezet dönt.

Ez hasonló bármely hivatalhoz, például a könyvelőjüket és a könyvvizsgálójukat Önök választják, azonban nem az Önök döntése, hogy mely hivatal fogja az adóbevallásukat és könyvelésüket, számviteli rendjüket ellenőrizni.

K: Ha szerzünk egy tanúsítványt, amely szerint a Társaság megfelel a GDPR elvárásainak, akkor már rendben vagyunk?

V: Jelenleg nincs ilyen tanúsítvány, de…

K: … Na jó, de ha 2018. május 25-ig lesz, akkor…?

V: Lássuk, mennyit ér(ne) egy tanúsítvány a gyakorlatban! Tegyük fel, az Önök társasága hibás terméket készít, forgalmaz, amely miatt a vásárló megsérül. A vizsgálatot végző hatóságot, illetve az Önök kártérítési felelősségét vizsgáló bíróságot mi fogja érdekelni:

• az Önök minőségbiztosítási rendszere és ISO … minősítése vagy
• az adott hibás termék a a nem-megfelelőségének a következményei?

Mennyit is érne bármilyen tanúsítvány…?

Milyen elvárásoknak kell megfelelni tulajdonképpen?

Egy kiemelt példa: az adatkezelőnek 30 napon belül választ kell adni, hogy

• adott magánszemély kapcsán milyen személyes adatot kezel,
• milyen jogcímen (milyen jogalap szerint),
• mióta,
• hogyan teszi ezt,
• hogyan jutott az adathoz,
• milyen elengedhetetlen érdeke fűződik az adatkezeléshez,
• miért nem lehet az érdeket az adat kezelése nélkül kielégíteni,
• milyen kockázat létezik az adatkezelés miatt,
• az adatkezelő hogyan kezelte, csökkentette ezeket a kockázatokat stb.

Figyelni kell arra, hogy

• a válasznak a GDPR bevezetése előtt gyűjtött adatokra is ki kell terjednie (a jogszabály bevezetése előtt megkezdett adatkezelésekre enyhébb követelmények vonatkoznak, de… lássuk később),
• a személyes adatok köre kibővül, személyes adatnak számít ,
  • a lokalizációs információ – és ami mögötte van (személyesen részletesebben),
  • az IP cím,
  • az e-mail cím stb. 
• a GDPR bevezetését megelőzően megkezdett adatkezelésekre enyhébb követelmények vonatkoznak, de…
• … gyakorlati szempontból ennek kevés jelentősége lesz, mert…
• … az adatkezelés kezdetének kevesebb jelentősége lesz, mint ahogyan a jogszabályból első pillantásra kiolvasható.

Bővebben személyesen, de röviden: a helyzet hasonló a korábban az ISO minősítések kapcsán elmondottakhoz.

Lássunk egy részletes példát, amely „hétköznapi nyelven” fogalmazva illusztrálja a jogszabályon belüli összefüggések különböző szintjeit is:

• adatkezelés jogalapja
• hozzájárulás
• hozzájárulás jellemzői
• tájékoztatás

Az adatkezelés jogalapja

Személyes adat akkor kezelhető, ha az adatkezelés jogalapja „rendezett”. A GDPR-ban az adatkezelésnek hat jogalapja van, úgymint

• hozzájárulás,
• szerződés (teljesítés/megelőző lépések),
• jogi kötelezettség teljesítése,
• létfontosságú érdek védelme,
• közérdekű vagy közhatalmi jogosítvány gyakorlása,
• jogos érdek érvényesítése

Az első tételt kiválasztva és tovább elemezve: a hozzájáruláson alapuló adatkezelésnél a hozzájárulás önmagában nem elegendő az adatkezelés jogosságának kimondásához, több feltételnek kell együttesen teljesülnie, mint például:

• az adatkezelés célja tisztességes legyen,
• a hozzájárulás önkéntes legyen,
• a hozzájárulás kifejezett legyen (az előre kitöltött négyzet pl. nem kifejezett – ez az ún. „opt-in approach”),
• a hozzájárulás egyértelmű legyen (a hallgatás pl. nem az!),
• a kitöltés egyértelmű legyen,
• a hozzájárulás bizonyítható legyen,
• adatkezelési műveletenként elkülönített hozzájárulás szükséges,
• a cél megváltozása ismételt hozzájárulást igényel,
• a hozzájárulás a jogellenes adatkezelést nem legalizálja,
• gyermek online hozzájárulása esetén speciális szabályoknak is meg kell felelnie (további követelmények, mint pl. szülői/gondviselői hozzájárulás is teljesülniük kell),
• különleges adatok esetén eltérő eljárásrend (és további követelmények…),
• jogos érdek esetén érdekmérlegelés szükséges (amely további elvárások teljesülését jelenti),
• megfelelő tájékoztatás szükséges,
• a hozzájárulás „aktív” legyen (ne legyen visszavonva) stb.

A tájékoztatásról

A tájékoztatásnak

• az adatkezelés megkezdése előtt kell megtörténnie,
• érthetőnek kell lennie (mindenkit a maga szintjén, szóhasználatával, alaptudását feltételezve stb. kell tájékoztatni – azaz ugyanazt másképpen kell megfogalmazni a laikusok/idősek számára, mint a geek informatikusoknak),
• kellően konkrétnak, pontosnak, helyesnek kell lennie,
• az aktuálisan felmerült adatkezelési igényre ki kell terjednie,
• a profilalkotásra vonatkozó információt is tartalmaznia kell (ha arra sor kerül),
• ki kell térnie az adatvédelmi szabályzatra (elérhetőségére, tartalmára stb.)
• ki kell térnie a hozzájárulás visszavonási lehetőségére és módjára,
• később is hozzáférhetőnek kell lennie,
• bizonyíthatónak kell lennie (tudnunk kell igazolni, hogy megtörtént – adott tartalommal és módon) stb.

„Magas labda”, ha

• az adatkezelő nem készítette vagy fogadta el az adatkezelési szabályzatát, vagy azt nem tette hozzáférhetővé a tájékoztatás során,
• a tájékoztatás és/vagy a hozzájárulás nem tért ki valamennyi adatkezelési célra, 
• a tájékoztatás az adatkezelés megkezdése után történik vagy teljesen elmarad,
• a tájékoztatás nem terjed ki a hozzájárulás visszavonási lehetőségére és módjára stb.,

ilyen esetekben a hozzájárulás „formai hiba” miatt nem tekinthető érvényesnek, ezért a „magas labdákat” célszerű kivédeni.

Érdekes, hogy az írásbeliség megítélése ellentmondásos illetve nem kellően definiált; az elektronikus megoldások (e-mailben adott hozzájárulás, tableten kézírással megadott aláírás stb.) a poszt írásakor nem elfogadott módjai a hozzájárulás igazolásának; bár a tableten kézírással aláírt szerződés több, mint egy éve elfogadott.

Milyen további GDPR elvárásoknak kell megfelelni ?

Visszatérve az elvárásokra, egy újabb példa: ha magánszemély kéri a személyes adatai kezelésének befejezését vagy a vele kapcsolatos információ törlését, azt;

• az adatkezelőnek 30 napon belül meg kell tennie és erről tájékoztatni kell a magánszemélyt, vagy …
• … ha az adatkezelés megszüntetése, vagy az információ törlése nem lehetséges, 30 napon belül tájékoztatni kell a magánszemélyt, melyik személyes adatának kezelése nem fejezhető be, mely vele kapcsolatos információnak a törlése nem megoldható – kellő indoklással.

A törlés megtagadásának oka (indoka) lehet, ha jogszabály rendeli el az adott adat kezelését, vagy szerződéses kötelezettség az adat kezelése (azaz nem lehetséges a bank felé fennálló tartozástól úgy „megszabadulni”, hogy az adós megkéri a bankot, törölje a vele kapcsolatos adatokat a GDPR-ban előírt törlési lehetőségre, vagy a „felejtés jogára” hivatkozva).

Ki érdeklődhet a személyes adatai kezeléséről?

A személyes adatai kezeléséről bármelyik magánszemély érdeklődhet (és adatainak kezelésének megszüntetését is bármely magánszemély kérheti), azaz

• ügyfelek,
• munkavállalók,
• partnerek,
• érdeklődők
• bárki …

Ki kell térni a „nem triviális” adatkezelésekre is, mert 

• a beérkezett e-mail tárolása már adatkezelés,
• a beérkező utalások kezelése adatkezelés,
• az ügyfélszolgálatra útbaigazításért betérőről készült kamerafelvétel tárolása adatkezelés stb.

Ennyi?

Az előzetes felméréseink alapján néhány terület „többlet figyelmet” igényelhet, ezért kiemelt figyelmet kell fordítani 

• a jogelőd társaság által indított adatkezelésekre,
• a migrált adatokra,
• az „örökölt rendszerekre”,
• a többszörözött felhasználókra,
• az elírásokra,
• a megváltozott nevekre,
• a megváltozott/átnevezett címekre
• archív adatokra, adatbázisokra,
• szerződéses partnerek által végzett tevékenységekre,
• meghatalmazottak által végzett tevékenységekre.

A személynevek leginkább házasságkötés és válás során változnak meg: így lehetséges, hogy Szép Emerencia, Remek Rezsőné, dr. Szép Emerencia, dr. Kiválóné dr. Szép Emerencia ugyanaz a személy, vagy uraknál hasonlóan: Kiváló Károly, dr. Kiváló Károly, dr. Kiváló-Szép Károly ugyanaz a személy.

A címek a városrendezés mellett „történelmi átalakulás” miatt is módosulnak; pl. a Ságvári Endre utca és a Köztársaság sétány lehetséges, hogy ugyanazt a közterületet jelölik.

Legyen egyértelmű: a leírtak „mindössze” példák az elvárásrendszer komplexitására, ezért mutattuk be az

• adatkezelés jogalapját,
• a hozzájárulást
• a hozzájárulás jellemzőit és
• tájékoztatást

mintaként.

„Néhány levelet csak meg tudunk írni!”

Érdemes átgondolni, hogy az Önök ügyfélszolgálata havonta mennyi érdeklődést, kérdést, reklamációt válaszol meg. A kérdés nem az, mit tesznek, ha egy-kettő levéllel többet kapnak: azt kell átgondolni, hogyan kezelnék, ha a jelenlegi többszörösére növekedne az érdeklődők száma. 30 napon belül meg tudnák válaszolni?

Önök hogyan járnának el, ha a jelenleginél harmincszor több érdeklődést kellene megválaszolniuk, 30 naptári napos határidőn belül?

Dr. Péterfalvi Attila NAIH elnök úr említett egy érdekes példát az egyik konferencián. A NAIH 2016 során 161 ügyet vizsgált (ennyi ügyben járt el). A Magyarországgal összemérhető lakosságú Belgium (11,35 M fő 2016-ban) már a kiadás évében, 2016-ban bevezette a GDPR-t. A belga adatvédelmi hatóság 2016-ban több, mint 5500 ügyben járt el, azaz egy főre számítva kb. harmincszor több adatvédelmi eljárás volt Belgiumban, mint Magyarországon. (A nagyobb ügyszámnak természetesen több oka is lehet – a GDPR az egyik.)

Megélhetési feljelentések

Tegyük fel, 2018. május 25-én nyolcezer különböző EU tagállamból származó állampolgár fordul Önökhöz adatigényléssel, vagy rögtön adattörlési kéréssel; személyesen, papíralapú levélben saját nevükben illetve meghatalmazottaik útján, telefonon valamint e-mailben. 30 napon belül mindannyiuknak helyes, teljes, bíróságon megvédhető tartalmú választ tudnának adni? Ha nem válaszolnak 30 naptári napon belül, a fordított bizonyítás miatt a jogsértés ténye megállapítható.

Tegyük fel, a magyar mellett angol, német, dán, spanyol, olasz, portugál, horvát és lengyel nyelven is érkeznek a megkeresések. Az Önök ÁSZF-jében, honlapján, üzletszabályzatában, Adatkezelési Tájékoztatójában, Etikai Kódexében, SZMSZ-ében, blanketta szerződéseiben stb. meghatározták, kinyilvánították, hogy megkereséseket csak magyar nyelven fogadnak? Az Önök ügyfélszolgálatán mennyien értik, használják a felsorolt nyelveket?

Tegyük fel …

Itt számos példa következhetne annak bemutatására, hogyan lehet „jégre vinni” szinte bármelyik szervezetet, azonban szeretnénk elkerülni, hogy az eseteket „rólunk nevezzék el”, ezért ezeket csak személyesen, ellenőrzött partnerekkel osztjuk meg. „Kipróbált példák„, eddig valamennyi ügyféltalálkozón, oktatáson, képzésen stb. „átment a vizsgán” valamennyi elképzelt „beugratásunk”, a hallgatók egyetértettek, hogy a bemutatott esetek az ő szervezetükben is „működőképesek” lennének, őket is csapdába lehetne csalni; őket is olyan helyzetbe lehetne hozni, hogy büntetést, majd kártérítést, kárenyhítést, sérelemdíjat kelljen fizetniük.

Bizonyítékok, bizonyítás

Szakmai pályánk során eddig 142 millió Euro értékű visszaélést azonosítottunk, vizsgáltunk ki, meglehetős számú elkövetési móddal találkoztunk. Ismerjük az egyes visszaélési típusok „gyenge pontjait” és azt is tudjuk, mely fajtájú visszaélésnél milyen lehetőségek léteznek a bűncselekmény bizonyítására, az elkövetők és az elkövetési mód azonosítására. Általunk felkészített ügyvéd pert még nem veszített.

A GDPR-ra várhatóan épülő „megélhetési feljelentők” elleni felkészülésnél ezek a tapasztalatok különösen hasznosak. Ahogyan egy visszaélésnél sincsen „bárcsak kapcsoló”, a GDPR-alapú „profitorientált adatvédelmi aggódók”, „megélhetési feljelentők” elleni felkészülésnél sem működik az „Ó, ha én ezt sejtettem volna” megközelítés.

Bárcsak kapcsoló, bárcsak üzemmód: „Bárcsak oda is tettünk volna egy kamerát, akkor most tudnánk, ki volt az, aki…”, „Bárcsak naplóztuk volna azt is, hogy…, akkor most vissza tudnánk követni, hogy…”, „Bárcsak utánanéztünk volna, hogy a szerződést aláírók korábban …., akkor most nem ….”, Bárcsak a szerződésben megköveteltük volna, hogy…” és így tovább.  

A „megélhetési feljelentők” elleni felkészülésnél nem egy-két napot, hanem több évet és cselekményt kell előre látnunk. Tudnunk kell, hogy mi lehet a mi gyenge pontunk, azt hogyan erősíthetjük meg (tervezés után cselekedni is kell); tudnunk kell, milyen megkeresésre hogyan reagálunk, az állításainkat hogyan fogjuk prezentálni, milyen bizonyítékokat tudunk majd prezentálni a hatóságok és a bíróságok felé, a bizonyítékokat hogyan fogjuk használni az esetleges perben, hogyan tudjuk igazolni a bizonyítékok teljességét, sértetlenségét, hitelességét stb.

Tudatosan kell felkészülnünk.

Mit kell tehát tenni a GDPR megfelelés érdekében?

Javasolt a feladatokat két csoportra osztani:

• felmérésre és
• felkészítésre.

Mit és hogyan kell felmérni?

Hogyan kell a felmérés eredményét felhasználni?

Egészen pontosan: milyen lépéseket kell tennünk a GDPR-nak való megfelelésre?

Örömmel segítünk Önnek, kérjük ezért vegye fel velünk a kapcsolatot.

További hasznos információ

• A GDPR teljes szövege magyar változatban IDE KATTINVA érhető el.
• A GDPR teljes szövege angol változatban IDE KATTINTVA érhető el.
• Az angol és magyar szöveg párhuzamos olvasásra alkalmas formában IDE KATTINTVA érhető el.

Hangsúlyozzuk, hogy a leírtak a poszt publikálásának idején rendelkezésre álló információ alapján kerültek megfogalmazásra, és nem tekinthetőek a GDPR teljes körű bemutatásának, illetve a GDPR-ra felkészülés teljes körű meghatározásának, VISZONT állunk rendelkezésükre személyes konzultáció során.

A felejtés jogát, a „privacy by design” elvárást stb. ebben a posztban azért nem írtuk le részletesen, mert nem „jogászkodás” volt a célunk, hanem a GDPR gyakorlatcentrikus bemutatása – együttműködés során azonban természetesen a GDPR minden elvárására kitérünk.

A GDPR bejegyzés először Jasipos IT biztonsági és audit kft-én jelent meg.

• CISA (Certified Information Systems Auditor)
• CISM (Certified Information Security Manager)
• CGEIT (Certified in the Governance of Enterprise IT) és
• CRISC (Certified in Risk and Information Systems Control)

minősítések mindegyikét!

Partnerünk az elismerést az egyesület hazai tagszervezetének (ISACA Budapest Chapter) 2017. június 13-i konferenciáján kapta. János 2011-ben szerezte meg a negyedik ISACA minősítését. Az ezóta eltelt hat év alatt rajta kívül még egy honfitársunk tudta követni teljesítményét, azaz jelenleg mindössze két magyar szakember viselheti mind a négy szakmai címet.

Gratulálunk Jánosnak a szakmai elismeréshez (és a tudáshoz, tapasztalathoz, amely az elismerés mögött van)!

Ez valóban szép, de miért jó mindez Önnek?!?

A biztonsági problémák ritkán jelentkeznek „vegytisztán”. Itt is igaz a mondás, hogy nem elég jónak lenni, annak is kell látszani – és azt akár utólag bizonyítani is, ráadásul költséghatékonyan.

Gyakran kiderül, hogy a megbízóinkat zavaró probléma valójában csak egy szelete a teljes problémacsokornak, amelyet komplexen kell kezelnünk. Előfordul, hogy a legjobb, ha nem is merülünk bele az eredeti probléma megoldásába, hanem kissé átalakítjuk a környezetet és így okafogyottá tesszük a kezdeti problémát.

Az ISACA és más szakmai szervezetek által kibocsátott minősítéseinknek, az ezek mögötti tudásnak, tapasztalatnak köszönhetően átlátjuk a bonyolult helyzeteket és gyors, hatékony megoldást kínálunk ügyfeleinknek. Valójában annyira hatékonyak vagyunk, hogy napidíjas elszámolást már lehetőleg nem is vállalunk. Azt tapasztaltuk, néhány óra alatt megoldunk mások által hónapok munkájával kezelhetőnek ítélt helyzeteket – ezért a sikerdíjat preferáljuk – de ez nem ide tartozik, az viszont annál inkább, hogy:

Mi az ISACA?

Az ISACA az információ rendszer menedzserek és ellenőrök nemzetközi szakmai szervezete, cikkünk írásakor 180 országban több, mint 140 ezer taggal. Bár a szervezet neve annak 1969-es alapítása óta változatlan (Information Systems Audit and Control Association), az egyesület jelentősen bővítette a tevékenységét, így a szervezet az auditorok mellett az információ biztonsági szakemberek, a kockázatkezeléssel foglalkozó specialisták és menedzserek, valamint az informatikai szervezeteket vezetők szövetsége lett, komoly tudományos háttérrel.

A szervezet szakmai minősítései a felsorolt területeknek megfelelően kerültek kialakítása:

• a CISA az auditorok,
• a CISM az információ biztonság területén ténykedők,
• a CGEIT az IT szervezeti vezetők,
• a CRISC pedig a kockázatkezeléssel foglalkozók

számára szükséges tudást és szakmai tapasztalatot, elismertséget követeli meg.

Az egyesület kutatásai leginkább a nagyvállalati informatika támogatását célozzák, a nagyvállalati legjobb gyakorlatra alapozott módszerek felkutatását, oktatását és világméretű elterjesztését végzik.

Az ISACA dolgozta ki (többek között) a COBIT (Control Objectives for Information and related Technologies) módszertant, amelyet az informatikai irányítás, kockázatkezelés, biztonság, minőségellenőrzés, auditálás, ellenőrzés során számtalan vállalat és intézmény alkalmaz. A hazai jogszabályok mellett a COBIT alapján vizsgálja a pénzintézeteket a Magyar Nemzeti Bank is.

Mennyit érnek az ISACA minősítései?

Az ISACA minősítései több szempontból nagyobb munkaerőpiaci értékkel bírnak, mint a főiskolai, egyetemi diplomák, mert a minősítések

• 180 országban ismertek, elismertek, míg az egyes főiskolákat, egyetemeket jellemzően csak a honos országukban, vagy a környező országokban ismerik, értékelik,
• a tudáson túl a tapasztalatot is megkövetelik; a CISA minősítéshez például sikeres vizsga mellett 5 év igazolt (és általában ellenőrzött) szakmai gyakorlat, valamint három szakmai ajánló is előfeltétele (a minősítés megkapása még ekkor sem bizonyos, mert a tapasztalatot és az ajánlásokat szakmai bizottság értékeli),
• megkövetelte szakmai vizsgán minden résztvevő egyforma feltételek szerint mérettetik meg: négy óra alatt 200 írásbeli kérdésre kell válaszolni (a kérdéssorok vizsgánként frissülnek), kérdésenként négy lehetséges válaszból kiválasztva a helyeset,
• nemzetközileg egyenszilárdságúak, mivel Budapesten, Tokióban, Pretoriában, Washingtonban stb. ugyanaznap van a vizsga, ugyanazok a vizsgakérdések, és a válaszokat központilag, ugyanolyan módszerrel, ugyanazok javítják,
• egyben „nyelvvizsgák” is – legalábbis a magyarok és számos további ország polgárai számára, mivel a tananyagok és a vizsgák csak angolul és néhány elterjedtebb nyelven (spanyolul, németül stb.) férhetőek hozzá; azaz ha valaki birtokol egy ISACA minősítést, az a szakmai tudás és tapasztalat mellett bizonyosan bevethető nemzetközi környezetben is.

Segítünk!

A szervezettel és a minősítések megszerzésével (felkészülés, vizsga stb.) kapcsolatban János örömmel segít az érdeklődőknek, aspiránsoknak; akár általános információval, akár konkrét szakmai kérdések megválaszolásával – vegye fel vele a kapcsolatot.

Bővebb információ az ISACA nemzetközi szervezetéről a www.isaca.org oldalon érhető el.

Az ISACA Budapest Chapter honlapja, az aktuális szakmai programokkal a www.isaca.hu honlapon található.

S továbbra is természetesen: ha gondja akadt egy ajánlatnál, szerződéskötésnél, hatósági ellenőrzésnél, ISO minősítés megszerzésénél, abban is segítünk, vegye fel velünk a kapcsolatot.

A ISACA bejegyzés először Jasipos IT biztonsági és audit kft-én jelent meg.

„Persze! Hány sérülékenységet is találnak havonta az X szoftverben? Azt használjuk minden gépünkön már Y éve, mégsem loptak még adatot tőlünk… Az ügyfélszolgálatról az egyik ügyintézőnk mobilját, na, azt elvitték múlt hónapban, ha belegondolok, az adatlopás volt, mert a lánya anyakönyvi kivonatát is lefényképezte vele korábban.”

Az ismerősöm meglepődött, amikor a pénzügyi igazgatónak adtam igazat, aki a saját szempontjából racionális döntést hozott, mikor visszautasította a kétezer számítógépre kiterjedő sérülékenység vizsgálatot valamint nem akart ugyanennyi számítógépre hároméves licencet venni az egyébként színvonalas XYZ szoftverhez, mert egyrészt nem látta szükségesnek, másrészt megtudta, mennyibe kerülne.

Merjük kimondani, a nagy igyekezetben valahogyan „elfelejtődött”, mi az IT biztonság lényege illetve mi a fontos az ügyfélnek.

Egy mondatban két alapvető igazság megosztásával kecsegtetni bátor tett, remélem, Ön értékeli, hogy mind a kettőnél fellebbentem a fátylat. 🙂

Ha kellően leegyszerűsítjük a témát, az IT biztonság lényege nem más, mint az informatikai infrastruktúra és a benne tárolt információ védelme, az ügyfél érdeke pedig az üzleti céljainak az elérése.

Persze ha egy mondatban foglaljuk össze bárminek a lényegét, néhány sallang kimarad. A sebészet lényege egy mondatban például vágás és varrás – kellően leegyszerűsítve. Az egy mondaton túli mindenfélét persze évtizednél hosszabb ideig tanítják, tanulják minden szakmában.

A sok szakmai érdekesség, újdonság mellett azért látni kell: az ügyfél számára az IT biztonság csak azért fontos, mint az adótanácsadója: az üzleti környezet jellemzőinek, eseményeinek számára negatív hatásait szeretné minimalizálni. Ha adott negatív lehetőségből még semmit sem tapasztalt – pláne, ha nem is érti a szakzsargont, nem fog pénzt áldozni a témára. Racionális.

A fenti esetre visszatérve megkérdeztem az ismerősömet, érdeklődött-e, mi történt a telefonnal (emlékeznek, azzal, amin az ügyintéző lányának anyakönyvi kivonat-fényképe volt). Értetlenül nézett rám: „Miért kérdeztem volna? XYZ szoftverről beszélgettünk meg a vállalat informatikai biztonságáról.”

Miért lett volna érdekes érdeklődni?

Érdekes lett volna megtudni, kiderült-e, ki vitte el a telefont. Ha kiderült, tovább lehetett volna kérdezni: hogyan azonosították az elkövetőt, hogyan szerezték vissza telefont és így tovább. Ha nem derült volna ki, lehetett volna tovább érdeklődni: van-e kamerarendszer az ügyfélszolgálaton, ha van, hogyan rögzítik a felvételeket és mennyi ideig őrzik meg azokat; hasonlóan: honnan és hogyan vitték el a telefont az ügyfélszolgálaton: az ügyfelek által látogatott térből vagy az ügyfélforgalomtól elzárt területről; van-e lehetőségük a munkavállalóknak elzárni a „dolgaikat” (telefont, pénztárcát, kabátot stb.).; ahogyan a telefont el tudták vinni, ugyanígy elvihettek-e volna mondjuk vállalati bélyegzőt, iratot stb.

Másik érdekes terület az adatkezelés tisztázása lehetett volna: megtudni, hogy az ügyintéző az ellopott telefonjával hozzáfért-e korábban vállalati adatokhoz (például a vállalati levelezőrendszer elérésével), tárolta-e a kollégák elérhetőségeit a telefonban, készített-e a telefonnal fényképfelvételeket a vállalat ügyfélforgalomtól elzárt részein – azaz azt behatárolni, valóban csak privát adatokat érint-e az eset, vagy az elkövető birtokába kerülhetett-e vállalat számára is lényeges információ?

A felsoroltak az addig nem ismert elméleti problémából rögtön a napi élet szintjére fordították volna át az IT biztonság témáját.

Lett volna üzlet belőle?

Korai kérdés – az ügyfél mindenesetre azt érezte volna, hogy őt érintő témáról folyik a diskurzus, az ismerősöm pedig kissé belelátott volna a vállalat életébe, megismert volna valamit a vezetők és munkavállalók gondolkodásmódjából.

Kedves ismerősöm, Dániel írta a honlapunkat olvasva:

„A blogbejegyzések érdekesek, szerintem abszolút pozitív, hogy a hasonló oldalaknál megszokott merev szakmaiság mellett itt megjelenik egy egyszerűbb, közérthető vonal is, de ez a „könnyedebb” tartalom azért nem megy a szakmaiság rovására.”

Köszönöm Dani, ezek szerint „átment az üzenet”, hogy lehet és kell érthetően beszélni IT biztonságról. Dani másoddiplomáját egyébként IT biztonság területen szerezte, néhány éve szerencsém volt konzulensének lenni. Biztonsági vonalon dolgozik jelenleg is, azaz szakmabeli.

A szakmai zsargon illetve a szakmai tartalom szükségesnél „szakmaibb” jellegű bemutatásának az üzleti döntéshozó számára érthető szövegre fordítása „nyugaton” már megkezdődött. A Forbes egy cikke éppen a gazdasági élet szereplői számára teszi érthetővé az IT biztonság területén használt leggyakoribb buzzword-öket, felkapott, de gyakran rövid életű szakmai kifejezéseket.

Az üzletembereket érdeklő, de általuk nem teljesen ismert kilenc idióma IT biztonság témában:

• cloud security (felhőalapú biztonság – egy következő blog bejegyzésben tekintjük át – akkora téma, hogy önálló cikket érdemel, kíván)
• compliance (elvárásnak, előírásnak megfelelés – lehet szabványnak megfelelés, jogszabálynak megfelelés, de ide tartozik a bankkártya társaságok által támasztott követelményeknek megfelelés is)
• cyber espionage (kiberkémkedés, Interneten keresztül végzett szervezett információszerzés)
• Data Loss Prevention (adatszivárgás megelőzés, a vállalati információ nem kívánt megosztásának, eltulajdonításának megelőzése)
• Endpoint Protection Platforms (végpontvédelmi platform, amely egy termékként tartalmaz több, korábban egyedileg kínált terméket, amelyek a „normál” felhasználók által használt eszközöket – számítógépet, mobiltelefont stb. – védik)
• privacy (a magánszemély által mással megosztani nem kívánt információ védelme)
• ransomware (zsarolásra használt kártevő, amely titkosítja és elérhetetlenné teszi a felhasználó gépén levő fájlokat és a titkosítás feloldásához szükséges kódot csak akkor árulja el, ha a felhasználó fizet az ismeretlen elkövetőnek)
• risk management (kockázatkezelés, a védeni kívánt információ és infrastruktúra azonosításától kezdve az üzleti érték és hatás meghatározásán keresztül a megfelelőségi követelményekig és a megfelelő védelem felépítéséig – önálló blogbejegyzést kíván a téma komplexitása)
• phishing (adatgyűjtés jellemzően e-maileken keresztül)

Az IT biztonság üzletembereket érdeklő felkapott kifejezései mellett a Forbes oldaláról elérhető egy másik lista is, amely az IT biztonsági szakértők 2015-re vonatkozó szakmai jóslatait tartalmazza.

A szakértők 2015-re vonatkozó, IT biztonság területet érintő szakmai előrejelzései:

• attacks against virtual payment systems (virtuális fizetési rendszerek elleni támadások)
• more old security holes surface in open source software (nyílt forráskódú rendszerek régóta fennálló biztonsági rései)
• data Loss Prevention (DLP) will become a hot issue for business leaders (az adatszivárgást megelőző megoldások kiemelt témák lesznek a piacvezető vállalatoknál)
• malware will be harder to detect and shutdown (a rosszindulatú kódokat az eddigieknél is nehezebb lesz felismerni, kiirtani)
• raw security incidents will continue to rise (egyre pusztítóbb biztonsági események lesznek)
• thinking beyond individual threats (az egyedi támadási faktorokra összpontosító védelmi megoldások helyett összetettebb, szofisztikáltabb védelmi intézkedésekben kell gondolkodni)

Szögezzük le, a Forbes nem IT biztonsági, hanem színvonalas gazdasági lap, viszont a cikkek megírásában tapasztalt IT biztonsági szakértők segítették őket. Mindkét cikk ugyanazon országban íródott, nyolc nap eltéréssel (2015. januárjában – ez a magyarázata az előrejelzésnek).

A két listáról hosszasan lehetne beszélgetni, most azonban csak a blogbejegyzésünk szempontjából lényeges szempontra összpontosítsunk és vegyük észre, hogy a listák között alig van átfedés, azaz a gazdasági élet szereplőinek teljesen más van a fejében IT biztonság kapcsán, mint ami az IT biztonsági szakemberek szerint lényeges 2015-ben! Mondjuk ki még egyszer:

Az üzletemberek számára teljesen más fontos IT biztonság szempontjából, mint az IT biztonsági szakembereknek!

Lehetne vitatkozni a következtetésemmel, például mondhatnánk, hogy az első lista azokat a kifejezéseket tartalmazta, amelyek fontosak ugyan számukra, csak nem ismerik őket vagy annyira fontosak, hogy bár ismerik a kifejezéseket, mégis megkérdezték, hogy jól értették-e őket; viszont a második lista minden eleme fontos ÉS teljesen ismert, azért nem volt szükséges megmagyarázni őket.

A válaszom erre, hogy ha az üzletembereknek, akiknek már 13 éve kötelezően meg kell felelniük a Sarbanes-Oxley előírásoknak („being compliance with Sarbanes-Oxley Act”) a „compliance” szó magyarázatra szorul, hadd feltételezzem okkal, hogy a „malware”, az „open source software” és a többi, szakértők által kiemeltnek tekintett terület vagy azért nem került említésre, mert nem ismert, vagy azért, mert nem tartják fontosnak.

A két cikk (és Dani levele 🙂 ) megerősített benne, hogy

• az IT biztonság az üzleti életben is fontos (lám, a Forbes is foglalkozik vele – a hazai lapszámban is kitérnek néha-néha rá),
• az IT biztonság területén továbbra is szükség van szakzsargontól mentes, érthető cikkekre, beszélgetésekre,
• kommunikálni, kommunikálni és még egyszer kommunikálni kell, hogy megértsük, mi foglalkoztatja az üzletembereket, ügyfeleinket és fordítva: megértsék, mi a háttere, indoka javaslatainknak.

Az IT biztonsági projekteket, feladatokat az üzleti döntéshozók hagyják jóvá, akik messzemenően racionálisak. Az IT biztonságnak akkor van létjogosultsága az üzleti életben, ha az ügyfelet segíti üzleti céljai elérésében.

Kérem gondolkodjunk közösen:

• ha Ön üzletember, állami, önkormányzati vagy non-profit területen dolgozik: Ön szerint mi a fontos IT biztonság szempontjából az Önök számára?
• ha Ön IT biztonsági szakember: Ön szerint mi a fő kihívás IT biztonság témakörben napjainkban?

[vcex_button url=”http://jasipos.com/kapcsolat/” title=”Kapcsolat” style=”graphical” align=”left” color=”green” size=”large” target=”self” rel=”none”]Véleményem szerint …[/vcex_button]

A IT biztonság bejegyzés először Jasipos IT biztonsági és audit kft-én jelent meg.

Pali mérnök és mellette közgazdász végzettséggel is rendelkezik. Az édesapja által indított könyvelő vállalkozásukat már több, mint egy évtizede ő vezeti, irányítja, azaz a családi vállalat sikeresen túlélt egy generációváltást sőt most sikeresebb, mint korábban bármikor. A minőségi, szorgos munka eredményeként a kb. másfél tucatnyi munkavállaló számára biztos hátteret jelentő vállalat számos elégedett ügyfélnek nyújt szolgáltatást.

A vállalat infrastruktúrája szépen fejlődött, fejlődik. Új irodájuk kialakítása folyamatban, az üvegajtós és üvegfalú dizájnos irodába beléptetőrendszer szabályozza a belépést, az informatikai rendszer üzemeltetéséről, az adatok mentéséről külön (részmunkaidős) informatikus gondoskodik, aki hetente meglátogatja őket és intéz minden, informatikával kapcsolatos feladatot, komoly mértékben tehermentesítve a könyvelő cég tulajdonosát, alkalmazottait. Az adatokat az irodában elhelyezett központi szerveren tárolják, amelyben két tükrözött merevlemez dolgozik (RAID1). A szerverről az új adatok naponta, a teljes adatmennyiség hetente a szerverhez kapcsolt lemezes adattárolóra (NAS, Network-attached storage) kerül másolásra.

Pál elégedett: az adataik biztonságban vannak („Négy merevlemezen tárolunk mindent, ez már több, mint elégséges biztonság!” – mondja), a kapcsolódó költségek számára vállalható mértékűek, az informatika adottságként és nem problémaként jelenik meg számukra.

Az adataik valóban biztonságban vannak?

A leírt adattárolási mód valóban sok veszélyforrás kockázatát csökkenti. Lássuk, miért nem kell (túlzottan) aggódnia Palinak:

• Ha meghibásodik a szerverbe szerelt egyik merevlemez, a tükrözésnek (RAID1 struktúra) köszönhetően a másik, épségben maradt merevlemezről az adatok helyreállíthatóak.
• Ha mindegyik merevlemez egyszerre meghibásodik, a lemezes adattárolóra mentett adatokból a fájlok, adatbázisok majdnem teljes mértékben helyreállíthatóak, legfeljebb egy napnyi adatot kell ismételten rögzíteni, betölteni.
• Ha a biztonsági mentés nem sikerül, az adatok a szerveren továbbra is rendelkezésre állnak.
• Ha a lemezes adattároló tönkremegy, az adatok a szerveren továbbra is rendelkezésre állnak.

Látható tehát, ha az infrastruktúrából bármelyik komponens az említett módon (!) kiesik, meghibásodik, az adatok továbbra is rendelkezésre fognak állni, a vállalkozás működése túl nagy zavart nem szenved, az ügyfelek jó esetben észre sem veszik, hogy bármi gond történt a könyvelő cégben.

A pozitívumok után tekintsük át, mely esetekben szembesülhetnek problémával a könyvelőcégnél.

Ha a használt adatbázisokban (bármilyen üzemeltetési vagy egyéb okból) belső szerkezeti hiba, logikai ellentmondás keletkezik, az a szerver mindegyik merevlemezén megjelenik, ugyanis a RAID1-es tükrözés független a merevlemezekre másolt adatoktól, a RAID1 mindent tükröz, az adatbázis hibáit is. Ha az adatbázisok már működésképtelenek is, a RAID1 tükrözése még működik (és működni is fog – ez technikailag független a merevlemezeken tárolt bármilyen adattól, adatbázistól) és a hibák mindegyik merevlemezen leképezésre kerülnek. A hiba előfordulási valószínűségét különböző üzemeltetési módszerekkel lehet csökkenteni, de az adott kisvállalatban alkalmazott szoftverkörnyezet és üzemeltetési lehetőségek alapján tízévente egy eset reális becslésnek tűnik.

A logikai hiba jellegéből adódóan a szerverhez kapcsolt lemezes adattárolóra is kiterjedne, mivel (a másolás jellegétől függően) a logikailag hibás adatbázis hibamentes adatmásolással kiírásra kerülne a lemezes adattárolóra, azaz lenne egy hibátlan de használhatatlan másolat az adattárolón vagy (másolási technikától függően) az adatbázis másolása teljes mértékben sikertelen lenne – amely a végeredmény szempontjából ugyanazt jelenti: nincsen megfelelő biztonsági másolat, amelyről a hibamentes adatbázis helyreállítható lenne. (Jó esetben a korábbi napok adatmásolása sikeres volt, azaz egy napnyi adatmennyiség ismételt rögzítésével, előállításával helyrehozhatják a kárt.)

A szerver és a hozzá kapcsolt hálózati adattároló logikailag és fizikailag egy egységet alkot, azaz ha a mostanában divatos „titkosító, zsaroló” (randomware) kártevők valamelyike (Cryptolocker, CTB-locker stb.) megfertőzné Pál könyvelőirodai hálózatát, Pali elveszítené a szerverén és a hálózati adattárolóján tárolt valamennyi adatát. Nem csak az adatbázisaiban tárolt adatokat, hanem valamennyi Word dokumentumát, Excel táblázatát, szkennelt dokumentumait, korábbi levelezését – mindent!

Elméleti esély? Sajnos nem, már egy évvel ezelőtt hatszázezer felett volt az ismert esetek száma világszerte, hazánkat tekintve fél évvel ezelőtt már ötszáz feletti eset került a szekértők fókuszába. (Az ilyen fertőzések jellemzője, hogy a kártevő az általa elérhető valamenyni merevlemez teljes tartalmát titkosítja és a felhasználónak 24-72 órát ad arra, hogy a 300-3000 USD összegű „visszafejtési díjat” elutalja, jellemzően Bitcoinban. Ha ez nem történik meg, a titkosított merevlemeztartalom örökre hozzáférhetetlen marad a felhasználó számára.) Megfelelő védelmi eszközökkel a randomware fertőzés esélye csökkenthető, de az esetek száma és a tendencia alapján kb. minden ötszázötvenedik vállalkozás számíthat ilyen problémára. (A blogbejegyzés végén megtalálhatóak ennek és a további kalkulációknak az alapadatai és a számítási módszerek.) Az egyetlen valódi segítséget a rendszeres biztonsági mentés jelenti, amelyből az adatok ilyen esetben visszaállíthatóak.

Lehet mondani, hogy az „egy az ötszázötvenhez” elenyésző valószínűség – ez a kis esély mégis azt jelenti, hogy Pali vállalkozása kétszer akkora valószínűséggel fog zsaroló vírus áldozatává válni, mint amekkora eséllyel Pál súlyos vagy halálos közlekedési balesetet szenved Budapesten! Ilyen módon nézve a problémát máris kevésbé örömteli a kép.

Probléma továbbá, hogy a szerverről hálózati adattárolóra másolásról, a másolás sikerességéről vagy sikertelenségéről Pál nem kap visszajelzést. A könyvelőiroda informatikusa Pál „bizalmi embere”: hetente egyszer meglátogatja az irodát, meghallgatja és teljesíti a dolgozók kéréseit és ekkor ellenőrzi az adatok másolását is. Pál tudomása szerint az informatikai rendszereik üzemeltetése során nem fordult elő ilyen probléma sohasem.

Az „üzemeltetési módszertan”okozta kisebbik gond, hogy az esetleges sikertelen adatmásolásokra lehet, csak egy hét elteltével derül fény, azaz ha ilyenkor következne be valamilyen adathiba, akkor nem egy nap, hanem egy hét adatmennyiségét kellene reprodukálni. Nagyobb probléma lehet, ha az informatikus a vezetői kontroll teljes hiánya miatt nem is ellenőrzi a másolások sikerességét ezért akár több hónapnyi vagy évnyi adat sem kerülhetett át a szerverről a hálózati adattárolóra. (A napi munkavégzés során ezt Paliék nem vennék észre, mivel a munka során a szerverről dolgoznak, a hálózati adattárolót „biztonsági mentés” céljából vásárolták anno.) Ha az adatmásolás valóban több hónapig, évig elmarad, hiba esetén ezt a több hónapnyi, évnyi adatot kellene újra rögzíteni, reprodukálni. Belegondolni is rossz…

További probléma, hogy a szerverek és a hálózati adattároló ugyanabból az elektromos hálózatból kapja az energiát. Az irodaépület üzemeltetője szerződésben vállalta a hálózat villámvédelmét, ezért Pál nem telepített sem túlfeszültségvédőt sem szünetmentes tápegységet (mondván, áramszünet esetén egyébként sem tudnának dolgozni).

A legjobbat feltételezve nem fog túlfeszültség megjelenni az elektromos hálózatban, „csak” energiakiesés. Ha ez „biztonsági mentés” (adatmásolás) során történik, az adott másolás sikertelen lesz – de ez a kisebbik gond. Ha az áramszünet a szerveren levő adatbázisok használata közben következik be, akár az adatbázis is megsérülhet – ez már komolyabb problémát okozhat a vállalkozás életében.

Ha ismerősöm csalatkozik az épület üzemeltetőjében (mivel az nem megfelelően védi az elektromos hálózatot) a villámcsapás stb. miatti túlfeszültség egy időben teheti tönkre a szervert és a lemezes adattárolót. Nyilván jogi eljárást indíthat és nagy valószínűséggel a bíróság igazat is fog neki adni – néhány év múlva, ami vajmi keveset fog segíteni rajta és ügyfelein, a határidős adó- és járulékbevallásokban. (A kártérítés mértékének megállapításával és behajtásával kapcsolatos eljárást, mizériát nem is említem.)

Az irodai környezet és a lokáció ismeretében úgy becsülöm, Paliék túlfeszültség vagy áramkimaradás miatti problémával legalább tízévente egyszer szembesülni fognak.

Pál egy korábbi rossz tapasztalata miatt nem kívánt automatikus tűzoltóberendezést telepíttetni az iroda területére – élénken emlékszik, amikor a tévesen beindult sprinklerek az alig fél éve beszerzett teljes informatikai és irodatechnikai berendezés-garnitúrát eláztatták, tönkretették egy kellemes tavaszi hétvégén, amikor senki sem tartózkodott az irodában. Az automatikus oltóberendezés nélküli „csak” tűzjelzős megoldás növeli az esélyét annak, hogy egy irodatűzben valamennyi adatuk megsemmisül. Nyilvánvalóan a szerver és a NAS elázása sem sokkal jobb, mint elégése – mindkét esetben az a probléma, hogy a könyvelőiroda teljes adatmennyisége megsemmisül és a cég tevékenységének folytatása komoly kihívást fog jelenteni.

Költséghatékonysági okból a szerver és a hálózati adattároló az ügyfelek által is látogatható térben van elhelyezve, külön fizikai védelem nélkül (a belsőépítész még fel is használta őket dizájnelemként). Ha egy nem kívánt látogató túljut a beléptetőrendszeren, könnyen eltulajdoníthatja a szervernél lényegesen kisebb méretű hálózati adattárolót a rajta levő teljes ügyféladat-mennyiséggel. Mivel a napi munka során Paliék nem a NAS-ra másolt adatokkal dolgoznak, a NAS hiánya akár csak órák, napok múlva tűnne fel nekik.

Az adatok az adattárolón és a szerveren egyaránt titkosítás nélkül kerülnek tárolásra, ezért Paliék kisebb gondja lenne, hogy az adatbázisok helyreállítása hatalmas erőfeszítést és költséget jelentene, illetve az ügyfelek adatszolgáltatásai, bevallásai jelentős késedelemmel kerülnének elküldésre, ha a szerver éppen akkor menne tönkre, amikor ellopják a hálózati adattárolót; jelentősebb probléma lenne számukra, ha az eltulajdonított eszközön levő adatokat illetéktelenül felhasználják, ezzel kárt okozva az ügyfeleknek és Paliék könyvelő cégének. 

Ha a kisebbik rossz következik be és „csak” határidőt túllépve készülnek el a bevallások, a cég az ügyfeleknek nyújtott kártérítések miatti visszaesésből még felállhat, viszont ha a teljes adatmennyiséget ellopják és felhasználják, a könyvelő cég nem élheti túl a hírnévromlást és az ellene indított kártérítési eljárásokat.

Érdekesség, hogy Paliék jelenlegi irodájából egy hordozható számítógépüket és három mobiltelefonjukat már ellopták (több, egymástól független időpontban), ezért is építettek ki a hamarosan használatba  vehető új irodában beléptetőrendszert. Pál cégének sajátosságait és az iroda elhelyezkedését, kialakítását tekintve valószínűsítem, hogy az „irodai szarkák” a jövőben sem fogják kímélni őket, különös tekintettel arra, hogy kamerás megfigyelőrendszer szándékosan nem került telepítésre.

Mi a megoldás mindezekre?

Néhány egyszerű intézkedéssel jelentősen megbízhatóbb lenne a biztonsági mentés – sőt néhány intézkedéssel tényleges biztonsági mentés lenne bevezetve Pál vállalkozásában:

• A szerverhez és a hálózati adattárolóhoz szünetmentes energiaellátást kellene telepíteni (egyben megoldva a túlfeszültségvédelmet).
• Ha ragaszkodnak a kiépített infrastruktúrához (szerver + NAS) a hálózati adattárolóra az adatokat nem csak a nap végén, hanem napközben is másolni kellene – fél óránként legalább, a sikeres és sikertelen másolásokról pedig e-mailben értesítést/riasztást kellene kapnia az informatikusnak és néhány belső munkavállalónak is.
• A szerveren és a hálózati adattárolón tárolt adatokat titkosítva kellene tárolni.
• A hálózati adattároló mellé mentőegységet kellene telepíteni és az adatokat önálló adathordozóra naponta ténylegesen menteni kellene (ideális esetben két példányban).
• A biztonsági mentésekből egy-egy (titkosított) példányt az irodától távol, jól védett helyen kellene tárolni (azt, hogy ez mit jelent, egy későbbi bejegyzésben járjuk körbe).
• A biztonsági mentések mellett be kellene vezetniük az archiválást is – amelyre egyébként jogszabály kötelezi őket. (A biztonsági mentés és az archivált adatok közötti különbséget egy későbbi cikkben tervezzük bemutatni.)
• A szervert és a hálózati adattárolót (valamint a telepítendő mentőegységet) ügyfelek által nem látogatott helyen kellene tárolni, megfelelő körülmények között (erről szintén külön bejegyzést tervezünk írni).
• Rendszeresen tesztelni kellene, hogy vissza tudják-e állítani a biztonsági mentésekből az üzemi rendszereiket (erről szintén egy későbbi blogbejegyzésben fogunk részletesebben írni).

Mennyi lenne mindennek a költsége?

Pál alkalmazottainak jellemző javadalmazásával kalkulálva egy munkavállaló egyhavi átlagos munkabérével összemérhető kiadást jelentene a leírtak megvalósítása, a megfelelő biztonsági mentés megvalósítása.

Megítélés kérdése, hogy ez sok vagy kevés egy több évtizedes múltra visszatekintő, másfél tucatnyi munkavállalónak megélhetést, néhány száz ügyfélnek számviteli szolgáltatást nyújtó vállalat adatainak biztonságos mentéséért; az viszont biztos, hogy a megfelelő biztonsági mentés megvalósításának költsége jelentősen alacsonyabb összeg, mint a korábban említett bármelyik hiba következményeinek megszüntetése.

Fontos hangsúlyozni, hogy a leírt szempontok nem jelentik a biztonsági mentés témakör teljes áttekintését, de szeretnénk egy tea/kávé elfogyasztási idején belül tartani egy-egy blogbejegyzés olvasási idejét. Hasonlóan kiemelendő, hogy az ajánlott intézkedések nem jelentik a teljes körű vagy kizárólagosan megfelelő védelmet: a javaslatokat Pál vállalkozásának ismeretében tettük, a tevékenységi kör, elhelyezkedés, ügyfélállomány és nem utolsó sorban Pali kockázatvállalási hajlandósága és költségérzékenységi szintje alapján.

Ha Pali informatikai fejlesztéssel, gépészeti tervezéssel, tejfeldolgozással, telekommunikációs szolgáltatással, kiskereskedelemmel stb. foglalkozó vállalkozást irányítana, vagy a munkavállalók száma lényegesen több (esetleg kevesebb) lenne esetleg a tulajdonosi struktúra eltérő lenne, tanácsaink is (részben) másként szóltak volna.

Önök hogyan mentik az adataikat? Ügyfeleik számítanak Önökre – bizonyos benne, hogy probléma esetén helyre tudnák állítani az adatbázisaikat, fájlaikat és folytatni tudják tevékenységüket?

Lépjünk kapcsolatba most és örömmel áttekintjük az Önök mentési, archiválási megoldását, visszajelzést adunk a megfelelőségekről és javaslatokat teszünk a fejlesztésre (ha szükséges). 

A cikkünkben említett kalkulációk részletei (adatok és számítási módszer):

• A „zsaroló, titkosító” kártevők kapcsán:
  • Magyarország lakossága 2014.01.01-én: 9.877.365 (https://hu.wikipedia.org/wiki/Magyarorsz%C3%A1g_n%C3%A9pess%C3%A9ge)
  • az internetet rendszeresen használók aránya 2014-ben: a népesség 75 százaléka (https://www.ksh.hu/docs/hun/eurostat_tablak/tabl/tin00091.html)
  • az internethasználókból 18 fő Pál irodájában dolgozik (a Palival folytatott beszélgetés alapján)
  • a blogbejegyzés publikálásáig 750 hazai Cryptolocker fertőzés fordult elő (írott sajtóban az utóbbi hónapban olvastam 500-1000 eddigi hazai esetről – ezek átlaga 750)
  • 9.877.365 x 0,75 : 750 : 18 = 549 (egészre kerekítve) azaz egy az ötszáznegyvenkilenchez az esélye, hogy Paliék vállalkozása valamely zsaroló, adattitkosító kártevő áldozatául esik.
• Közlekedési balesetek bekövetkezési esélye:
  • Budapest népessége 2014.01.01-én: 1.744.665 (http://www.geoindex.hu/uzleti-szolgaltatasok/elemzes/magyar-telepulesek-nepessege-2014-evi-adatokkal/)
  • súlyos és halálos közlekedési balesetek száma Budapesten 2014-ben: 731 + 50 = 781 (http://www.ksh.hu/docs/hun/xstadat/xstadat_evkozi/e_feb002.html)
  • egy balesetben két sérülttel számoltunk
  • 1.744.665 : 781 : 2 = 1117 (egészre kerekítve) azaz egy az ezeregyszáztizenhéthez az esélye, hogy budapesti lakos súlyos közlekedési balesetet szenvedjen

Elnézést a példáért, kívánom minden olvasónak, hogy elkerülje a balszerencse, viszont hadd hangsúlyozzuk ismételten: egy másfél tucatnyi munkavállalót foglalkoztató vállalkozásnak kétszer akkora esélye van „zsaroló, titkosító” kártevő áldozatává válni, mint arra, hogy a budapesti cégvezetőt komoly közlekedési baleset éri. Előbbi esemény bekövetkezési valószínűségét illetve az esetleges fertőzéskor a kár nagyságát tudjuk csökkenteni – lépjünk kapcsolatba most, kezdjünk dolgozni vállalata biztonsága érdekében mihamarabb!

A Biztonsági mentés bejegyzés először Jasipos IT biztonsági és audit kft-én jelent meg.

A válogatott felkészítése során elhangzott, hogy érezhetően javult az edzésmunka hatékonysága (az ugyanazon edzésmunka hatására elért fejlődés), amikor a sportolóknak részletesen elmagyarázta, mely gyakorlatra miért van szükség, a gyakorlat során milyen fiziológiai folyamatok mennek végbe, a gyakorlatoknak milyen hatása lesz, hol és mikor jelentkezik majd a fejlődés.

Tanácsadás során ugyanígy járunk el mi is. Ügyfeleink a saját területükön kiemelkedő szakemberek, komoly eredményeket értek el munkájuk során. Komolyan  tisztelem őket -általában nem könnyű meghozni a döntést, hogy a belső szakértelem mellé kívülről „importálnak” tudást és tapasztalatot (az erőforrás könnyebben elfogadható még önérzetesebb szakemberek számára is).

Az együttműködésünk akkor szokott igazán lendületet kapni, amikor elkezdünk közösen gondolkodni. Meghallgatjuk a feladat elvégzése vagy a probléma megszüntetése érdekében eddig tett intézkedéseket, elemezzük, mely akciót miért hajtották végre és az erőfeszítésnek milyen hatása volt majd megkérdezzük: „Mi a véleményük, ebben az esetben lehetne… ?” és ekkor vagy azonnali ötletelfogadás történik, vagy belekezdünk egy kölcsönös értelmezésbe, amely során részletesebben bemutatjuk, miért is tartanánk jó megoldásnak javaslatunkat, a javaslatunk megvalósítása milyen erőforrásokat igényel és cserébe mely területen milyen hatás várható – s természetesen ezt a véleményt mire alapozzuk (számítás, előzetes tapasztalat stb.). Feladatfüggő, mindez mennyi időt vesz igénybe – legutóbb kb. 20 perc alatt azonosítottuk azokat a pontokat, amelyek újragondolva ügyfelünk licencköltsége harmadára csökkenthető (ez  számunkra is rekordidő volt, de ettől eltekintve korántsem végnélküli beszélgetésekről van szó).

A sport és az informatikai tanácsadás azért bemutatja a különbséget is. A sportban az edző magyarázata után nincsen választás, azt végre kell hajtani. Az informatikai tanácsadásban a döntést mindig az ügyfél hozza, ha nem ért egyet a javaslatunkkal, azt tudomásul vesszük és a többi lehetőségből ajánlunk. A csúcsra több úton is el lehet jutni.  🙂

Nem, ez nem Kemény Dénestől származik. Ő azt mondta, hogy „ha akartad a biciklit, akkor pedálozzál„. S ezt látjuk magunk körül: akinek feladata van, igyekszik azt végrehajtani. Ha gondja van, segítséget kér. Az informatikai tanácsadás olyan, mint a célzott továbbképzés: az ügyfél a számára fontos területről kap információt azért, hogy a kapott javaslatokat érdemben elemezni, vizsgálni tudja, megalapozott döntést tudjon hozni.

Kemény Dénes elárulta, ő rendszeresen beült más edzők edzéseit megnézni és sokat tanult, vett át másoktól. „A továbbképzés nem ciki, ha ciki, ne mond el.” – tanácsolta. Szívünkből szólt: ha Önnek bármi információ, közös gondolkodás, célzott továbbképzés kell, hogy új szempontokat friss megközelítéssel elemezhessen annak érdekében, hogy megalapozott, vállalatát előrelendítő döntést hozzon, örömmel leszünk partnerek, diszkrét csendestársak benne. A döntést Ön hozza, partnerei, kollégái Önt fogják látni.

Sportról gasztronómiára váltva: Ön a szakács, mi az alapanyagot szállítjuk, a piacon mutatjuk meg a „tuti árusokat”. Ez olyan hozzájárulás, hogy meg sem kell említeni. A Michelin csillagot a szakácsok kapják.

Önöknek, Önnek segíthetünk egy informatikai „Michelin csillag” megszerzésében? Lépjünk kapcsolatba most!

A Informatikai tanácsadás bejegyzés először Jasipos IT biztonsági és audit kft-én jelent meg.

(A jól átgondolt, többrétegű, mélységi technikai védelem kialakítása és működtetése a vállalat feladata. Az IDS/IPS, NAC, EPP, MDM, FDE és a többi néhány betűs technikai megoldás természetesen szintén fontos, a „humán” és a technikai védelem együtt, egymást kiegészítve ad egységes, átfogó védelmet. A technikai védelem is szóba fog kerülni több későbbi bejegyzésben (nem rövidítésekben, hanem érthetően – a korábbi terminus technikus dömping a technikai oldalról érkező olvasók megnyugtatására íródott, hogy lássák, érdemes ide visszatérni a későbbiekben) – a mai cikk azonban egy (látszólag) kevésbé komplikált védelmi megoldásról szól.

Visszatérve a képzésre: tanulságos volt az is, mikor „fagyott meg a levegő” vagy kezdett zavartan nevetgélni a társaság, mely témák, mintapéldák érintették meg leginkább a hallgatókat. Az egyik ilyen a jelszavak védelme volt, pontosabban az, hogy a jelszavát mindenki kezelje bizalmasan, ne ossza meg másokkal.

A munkavállaló aláírja a munkaszerződését, kap egy felhasználói azonosítót az informatikai rendszerekhez (innen kezdve őt felhasználónak is nevezhetjük), kap az azonosítójához egy kezdeti jelszót, majd kezdi a munkát, belép az informatikai rendszerbe, valaki elmagyarázza neki, mit és hogyan kell csinálni és így tovább. Ami számunkra jelenleg lényeges: az informatikai rendszerbe történő első belépéstől kezdődően a munkavállaló valamennyi informatikai tevékenysége naplózásra kerül, mint az általa végzett tevékenység.

Nyilvánvaló – gondolja Ön. Nyilvánvaló – gondolják a felhasználók.

A felhasználói azonosítót és a hozzá tartozó jelszót nem szabad mással megosztani, mivel ha más megismeri az azonosítót és a jelszót, az illető az eredeti felhasználó nevében tud végrehajtani tranzakciókat, amelyeket az informatikai rendszer úgy naplóz, mintha azokat a felhasználó hajtotta volna végre.

Nyilvánvaló – gondolja Ön. Nyilvánvaló – gondolják a felhasználók.

Két megjegyzés:

• A vállalaton kívüli támadók technikái közül a korábbi blogbejegyzésben említett social engineering a leginkább költséghatékony célzott támadás. A social engineering jó magyar fordítással: pszichológiai manipuláció, amelynek során a cél az, hogy a kívánt bizalmas adatokhoz ne informatikai rendszerek feltörésével, hanem felhasználók megtévesztésével – többek között azonosítójuk és jelszavuk megszerzésén keresztül – jussanak hozzá.
• A social engineering minden hatékonysága mellett visszaélések esetében a felhasználó azonosítójával és jelszavával leggyakrabban nem a vállalaton kívüli ismeretlen elkövető él vissza, nem a hacker szerzi meg pszichológiai megtévesztéssel a munkavállaló azonosítóját, hanem a felhasználóval egy munkahelyen dolgozó másik munkavállaló (például melléállva vagy válla felett átnézve meglesi az informatikai rendszerbe történő belépéskor).

A jelszavak védelme, megosztási tilalma a kollégákra, felettesekre és beosztottakra egyaránt vonatkozik; velük sem kell, velük sem szabad közölni a jelszót.

75 millió Euró elkövetési értékű visszaélést vizsgáltunk eddig. A más felhasználói azonosítójával és jelszavával elkövetett visszaéléseket mindegyik általunk vizsgált esetben belső munkavállaló, kolléga követte el.

Amikor információ biztonság-tudatosság képzésen ezt megemlítem, mindig vágni lehet a csendet. Meg is értem: a munkavállalói létezés alapja a bizalom; a kollégákkal szembeni „titkolózás” ezzel teljesen ellentétes.

Titkolózás? Bizalmatlanság?

Jogos önvédelem.

Dolgozhatnak évtizedek óta együtt, előfordulhat olyan helyzet (amelyről Ön nem tud), amikor egyik ismerőse vagy kollégája úgy érzi, nincs más lehetősége, mint hozzányúlni a rábízott vagy körülötte levő értékekhez, ráadásul ez kisebb kockázatot jelent számára, mint a felmerült kényszer. Nem biztos, hogy ez valós értékelés, az sem biztos, hogy nincs más lehetőség, de a leendő elkövető így gondolja, ezt érzi – és lép.

Remélhetőleg nem lesz ilyen eset az Ön környezetében – így legyen. Ha viszont mégis…

A visszaélés megelőzés több személyt is meg tud védeni: Önt, becsületesen dolgozó kollégáit, az ügyfeleiket – még a visszaélést fontolgató kollégát is (önmagától).

Gondoljon önmagára és családjára – előzze meg a visszaélést, ne ossza meg jelszavát mással.

Ön már tudja, mire kell figyelnie, Ön már biztonságban lesz. Kollégái, beosztottai is meg tudják védeni magukat?

Lépjünk kapcsolatba most, kezdjük el mihamarabb fejleszteni az Önök munkavállalóinak biztonságtudatosságát!

A Visszaélés megelőzés – önvédelem bejegyzés először Jasipos IT biztonsági és audit kft-én jelent meg.

Látszólag különböző, de valójában igen hasonló terület a visszaélések vizsgálata – mindjárt meglátjuk, miért is…

Felidézve az általunk vizsgált visszaéléseket, azoknak több, mint 90 százaléka többé-kevésbé belső „félrelépésekre” volt visszavezethető, azokkal kezdődött.

Jellemző elkövetési minta volt, hogy az egyik, egyébként az átlagnál szorgalmasabb, ambiciózusabb munkatárs véletlenül elkövetett egy hibát – aztán telt-múlt az idő és nem történt „semmi”. A hibát nem fedezték fel, senkinek sem „tűnt fel”, hogy valami nem megfelelő történt.

A hibát elkövető munkatárs eleinte szorongott, majd egyre inkább megnyugodott és később – elkezdett gondolkodni. Azon tűnődött, mi lehetett az oka, hogy az egyébként jól működő szervezetben senki sem észlelte a hibát, senki sem vette észre, mi történt.

A tűnődés során a munkatárs rendszerint kiszámolta, mekkora kárt okozott szándékolatlanul a vállalatnak, majd következő lépésként felmerült benne, mi történt a veszteséggel, ki „járt jól” vele – és innen már csak egy lépés, hogy az is eszébe jusson, akár ő is lehetne a veszteség haszonélvezője. A gondolatot tett követte: elkövette a „hibát” ismét, kis értékre, felkészülve, hogy meg tudja magyarázni, mit nézett el, mit tévesztett – de nem kellett magyarázkodnia, senki sem vette észre ezt sem… és a következőt sem … és az azt követő „hibát” sem…

A „hibák” egyre gyakoribbak lettek, egyre nagyobb értékben „fordultak elő”… és a korábbi szorgalmas munkatárs még többet dolgozott, hiszen egyre több „hiba” nyomát kellett eltakarnia, egyre több szálra kellett figyelnie, míg egyszer csak valakinek feltűnt, hogy … de ez már egy másik történet lesz.

A Social Engineeringtől indultunk, az emberek megtévesztésén alapuló támadásokról. A kapcsolatot a Social Engineering és a belső visszaélések között a következő blogbejegyzésben megválaszolom, ígérem – most viszont foglalkozzunk egy Önnek talán érdekesebb kérdéssel: gondolt Ön már arra, hogy mekkora kára származhat vállalatának egy-egy munkatársi tévedésből? S gondolt már arra, hogy mekkora kára származhatna egy-egy szándékos „tévedésből”?

S gondolt már arra, mennyibe kerülne Önöknek meggyőződnie arról, történt-e valami, amiért aggódni kellene? Elárulom: a lehetséges kárérték töredékébe…

Konkrét példa: az általunk kezelt legutóbbi visszaélés kivizsgálás, felderítés ügyben a díjazásunkhoz viszonyított kb. húszszoros értékű visszaélést, vállalatnak kárt okozó tevékenységet azonosítottunk (őszintén kívánom, inkább érezte volna kidobott pénznek a javadalmazásunkat az ügyfél…). Ha egy évvel korábban kezdtük volna a vizsgálódást (egy évvel korábban vette volna fel velünk a kapcsolatot ügyfelünk), a történet „megállt volna” a végső kárérték kb. ötödénél…

Ön bízik a munkatársaiban – ez jó, ez így helyes! A legtöbb keményen dolgozó, szorgalmas munkatárs becsületes, a vállalat érdekeit tisztelő, támogató kolléga!

Adjon megbízást nekünk (ahogyan a példában szereplő ügyfelünk is tette) a folyamatok áttekintésére, a belső kontrollok azonosítására, értékelésére. Mi átnézzük belső folyamataikat, nyilvántartásaikat, az alkalmazott kontrollokat, összevetjük az iparágban szokásos eljárásokkal és az egyéb elvárásokkal, mintát veszünk a tranzakcióikból és számos további módon értékeljük a belső kontroll rendszerüket, hatékonyságukat, miközben Önnel folyamatosan konzultálunk az eredményekről. Amennyiben további vizsgálatra érdemes tényeket találunk, Ön eldöntheti, megnézzük-e az esetet részletesebben (természetesen továbbra is diszkréten, mint hatékonyság-növelési tanácsadók) vagy lépjünk tovább.

Legjobb esetben átadunk Önnek egy összesítést a belső folyamataikról, kontroll rendszerük hatékonyságáról, amellyel Ön bármely további auditnál, ellenőrzésnél igazolni tudja, hogy a belső kontroll rendszerük hatékonyan működik és Ön erről külső, független szakértők által is meggyőződött.

Legrosszabb esetben … nos, ez nem fordulhat elő, mivel a legrosszabb az lenne, ha a “munkatárs” által elkezdett “hibasorozat” zavartalanul folytatódna… viszont mi azért dolgozunk, hogy ez ne fordulhasson elő.

[vcex_button url=”http://jasipos.com/referenciaink/” title=”Referenciáink” style=”graphical” align=”left” color=”green” size=”large” target=”self” rel=”none”]REFERENCIÁINK[/vcex_button]

[vcex_button url=”http://jasipos.com/kapcsolat/” title=”Kapcsolat” style=”graphical” align=”left” color=”green” size=”large” target=”self” rel=”none”]KAPCSOLATFELVÉTEL[/vcex_button]

A Visszaélés kivizsgálás, felderítés bejegyzés először Jasipos IT biztonsági és audit kft-én jelent meg.