Az információvédelem kezelése
30 perc olvasás
A Hétpecsét Információbiztonsági Egyesület 63. szakmai fórumát tartotta az információvédelem kezelése témakörben 2014. november 19-én. Tarján Gábor egyesületi alelnök bevezetőjében utalt az Egyesület 2001. óta tartó tevékenységére, szólt a Hétpecsétes történetek javított kiadásáról, az első kötet online) elérhetőségéről, (szabadon letölthető a hetpecset.hu honlapról a Kiadványok menüpont alatt) a 2014. évi ISACA konferenciáról, az Egyesület támogatóiról, s bejelentette, 2015. januártól az Egyesület összejövetelei új helyszínen, az Üllői út 94-98. szám alatti Tulip Inn Budapest Millennium szállóban zajlanak. Felhívta a figyelmet az egyesületi tagok LinkedIn-en zajló kommunikációjára.
A Hétpecsét Információbiztonsági Egyesület 63. szakmai fórumát tartotta az információvédelem kezelése témakörben 2014. november 19-én. Tarján Gábor egyesületi alelnök bevezetőjében utalt az Egyesület 2001. óta tartó tevékenységére, szólt a Hétpecsétes történetek javított kiadásáról, az első kötet online) elérhetőségéről, (szabadon letölthető a hetpecset.hu honlapról a Kiadványok menüpont alatt) a 2014. évi ISACA konferenciáról, az Egyesület támogatóiról, s bejelentette, 2015. januártól az Egyesület összejövetelei új helyszínen, az Üllői út 94-98. szám alatti Tulip Inn Budapest Millennium szállóban zajlanak. Felhívta a figyelmet az egyesületi tagok LinkedIn-en zajló kommunikációjára.
Horváth Gergely Krisztián, ISACA elnökségi tag a szakterület terminológiájának rendezéséről, a magyar nyelvű változat egyértelműségéről szólt, az egész terminológia egységesítését tekintve,
Ellenőrzési mechanizmusok, védelmi intézkedések vagy kontrollok? Hogyan mondjuk? És a szabványokban
(pl: MSZ ISO/IEC 27001, Cobit 5) mi szerepel? – címmel.
A tíz év információbiztonsági és audit tapasztalattal rendelkező előadó szakmai lektorként vett részt a COBIT 4.1 (2008) és a COBIT 5 (2013-14) magyar változatának elkészítésében.
Az ISACA (Information Systems Audit and Control Association, www.isaca.org) az információ rendszer menedzserek és ellenőrök nemzetközi szakmai szervezete, melyet 1969-ben alapítottak az Egyesült Államokban és 193 tagszervezettel további 160 országban, több mint 95 ezer taggal rendelkezik, (legújabb tagszervezete a közelmúltban 40 fővel alakult Velencei tagszervezet – Venice Chapter). Az ISACA komoly tudományos hátterét olyan intézetek és cégek testesítik meg, mint pl. a nagyvállalati IT irányítás támogatására 1998-ban létrehozott kutatóintézet az ITGI (Information Technology Governance Institute).
Az ISACA alapvető célja a legjobb gyakorlatra alapozott módszerek felkutatása, oktatása és világméretű elterjesztése. Támogatói és szponzorai között a legnagyobb tanácsadó cégek állnak. Az ISACA által kidolgozott módszertant (COBIT – Control Objectives for Information and related Technologies) a világ számos országában, nagyon sok vállalat alkalmazza, akik felismerték, hogy a jól működő informatikai háttér nélkül nem lehetséges korszerű üzleti vállalkozást működtetni és fenntartani, azaz ilyen módszertanra szüksége van minden cégnek.
Ezen informatikai háttér működtetési módszereihez ad segítséget az ISACA.
Az ISACA idehaza 466 taggal rendelkezik, nemzetközi tagsága 180 országból szerveződik, 115 ezer taggal.
A hazai biztonsági szakemberek a nemzetközi átlagnál nagyobb létszámot képviselnek a szakmában.
Az ISACA új kezdeményei:
Cybersecurity Nexus (CSX) program (http://isaca.org/cyber) : a kiberbiztonság területén alapszintű kutatási anyagokat, tudományos szakanyagokat jelentet meg, ill. megjelent két új vizsgalehetőség; a
Cybersecurity Fundamentals és a Practitioner Certification. Megjelentek kiberbiztonsági kutatási anyagok és útmutatók, kiberbiztonsági oktatási és együttműködési formák. A közelmúltban jelentek meg az EU direktívákhoz kapcsolódó biztonsági anyagok, az IT Assurance framework (ITAF) v3 (http://isaca.org/itaf), IT ellenőrzési szabványok, módszertani kézikönyv, vizsgálati programok, s további szakmai anyagok is. (http://isaca.org/research)
A COBIT elterjedtsége jelentősen növekedett az elmúlt évben, több mint 145 ezren töltötték le.
A COBIT 5 magyarítása jelenleg a keretrendszerre terjed ki, a többi része angolul érhető el. Az információ-biztonsági rész külön kötetben jelent meg, a korábbi business security-t is magába olvasztva, maga is egységes keretrendszerré vált. Az ISACA központ az elterjedés érdekében támogatja a nyelvi változatok létrehozását.
A COBIT 5 tartalma:
Ösztönző segédletek; ösztönző eljárások, ösztönző információ, egyéb ösztönző útmutatók
Szakmai segédletek; megvalósítási lehetőségek, információbiztonság, bizonyosság-nyújtás, kockázat-ismertetők, egyéb szakmai útmutatók
Az anyag inkább menedzsment jellegű, mint irányítást szolgáló tartalmat jelent.
Az anyag magyar nyelvű változata rövidesen megjelenik. (www.isaca.org/cobit) Az ISACA magyar tagozata végzi a munkát, célja; az angol nyelvű szakirodalom és ajánlásrendszer lefordításával segíteni elő a szakma magyarországi elterjedését, megbecsülését.
A vezetőség úgy döntött, először az angol változatban Glossary-val jelölt alap fogalomtárt fordítják magyarra, hogy ez adja később az alapvető fogalomkészletet a további fordításhoz. A magyar változaton munkálkodók az elmúlt 5 év tapasztalatai alapján felülvizsgálják az ISACA anyagokban használt magyar fogalmakat, erre építve valósítják meg az ISACA fogalomtár magyarítását (Glossary).
A kiterjedt és számos nehézséget jelentő feladat során egységes, szövegkörnyezettől és szókapcsolattól független megoldásra törekedtek, mivel a korábbi munkák szövegkörnyezettől és szókapcsolatoktól függő magyar változatot eredményeztek; szakmánként (menedzsment, számvitel, belső ellenőrzés, információbiztonság, stb.) és egy-egy nemzetközi cég kiadásában más-más magyar változat honosodott meg. Az elkészült magyar változat már letölthető az ISACA magyar oldaláról (ezer fogalom, magyarázattal):
Angol: http://isaca.org/Pages/Glossary.aspx
A jelenlegi magyar változat lektorált verziót jelent, az amerikai kollégák is átnézték, formai észrevételek voltak.
Példák az angol nyelvű fogalmak feloldására:
Az „enabler" kulcs-jelentőségű fogalom az anyagban, de hazai vonatkozásban nem elterjedt koncepció.
A COBIT 4.1-ben: lehetővé tevő, elősegítő, megvalósító
COBIT 5-ben: ösztönző tényező, képesítő, támogató
Kulcsfogalom a „control" is. Nagyon széles értelmezése van, használták magyar szakirodalomban intézkedés értelemben is, vagy nukleáris szakmában biztonság értelemben, információ biztonságnál pedig védettség értelemben, az 5-ös változat fordítói egyenlőre maradtak a kontroll -nál magyarban is.
COBIT 3 (2000.) – irányítási és ellenőrzési mechanizmus
COBIT 4.1 (2008.) – kontroll
COBIT 5 (2014.) – kontroll
Állami számvevőszék: kontroll
Nemzetgazdasági minisztérium (2009.) : kontroll
MSZ ISO/IEC 27001: intézkedés
MSZ ISO/IEC 27001:2014: intézkedés
„audit trail" :
COBIT 3: ellenőrzési nyomvonal
COBIT 5: audit nyomvonal
Vonatkozások:
MSZ ISO/IEC 27002:2011:Audit kísérődokumentumai
MSZ ISO/IEC 27001:2014
„masqueraders":
olyan támadók, akik a jogos felhasználók azonosságával és az ő bejelentkezési meghatalmazásuk felhasználásával hatolnak be a rendszerbe.
Magyarítási lehetőségek: álarcos-, álarcos heckerek, eltulajdonított azonosítót használó-, jogos felhasználót megszemélyesítő
„brouter":
Meghatározása: eszköz, amely összeköti az azonos és a különböző adatkapcsolati típusú LAN szegmenseket, ami a megoldás jelentős előnye. A hálózati hídhoz hasonlóan, a csomagokat az adatkapcsolati szintű cím alapján továbbítja egy ugyanolyan típusú, másik hálózatba. Amennyiben szükséges, feldolgozza és a hálózati protokoll cím alapján továbbítja az üzeneteket egy másik adatkapcsolati típusú hálózatra.
Magyarítási lehetőségek: útválasztós híd (brouter), brouter, brútválasztó (sic!)
„state-holders":
érdekelt felek
„end-to-end":
teljes lefedésű
„gouverment":
az irányítás
holistic (data protection) approach:
(„holisztikus megközelítés" helyett:) átfogó megközelítés
A fordítók várják a jobbító javaslatokat!
COBIT 5 alapelvek:
Feleljen meg az érdekelt felek igényeinek
Fedje le a teljes vállalatot
Egységes, integrált keretrendszert alkalmazzon
Ösztönözze az átfogó megközelítést
Legyen szétválasztva az irányítás és menedzsment
A COBIT 5 erőforrásai:
Alapelvek, szabályzatok és keretrendszerek
Eljárások
Szervezeti struktúrák
Kultúra, etika és viselkedés
Információ
Szolgáltatások, infrastruktúra és alkalmazások
Humánerőforrás, készségek és képességek
Gyöngyösi Péter, a BalaBit IT Security termékmenedzsere az IT biztonság területén zajló paradigmaváltásról szólt. Az elmúlt tíz évben minden megváltozott; mobilitás, felhő, szociális közeg, konzumerizáció, mindez a biztonság területét is megváltoztatta. Az új felállás nem viseli el a hibás működést, az emberi mulasztást, a belső-külső kártevőket, az automatizált támadásokat. Ma már konzervatív cégek is kihelyezik teljes szolgáltatásukat a cloud-ba.
A BalaBit maga is kihelyezi sales-source-át a felhőbe, mindez korábban elképzelhetetlen lett volna.
A szociális média mára nagyon komoly szakmai fórummá is vált. Kezd elmosódni a határ a cégeknek a professzionális környezetre készült eszközei és megoldásai, valamint a végfelhasználók számára előállított megoldások között. Ez nagyon érdekes dinamikát indukált az IT-ban és az IT biztonság-technológiában.
Korábban az üzlet megfogalmazta azokat az igényeket, melyek kielégítése révén dolgozói a meghatározott feladatokat elláthatták. Az IT ehhez biztosította a környezetet, a felhasználó pedig használta azt. Az IT biztonsági szerepe annyi volt, hogy az üzletet segítve, biztosítsa annak zavartalanságát, biztonsági szempontból azt ne tartsa fel semmi.
Jelenleg a felhasználók sokkal aktívabban vesznek részt a környezet kialakításában, igénylik, hogy ebben a környezetben használhassák eszközeiket. Látják a meglévő jó szolgáltatásokat, s ezeket azonnal igénybe akarják venni. Erre szükségük is van a gyorsuló környezethez való agilisabb alkalmazkodáshoz. Léteznek ma már olyan eszközök, amelyek kifejezetten az un. shadow-IT, árnyék-IT felderítésére szolgálnak. Amerikai cégeknél tapasztalható tendencia; szükségtelen új szolgáltatások telepítése, a felhasználók nem várnak új szolgáltatásokra, új marketing rendszerre, nem várnak fél évig igénylésük teljesüléséig, s további fél-év egy-évet IT-bevezetésére, hanem céges kártyájukkal helyből megvásárolják a szolgáltatást, s elkezdik használni.
Az ilyesfajta hozzáállás, és szolgáltatások trendszerűen terjednek, mert a felhasználók egyszerűen jobban, agilisabban akarják végezni munkájukat. Adott esetben az információbiztonsági szakember abba a kellemetlen helyzetbe kerülhet, hogy neki kell ezekre a jó trendekre nemet mondania. Ne használd a mobilodat, mert ha elhagyod, akkor mi van? Ne használd azt a cloud szolgáltatást, mert kikerülsz az adatpontról és nem tudunk megfelelni az előírt szabályozásnak. Ne jelentkezz be otthonról, mert a határvédelmet nem tudom megoldani. Sajnos, ilyenkor az IT gondozója nem védi, hanem akadályozza az üzletet, ezen kéne változatni.
Különböző felmérések arra mutatnak, hogy a biztonsági incidensek több mint fele mögött egy-egy meghatározható személy állt, aki gondatlanságból, vagy szándékosan indította el a folyamatot.
Hasonlóképpen kimutatták, hogy az incidensek több mint fele belülről indul. Nem a gonosz távol-keleti hacker támad a sötétből, hanem olyan valaki, aki egyébként is hozzáférhet a rendszerhez.
Az IT biztonságban szoktuk szerepeltetni a kontrollokat, mint magától értetődő dolgokat. Elhatározzuk, hogy
ezt meg ezt lehet, szabad csinálni, ezt meg nem szabad, ez a személy azt az adott adatot módosíthatja.
Ily módon létre lehet hozni egy betartható szabályrendszert. Jelenleg nagyon erős hangsúlyt kapnak az IT biztonság területén az ilyesfajta kontroll-rendszerek. Szükség is van rájuk, s az adott lépések nagyon fontosak.
A biztonságot azonban nem érdemes abszolutizálni, súlyozni kell alkalmazásakor. Bízzunk abban, hogy a felhasználók a legtöbb esetben megfelelően fognak viselkedni, s hogy a megbízható működés a normális, az átlagos. Ahol nagy fontosságú dologról van szó, ott alkalmazzuk a kontrollokat, a többi helyen helyezzük a hangsúlyt a megfigyelésre, aminek már önmagában visszatartó ereje van. Erre kellene mozdulni az IT biztonság területén, azaz, a további fejlesztéseknél a megfigyeléseket kéne előtérbe helyezni, nem a kontroll-eszközöket bonyolítani, azok használatával szigorítani.
Amennyiben nem gördítünk akadályokat a felhasználók elé, növekedhet az erkölcsi tartás, a morál is; azért akarja használni azt a külső cloud rendszert, vagy a mobilját, hogy a cégnek dolgozzon. Bátorítani kell ötletei kifejtésében, nem pedig ledorongolni.
Az IT szervezet mindebben az agilitásával tud segíteni, egy új rendszernek a megfigyelését kell beépíteni, s nem kell minden esetben adaptálni a kontroll környezetet.
Határozott vélemény szerint, a nagyobb megtérülést az informatikai rendszerbe beépített biztonsági megfigyelés bővítésével lehet elérni.
Egy ilyen megfigyelő rendszer összerakása azonban nem magától értetődő. A megszokott, elterjedt megfigyelő rendszerek statikus szabályokon alapulnak. Pl. küldjön egy riasztást, ha nagyon sok adatot töltöttek le, vagy ha a határvédelmi vonalon átment egy kártyaszám vagy ha egy adott mintának megfelelő fájlt látunk, mert az valószínűleg vírusfertőzést jelent. Ezek a rendszerek jól megfogják az ismétlődő, kreditálható szabályok szerinti eseményeket. Ez az alapszint, amit biztosítanunk kell biztonság terén.
Azonban, a rendszer növekedése során ezek nagyon nehezen skálázhatóak. Sok cégnek okoz szenvedést, hogy embereket találjon, akik képesek ezeket a rendszereket karban tartani, képesek ezeket a mintákat megalkotni. Márpedig ezekkel folyamatosan foglalkozni kell, a használt szoftverek új változatai jönnek ki, új szoftverek is megjelennek, amiket be kell vezetni, stb. Újfajta szabályozások tűnnek fel, amelyek megkövetelik, hogy ugyanilyen riasztásokat rakjunk új rendszerekbe.
Mindemellett, ezek az IT rendszerek túlságosan összetetté válnak ahhoz, hogy a fenti feladatok teljes körűen és megfelelő minőségben megoldhatók legyenek. Tíz rendszer esetén még át lehet látni, hogy melyiknél milyen minta jelzi a támadó viselkedését, de ötven, vagy száz rendszer esetén a közöttük lévő között bonyolult összefüggések miatt ez nehezen kezelhető.
A BalaBit ezekre a gondokra két megoldást talált. Egyrészt, összpontosítsunk arra az elemre az egész rendszerben, ami mindig ott lesz, s ami az egész rendszer értelmét jelenti; ez maga a felhasználó személy, másrészt arra az entitásra, aki a támadások 60%-a mögött megtalálható, akinek a viselkedése sokkal jobban átlátható, előre vetíthető, mint egy informatikai rendszeré. Az emberi viselkedést évezredek óta tanulmányozzuk, nagyon sok esetben jól jellemezhető, jól vizsgálható. Legalábbis sokkal jobban, mint egy szoftveré.
A másik megoldás lehetőség; az előre meghatározott minták helyett használjuk mindazt az algoritmus-halmazt, amit az elmúlt évtizedek alatt informatikai területen kidolgoztak, s aminek mostanra hatalmas bővülését figyelhetjük meg (BigData, stb.). A gépi tanulás a megoldás; automatikus algoritmusokat használva fedezzük fel a szabályszerűségeket, s ennek alapján végzünk biztonsági elemzést.
A magatartás-elemzés nagy fejlődést hoz az IT biztonság területén. Maguk a felhasználók nagy változatosságot mutatnak kinézetre, s az informatikai rendszerekben is más-más módon dolgoznak, más rendszereket használnak, különböző mennyiségű e-mailt küldenek, különböző sebességgel gépelnek, máshonnan jelentkeznek be, más időpontban, más időzónában dolgoznak. Összességben; a rendszerekben digitális lábnyomokat hagynak, melyek megjelennek a logokban, a különböző rendszerek adatbázisaiban, s kontroll eszközeink audit trail-jeiben. (http://en.wikipedia.org/wiki/Audit_trail )
Ezek a digitális lenyomatok ugyanolyan jellemzőek lehetnek egy-egy személyre, mint fizikai ujjlenyomata.
Az algoritmusok kellő körültekintéssel való alkalmazásával, ha kellő mennyiségű információ áll rendelkezésre, akkor a felhasználókról nagyon jó profil építhető, s meg tudjuk vizsgálni, hogy újabb cselekedetei hogyan viszonyulnak ehhez a mintahalmazhoz.
A megoldás alapötlete, a kulcs az ember; a felhasználót kockázati szempontok, szokásos aktivitások szerint elemezzük, s el tudjuk helyezni egy un. szokatlansági skálán. Egy kis kockázatú, mindennapi azonos tevékenységét végző személy biztonsági kockázatai nem jelentősek, nem is akarunk vele sokat foglalkozni. Egy nagy kockázatú személy, pl. egy rendszergazda tevékenysége már akkor is érdemes lehet a figyelemre, ha mindennapos munkáját végzi, érdemes eltárolni, rögzíteni. Amennyiben egy kis kockázatú felhasználó valami nagyon szokatlant csinál, arra is érdemes odafigyelni.
Igazán figyelmet az érdemel, amikor egy nagy kockázatú felhasználó valami nagyon szokatlan dolgot csinál.
Pl. a rendszergazda tőle szokatlan időpontban lép be, vagy a vezérigazgató belépést kezdeményez a szerverre (mert egyébként van jogosultsága rá), de nem szokott ilyet csinálni. Vagy; egy értékesítési vezető ezrével kezdi letölteni az eladási adatokat a rendszerről.
Ilyen adatokból fel tudjuk építeni az események priorizált listáját, és súlyozhatjuk, hogy mi az amire kiemelten kell figyelni, mi az, ami potenciálisan a legnagyobb kockázatot jelenti rendszerünk integritása és biztonsága szempontjából.
A konkrét megvalósításnál nincs szükség fantasztikus, új algoritmusok kigondolására, elegendő, ha az évtizedek óta létező, kipróbált algoritmusokat használjuk. Ilyeneket használnak pl. a boltok ajánló rendszereikre, mint az Amazon könyvajánlója. Vagy az a figyelő, amit bankkártya cég alkalmaz, szokatlan felhasználói viselkedésre, időtől, távolságtól elrugaszkodó tranzakciók esetén. Ezek a magatartás-elemző algoritmusok ipari területen nagyon régóta alkalmazásban vannak, őket kell biztonságtechnikai területre átültetni.
Nem létezik egyetlen, mindent tudó algoritmus, de van többféle, melyek többféle szempontból nézik az adatokat, s ezek eredményét összegezve fel tudjuk ismerni a figyelemre méltó dolgokat.
A BalaBit-nél ezen megoldások folyamatos fejlesztése, finomítása zajlik. A legegyszerűbb, s egyik legjobb hatásfokú közülük, amelynél időrend szerinti eloszlásokat nézünk. Pl. egy bizonyos felhasználó az adott tevékenységet mikor szokta csinálni, vagy egy adott cégnél mikor szoktak dolgozni, s az ehhez képest mutatkozó, pl. időbeli eltérés már figyelmet érdemel.
Másik lehetséges megoldás az időeloszlások szerinti, automatizált mintakeresés, amelyet ajánlórendszerek és szöveganalízis bevetésével alkalmazhatunk. Pl. egy-egy port szokatlan, fenyegetésre utaló minta szerinti használatakor riaszthat. A kereskedelem régóta használ hasonló, automatizált mintakereséseket; egy-két termék vásárlásakor felismerhető, milyen étel készül, s mi a még szükséges kiegészítő. Erre alapozva csomagok, akciók, ajánlások fogalmazhatók meg.
A felismert szokatlan IT viselkedés alapján pl. riasztást adhatunk, vagy kiszólhatunk a jelszót sokadszor elrontónak, hogy azonosítsuk, jogosultsága szerint tevékenykedik-e. Egy nagyon kockázatos eseményre a kontrollok újabb szintjét kapcsolhatjuk be, pl. egy sokkal részletesebb naplózást, de egy kevéssé kockázatosra csak a logokat gyűjtjük.
A háttér-biztonsági intelligencia (Contextual Security Intelligence) vizsgálatának tárgya tehát a viselkedés-elemzés, benne a naplózás, a PAM (Pluggable Authentication Module), a háttéradatok, a SIEM (security and event management), és a hozzáférés-vezérlés.
http://en.wikipedia.org/wiki/Pluggable_authentication_module
http://en.wikipedia.org/wiki/Security_information_and_event_management
A BalaBit vonatkozó eCSI termékvonala:
Blindspotter: 2014-ben bejelentett tevékenység-, és viselkedés-elemző, ellenőrző eszköz, valósidejű dashboardokkal, priorizált listákkal a környezet megmutatására, automatikus reakcióval, s az érzékeny adatok védelmével
A Syslog-ng naplókezelő rendszer: az információ forrása, begyűjti az üzeneteket, nagyon sokféle rendszerből, adatforrásból, megbízható módon és kiemelkedő teljesítménnyel naplóz
A Shell Control Box sokkal mélyrehatóbb infókat tud gyűjteni; ez kiemelt felhasználókat kontrolláló monitor eszköz, független adatforrás, részletes felvétellel, kontrollponttal. Itt tudjuk kontrollálni, hogy valaki milyen gyorsan gépel, milyen a képernyő felbontása, milyen alkalmazásokat futtatott, stb. A kontrollponttal a veszélyes kapcsolatot meg is tudjuk szakítani.
Dr. Ormós Zoltán, az informatikai joggal foglalkozó Ormós Ügyvédi Iroda vezetője a cloud szolgáltatások jogi vonatkozásairól szólt.
A jogi vonatkozások vizsgálatakor is az adatok, az infrastruktúra előírások, az IT biztonság és az adatvédelem játsszák a főszerepet. Az iroda tevékenységének indításakor, a '90-es évek végén alapkérdés volt; szükség van-e egyáltalán a tárgyat érintő jogszabályokra, ill. kell-e valamiféle szerződés informatikai szoftver, hardver a vásárláskor? A következő időszakban, a kétezres évek elején, az outsourcing felfutásakor, a nagyobb szoftver-licenc szerződések már a magyar jog alapján zajlottak. Jelenleg a különböző, felhő-szerződések jelentik az informatikai érintettséget. Az iroda ezek elemzésével, és adatvédelemmel, a személyes adatokkal kapcsolatos, megkülönböztetett jogi szabályozással is foglalkozik. Az adatvédelem a személyes adatok megkülönböztetett kezelési rendje, annak jogi előírásai.
Amikor egy cloud-szerződést kap kézhez egy jogász, akkor először a joghatóság kérdését kell megvizsgálnia;
mely ország joga alá tartozik a szerződés, pl. az amerikai jog Amerikán belül államonként változik.
Magyar jogász ilyenkor általában csak tanácsadóként működhet közre, nem jogtanácsosi minőségben.
Az angolszász jogi kifejezések értelmezése erősen eltér más jogrendszerek értelmezésétől. A kötbér pl. más-más értelmezésű az angolszász és a magyar jogban, ez a jogintézmények problémaköre.
A peresíthetőség költség szempontjából is nagyon fontos, pl. egy külföldi jog alá tartozó cloud szerződés különleges költségszintet, különleges jogérvényesítést, stb. jelent. Egy angol ügyvédi irodánál pl. eleve egy adott összeget le kell tenni, abból vonódnak le az eljárási költségek, egy magyar ügyvédnél az első beszélgetés ingyenes…
A perek költségszintje is egészen más, lehet, hogy gyorsabban zajlanak és szakmailag megalapozottabbak, de a peresíthetőség költségei nagyon eltérnek a hazai gyakorlattól.
Amennyiben egy szolgáltató akar cloud szerződést létrehozni, akár le is másolhat egy interneten fellelhető változatot, sokan ezt csinálják. Nem mindegy azonban, milyen jogot írunk a szerződésbe, ajánlatos, hogy egy magyar szolgáltató a magyar joghatóság alól lehetőleg ne mozduljon ki, bár az EU nagyon sok mindent biztonságosan meghatároz a jogharmonizáció eszközeivel. A környező országokból való kliensek szerződéskor ódzkodnak a magyar jog alá tartozástól…(amikor NOD32-t használtunk a román jog alá tartozunk) de a joghatóság lehet magyar, s ez nem nagyon fog kiderülni. Alkalmas változat lehet a svájci, vagy osztrák jog, ami eléggé hasonlít a magyarhoz ahhoz, hogy barátságosan fogadják, s a perköltségek sem olyan magasak, mint az angolszász jogban. Angolszász jogterületen három nagy tapasztalatú joghatóság ajánlható; New York állam joga, a kaliforniai jog és England-Wels joga, ezek nagy esetjogi tapasztalattal bírnak IT-jogi ügyekben.
Sok szolgáltató használja az ÁSZF-et (Általános Szerződési Feltételek), mindenki fogadott már el ilyet, pl. amikor bankjával, hírközlési szolgáltatójával szerződött. Új Ptk. (Polgári Törvénykönyv) lépett életbe 2014.márc.14-től.
Nagy jelentőséggel bír a kötbér; a velünk szerződő fél minden velünk szemben teljesítendő kötelezettségét kötbérezzük! Ha nem kötbérezünk, akkor nem áll fenn „a főkötelezettség teljesítését kikényszerítő, vagy elősegítő mellék-kötelezettség" (a kötbér definíciója latinból). A kötbér kikötése jó lehetőség ad rá, hogy rászorítsunk valakit valaminek a teljesítésére. Ezek után a kárt sem kell bizonyítanunk pl., ha (késedelmi kötbér esetén) a fél késett két napot, s nekünk van 60 ezer Ft plusz kiadásunk, ilyenkor a szerződésben meghatározott napi összeg, pl. 50 ezer Ft, automatikusan jár nekünk. A kötbér mértékére a szerződésben bármekkora összeg meghatározható, s ha még túlzott mértékűnek tűnik is egy adott esetre, akkor sem lehet érvénytelen! A túlzott mértékű kötbért a bíróság mérsékelheti, de minél nagyobb a szerződött érték, annál nagyobb a visszatartó erő. Nem kell Ft-ra bizonyítgatnunk a károkat. Kötbért hibás, késedelmes és elmaradt teljesítésre lehet előírni.
A kártérítési felelősség vonatkozásában, a korábbi Ptk.-ban a 3.14-es szakasz második bekezdése szerint, csak meghatározott feltételek mellett lehetett kártérítési felelősséget csökkenteni, az új Ptk. alapján már gond nélkül beírható a szerződésbe, hogy 0 Ft. kártérítés, vagy az utóbbi egy év díjainak megfelelő kártérítés jár.
A szerződésszegésből fakadó igények elévülési ideje eddig betonba volt öntve, ez most változott az új Ptk.-ban,
beírható pl., hogy a szerződés megszűnésétől, vagy az igény elévülési idejétől számított 1 év után egyik szerződő fél sem léphet fel követeléssel. Tehát a korábbi 5 évről le lehet vinni 1 évre az elévülési időket.
Aki szolgáltat, annak számára a fő szempont: mindent korlátozni! A kártérítési felelősséget, a kötbéreket, sőt agregát maximumokat is be lehet építeni, elő lehet írni pl., hogy a szerződésszegésből fakadó össze kötbérem összeadva nem lehet több egy adott összegnél.
Cloudnál is beszélünk ÁSZF-ről. Fontos; ha jogszabálytól, vagy szokásos piaci gyakorlattól vagy a felek között kialakult korábbi szerződéses feltételtől eltér egy általános szerződési feltétel, pl.
ISAC-ben akarom levinni a szokásos elévülési időt 5 évről 1 évre, vagy
az első kategóriás használati szint ingyenességét akarom korlátozni, s rögtön, vagy fél év után pénzt akarok kérni,
vagy módosítom az ISAC-et.
Ilyen esetben külön tájékoztatást kell adnom az ügyfélnek, s külön, kifejezett elfogadást kell kérnem tőle.
Egy netes szerződés esetén pl. külön jelölő-négyzet van erre, külön sor az elévülési időről, vagy arról, hogy egy hónap után fizettetni akarok a szolgáltatásért, vagy módosult valami a szerződésben, ezt egy-egy külön jelölőnégyzetben el kell fogadtatni. Sajnos, általában sem a szolgáltató nem ismeri, nem alkalmazza ezt a szabályt,
sem a szolgáltatást igénybe vevő nem tudja, hogy vannak ilyen kötelezettségek. Pedig érvelhetne, hogy rá ez a szakasz nem érvényes, mert nem lett vele elfogadtatva. A jogi területen való teljes tájékozatlanság miatt bármit meg lehet most csinálni, de arra a felhasználóra, aki ismeri ezeket, arra ezek nem lesznek érvényesek!
A külön jelölő-négyzet követelménye a cégeknek szolgáltató B2B szolgáltatókra is vonatkozik.
A fogyasztóknak IT-t, vagy egyéb, netről elérhető szolgáltatást nyújtókra külön szabályok érvényesek. Pl., ha a főszolgáltatás ellenértékén, azaz az alapszolgáltatáson és annak a díján túl további pénzbeli követelései vannak a fogyasztó felé, az külön tájékoztatást, külön elfogadást igényel. Mindent külön-külön el kell fogadtatni jelölő négyzettel.
A tisztességtelen kikötések semmisek. Új szabály: ha a fogyasztói szerződésben szándékosan, vagy felületességből homályosan fogalmaztam, az tisztességtelennek minősül és semmisnek tekintendő. Tehát, ha valami nem egyértelműen van megfogalmazva, akkor időkorlát nélkül bárki hivatkozhat a kikötés semmisségére, s a szolgáltató kényszerül a bíróságon a kikötés érvényességét bizonyítani, annak homályosságát cáfolni, érvényességét állítani.
Célszerű a hosszú szerződéseket a megértés érdekében kivonatolni, de a kivonat nem helyettesítheti a szerződést.
A trend megfordult; outsourcing esetén eddig a szolgáltatók auditálták, mérték fel a megrendelő kapacitásait, hátterét, infrastruktúráját, stb., de a cloudnál a cloudosok megmondják; ezt kínálom, nézd végig, hogy ez neked megfelel-e. A cloud vizsgálatakor a megrendelő nézze meg a szolgáltatási szerződés feltételeit is, mert nagyon sok trükk van oda eldugva. Pl.; hiába kínál valaki 4-kilences rendelkezésre-állást, mégis, a 19 percnél rövidebb leállások ebbe nem számítanak bele, ez már csak a szerződésben van benne. Pl., ha egymás után 6×19 percig áll egy ÁFA-bevallási határnapon a pénzügy rendszere, de a 99,99-et a szolgáltató hozta, mert csak hatszor állt le 18 percre aznap, ez azt jelenti, hogy a szolgáltató nem vállal igazi felelősséget, igazi rendelkezésre állást…
Adatvédelmi szempontból is az EU-t kell preferálni, nagy multiknál sokszor előírás is, hogy az EU-n belül kell maradni.
Példák cloud szerződésből:
Csak a meghatározott mértékű leállás számít leállásnak (downtime), s nem mindegy, hogy milyen (munka-)idősávra (amerikai, nyugati parti, keleti parti, közép-amerikai, európai, stb.) vonatkozik. Nekünk a közép-európai idősávra kell a 4-kilences rendelkezésre-állás.
Minimum 10 perces leállás a leállás
Tervezett leállás nem számít
Fontos; főszerepben az adatok:
Minden adat (szellemi tulajdon) a megrendelőé, a szolgáltató csak a szerződés alapján dolgozhatja fel.
Az adat-hozzáférés a szerződés teljes fennállása alatt, folyamatosan garantált legyen, pl. egy elfelejtett havirészlet-befizetés, vagy szolgáltatási díj befizetés, vagy a szolgáltatóval való vita esetén se tagadja meg a hozzáférést valamely adatkörhöz, vagy annak egészéhez. Érdemes erre nagyon erős kötbért is beépíteni.
Különböző semleges helyeken legyenek back-up-ok (a szabvány szerinti telepítés ezt hozza magával).
Szerződés megszűnésekor teljes körű adatmegsemmisítés legyen a szolgáltatónál, akár törvényben minősített, előírt szoftverek, módszerek használatával, a teljes cloud-láncon (szervereken), az alvállalkozóknál is!
Illetéktelen hozzáférések kezelése; azonnal jelenteni a megrendelőnek, a megtett intézkedésekkel együtt! Erre kötbért, vagy valamilyen kártérítést is ki lehet kötni. EU rendelet készül ennek teljeskörű szabályozásáról.
Az adattárolás helyét a szolgáltatónak meg kell adnia (amerikai gyakorlat: cont.USA),
Meg kell adni, hogy a hivatalos megkeresésekre hogyan reagál a szolgáltató. (Mindent kiad …)
Infrastruktúra, IT-biztonság:
A lehető legjobban körülírt infrastruktúra és módszerek (tűzfal, folyamatos működés garanciái, titkosítás, fizikai biztonság)
Audit jog (elismert auditáló cégeken keresztül, vagy leírások tanulmányozása által), ill. tanúsítványok (ISO 27001-nem túl erős)
Audit minimális terjedelme: buffer túlcsordulás ellenőrzése, nyitott portok, szükségtelen szolgáltatások, felhasználói input szűrés, cross site scripting sérülékenység, SQL sérülékenység, stb.
Adatvédelem:
Többszintű adatfeldolgozói rendszer
Safe Harbour: az USA és az EU közötti szerződés, csak a személyes adatokra vonatkozik, az amerikai szolgáltatók európai működését támogatja, a kétféle erősségű rendszer közelítésére, az EU országból kiinduló adatok kezelésére. Ezek az un. „biztonságos kikötők" megfelelnek az USA szabályzásnak.
DG Infosec: egységes EU adatvédelmi szabályok
Adatkezelő: aki az adatgazdától közvetlen felhatalmazással bír, a neki segítő technikai szolgálat az adatfeldolgozó.
Faragó János, az Andrews IT Engineering Kft. vezető tanácsadója a közüzemi számlázás vonatkozó IT kérdéseiről tartotta előadását, Közüzemi számlázás, avagy a zártság dilemmái címmel.
A törvényi háttér:
Közüzemi törvények:
2003.évi C. törvény az elektronikus hírközlésről
2007. évi LXXXVI. törvény a villamos energiáról
2008. évi XL. Törvény a földgázellátásról
2011. évi CCIX. Törvény a víziközmű-szolgáltatásról
2014. 10. …a számlázási rendszer az információbiztonság megfeleltetéséről…az állami és önkormányzati szervek elektronikus információbiztonságáról szóló törvénynek megfelelően és módon köteles gondoskodni.
A módszertan
2013. évi L. trv. az állami és önkormányzati szervek elektronikus információ-biztonságáról
77/2013. (XII. 19.) NFM rendelet
Egyedi számlázó szoftverek esetén a vizsgálatnak ki kell terjednie a számlázó szoftver forráskód-szintű elemzésére,
kivétel: meglévő terméktanúsítvány esetén, vagy ha szerepel nyilvános, nemzetközi sérülékenységi adatbázisokban.
A törvény hatóköre:
A számlázási rendszer (nem szoftver): a szoftver és a környezet együttese, a számlázási folyamathoz szükséges összes releváns bemeneti adatot kezelő rendszerelem, a díjak hibátlan kiszámítását végző rendszerelemek,
a számlázó szoftver-termék (konkrét beállításainak, telepítésének és üzemeltetésének ellenőrzése)
A környezeten csak azokat az informatikai elemeket értjük, amelyek a számlák közvetlen kiállításában résztvesznek, a számlák kiállításához közvetlenül nem tartozó rendszerelemek nem esnek a tanúsítás hatáskörébe.
ITS követelmények
„Általános információbiztonsági" zártság
A jogosulatlan hozzáférés és az észrevétlen módosítás kezelése, az informatikai zártság biztosítása (fizikai intézkedések, adminisztratív intézkedések, logikai intézkedések). Ezek feladata; biztosítani a bizalmasságot, sértetlenséget és a rendelkezésre állást.
A határidő
2015. január 1-től: a szabályozott feltételeknek meg nem felelő számlázási rendszerből kiállított számla érvénytelen.
Példák a felkészülési időre:
Az államigazgatásban: 0-ról 1. szintre (1 év); 1.-ről 2. szintre (+2 év); 2.-ról 3. szintre (+2 év) = 0-ról 3. szintre (5 év)
Az önkormányzatoknak legalább a kettes szintet el kell érniük.
A közmű szektorban: > 2 szint (3 hónap)
Felkészülés a 0-3 szintre: minimum 6 hónap
A tanúsítás további, minimálisan 2 hónapot jelent (forráskód szintű elemzés esetén: minimum 3 hónap)
A versenypiacban nincs szint megadva.
A besorolást megadó szervezet, hatóság (?) még nincs meghatározva, a megoldás lehet önbesorolás, vagy tanúsítói döntés is. Nincs még eldöntve a jelenlegi, kezdő szint mértéke sem.
A távközlésre vonatkozó anyagrészben a zártság témaköre a tételes számlamelléklet pontnál került tárgyalásra.
Meghatározandó még, hogy a rendelkezés csak a forgalmi díjas, vagy a fix havi díjas szolgáltatásokra is vonatkozik (pl.: internet), a törvény szövegezése jelenleg ebben nem ad útmutatást.
A szervezeten kívüli rendszerelemek is kérdésesek, pl. erőművek, elosztók, kereskedők idevágó helyzete hogyan alakul. Alapjában nem tartoznak a rendelet hatálya alá, de tk. oda kéne tartozniuk.
Meg van határozva, hogy kinek kell megszerezni ezt a tanúsítást, de tudnivaló, hogy sok cég nem maga végez minden tevékenységet, pl. a kábel-szektorban a számlázás alapját adó mérést nem az adott szervezet végzi. Ők tk. viszonteladók, s a valóságos szolgáltatást végző cégtől megkapják a mért adatokat, ezek alapján végzik a számlázást, ők maguk nem mérnek. A számladíj helyes kiszámításának egyik alapja a bemeneti adatok milyensége.
Az egyedi számlázó szoftverek esetében az egyedi fogalmát még definiálni kellene, hiszen alapjában, minden szoftver egyedi. Meghatározandó, mitől nem egyedi egy szoftver.
Amennyiben forráskód szintű vizsgálatot kellene végezni, kérdés, hogy a forráskódot honnan szerzi meg a cég.
Egy nagyobb rendszertől, amelynek pl. Németországban van a székhelye, s jó néhány közüzemnél ő a számlavezető rendszer, a forráskód megszerzése irreális elképzelés. Kisebb cégeknél is problémás, csak ha saját maguk fejlesztették, akkor járható.
A megfelelőség sajátosságai
Egy adott szervezet számlázási szoftvere van a középpontban. A fent említett fizikai intézkedéseket a szervezetnek magának kell kialakítania, végrehajtania. A számlázó szoftver ehhez nem tesz hozzá semmit.
Az adminisztratív védelmi intézkedések 43 főcsoportra oszlanak. Vannak olyan intézkedések, amelyek a szervezetre és a számlázó szoftverre egyaránt vonatkoznak, olyanok, amelyeket a szervezetnek bele kell építenie valamelyik biztonsági intézkedésébe.
A logikai védelmi intézkedések közül 38 a számlázó szoftverre vonatkozik, 48 pedig a szervezetre, közöttük vannak átfedő intézkedések is.
Összegezve; a korábbi, 77/2013 számú rendelkezés termékirányítási rendszerről szól, az ISO/IEC 27001 pedig irányítási rendszerről. Az új változat a rendszerek biztonságának növelése felé mutat.
Harmat Lajos
