A 2018 május 25-én érvénybe léptetett GDPR szerinti megfelelés nagyjából fele-fele arányban jogi és információbiztonsági kérdés. Rövid összefoglalóm segít abban, hogy a nem IT végzettségű szakemberek is közelebb kerülhessenek a téma információbiztonsági oldalának és gyakorlati megvalósíthatóságának megértéséhez. Hogy a vállalatuk biztonsága, jó hírneve és nem utolsósorban a személyes és különleges személyes adatok tulajdonosainak jogos védelme érdekében el tudják fogadni, hogy a GDPR szabályzat alapján kockázatkezelést kell végezni, melynek védelmi intézkedéseit egyébként számon is fogják kérni a vállalatokon. Annál is fontosabbnak tarjuk mindezt mi, akik kockázatkezeléssel, információbiztonsági tanácsadással foglalkozunk és eszközt adunk vállalatoknak a GDPR megfeleléshez, mert a GDPR projektek az esetek döntő részében vagy a jogi vagy a compliance osztály hatáskörébe tartoznak és az információbiztonsággal foglalkozó szakterületek – gyakran az IT – már csak akkor kapja a felkérést a projektben való részvételre, ha már megszületett a jogi szabályozás. Szerintünk nem ez a járható út. A két területnek az első pillanattól kezdve együtt kellene gondolkodnia. A GDPR szabályzat több helyen is említi, hogy kockázatkezelést kell végezni, s megfogalmazza azt is, hogy mire kell ezzel kapcsolatban figyelni. Látszik, hogy a rendeletet nem információbiztonsági szakember írta, ugyanis először fogalmaz meg egy intézkedést, aztán pedig célkitűzést. Ezt fordítva érdemes csinálni, így a kiragadott célokkal kezdem:
Biztosítani kell a személyes és különleges személyes adatoknak a bizalmasságát, sértetlenségét és rendelkezésre állását, még pedig folyamatosan. Ez azt jelenti, hogy az informatikai rendszert úgy kell felépí- teni, olyan védelmi intézkedéseket kell életbe léptetni, hogyha az egyik rendszer kiesik, akkor a másik tudja biztosítani ezeknek az adatoknak a védelmét. Tehát, ha betörnek a szerverszobába, és elviszik a hónuk alatt azt a szervert amelyiken az összes ügyfelük adatát tároljuk, akkor azok az adatok olyan titkosítással legyenek eltárolva, amely feltörhetetlen, így amint kihúzzák a szervert az elektromos hálózatból, az adatok ne legyenek hozzáférhetők.
Ha bármelyik informatikai szolgáltatás kiesik, akkor azt az informatikai szolgáltatást helyre lehessen állítani azon IT szolgáltatások helyreállítási tervei (IT Service Plan) alapján, amelyek az adott szerver szoba által érintettek. Van, hogy az egész iroda elvész, ilyenkor még bonyolultabb a helyreállítás (Disaster Recovery Plan), hiszen figyelembe kell venni a helyreállítás szempontjából szűkösen rendelkezésre álló erőforrásokat is. Azokat az intézkedéseket, amelyeket egyszer már életbe léptettünk, folyamatosan fejlesztenünk kell, azaz mindig magasabbra és magasabbra kell kitűzni az elvárt biztonsági szintet magunk elé és amikor ezt a biztonsági szintet teljesítettük, akkor ezen a ponton sztenderdizálni kell. A sztenderdizálás után lehet újabb és újabb célkitűzéseket állítani, így válik a működésünk egyre tudatosabbá és biz- tonságosabbá.
Minden kockázat elemzés hatáselemzéssel kezdődik. Könnyű azt belátni, hogy nem csak a személyes adatok és nem csak a különleges személyes adatok azok, amelyek igazán fontosak a vállalatoknak. Egy nagy marketing kampány terveinek ellopása jelentheti a teljes felkészülési időszak és a rá fordított pénz utolsó fillérig való elvesztését, ami hasonlítható akár egy GDPR-hiányosság következtében kirótt büntetés mértékéhez vagy a büntetés kapcsán elszenvedett vállalati megítélés romlásának hatásához. Az üzleti tervek, a könyvelési adatok és sok más adat is lehet olyan értékes, mint azok a személyes adatok vagy különleges személyes adatok, amelyet a vállalatok tárolnak, s amelyre most oly nagy figyelem esik a GDPR rendelet hatásaként. Éppen ezért jó hír vagy rossz hír, mindenképpen az a szerencsés és módszertanilag is csak az támogatható, ha a vállalatok teljeskörű adatfelmérést végeznek. Az összegyűjtött összes adat közül – ami az adott vállalatnál meg-található és védendő -, tudják majd kijelölni azokat, amelyek személyes, vagy különleges személyes adatokat tartalmaznak. Ha meghatároztuk a GDPR által érintett adatelemeknek a körét vagy az adatköröknek a halmazát, akkor érdemes megvizsgálni azt, hogy ezeket az adatokat vajon jogszerűen gyűjtjük-e és megfelelő ideig tároljuk-e? Ezt célhoz kötöttségi elemzésnek hívják és a korábbi info törvényben is volt erre módszertan, az érdekmérlegelési teszt. Ez az érdekmérlegelési teszt az, amelyben a jogászok megindokolják, hogy pl. az ügyfél személyes érdekénél miért fontosabb az, hogy a vállalat mindenféle elemzéseket tudjon végezni egy direkt marketing kampány vagy pl. egy ajánlattétel érdekében (pl., hogy vegyen egy új terméket abból a csoportból, amit két héttel ezelőtt vásárolt). Tudnunk kell, hogy milyen adat elemeket tartunk nyilván az adott adatról, és azt, hogy kikkel fogjuk megosztani ezeket az adatokat (Ahogy azt Vörös István énekli a Prognózis együttesben: “A titok az a titok, amit egyedül tudok”.). Ki az adatkezelő, adatfeldolgozó? Kikkel osztjuk meg az adatot (adatmegosztás) az Európai Unión belül és az Európai Unión kívül. Mindezen, GDPR hatálya alá tartozó adatok összegyűjtése után, kockázatkezelést kell végezni. Ahogy a címben is jeleztem, a kockázat két tényezőből áll össze. Az egyik tényező a HATÁS, ami úgy fejezhető ki, hogy mekkora a kár akkor, hogyha ez a hatás százszázalékos valószínűséggel bekövetkezik a másik pedig a VALÓSZÍNŰSÉG, ami a nem kívánt eseménynek a bekövetkezési valószínűsége. Ami hatáscsökkentő intézkedéseket a GDPR felsorol, az lényegében a jogi szakterületre tartozik – csak a legszükségesebb adatkategóriákat gyűjtsük össze, a lehető legkevesebb érintettel osszuk meg és csak azokat az adatokat, amelyek rájuk tartoznak, illetve ezeket a kockázatokat osszuk meg az adatfeldolgozókkal. Ennek a keretrendszere a GDPR szabályozás.
Mivel azonban két tényezős szorzatról van szó, a hatás csökkentése pont az ötven százaléka annak, amivel egy kockázatot csökkenteni lehet. Egy két tényezős szorzat esetén vagy az egyik vagy a másik tényezőt, esetleg mind a kettőt csökkenteni kell, ha a szorzat eredményét szeretnénk csökkenteni. Tehát csak azzal, hogy már tudjuk, hogy milyen adatokat gyűjtünk, milyen adatfeldolgozásokat végezünk rajtuk, milyen automatikus döntéshozatali eljárással kategorizáljuk ügyfeleinket, kivel osztjuk meg a kockázatot, még nem értünk a feladat végére, még nincs biztonságban se az adat, se az ügyfél, se a vállalat. Ha kiszivároghat az adat mert nem tettük meg a megfelelő védelmi intézkedéseket, nem jártunk el jól. Fontos megérteni, hogy a jogi szakterület a hatásoknak a csökkentésében tud segíteni, az informatikai szakterület pedig annak a valószínűségét tudja csökkenteni, hogy ezek a nem kívánatos események bekövetkezzenek. Ennek a keretrendszere például az ISO 27001, ami az információbiztonság szabványa, vagy állami vállalatok esetén a 2013/L. törvény. Azt, hogy hol következhet be az informatikai rendszerben valamiféle adatszivárgás, módszeres elemzéssel tudjuk meghatározni. Az informatika ellenőrzési keretrendszere a COBIT (Controll Objective for Information Technology) általában öt fajta erőforrást különböztet meg. Az emberi erőforrást, a folyamatokat mint erőforrást, a hardvereket, szoftvereket illetve a létesítményeket, amelyben a berendezések illetve az emberek el vannak helyezve. A legfontosabb védendő objektum a COBIT keretrendszerben az adat, amikor kockázatkezelésről beszélünk. Az infrastruk- túra minden egyes tényezőjének, akár ember, akár hardver, akár szoftver akár létesítmény, lehetnek különböző sebezhetőségei. Például az alkalmazottak nem jól képzettek, vagy a folyamatok rosszul vannak megszervezve, vagy a hardvereken, olyan vastagon áll a por, hogy pillanatokon belül túlmelegszenek és le fognak állni, vagy a szoftverekben nem garantált a négyszem elvű ellenőrzés vagy nem kötelező a bejelentkezéskor jelszó használata, és így tovább. Számtalan ilyen probléma lehet. A külső környezetből különböző fenyegetések érkeznek, például egy unatkozó script kiddie az általános iskola 6. osztályának számítástechnika szakköréből, aki éppen csatlakozott a meghirdetett defaceelési versenyhez, azaz az Önök cégének a holnapjára saját fényképét kell feltenni bizonyítható ezzel, hogy ezt a honlapot ő hackelte meg és ettől ő a valamilyen hackelési versenyen kap plusz egy pontot. Ha ez a külső szándék, ez a fenyegetés egy biztonsági rést talál – akkor következik be kár. Ezzel a módszeres elemzéssel lehet átvizsgálni azt, hogy hogyan lehet ezt az adatvagyont megsérteni.
Fontos tehát az, hogy az Önök vállalatában ezeket a berendezéseket az informatika felmérje és megvizsgálja a különböző sérülékenység vizsgálatokkal, hogy hogyan lehet ezekbe betörni. A kockázatelemzésnek az egyik leg-elterjedtebb módszertana a CRAMM módszertan, ami összeveti azt, hogy a sebezhetőséget hol tudja kihasználni fenyegetés, és ebből megállapítja, a lehetséges kockázatot. Ha van védelmi intézkedés pont ennek a kockázatnak a kezelésére, például egy fegyveres őr az aulában, aki megkérdezi az oda behatolótól, hogy mégis mit keres itt, akkor a valós kockázat csökkenthető. Ha a valós kockázatok még mindig túl magasak, akkor lehet kockázatkezelési terveket készíteni, amit majd az Önök cége a jövőben végre fog hajtani.
Megkülönböztetünk adminisztratív, logikai és fizikai védelmi intézkedéseket. A fizikai, amikor titkosítunk valamit vagy egyszerűen bezárjuk, elzárjuk a dolgokat. A logikai az, amikor logikai védelmet valósítunk meg, pl. jelszavas védelem. Az adminisztratív meg az, amikor írunk egy szabályzatot, hogy ezt így és így kell csinálni, és aki nem így csinálja azt csúnyán megbüntetjük.
Azt, hogy miféle dolgokat kell ellenőriznünk az informatikai rendszerünkben, az ISO 27001 keretrendszernek az “A” melléklete szabályozza, amely 104 célkitűzést tartalmaz. Ilyesmikre kell gondolni, hogy pl. távmunka esetén nagyon divatos mostanság otthonról dolgozni – hogyan védem azt, hogy a fiam a Counter Srike-ot ne azon a gépen játssza, amelyiken én dolgozom? Fontos terület még az incidens kezelés, ami a GDPR esetében különös szerepet kap, hiszen bizonyos típusú adat- védelmi incidenseket azonnal jelentenünk kell. Az információ biztonság folyamatos fejlesztése a harmadik pontja annak a felsorolásnak, amit a szabvány előír. Sztenderdizáljunk, valamint az úgynevezett PDCA módszertannal (Plan Do Check Act) tervezzük meg a változtatásokat és aztán szépen folyamatosan léptessük életbe azokat. Mérjük, hogy jól működnek-e és hogy ha jól működnek, ak- kor ezeket az intézkedéseket nem kell korrigálni. Be kell vezetni és amit bevezettünk azt újra sztenderdizálni kell azon a szinten és így lépcsőről lépcsőre lehet egyre jobb és jobb információbiztonsági környezetet teremteni.
Ezeket az információ biztonsági védelmi intézkedéseket fogják Önökön számon kérni. A cégek felelősei számon kérhetők a védelmi intézkedések be nem vezetése végett. Hogy miért nem telepítettek egy tűzfalat, ami képes meg- védeni a rendszerüket? Vagy miért nem vették figye- lembe, hogy a fejlesztés során a legelemibb fejlesztési szabványokat sem követték? Ezeket a dolgokat érdemes szem előtt tartani amikor dönteniük kell vagy javaslatot kell tenniük a GDPR megfelelés információbiztonsági ol- dalának fejlesztéséről.
A módszertan körülbelül abból áll, hogy összegyűjtjük az összes adatkört, összeállítjuk az adatinfrastruktúrát, azaz megmondjuk, hogy milyen adatot milyen szoftver, hard- ver, létesítmény stb. szolgál ki. Aki ismerős az ISO 9000- es környezetben, az már hallott erről, aki még nem annak mondom, hogy ezt így kell csinálni. Ezután az adatköröket tovább kellene elemezni, megkülönböztetni, hogy szemé- lyes adat, vagy különleges személyes adat, fel kell sorolni az adatnak az egyéb kategóriáit. A NAIH ajánlásában szereplő angol szabvány hivatkozásait, hogy milyen adatkategóriákat ismerünk, beleépítettük az ADAPTO szoftverbe, így nem kell kitalálni, mert ajánlásaink vannak rá.
Meg kell határozni – és ezt végzik a jogászok – a következőket: adatkezelés célja, jog alapja, megtartási idő, szabályzat stb., az adatkezelő és az adatfeldolgozók. Meg azokat az adatokat, amiket leír a GDPR, tehát az adatvé-delmi tisztviselő nevét, elérhetőségét, a képviselőjének a nevét, a meghatalmazottjának a nevét stb., ezek mind- mind adatok, amiket nyilván lehet tartani, ez az adminisztratív része a dolgoknak. Ezek után csökkenteni kell a hatást, ezt mindig a jogi szakterület végzi, azaz meghatározza, hogy mely adatok azok, amelyekre szükségünk van és melyek, amelyekre nem. Melyek azok, amelyeknek a létjogosultságát meg tudjuk indokolni és melyek azok, amelyeket nem. Utána kell elvégeznünk egy kockázat elemzést, amelyben megnézzük, hogy az így megállapított adatköröket mi módon tudjuk megvédeni. Milyen további védelmi intézkedések kellenek annak érdekében, hogy ezeknek az adatoknak a zárt, a teljeskörű és folytonos védelmét meg tudjuk valósítani.
Azt szoktam mondani mindenkinek, hogy ha tíznél több piros – azaz feltétlenül kezelendő – kockázata van, akkor rosszul dolgozik, ugyanis kevés olyan cég van, aki egyszerre tíz darab adatbiztonsági projektet képes menedzselni. Csinálj tízet és hogyha azt felszámoltad, vagy a jelentős részét felszámoltad, akkor utána szállítsd lejjebb a kárküszöbértéket és akkor a narancssárgák egy részéből újra piros lesz. Így mindig kezelhető mennyiségű projekttel kell foglalkozni, és megvalósul a folyamatos fejlesztés, amellyel jobb és jobb információbiztonsági környezetet állítunk elő a vállalatunkban. A kockázatkezelési terveket végre kell hajtani. Aki késve kezdte el a jogi részét rendezni a GDPR megfelelésnek, az egészen biztosan elkésett és nem lesz rá elég kapacitása. Az információ biztonsági intézkedések végrehajtására meg még úgy sem. Módosítsuk a szoftvereinket, szervezzünk át folyamatokat, valósítsunk meg hálózati biztonságot, tegyünk fel új naplóelemző szoftvert és így tovább és így tovább. Ez egy nagyon bonyolult feladat, erre érdemes odafigyelni, időt, energiát, szakértelmet, anyagi erőforrást allokálni rá. Ha pedig kitűznek szabályozási célokat maguk elé (például a GDPR-ban fellelt szabályozási célokat), akkor jó, ha ellenőrizni tudják, hogy ezeket a célkitűzéseket elérték- e vagy sem, ha nem érték el, akkor miért nem érték el, és mikor fogják elérni a jövőben, milyen intézkedésekkel? Ezt hívják megfelelősségi vagy alkalmazhatósági nyilatkozatnak.
Az ADAPTO-nak minderre van módszertana és szoftvere.
A szoftver használatával be tudják építeni a GDPR-t az információbiztonság rendszerébe és nem egy újabb szigetrendszerként működtetik azt. A kockázatelemzés módszerével biztosított az adatok megfelelő védelme, ami a számonkérés része és túlmutat a szükséges, de önmagában elégtelen érdekmérlegelési teszten. Az ADAPTO szoftverből közvetlenül igazolni tudják, hogy megvannak a szükséges védelmi intézkedések is, így a GDPR felkészülés teljessé válik.
Pfalnzner Sándor, ISOFÓRUM Tavasz-2018 Konferencián elhangzott előadás írott változata Forrás: Magyar Minőség 2018/07