A Hétpecsét Információbiztonsági Egyesület a fenti témakörben tartotta ötvenhetedik szakmai fórumát 2013. szeptember 18-án.

A Hétpecsét Információbiztonsági Egyesület a fenti témakörben tartotta ötvenhetedik szakmai fórumát 2013. szeptember 18-án.


Tarján Gábor alelnök bevezetőjében felvázolta a 2001. óta „értékteremtő munkacsoport" formájában működő egyesület érdeklődési területét. A kezdeményezés indítói magánszemélyek és néhány cég, mint a MagiCom,  és a Szenzor voltak. Az adott időben jelent meg az információ biztonság témakörével foglalkozó, BS7799 jelzésű  szabvány, a munkacsoport első feladatának tekintette ezen szabvány lefordítását, s a területet lefedő oktatási anyagok létrehozását. Ezen előzmények után alakult meg 2004-ben a Hétpecsét egyesület az információs társadalom biztonságának támogatására, az információvédelmi kultúra fejlesztésére, az időközben ISO 27001 jelzetűvé vált szabvány további terjesztésére. Az egyesület tanúsítási helyzetkép felmérést is végzett az ISMS (Information Security Management System – Információbiztonsági Irányítási Rendszerek) elterjedtsége, tanúsítottsága vonatkozásában, a 2010-ig terjedő időszakra.   

Minden évben öt szakmai fórumot tartanak az általánosítható tapasztalatok megosztására.  

Az egyesület három díjat alapított, s ítél oda évenként, ezek;   

Az Év Információbiztonsági Újságírója – minden év májusában kerül átadásra

Az Év Információbiztonsági Szakdolgozata – átadása szeptemberben

Az Év Információbiztonsági Diplomadolgozata – átadása szeptemberben

 

A szakmát érintő friss hírek közé tartozik, hogy 2013. szeptember 15-én lezárult a nemzetközi szabványosítási testületen belül a szavazás két szabvány-tervezettel, az FDIS-ekkel (Final Draft International Standard) kapcsolatban. Innentől már csak egy lépés a valódi szabványhoz való eljutás, a mostani elfogadás után ezek hamarosan bevezetésre is kerülnek, s felülírják a nemzeti szabványok forrás-szabványait is. A megjelenés 2013. novemberében lesz, a magyar változathoz szponzor-cégeket és fordítókat vár az egyesület. A továbbiakban ezen,

27001-es szabvány alapján lehet majd minősítést szerezni. Az ISO 27002-es pedig a gyakorlati kódexet, iránymutatást jelenti. Az ISO 27000 Magyarországon magyarul még nem jelent meg, ez tulajdonképpen a szakszótárat és az egész rendszer körülírását tartalmazza. A tavalyi megjelenés után jelenleg ez átírás alatt van, jövő tavasszal várható újabb megjelenése.  

 

Hargitai Zsolt, a NetIQ Novell SUSE Magyarország üzletfejlesztési igazgatója az identity management aktuális kérdéseiről, a mobil eszközökön és a felhőben való szerepéről szólt előadásában.  

Cégéről a vezető elmondta, az átszervezés után a korábban önálló NetIQ-s és Novell-es biztonsági portfolió képviselője egységesen a NetIQ lett.

A Novell mintegy tíz évvel ezelőtt úttörő módon kezdett foglalkozni Magyarországon az identity management kérdésével. A témakör lényege; az alkalmazottak életciklusának, jogosultságainak felügyelete, kezelése.  

Idő múltán ez a terület kibővült, megfogalmazása, értelmezése is változott Magyarországon.  

Ma a legtöbb projekt a jogosultságok igénylésével, jóváhagyásával, nyilvántartásával indul, az un. Identity Escess Government megnevezés a klasszikus anyagokban ezt fedi. Vagyis, van egyfajta, a szabványoknak megfelelő előírás, hogy legyen nyilvántartásunk, hogy kinek, mihez legyen jogosultsága, ezt mikor és ki hagyta jóvá, stb.  

Optimális esetben ezeket a jogosultságokat rendszeresen felülvizsgálják, újraminősítik, de a tapasztalatok azt mutatják, idehaza a rendszeres felülvizsgálat, a folyamatok újraminősítése kevéssé működik.  

Az igényelt hozzáférési jogok hozzáférést nyernek a kapcsolódó rendszerben, a rendszerek egy részében automatikusan történik ez a beállítás (un. provisioning folyamattal), ill. a megindult munkafolyamat során az informatikusok kézzel, vagy egyéb eszközökkel állítják be.   

 

Viszonylag új irányzat az, amikor a fentieket megpróbáljuk integrálni a log-menedzsmenttel, a security menedzsment megoldásokkal, s ellenőrizzük is, hogy mi történik ezekkel a jogosultságokkal. Monitorozni tudjuk, hogy ezeket a jogosultsági beállításokat használják-e, s hogyan a felhasználók, használnak-e olyan eléréseket, amelyekre nem volt hozzáférés jóváhagyás, s valamilyen egyéb módon került beállításra. Technológiailag ezt úgy tudjuk megoldani, hogy ezeket a személyazonossági információkat log-menedzsment rendszerbe integráljuk s a log-megoldás számára egyfajta intelligenciát adunk azért, hogy a benne tárolt adatokról azt is tudatosítsuk, azok kihez tartoznak, az egyes rendszerekben különböző néven szereplő felhasználó tevékenysége hogyan kötődik az  

illetőhöz.

Mindez egyfajta activity integration fogalommal írható le, az alkalmazást, az aktivitást lehet monitorozni és bizonyos integrációt lehet eszközölni a rendszerek között. Tipikus lekérdezések végezhetők, pl., hogy egy felhasználó milyen rendszerekben azonosította magát, azokban a rendszerekben milyen tevékenységet végzett, milyen jogosultság- változások köthetők hozzá. Ily módon nagyon erős kontroll hozható létre az Identity Management fölött. Alapvetően ez a kontroll évente, félévente elvégzendő, de a leírt módon erre még rásegíthetünk. Az ilyesfajta kontroll előnye, hogy nincs szükség az üzleti vezetők bevonására.

 

A terület további újdonsága az informatika változásaihoz köthető. Változott az ügyfelek elvárása, változtak az üzleti igények, változott emiatt az informatikai biztonság, s az Identity Management rendszerek is változnak.  

A legfontosabb trendek; a felhőben tárolt, vagy használt alkalmazások, mobil eszközök, a távoli hozzáférés kezelése, a saját és a vállalati mobil eszközök használata.  

A rendszerhasználat módja, a tárolt rendszerek helye jelentősen változott az elmúlt időszakban. A szolgáltatások, az elérések, s a személyazonossági tárolási mechanizmusok is kiléptek a korábbi zárt világból. Nem csak a vállalaton belül vannak szolgáltatásaink, egy részük kikerül a felhőbe, ezeket valahogy el kell érni. Maga az elérés helye is kikerült az informatikai rendszerekből, hisz mobil eszközökről a világ bármely pontjáról el tudjuk érni a szóbanforgó eszközöket. Külső személyazonossági nyilvántartásokat (identity store) is használunk, pl. közösségi hálózatokat, közösségi rendszereket, s az ezekben tárolt személyazonossági információkat is megpróbáljuk bevonni az informatikába. Mindez jelentősen megváltoztatja az identity management világát.   

 

Hogyan lehet mindezt kezelni, biztonságosan integrálni az informatikai rendszerbe? Felhő alapú rendszereknél tipikus kihívást jelent pl., hogy van valahol egy alkalmazásunk, mondjuk, ami egy magyar internet szolgáltatónál fut. Alkalmazottaink (egy része) szeretné elérni ezt a rendszert. Ott azonosítania kell magát, hozzá kell férnie ezekhez az alkalmazásokhoz. Ezt az egész folyamatot kell biztonságossá tennünk.  

Hogyan kezeljük a felhasználói fiókokat, hogyan hozzunk létre újakat, hogyan szüntessük meg a használaton kívülit, vagy már jogosulatlant? Hogyan kezeljük biztonságosan a jelszavakat? A vállalati rendszereknél be tudunk állítani irányelveket, hogy lejárjon egy idő után a jelszó, adott hosszúságú legyen, tartalmazzon bizonyos karaktereket, stb. A felhőben ezeket elég nehezen tudjuk kezelni, a szolgáltatóval esetleg be tudjuk állíttatni, de a kezelés nem a mi kezünkben van. Nehezen tudjuk monitorozni a történéseket, a szolgáltatótól kérhetünk riportokat, de ez nem azonos értékű.    

 

Ezen gondok optimális megoldása, ha az interneten működő felhő alapú szolgáltatást valamifajta felhő-hozzáférési rendszeren keresztül tesszük elérhetővé, függetlenül attól, hogy belső vagy külső felhasználóról van-e szó. Valamilyen módon kikényszerítjük, hogy az illető felhő alapú szolgáltatások elérése azon a felhő alapú eszközön keresztül történjen, amelyet beillesztünk a vállalati hálózat és a felhő alapú alkalmazás közé. Ily módon megoldódik a monitorozás kérdése is, s a többi kihívásra is felelhetünk. Ellenőrizhetjük, naplózhatjuk, hogy ki használja az illető alkalmazást, s milyen módon. Riportokat, riasztásokat adhatunk hozzá.  

 

A külső felhasználót hogyan késztetjük a kívánt útra? A közbülső eszközzel ki tudjuk kényszeríteni, hogy a felhőben levő alkalmazás olyan jelszóval legyen elérhető, amelyet az alkalmazott nem is ismer. Ennél a bizonyos beiktatott központi eszköznél  kell azonosítania magát a vállalat azonosítási módszerével, pl. egy active directory jelszóval, felhasználói azonosítóval. Léteznek olyan szabványok, pl. a SAM, melyek segítségével a két rendszert össze lehet hitelesíteni, s ha a felhasználó pl. a helyi active directoty-ban azonosította magát, akkor ugyanazon azonosítójával, egypontos bejelentkezésen keresztül tudja magát azonosítani a felhő alapú alkalmazásba. Ezzel az egypontos bejelentkezés, a jelszó-menedzsment, ill. a felhasználói fiókok problémáját is meg tudjuk oldani.  

A felhasználói fiókok létrehozására és menedzselésére két módszer jöhet számításba; az illető eszközbe beteszünk egy szinkronizációs mechanizmust, amelynek segítségével egy identity manager motor automatikusan létrehozza, vagy törli a felhasználói azonosítót, ez a módszer szigorú kontrollt biztosít a terület fölött. A másik megoldás alapja; a szabványok lehetővé teszik, hogy egy autentikált felhasználót automatikusan bebocsássunk a szolgáltatásba. 

Ezzel a felhő alapú rendszerek kezelése nagyon egyszerűen megoldható.  

A közösségi hálózatok identity provider, ill. címtár módjára felhasználhatók informatikai rendszereinkben. Ebben az esetben arról van szó, hogy külső címtárat akarunk felhasználni arra, hogy a felhasználók elérhessék szolgáltatásainkat. A piacon léteznek technológiák, melyekkel az általunk biztosított webes szolgáltatásokat a közösségi hálózatokon létező profilokkal érhetik a felhasználók. Ily módon több felhasználó veheti igénybe szolgáltatásainkat, még inkább felhasználó-barát lesz internetes portálunk, webáruházunk. Sok felhasználót elriaszt a regisztráció, de ha engedjük neki, hogy közösségi autentikációt végezzen, akkor a közösségi azonosítójával ezt megteheti, az ő jelszavát nekünk nem kell tárolni, a kényelme pedig biztosított.  

 

A mobil felhasználókkal kapcsolatosan felmerülő tipikus problémákat a személyazonosság viszonylatában is orvosolni kell. A mobil eszközöket célszerű valamilyen eszköz-menedzsment programmal biztonságosabbá tenni, erre valók a mobil device management eszközök.  

A céges alkalmazások mobil eszközről való biztonságos elérésére és kezeléssére is léteznek technológiák, amelyekkel személyre-szabottan, a felhasználók csoport-tagságához, jogosultságához, hozzáférési információjához rendelhetünk hozzá alkalmazást. Az eszközökön egy kis mobil alkalmazás segítségével a felhasználó számára képernyőn elérhetővé tesszük a különböző vállalati alkalmazásokat, testre szabottan, irányelvek alapján. Felhasználói azonosítókhoz rendeljük hozzá azokat az alkalmazásokat, amelyekre a felhasználóknak szükségük van és használhatnak. Biztonságos, pl. tanúsítvány alapú autentikációval bármely alkalmazás egy kattintással elérhető titkosított csatornán, nem kell jelszavakat tárolni a mobil eszközön, s adatokból is csak minimális mennyiséget.   

 

Dr. Muha Lajos főiskolai tanár (Nemzeti Közszolgálati Egyetem) az elektronikus információ-szabadságról szóló törvény megalkotásának jelenlegi helyzetéről adott áttekintést.    

Móritz Pál, a Szenzor Gazdaságmérnöki Kft. ügyvezető igazgatója az ISO /IEC TR 27015:2012 szabványról szólt, amely információbiztonság menedzsment útmutatóként szolgál (Information Security Management Guideline) a pénzügyi szervezeteknek a pénzügyi szolgáltatásokra, azaz, a pénzkezelési, befektetési, átviteli és kölcsönzési szolgáltatásokra.  

A szabvány viszonylag rövid, 20 oldalnyi. Útmutatóként abból indul ki, hogy létezik egy követelmény szabvány, az ISO/IEC  27001-es, ami az információbiztonsági követelmények szabványa. Ez megmondja, hogy minek kell megfelelni. Ehhez a 27001-es szabványhoz tartozik egy 27002-es jelzetű Code Practice, a gyakorlati előírások gyűjteménye. Egy tanúsító nem kérheti ugyan számon ennek teljesítését, de a rendszerépítésnél ragaszkodhat ennek figyelembe vételéhez.  

A 27015-ös szabvány a 27001-es követelményrendszer 27002-es Code Practice-éhez ad ágazati útmutatót a pénzügyi szervezetekre. Sorbaveszi a 27002-es szabvány 5-től 15-ig terjedő fejezeteit, minden egyes alpontnál közli, hogy van-e kiegészítő információ, vagy sem.   

A megfogalmazott, fontosabb kiegészítő elemek:

A 6-os fejezet a szervezeti követelményeket fogalmazza meg. A felelősséggel kapcsolatban felhívja a figyelmet, hogy léteznek útmutatók, akár törvényi elemek, amelyekben a felelősségekben konkrét elválasztásokat, ill. bizonyos felelősségeknek a nevesítését várják el bizonyos előírások. Itt megjelenik két útmutató is, a PCI DSS, a kártyákra vonatkozó, ill. a Cobit vonatkozó útmutatói.  

 

A 6.2 fejezet a kockázattal foglalkozik, ez az alvállalkozókkal és a külső partnerekkel való együttműködésre foglalkozó fejezete a szabványnak. Arra hívja fel a figyelmet, hogy vannak multi cégek, amelyek egy része más kontinensen, pl. Indiában, más része unión belül, de Magyarországon kívül van. Nekünk számba kell venni, amikor különböző partnerek, legyen szó akár vevői, akár szállítói oldali partnerekről, hogy esetünkben előfordul-e olyan ország, ahol eltérőek a biztonsági követelmények, s ez jelent-e kockázatot a rendszerrel szemben, ha arra a területre kerülnek adatok és információk.     

Két hosszú részben foglalkozik a szabvány avval, hogy a vevőkkel kapcsolatban, ill. a szállítói oldalon, mint harmadik oldalon hogyan tudjuk a kockázatokat csökkenteni. Kimondja, a vevőknek adjunk meg mindenfajta biztonsági tanácsot, hogy mire vigyázzanak. Segítsük őket abban, hogy lehetőleg elkerüljék a hibákat, de pontosan tájékoztassuk róla, hogy mi az ő felelősségük, mi a pénzintézet felelőssége, s egyáltalán, az online tranzakciók folyamán hogyan működünk együtt.   

 

A szállítói oldalon, harmadik felekkel való együttműködés esetén a szabvány sorba veszi, hogy mi mindent lehet beleírni abba a szerződésbe, megállapodásba, amire érdemes odafigyelni. Tételesen sorba veszi a szóba jöhető kritikus elemeket. Pl. nagyon fontos, hogy nem csak azt kell figyelembe venni, ha valami más szolgáltatást nyújt a partner, hanem azt is, ha valami változtatást hajt végre az infrastruktúráján, amivel szolgáltat nekünk, meg kell vizsgálnunk, hogy a kockázat nőtt, vagy csökkent ezáltal a rendszerben. Azt is nézzük meg, hogyan működünk együtt az incidens-kezelésben, nem csak auditáljuk az ő szolgáltatásokkal kapcsolatos tevékenységét. Amennyiben további partnereket alkalmaz, akkor oda is elmegyünk, ez is legyen tárgya a szerződésnek, épüljön be a megállapodásba.   

 

Sokszor emlegeti a szabvány az un. Financial Device fogalmát, azokat az eszközöket, melyeket a pénzügyi tevékenységekhez használnak. Kiemeli az ATM-et, az önkiszolgáló terminálokat (SST), s a POS elemeket.  

Mniden gyakorlati ponton fontosnak tartja megemlíteni, hogy foglalkozni kell velük, már a vagyonleltár felvételétől, s az intézkedésektől kezdődően. Foglalkozni kell kapacitás képességükkel, virus-védelmükkel, sw változatuk frissen tartásával, biztonságos sw azonosításukkal.  

Az emberi erőforrás biztonságnál a szabvány bizonyos kritikus szerepben lévő személyek esetén az átvilágítás erősítését szorgalmazza. Olyan személyekről van szó pl., akik hozzáférnek kritikus adatokhoz, PIN kódokhoz. Kritikus személy az a rendszer-adminisztrátor, aki a futtatás közben az egész rendszer működését meghatározó szerepet tölt be. Pénzügyi rendszereknél biztonsági felügyelők is vannak, akik felügyelik a rendszer működését, tartozzanak ők is az erősen ellenőrzöttek körébe.  

 

Az un. „szabadság politika" azt jelenti, ne legyen olyan felállás, ahol mindig egy emberhez kötődik egy teljes folyamat, vagy meghatározott tevékenységek köre. Ajánlás; ilyen esetekben legyen legalább tíz, egymás utáni munkanap szabadsága legyen az illetőnek, amikor egy másik személy kezeli a tevékenységet. Így kiderülhet,  nincs-e valami összefonódás, valamilyen speciális folyamat a rendszerben.   

A képzések kapcsán sok témát vet fel a szabvány, pl. jogi oldalról legyenek felkészültek a kollégák, s a szabvány felsorolja a kezelendő tipikus biztonsági eseményeket, kezdve a phisinghel.

A mobil korlátozás arra hívja fel a figyelmet, hogy mobil eszközökkel nagyon könnyű lefényképezni a végrehajtott műveleteket, a képernyőn megjelenő információkat, s le lehet filmezni a lenyomott billentyűket. Biztonsági zónának minősített területen ezeket az eszközöket nem szabad használni.   

 

A felelősség szétválasztásáról szólva, kiemeli a szabvány; legyenek elválasztva bizonyos tevékenységek. Amikor egy tranzakciót, egy ügyletet elindítok, akkor mindig legyen még egy ellenőrzési pont, legyen elválasztva az indítás és a végrehajtás. A fogadó oldalon is legyen elválasztva a verifikáció a rendszerben.  

 

Selejtezéseknél nem csak az alapeszközök (adatbázisok, gépek, eszközök) selejtezésével kell foglalkozni, mivel  mindenfajta kiegészítő tevékenység környékén is maradhatnak adatok, pl. a kulcsgeneráló sw környékén lévő adatbázisban. Hasonló gondossággal kell eljárni a mágnescsíkok selejtezése esetén is. Pénzintézeteknél vannak még papír-elemek, csekkek, formanyomtatványként működő űrlapok, rajtuk a cég azonosítója, ez is visszaélésre adhat alkalmat.  

 

A szokatlan eseményekre, vevő tranzakciókra monitorozást kell alkalmazni.    

 

Az eredeti, 27002-es szabványhoz képest két új momentumot találunk, egyik az internetbank szolgáltatások témaköre. A szabvány felsorolja, milyen kiinduló biztonsági elemekre érdemes gondolni internetbank szolgáltatás indításánál.  

Külön ki kell értesíteni az ügyfelet, amikortól élővé válik a rendszere, s korlátokat kell beállítani. Cégeknél, több- emberes tevékenységi jogosultság esetén világosan rögzíteni kell a személyes hatásköröket, azaz, ki az egyedi aláíró, ki a kettős aláíró. Nem fogadható el, hogy ha egy ügymenet (session) megszakad, akkor az a megszakítástól folytatódhasson. Megszakadás esetén kötelező legyen újrahitelesíteni a hozzáférést.  

 

A szabvány a várható és a jelenlegi létszámra kapacitás-menedzsmenti példákat hoz.  

 

Csalás esetén a szabvány nem csak védekezést vár el el a biztonsági követelményektől, de azt is, hogy a csalás után biztosítsa annak visszakövetését, hogy hol keletkezett, valamint  biztosítsa a csalás nélküli helyzet helyreállítását, egyfajta helyreállítási funkcióval.   

 

A titkosítással kapcsolatban írja; időközönként nézzük meg, hogy a titkosítás elég szigorú-e, megfelel-e a legutóbbi, ismert követelményeknek. Amennyiben nem, akkor tegyük meg a minőséggel kapcsolatos lépéseket.  

 

A működés-folytonosságban a partnerekkel való kockázatokat, működés-folytonossági követelményeket emeli ki a  szabvány. Amennyiben megszűnik az internet kapcsolat, vagy a szolgáltató, aki a kártyákat gyártja, vagy a hitelesítővel nem működik a kapcsolat, akkor nem tudunk mi sem szolgáltatni, ezek is folytonossági kockázatok.    

A folytonossági tervben ennek megfelelően kell intézkedni.   

 

A műszaki megfeleléssel kapcsolatban a szabvány felhívja a figyelmet, hogy nem csak technikai oldalról kell megfelelőséget nézni, de vannak jogszabályi előírások, az azoknak való technikai megfelelést is nézzük át időnként.

Azt is nézzük, hogy amit kitaláltunk, az korrekten lett-e bevezetve.  

 

A szabvány új kontrollt jelenít meg, a megfelelőség monitoringot, ami arról szól, hogy az, amit megcsináltunk megfelel-e az aktuális jogszabályoknak. Legyen egy olyan listánk, ami tartalmazza, hogy minek kell megfelelni egy pénzintézeti információs rendszernek. Ebbe legyen beépítve a szabvány változásának figyelése, legyen egy követelmény figyelő rendszer, ill. egy megfelelés mondja ki, hol, hogyan tudjuk biztosítani ezeket a követelményeket.      

 

A rendezvényen sor került  az "Év információbiztonsági szak- és diplomadolgozata" cím 2013. évi nyerteseinek kihirdetésére. A nyolcadik alkalommal kiírt nyílt pályázat révén az Egyesület azokat a fiatal, információbiztonsággal foglalkozó főiskolai és egyetemi hallgatókat kívánja elismerni, akik szak-, illetve diplomadolgozatukat az információbiztonság témakörében írják.  

2013-ban Paráda István, a Nemzeti Közszolgálati Egyetem hallgatója szakdolgozat (BSc) kategóriában,  

Dinya Péter, a Budapesti Corvinus Egyetem hallgatója pedig diplomadolgozat (MSc) kategóriában nyerte el a megtisztelő címet.  

 

Paráda István "A hálózatbiztonság vizsgálata a hálózati eszközöket érintő támadások gyakorlati szimulációin keresztül" című pályaműve ismertette azokat a támadási módokat, eszközöket, melyeket akár nagyobb szaktudás hiánya esetén is lehet alkalmazni, majd egy komplex támadást mutatott be egy adott "áldozat" asztali számítógéppel, ill. különféle hálózati eszközökkel szemben. Végül általánosságban áttekintette a Magyar Honvédség hálózatának felépítését, működési elveit, technológiai megvalósítását.

A fórumon Paráda István bemutatta dolgozatát, majd válaszolt a szakmai közönség kérdéseire. Az erkölcsi elismeréssel és utazási utalvánnyal járó díjat az Egyesület elnöke, Gasparetz András adta át szeptember 18.-án, az Egyesület LVII. Információvédelem menedzselése szakmai fórumán. A nyertes az utazási utalvány mellett a Herendi Porcelánmanufaktúra "bölcs bagoly" porcelánfiguráját is átvehette dr. Ködmön István, az Egyesület alelnöke nevében Gasparetz András elnöktől, és Tatján Gábor alelnöktől.

 

Dinya Péter "Jelszavak használatával kapcsolatos megoldások, módszerek és szokások elemzése" című dolgozatával arra kívánt válaszolni, milyen tulajdonságokkal rendelkezik egy könnyen megjegyezhető, de feltörhetetlen jelszó, másrészt olyan olvasmányt kívánt felmutatni, melynek segítségével az átlagos felhasználó hasznos ismereteket szerezhet jelszavai kezeléséhez. A dolgozat vizsgál, megmagyaráz, és ha szükséges, megcáfol vagy igazol olyan információkat, amelyek befolyásolhatják a jelszavakkal való bánásmódot.

Dinya Péter diplomadolgozatát az Egyesület novemberi szakmai fórumán fogja bemutatni.

A nyertes pályaművek nem jöhettek volna létre a konzulensek nélkül, így a Fórumon oklevelet adtak át  

dr. Fehér Péternek, Dinya Péter, valamint Jobbágy Szabolcsnak, Paráda István konzulensének.

 

 

 

http://hetpecset.hu  

http://en.wikipedia.org/wiki/Information_security_management_system

http://www.szenzor-gm.hu/megfeleloseg-menedzsment/isms/

http://rqc.hu/index.php/tanacsadasok/60-ibir

http://hu.wikipedia.org/wiki/ISO_27001

http://webstore.iec.ch/preview/info_iecfdis60092-501%7Bed5.0%7Den.pdf  

www.netiq.hu

http://www.webopedia.com/TERM/P/provisioning.html  

http://en.wikipedia.org/wiki/ISO/IEC_27000

http://www.gobookee.net/iso-27015-standard/

 

 

 

Harmat Lajos

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük