IT BIZTONSÁGI ÉRTÉKELİ LABORATÓRIUM KONCEPCIÓ

IT BIZTONSÁGI ÉRTÉKELİ LABORATÓRIUM KONCEPCIÓ

E-közigazgatás keretrendszer kialakítása projekt

A dokumentum az Új Magyarország Fejlesztési Terv keretében, az Államreform Operatív Program támogatásával, az „Elektronikus közigazgatási keretrendszer” tárgyú kiemelt projekt megvalósításának részeként készült. A dokumentum elkészítésében részt vett:


1. Metaadat-táblázat Megnevezés Cím (dc:Title) Kulcsszó (dc:Subject) Leírás (dc:Description) Típus (dc:Type) Forrás (dc:Source) Kapcsolat (dc:Relation) Terület (dc:Coverage) Létrehozó (dc:Creator) Kiadó (dc:Publisher) Résztvevı (dc:Contributor) Jogok (dc:Rights) Dátum (dc:Date) Formátum (dc:Format) Azonosító (dc:Identifier) Nyelv (dc:Language) Verzió (dc:Version) Státusz (State) Fájlnév (FileName) Méret (Size) Ár (Price) Felhasználási jogok (UserRights)

Leírás IT biztonsági értékelı laboratórium koncepció IT biztonság; értékelés; labor Alkalmazások és eszközök IT biztonsági bevizsgálásához kialakított laboratórium követelményeit tartalmazza a dokumentum. Szöveg . . Magyarország e-Közigazgatási Keretrendszer Kialakítása projekt Miniszterelnöki Hivatal Stratis Kft. . 2008. MS-Word . HU V2.0 Kötelezı EKK_ekozig_ITbiztonsagiertekelolabor_080813_V2.doc 362 KB . .


2. Verziókövetési táblázat A dokumentum neve A dokumentum készítıjének neve A dokumentum jóváhagyójának neve A dokumentum készítésének dátuma Verziószám Összes oldalszám A projekt azonosítója

2.1. Verzió V1 V2 V3

IT biztonsági értékelı laboratórium koncepció

Stratis Kft. 2008.08.13. V2 25 E-közigazgatás keretrendszer kialakítása projekt

Változáskezelés Dátum 2008.07.30. 2008.08.13.

A változás leírása A MeH-nek átadott verzió. Minıségbiztosító javaslatainak átvezetése.


3. Szövegsablon Megnevezés 1. Elıszó (Foreword) 2. Bevezetés (Preamble) 3. Alkalmazási terület (Scope) 4. Rendelkezı hivatkozások (References) 5. Fogalom-meghatározások (Definitions) 6. A szabvány egyedi tartalma (UniqueContent) 7. Bibliográfia 8. Rövidítésgyőjtemény 9. Fogalomtár 10. Ábrák 11. Képek 12. Fogalmak 13. Verzió 14. Mellékletek (Appendix)

Leírás . . Termékek, szolgáltatások értékelésének, auditjának elıkészítése . . . . . . . . . . .


4. Tartalomjegyzék 1. 2.

Metaadat-táblázat ............................................................................................................................................ 3 Verziókövetési táblázat ................................................................................................................................... 4 2.1. Változáskezelés ...................................................................................................................................... 4 3. Szövegsablon .................................................................................................................................................. 5 4. Tartalomjegyzék.............................................................................................................................................. 6 5. Bevezetés ........................................................................................................................................................ 7 6. A laboratórium kialakításának indoklása ........................................................................................................ 8 7. A laboratórium kialakítása .............................................................................................................................. 9 8. A laboratórium felépítése.............................................................................................................................. 12 8.1. Infrastrukturális követelmények........................................................................................................... 12 8.2. Informatikai követelmények ................................................................................................................ 12 8.2.1. Használjunk munkára szánt gépektıl és az Internettıl izolált rendszert! ....................................... 12 8.2.2. Általános labor architektúra............................................................................................................ 12 8.2.3. Virtualizáljunk mindent!................................................................................................................. 13 8.3. Az angol példa...................................................................................................................................... 14 8.3.1. Minıségi elıírások ......................................................................................................................... 15 8.3.2. Biztonsági elıírások ....................................................................................................................... 15 8.3.3. Felkészültség .................................................................................................................................. 16 8.3.4. Akkreditáció ................................................................................................................................... 16 8.3.5. Oktatás............................................................................................................................................ 17 8.4. A MIBÉTS laborral kapcsolatos elıírásai............................................................................................ 17 8.4.1. Általános követelmények ............................................................................................................... 18 8.4.2. Speciális követelmények ................................................................................................................ 18 8.4.3. Kiegészítı dokumentumok ............................................................................................................. 18 8.5. Külföldi megvalósítások ...................................................................................................................... 19 8.5.1. Science Applications International Corporation Common Criteria Testing Laboratory ................ 19 8.5.2. Telecommunication Technology Center......................................................................................... 20 8.6. Személyi követelmények...................................................................................................................... 20 9. Labor mőködtetése ........................................................................................................................................ 23 10. Vizsgálatok végzése ............................................................................................................................. 23 11. Infrastruktúra........................................................................................................................................ 24 12. Dokumentumkezelés ............................................................................................................................ 24 13. Információ védelem ............................................................................................................................. 25 14. Rövidítések jelentése és fogalomszótár................................................................................................ 26


5. Bevezetés A rendszereket a funkcionális és biztonsági követelmények egyidejő betartásával kell tervezni, fejleszteni, implementálni, beszerezni/szállítani és használni, valamint mőködtetése befejezése után felszámolni. Ezen követelmények mérhetısége, összehasonlíthatósága, ellenırizhetısége szükségessé teszi a minısítés és tanúsítás alkalmazását. A program célja, hogy a minıségbiztosítás módszerek bevezetésével, minták és ajánlások elkésztésével támogassa az IT-biztonság felhasználóit. Ugyancsak célja a minısítési és tanúsítási intézményrendszerek megteremtése és mőködtetése, az ezekhez szükséges szabványok kialakítása, EU-s és más nemzetközi ajánlások átvétele és a terület nemzetközi szereplıivel történı együttmőködés megvalósítása. Már mőködı rendszerek esetében a megfelelı kockázatkezelési eljárások segítenek a biztonság elérésében. A versenyképesség és tudatosság növelése érdekében ma már nem elég, ha a termék elıállítója (alkalmazásfejlesztı, szolgáltatásnyújtó, eszközgyártó) állítja, hogy az adott termék biztonságos, megfelel a szabványoknak és együttmőködésre képes más termékekkel, ezt mérni és tanúsítani kell. A program keretében meg kell követelni (minimum az állam- és közigazgatási rendszerek szállítóitól), hogy a biztonság és bizalom kialakulásnak elısegítése érdekében a gyártó/felhasználó (különösen kritikus és kormányzati infrastruktúrák esetében) olyan rendszert és szervezetet hozzon létre, vásároljon, terjesszen, illetve mőködtessen, amely a garantált biztonság és együttmőködı-képesség (interoperabilitás) tanúsítványával (pl. ISO 9001 – International Organization for Standardization, CC – Common Criteria, MIBÉTS Magyar Informatikai Biztonsági Értékelési és Tanúsítási Séma, ISO/IEC 17799, BS 15000 – British Standard, COBIT – Control Objectives for Information and Related Technology) rendelkezik. A biztonsági szempontokat, szabványossági feltételeket, együttmőködési képességet független szakértık is igazolhatják különbözı vizsgálatok alapján, így növelve az adott termék versenyképességét. A biztonságos mőködés alapvetı fontosságú, a szabványos és együttmőködésre képes termékek pedig szükségesek ahhoz, hogy ne egymástól elkülönülı, szigetszerő alkalmazások jöjjenek létre, hanem összefüggı területeket alkossanak, amelyeknél a szinergiából származó elınyöket is ki lehet használni. A fentieken túlmenıen a tervezett idıszakban hazánknak nem csak a minısítést, tanúsítást elfogadó országnak, hanem a szükséges jogosítványok megszerzésével saját minısítı, tanúsító képességekkel is kell rendelkeznie. Az ehhez szükséges tudást, technikai hátteret és szabályozási környezetet a programban, annak is az elején végre kell hajtani. A technikai háttér olyan laboratóriumokban teremthetı meg, melyek képesek a rendszerek és szervezetek biztonsági és interoperabilitási képességeit vizsgálni és tanúsítani.

6. A laboratórium kialakításának indoklása Magyarország CCRA-hoz való 2003. szeptemberi csatlakozásával megnyílt az informatikai termékek nemzetközi szabvány szerinti biztonsági értékelésének és tanúsításának lehetısége. Ezzel az aktussal ugyanis kezdetét vette a Magyar Informatikai Biztonsági Értékelési és Tanúsítási Séma kidolgozása. A MIBÉTS szerepel a MITS kiemelt programjai között, „Biztonsági szempontok társadalmi tudatosításához szükséges jogi és szervezeti háttér kialakítása” címmel. Ennek elsı két pontja szerint szükséges a MIBÉTS módszertanának kidolgozása és oktatása, valamint a séma jogszabályi hátterének kialakítása és szervezetrendszerének felállítása. A módszertan megjelent a MIBA (Magyar Informatikai Biztonsági Ajánlások) címmel.

7. A laboratórium kialakítása A BME IK koncepciót alakított ki IT biztonsági értékelı laboratórium kialakításáról. Ez ügyben ajánlatot kértünk több minıségbiztosítással foglalkozó cégtıl, akik reményeink szerint az IK ISO 9000 szerinti tanúsítását elvégzik, illetve felkészítik a labort a késıbbi akkreditációra. Bár a felelıs szervezet (Miniszterelnöki Hivatal) kijelöléssel is befogadhat a sémába egy értékelı labort, mégis fel kívánunk készülni egy késıbbi, NAT általi akkreditációra és pár év múlva a Common Criteria szerinti értékelésre is, ezért feltétlenül elınyös a minél szabványközelibb megvalósítás. Jelenleg az alábbi szabványok azok, melyeket érdemes figyelembe venni a labor kialakításánál: •

15/2001. (VIII.27.) MeHVM rendelet az elektronikus aláírási termékek tanúsítását végzı szervezetekrıl, illetve a kijelölésükre vonatkozó szabályokról: http://www.nhh.hu/menu4/m4_6/eat-rendeletek/15mehvmrend.pdf. Jelenleg ez az a magyar jogszabály, amire a legjobban hasonlít a mi feladatunk.

•

NIST Handbook 150-20, NVLAP Information Technology Security Testing Common Criteria: http://niap.nist.gov/cc-scheme/HB150-20.pdf. Ez az amerikai séma elıírása a CC laborokra.

•

NIST Handbook 150, NVLAP Procedures and General Requirements: http://ts.nist.gov/ts/htdocs/210/214/docs/final-hb150-2001.pdf, MSZ EN ISO/IEC 17025, Vizsgáló- és kalibrálólaboratóriumok felkészültségének általános követelményei, MSZ EN 45002, Vizsgálólaboratóriumok minısítésének általános feltételei. Ezek a laborokra vonatkozó általános követelmények, amikkel az a gond, hogy nagyon nehéz lefordítani ıket az informatikai laborokra.

•

Készül a magyar minıségügyi kézikönyv is, ez azonban még nagyon kezdeti állapotban van. A bevezetése szerint: "Az MKKMT az alapkövetelmények megfogalmazását illetıen az MSZ EN ISO/IEC 17025:2001 szabványhoz igazodva és a MIBÉTS séma figyelembevételével, annak felépítését felhasználva készült. Az MSZ EN ISO/IEC 17025:2001 szabvány a „Vizsgáló- és kalibrálólaboratóriumok felkészültségének általános követelményei” címet viseli, melybıl számunkra az informatikai biztonság területét érintıen nyilvánvalóan a „vizsgálólaboratórium” kifejezés kap hangsúlyt. Az említett szabvány alapja az EN ISO/IEC 17025:2001 nemzetközi szabvány, egészen pontosan azzal teljesen megegyezik. Az említett MSZ EN ISO/IEC 17025:2001 szabvány a korábbi MSZ EN 45001:1990 és az MSZ 18935:1991 helyett készült, azoknak korszerőbb változata.

Így e szabvány az MSZ EN 45001:1990 szabványnak is megfelel, minden olyan követelményt tartalmaz amelyet vizsgáló laboratóriumoknak ki kell elégíteni." Amennyiben minden várható jogszabály megszületik, és a MIBÉTS séma a magyar közigazgatásban is létjogosultságot szerez, a labor hamar önfenntartóvá válhat. A labor ideális mőködéséhez középtávon egy adminisztratív munkatárs és egy szoftveres munkatárs felvétele javasolt. Németországban, egy nagy értékelı laborban kb. 6-8 fıállású munkatárs dolgozik és 20-30 külsı szakember áll rendelkezésre, akik szükség esetén szakértelmükkel támogatni tudják az értékelési folyamatot. A labor elhelyezése az intétmény egyik megfelelıen védett helységében történik, ahol egy teljes informatikai hálózat is kialakításra kerül. A MIBÉTS elıírásai szerint a megbízónak adott esetben a termék mellett a mőködéshez szükséges környezetet is biztosítani kell. Amennyiben az általunk nyújtott infrastruktúra nem kielégítı, ezen pontnak megfelelıen tovább lehet bıvíteni.

A labor kialakításának eredeti ütemterve a következı: Minta ütemterv azIT biztonsági értékelı laboratórium kialakításához szükséges lépésekrıl 2009. év

6. 7. Feladat megnevezése 1. hónap 2. hónap 3. hónap 4. hónap 5. hónap hónaphónap Az IT biztonsági laborral kapcsolatos követelmények lefektetése: Felhasználva a meglevı laborokra vonatkozó nemzetközi, és a CC laborokra vonatkozó külföldi valamint kezdeti magyar szabványokat, meg kell vizsgálni a MIBÉTS labor céljait és követelményeit, és ezt egy dokumentumba kell foglalni. Határidı: 1 hónap A szervezet kialakítása: Az ügymenet, a személyzet és az infrastruktúra elvi megtervezése a követelmények alapján. Határidı: 0,5 hónap Külsı cég bevonása a minıségügyi rendszer kialakításába: Egy olyan cég pályázaton való kiválasztása, aki képes az egyetemi környezet kötöttségei mellett is a szabványoknak megfelelı értékelılabor minıségügyi rendszerét kialakítani. Határidı: 1,5 hónap Visszacsatolás: A külsı cég eredményei és útmutatásai alapján az elvi szinten megtervezett szervezeti felépítés szükséges átalakítása, a külsı cég által készített dokumentumok befogadása. Határidı: 1 hónap Véglegesítés: Az elvi séma véglegesítése, jóváhagyatása. Határidı: 0,5 hónap Megvalósítás: Az ügymenet, a személyzeti feltételek, az infrastruktúra és a minıségügyi rendszer kialakítása a tervek alapján, a szükséges beszerzések lebonyolítása. Határidı: 1 hónap Tesztelés: A kialakított rendszer tesztelése egy mintaértékeléssel. Határidı: 1 hónap Visszacsatolás: A tesztelés során jelentkezı tapasztalatok alapján a rendszer finomhangolása. Határidı: 0,5 hónap Átadás: Az IT biztonsági értékelı labor ünnepélyes átadása és üzembe helyezése Határidı: 1 hónap

8. A laboratórium felépítése 8.1.

Infrastrukturális követelmények

A laboratórium infrastrukturális követelményeinek meghatározásához jó alapot nyújt az NCSL International Recommended Practice RP-7 Laboratory Design címő leírása, mely az USA Common Criteria sémája szerint mérvadó az IT-biztonsági laboratóriumok kialakításához.

8.2.

Informatikai követelmények

Elıször is vizsgáljuk meg azt, hogyan építettük ki a saját rosszindulatú kód analízis laboratóriumunkat. Gyakran elıkerül a kérdés, hogy milyen felszerelésre van szükség, ha otthon vagy munkahelyünkön szeretnénk analízist végezni. Ahhoz, hogy tesztelhessük a különbözı, védekezı és támadó jellegő programokat, szükségünk van egy biztonságos környezetre a kísérletezéshez. Elıfordulhat ugyanis, hogy a valódi felhasználásra szánt rendszerbe is bekerülnek különbözı rosszindulatú kódok. A laboratóriumi struktúrát használva, amely ebben a fejezetben leírásra kerül, megvizsgálhatjuk a felfedezett kódokat, hogy mélyebb betekintést nyerhessünk azok mőködésébe, és felmérhessük az okozott kárt. 8.2.1. Használjunk munkára szánt gépektıl és az Internettıl izolált rendszert! A labor létrehozásánál a következı szempontokat vettük figyelembe: Olyan számítógépeket akarunk használni, amelyekre nem támaszkodunk valódi munka közben. Ezeket a gépeket soha nem kötjük rá valódi hálózatra vagy az Internetre, amíg minden szoftvert el nem távolítottunk róluk a merevlemez mélyformázásával. Szintén elkerülendı bármely érzékeny adat elhelyezése a rendszerre, hiszen néhány rosszindulatú kód típus ellophatja az adatokat, vagy tönkreteheti azokat. Érdemes továbbá a labort bekapcsolt állapotban, mőködésre készen tartani, arra az esetre, hogyha vészhelyzet lép fel, például egy gyorsan terjedı féreg, amelyen egy gyors analízist szeretnénk végezni.

8.2.2. Általános labor architektúra A labor viszonylag olcsón felszerelhetı. Jó, hogyha sikerül egy gyors processzort és némi memóriát szereznünk a gépekbe, de ez nem feltétlenül szükséges a labor mőködéséhez. A cél az, hogy olyan gépeket szereljünk fel, amelyek operációs rendszereket és néhány kiválasztott célprogramot futtatnak. Egy tipikus rosszindulatú kód analízisre alkalmas egy négy számítógépbıl álló laboratóriumi architektúra. A javaslat az, hogy a labort olyan gépekbıl építsük, amelyek legalább 350MHz-

es processzorokkal, 64MB memóriával és 5 GB tárral rendelkeznek. Minden gépbe kell hálózati kártya, többnyire egy egyszerő 10MBps sebességő ETHERNET kártya elegendı. A jelenleg az Informatikai Központban mőködı architektúra ennél lényegesen nagyobb kapacitású gépekkel van felszerelve. A következı ajánlható az operációs rendszerekhez szükséges hardver és szolgáltatáslista összetételhez: A referencia laborban van egy Windows 2003 rendszer Microsoft IIS webkiszolgálóval. Sok cég használ Windows 2000 vagy 2003 rendszert IIS webkiszolgálóval, ezért ezek a támadások gyakori célpontjai. Ezért ez a rendszer alkalmas arra, hogy kiértékeljünk sokféle férget és RootKitet, amelyeket Windowsos gépekre terveztek. A Windows természetesen kereskedelmi operációs rendszer, ezért az ehhez szükséges licensszel drágábbak a labor számítógépei. A következı rendszer egy Linux, amelyen egy FTP szolgáltatás és az Apache webkiszolgáló fut. Ahogy a Windows és az IIS, úgy ez a párosítás is gyakori célpontja a rosszindulatú kódoknak, amennyiben sebezhetıen vannak telepítve. A harmadik rendszer egy Windows XP, amelyben be vannak állítva a Windows beépített, általános fájlmegosztási mechanizmusai. A negyedik gépen egy OpenBSD operációs rendszer van, amelynek jelentıs beépített biztonsági funkciói vannak. Ezen a tesztet a Network File System (NFS) kiszolgáló segítségével végezhetjük el. Minden gépen érdemes elhelyezni különbözı vírusirtókat, amelyek segíthetnek felismerni a jól ismert rosszindulatú kód példákat, amikor feltesszük ıket a rendszerre. Továbbá fájlintegritás ellenırzı szoftvert is telepítünk a gépekre, hogy a kritikus fájlokat és rendszerbeállítások érvényességét figyelhessük. Analízis közben ezeket idılegesen ki lehet kapcsolni, de ezek biztosíthatják a kontrollált körülményeket. Az összeköttetést egy olcsó hub vagy switch biztosítja. A hub azért jobb megoldás, mert minden vonalra ismétel minden forgalmat a helyi hálózaton. Így könnyebb sniffer programokat futtatni a hálózaton és megfigyelni a forgalmat. Ha switchet használunk, akkor egy span portot kell létrehoznunk és beállítanunk arra, hogy minden forgalmat továbbítson, amely a hálózaton történik. A gépekhez egy belsıhálózati IP-cím kiosztást kell társítani egy megfelelı belsıhálózati maszkkal. Tipikusan 10.x.x.x és 255.255.255.0. 8.2.3. Virtualizáljunk mindent! A labor eddigi felszerelése négy számítógépbıl és egy hubból állt, de lehetséges az is, hogy egyetlen számítógép segítségével egyidejőleg futtassunk több operációs rendszert. Ha virtuális rendszereket állítunk fel, akkor lehetıségünk van arra, hogy feltelepítsünk egy gazda operációs rendszert egyetlen számítógépre, vagy laptopra, és azon több virtuális operációs rendszert telepítsünk fölé. A gazda egy egyszerő operációs rendszer, amely a hardver felett fut, míg a vendég rendszereket programként indítjuk el efölött. Ezek a programok virtuális operációs rendszerek abban az értelemben, hogy maguk is képesek programokat futtatni és kommunikálni egymással egy virtuális hálózaton keresztül, amely összeköti ıket. A virtuális rendszereket egy emulációs programon keresztül hozzuk létre a gazdaszámítógépen, és néhány, a gazdán lévı fájlból állnak. Minden virtuális rendszert úgy lát, mintha saját hardveres rétege lenne, pedig egyetlen processzoron osztoznak.

Az ötlet, hogy virtuális környezetben végezzünk rosszindulatú kód analízist, nem új. Az IBM kutatói a jövıbe mutató munkát végeztek e téren virtuális gép környezetben, még 2000-ben [1]. Mi is hasonló koncepciót képzelünk el a laboratóriumba. Többféle program is a rendelkezésünkre áll, amelyek képesek egy számítógépet olyan gazdává tenni, amelyen sok operációs rendszer fut. A kereskedelmi termékek, pl. a VMWare (elérhetı a www.vmware.com-on), a Virtual PC (elérhetı a www.connectix.com-on) és más termékek az x86 processzorcsaládot emulálják szoftveresen, és ezzel elérik azt, hogy telepíthetünk és futtathatunk virtuális gépeket egyetlen hardverre. Vannak szabad szoftverek is (freeware), amelyekkel elérhetjük ezt a funkcionalitást, pl. A Plex86 Virtual Machine Project a http://plex86.sourceforge.net-en, és a Bochs projekt a http://bochs.sourceforge.neten. Továbbá ha csak Linuxot szeretnénk a laborba, akkor az UML projekt jöhet számításba, amely több, független Linux kernelt futtat linuxos processzekben egyetlen linuxos gépen. Az UML szabadon hozzáférhetı a http://user-mode-linux.sourceforge.net-en. A virtuális megoldások szépsége, hogy egyetlen laptopon, hordozható módon megvalósítható a labor. Ezzel adott esetben ki is szállhatunk egy probléma helyszínére. További elıny, hogy a legtöbb ilyen virtuális rendszer képes visszaállítani a változásokat anélkül, hogy újra kellene építenünk a rendszert. Így azonnal helyreállíthatjuk bármelyik vendég operációs rendszert, ezáltal könnyő megfigyelni valamely rosszindulatú kód hatását a teljesen virtuális rendszeren. Nem kell törıdni vele, hogy a kód esetleg hibás, vagy komoly károkat okozhatna, mert könnyen visszaállíthatjuk az eredeti állapotot. Arra is lehetıséget adnak ezek a szoftverek, hogy befagyasszuk a rendszer mőködését, és megvizsgáljuk a kártevıt mőködését. Ahhoz, hogy több rendszer futhasson egyszerre, a gazdaszámítógépnek valamivel erısebbnek kell lennie, az elızı fejezetben leírtaknál. Egy virtuális analízis labor mőködéséhez a következı konfigurációt ajánljuk: legalább 2GHz-es processzor, és virtuális rendszerenként legalább 64 MB memória. Ez a vendég és a gazda rendszerekre is vonatkozik. Egy gazdából és 3 vendégbıl álló rendszeren ez legalább 256MB memóriát jelent. Mivel a rendszer memóriaérzékeny, érdemes a RAM mennyiségét megduplázni, hogy megfelelı sebességet érjünk el. Jelenleg ilyen gépekkel rendelkezik a víruslabor. A legflexibilisebbnek és legstabilabbnak a tesztek alapján a VMWare bizonyult, habár jóval költségesebb, mint a szabad szoftveres megoldások. A virtuális környezet nem szükséges a rosszindulatú kódokat analizáló labor megvalósításához, de sokkal könnyebbé és portolhatóbbá teszi az analízis folyamatot.

8.3.

Az angol példa

Az elképzelt értékelı laboratórium többek között az angol UK ITSec Scheme útmutatásai alapján jött létre. Ebben a sémában hangsúlyosan foglalkoznak azzal, hogy milyen módon jöhet létre egy értékelı labor, vagyis egy Commercial Evaluation Facility (CLEF). A laborok akkreditációja a brit akkreditációs rendszer, azaz az UKAS felügyelete alatt történik. A laboroknak alapvetıen minıségi, biztonsági és személyzeti követelményeknek kell megfelelniük.

Alapvetı követelmény, hogy a CLEF elsısorban a sémába tartozó biztonsági értékelésekkel foglalkozzon és ennek érdekében viszonylag állandó szakértıi bázissal rendelkezzen. Így képes arra, hogy önállóan dolgozzon, függetlenül az anyavállalattól. Célszerő, hogy a CLEF önálló épületben vagy legalább önálló szárnyban legyen elhelyezve, és rendelkezzen megfelelı irodai felszereléssel, adminisztrációs személyzettel és kommunikációs hálózattal. További elıírás, hogy megfelelıen képzett és tapasztalt személyzet mőködjön közre az értékeléseknél, fel legyen készülve többfajta értékelési feladatra, legyen alapvetı, hardverek vizsgálatára szolgáló felszerelése. Fontos, hogy az archiválási eszközök megfeleljenek az UKAS elıírásainak. Ha ezek teljesülnek, a CLEF-et az ISO 17025:2000 szabványnak megfelelıen akkreditáltatni kell, mint tesztelı laboratóriumot. 8.3.1. Minıségi elıírások Az értékelı szervezetnek olyan szervezeti felépítésben kell mőködnie, hogy tudja teljesíteni és fenntartani a szükséges magas színvonalú munkát, mely az UKAS követelményeinek megfelelı minıségügyi kézikönyvben van leírva. Javasolt, hogy a szervezetben legyenek a következı szereplık, melyek közül egy személy több szerepet is betölthet: • • • • •

mőszaki irányító minıségbiztosítási irányító üzleti vezetı adminisztrációs felelıs biztonsági menedzser

Az értékeléseket kicsi, 2-3 fıs csoportok végzik, melyeknek vezetıi a mőszaki irányítónak tartoznak beszámolási kötelezettséggel. 8.3.2. Biztonsági elıírások A CLEF-nek minden körülmény között biztosítania kell a bizalmas üzleti információk védelmét. Ezt a védelmet hitelt érdemlıen bizonyítani kell a felügyelıszervnek. Ehhez segítség a Biztonsági Kézikönyv, mely az összes, biztonsággal összefüggı eljárást és felelısséget rögzíti. A Biztonsági Kézikönyv foglalkozik a fizikai, személyzeti és információs biztonsággal is. Az ebben foglaltak betartatása a biztonsági menedzser feladata. A fizikai biztonság legfontosabb elıírása, hogy csak arra felhatalmazott személyek léphessenek be az értékelés helyére. Ez akkor okozhat gondot, ha egy helyen több értékelést is folytatnak, kellı körültekintéssel azonban ez is teljesíthetı. Az értékelések során elıfordulhat, hogy a laboratórium érzékeny kormányzati termékekkel dolgozik. Ekkor az értékelınek át kell esnie egy nemzetbiztonsági vizsgálaton. Egyéb esetben az értékelésben résztvevı minden szereplınek titoktartási nyilatkozatot kell aláírnia. Amennyiben az értékelıszervezetnek nincs elég munkája, az anyacég bevonhatja más projektbe is a dolgozókat, azonban ekkor is be kell tartani a pártatlanság elvét.

Az informatikai biztonság eléréséhez bizonyos esetekben teljesíteni kell az erre vonatkozó brit szabványokat. Biztonságos kommunikációs rendszert kell használni, valamint olyan archiválási megoldásokat, melyekkel mind a papíralapú dokumentumokat, mind a mágneses adattárolókat biztonságos körülmények között lehet tárolni. 8.3.3. Felkészültség A sikeres értékelés lefolytatásához hozzáértı értékelıkre van szükség, akik ismerik az informatikai biztonság elveit, az értékelés eljárásait, és ezeket alkalmazni tudják bármilyen értékelési garanciaszinten. Az értékelı lehet gyakornok vagy minısített szinten. A gyakornok elvégezte az értékelıi tanfolyamot. A minısített értékelı olyan személy, akit a felügyelı szervezet nyilvántartásba vett, tehát alkalmas arra, hogy egy értékelést felügyelet nélkül végrehajtson. Az értékelés során a gyakornok és a minısített értékelık aránya a csoportban nem lehet magasabb a 3:1 aránynál. Ahhoz, hogy valaki értékelı lehessen, el kell végeznie egy tanfolyamot, melyet a séma gazdája által elfogadott tananyag alapján tartanak. Ezeket a tanfolyamokat minısített értékelıknek kell megtartania. Amennyiben rendelkezésre áll a megfelelı számú és felkészültségő szakmai stáb, a CLEF-nek egy mintaértékelést kell végrehajtania, mely lehetıleg EAL4 szintő termékkel történik. 8.3.4. Akkreditáció Az értékelı-szervezet kétfajta akkreditációval rendelkezhet. A 0. szintő akkreditáció elnyerésével a labor 3 évre kap mőködési engedélyt a saját telephelyén lefolytatandó értékelésekhez. Az 1. szintő akkreditációval a telephelyen kívüli értékelésre is lehetıség nyílik. A CLEF mindkét akkreditációval kell, hogy rendelkezzen ahhoz, hogy a teljes tesztelési eljárást el tudja végezni. Az akkreditáció folyamata tartalmazza az értékelési szempontok és a módszertan felhasználásának vizsgálatát. Ennek vizsgálatához a kijelölési testület különbözı tesztesetekkel rendelkezik. Új tesztek is keletkezhetnek, amennyiben a meglevı teszthalmaz nem képes ellátni az akkreditáció során keletkezı problémák konzisztens megoldását. Ezek az új tesztek szolgálnak alapul a séma evolúciójához. Az akkreditáció elıtt a labornak jelentkeznie kell az UKAS-nál. A jelentkezés után felmérik az értékelıt. Ha mindent rendben találnak, az értékelınek egy mintaértékelést kell végrehajtania, mely 3-4 hónapos idıtartamot fed le. A mintaértékelés célja, hogy a felügyelı szervezet meggyızıdjön arról, hogy az értékelıszervezet képes az értékelés végrehajtására. Az eljárás úgy van kialakítva, hogy mind az értékelık egyéni képességeit, mind a CLEF menedzsment és adminisztrációs eljárásait ellenırizzék. A mintaértékelésben az Értékelés Tárgya lehetıleg egy valós rendszer vagy termék, melyet akár a CLEF is javasolhat. A tipikus mintaértékelésben 3-4 gyakornok értékelı vesz részt. Fontos, hogy ekkor elsısorban az értékelıket értékelik, és nem a konkrét terméket, ami ennek

ellenére a késıbbiekben megszerezheti a tanúsítványt a mintaértékelés alapján. A felügyelı szervezet különös figyelemmel követi az értékelés megtervezését, levezetését, a beszámolást, a kapcsolattartást és a titoktartást. 8.3.5. Oktatás Az értékelıi tanfolyam célja, hogy megismertesse a hallgatókat a biztonsági elvekkel, a sémával és az értékelési módszertannal. Foglalkozik a brit gyakorlattal, mind technikai, mind eljárásbeli értelemben. A tanfolyam három modulból áll: az értékelés áttekintésébıl, a garanciaszintek ismertetésébıl és a séma megismertetésébıl. Az elsı modul szól az IT biztonsági elvekrıl és értékelésekrıl, valamint a séma alapvetı részeirıl. Ez a modul megelızi a többit. A második modul a biztonsági követelményeket, a fejlesztési reprezentációkat, a funkcionális tesztelést, a fejlesztési környezetet, a mőködési környezetet, a sérülékenységi vizsgálatot, a behatolási tesztelést és a garancia fenntartását mutatja be. A harmadik modul az értékelés lefolytatásáról és menedzselésérıl szól. Egy értékelı labor a felügyelı szervezet jóváhagyásával a saját munkatársainak tarthat elıadásokat. Amennyiben más CLEF-ek tagjai is hallgatják az elıadást, a tanfolyamot akkreditáltatni kell, és részvételi díjat lehet érte kérni.

8.4.

A MIBÉTS laborral kapcsolatos elıírásai

A MIBÉTS séma néhány alapelvet ír elı, melyeket az értékelınek minden körülmény között be kell tartania. Ezek a következık: • • • • • •

Az alkalmasság elve: az alkalmazott tevékenységeknek alkalmasnak kell lenniük a garancia megcélzott szintjének eléréséhez. A pártatlanság elve: minden értékelési tevékenységnek elfogultságmentesnek kell lennie. Az objektivitás elve: az értékelési eredményeket úgy kell kialakítani, hogy azok csak minimálisan tartalmazzanak szubjektív megítéléseket vagy személyes véleményt. A megismételhetıség elve: ugyanazon termék vagy rendszer megismételt értékelése ugyanazon értékelık által, azonos körülményekre vonatkozóan, alapvetıen az eredeti értékelési eredményeket szolgáltassa. Az újraelıállíthatóság elve: az ugyanarra az informatikai termékre vagy rendszerre vonatkozó, azonos követelmények szerint és ugyanazon értékelési bizonyíték mellett megismételt értékelésnek ugyanazokra az eredményekre kell vezetnie. Az eredmények helyességének elve: az értékelés eredményének teljesnek és szakmailag hibátlannak kell lennie.

Az alapelvek mellett olyan feltételek is vannak, melyeket mindenképpen szem elıtt kell tartani az értékelés során.

• • • •

A költség-hatékonyság feltétele: egy értékelés értékének ellensúlyoznia kell az összes érdekelt fél által befektetett idıt, erıforrásokat és pénzt. A módszertan fejlıdésének feltétele: a környezeti és mőszaki tényezık változásának az értékelésre gyakorolt hatását jól meghatározott és következetes módon le kell képezni az értékelés módszertanába. Az ismételt felhasználhatóság feltétele: egy értékelésnek hatékonyan fel kell használnia a korábbi értékelések eredményeit. Szaknyelv használatának feltételezése: az értékelésben résztvevı feleknek közös szakmai nyelvet kell használniuk.

Az értékelı, akinek ezeket a szabályokat be kell tartania, az a szervezet, melyet a NAT akkreditált vizsgálólaborként, vagy a szakminisztérium kijelölt. Kezdetben az utóbbi lehetıség látszik reálisnak, de minden kijelölt labornak törekednie kell arra, hogy megszerezze a NAT akkreditációt. Amennyiben a kijelölés megtörtént, a laboratóriumot fel kell venni a MIBÉTS nyilvántartásába. A kijelölés vagy akkreditáció során figyelembe kell venni az MSZ EN ISO/IEC 17025:2001 számú szabványt, mely a vizsgáló- és kalibrálólaboratóriumok felkészültségének általános követelményeirıl szól, valamint a minisztérium által meghatározott speciális informatikai biztonsági értékelési és séma követelményeket. Jelenleg a MIBÉTS elfogadásának idıpontja bizonytalan. 8.4.1. Általános követelmények Az értékelıre vonatkozó általános követelmények két csoportba oszthatók: irányítási és mőszaki követelményekre. Az irányítási követelmények a szervezet minıségirányítási rendszerére, a dokumentumkezelésére, a szerzıdésekre, szolgáltatásokra és egyéb szervezeti folyamatokra vonatkoznak. A mőszaki követelmények alatt a személyzeti, elhelyezési és vizsgálati módszerekre vonatkozó elıírásokat kell érteni. Az általános követelmények teljesülését vagy a NAT akkreditációjával vagy az IHM kijelölési eljárásával lehet igazolni. Ez azt jelenti, hogy a labor felkészült a MIBÉTS szerinti értékelésekre. 8.4.2. Speciális követelmények Az általános követelmények teljesülése még nem jelenti a sémába való automatikus felvételt. Ehhez teljesíteni kell még további elıírásokat. A vizsgálólaboratóriumnak belföldi székhelyőnek kell lennie. El kell fogadnia a szakminisztérium technikai felügyeletét és ellenırzését a séma szabályainak megfelelıen. Továbbá el kell fogadnia a tanúsító által delegált személy részvételét bizonyos értékelési tevékenységekben. 8.4.3. Kiegészítı dokumentumok Az értékelı szervezetek mőködését szabályozó két fontos dokumentum kidolgozása, elfogadása jelenleg is folyamatban van. Az egyik az informatikai termékek és rendszerek biztonságának értékelését végzı szervezetekrıl szóló miniszteri rendelet, a másik pedig az értékelıknek szóló tanfolyam.

A miniszteri rendelet hatálya kiterjed az informatikai termékek és rendszerek biztonságának értékelését végzı szervezetekre, valamint az ezek kijelölésére irányuló eljárásban részt vevı személyekre és szervezetekre, továbbá az informatikai termékek és rendszerek biztonságának tanúsítására. A kérelmezıvel szembeni követelmények teljesülését – hasonlóan az elektronikus aláírási termékek értékeléséhez – a Nemzeti Hírközlési Hatóság vizsgálná. A vizsgálat során ellenırzik a kérelmezı szervezeti felépítését, mőködési és eljárási szabályait, szerzıdési feltételeit, a személyzet technikai felkészültségét, függetlenségét, a minıségirányítási rendszert, az értékelıi folyamatok megfelelı elkülönítését, az értékelık díjazásának függetlenségét az elvégzett értékelések számától, valamint minden olyan követelményt, melyet az egyéb elıírások megszabnak. A kijelölésre jelentkezı laboratóriumnak rendelkeznie kell az általa mőködtetett értékelési rendszer és az eljárások leírását tartalmazó részletes szabályzattal, ellenırzı rendszerrel és technikai valamint személyi háttérrel. Ezen kívül felelısségbiztosítást kell felmutatni. Ezeket a követelményeket a kijelölés után is fenn kell tartani.

8.5.

Külföldi megvalósítások

Mivel Magyarországon még nincs hagyománya a Common Criteriához (CC) hasonló értékeléseknek, érdemes utánanézni, hogy a világ más részein mi történik. Bemutatunk egy amerikai labort, ahol már régóta folyik CC értékelés, és egy tajvani példát, akik még a CCRAhoz sem csatlakoztak, de céljuk a módszertan minél elıbbi bevezetése. 8.5.1. Science Applications International Corporation Common Criteria Testing Laboratory Az Egyesült Államok számtalan kormányzati és civil ügynöksége, például a Védelmi Minisztérium, elvárja, hogy minden olyan informatikai termék és rendszer, mely nemzetbiztonságilag fontos információkat érkeztet, kezel, tárol és megjelenít, rendelkezzen Common Criteria szerinti minısítéssel. A SAIC CCTL az elsık között kapta meg az ilyen értékelésekhez való akkreditációt 2000-ben. Az elfogadási eljárás kezdetét a labor minıségirányítási kézikönyvének benyújtása jelentette. Ezek után vizsgálták meg a munkatársak kompetenciáját és az eljárások megfelelıségét. Az akkreditáció egy éven keresztül folyt, végül EAL1 és EAL4 közötti értékelésekre kaptak felhatalmazást. Mőködésük elsı két évében 4 értékelést folytattak le a séma fenntartóinak felügyelete mellett. A labor legfontosabb erıforrásai az értékelık. 2002-ben 11 értékelı dolgozott fıállásban a cégnél. İket a cég más osztályain dolgozó, CC ismeretekkel rendelkezı szakemberek segítik, amennyiben az ı szakértelmüket igénybe vevı értékelési feladat van. Ha szükséges, külsı munkatársakat is bevonhatnak.

A telephely külön szárnyban van, beléptetırendszeren keresztül lehet csak bejutni. Mindegyik iroda használható izolált és kontrollált laborként is, ahol felállítható a megbízó rendszere. Az internetes hozzáférésen keresztül web, e-mail és ftp kapcsolatot kapnak a munkatársak. Emellett további védelmet is biztosítanak kártékony kódok kiszőrésére. Dedikált laborhálózat szolgálja az értékelés környezetét. A Microsoft Visual SourceSafe program használatával oldják meg a zárt dokumentumokhoz való naplózott hozzáférést. A cég elsısorban magas garanciaszintekre és összetett termékekre fókuszál. A TCSEC sémában a CCTL jogelıdje végezte többek között a Microsoft Windows NT 4.0 és a Microsoft SQL Server 2000 értékelését. A tanúsítvány megszerzése után ide került többek között a Microsoft Windows 2000 értékelése is. 8.5.2. Telecommunication Technology Center A tajvani kormányzat is felismerte, hogy az informatikai termékek biztonsága mennyire fontos napjainkban. A TTC egy kormányzat által finanszírozott szervezet a Nemzeti Cheng Kung Egyetemen belül, mely 2004-ben indul, célja pedig egy Common Criteria tesztlabor létrehozása, mellyel elıre fel tudnak készülni a CCRA-ban való részvételre, melyhez az ország egy-két éven belül tervezi a csatlakozást. A TTC megbízása telekommunikációs, mősorszóró és informatikai biztonsági területek szakmai támogatására szól. Felügyelı szerve a tajvani hírközlési felügyelet. Elsı értékelési projektjük egy intelligens kártyával kapcsolatos. Ehhez külföldi, már mőködı laborok bevonását tervezik. A második értékelés tárgya egy tőzfal. A labor két-három éven belül szeretné a teljes CC tanúsítványt elnyerni. Ehhez azonban elıbb az országnak kell a CCRA-hoz csatlakoznia. Mind a laborral, mind a csatlakozással a tajvani termékeknek kívánnak versenyelınyt teremteni a világ IT piacán. Céljuk az, hogy a tajvani termékek jelenlegi fölényét kihasználva a CC népszerőségét is növeljék.

8.6.

Személyi követelmények

Mivel az emberi tényezı a leggyengébb láncszem a rendszerben, ezért hogy erısebbé tegyük ezt a láncszemet, szükség van: • • •

A tudatosság fejlesztésére. Képességek és ismeretek fejlesztésére, hogy a felhasználók biztonságosabban hajtsák végre feladataikat. Mély tudás elsajátítása, mely elegendı biztonsági programok tervezésre, fejlesztésére.

A felhasználókat rá kell ébreszteni felelısségeikre a biztonság terén, s megfelelı képzés segítségével megváltoztatni hozzáállásukat, viselkedésüket. Ez elvezet a felhasználók felelısségre vonásához is, hiszen addig nem lehet igazán hibáztatni ıket, amíg nem tudják a

megfelelı eljárásokat, s nem használják ıket. Ugyanakkor a büntetéseket sem lehet erıltetni, ha az alkalmazottak figyelmen kívül hagyhatják azokat. A számítógépes veszteségek sokkal nagyobb mértékben kapcsolhatóak az emberi tényezıhöz, mint minden más területhez együttvéve. Általában a következı okok miatt jönnek létre ezek a veszteségek: hibák, szándékos károkozás. Bár az oktatás, képzés miatt elsısorban a vétlen hibák mennyisége csökkenhet, a szándékos károkozás és engedély nélküli akciók száma is csökkenthetı, mivel megnı az alkalmazottak tudása a felelısségük és a büntetések kapcsán. Motiválni kell a képzésben résztvevıket, hogy használják és gyakorolják az elsajátított tudást. Annak elmagyarázása, hogy mi történhet a szervezettel a biztonság összeomlása esetén, gyakran hat az alkalmazottakra, hogy komolyan vegyék az intézkedéseket. A következı táblázat mutatja, melyik mire szolgál: Tulajdonság Szint Oktatás módja

Tesztelés módja Ráfordított idı

Tudatosság „Mi” Információ Média: -Videók -Hírlevelek -Poszter, stb. Igaz/Hamis, több választású teszt Rövid

Képzés(gyakorlati) „Hogyan” Tudás, gyakorlat Gyakorlati oktatás: -Órák -Workshop

Oktatás „Miért” Belátás Elméleti oktatás: -Szemináriumok -Háttéranyagok

Probléma megoldás

Esszé

Közepes

Hosszú

A tudatosság növelése arra szolgál, hogy emlékeztesse az embereket az alapvetı biztonsági intézkedések fontosságára (például ajtók zárására, kijelentkezés a munkaállomásokból, stb). Fontos, hogy megfelelıen kreatív és változatos legyen, hiszen egy biztonsági poszter lehet akármilyen jól megtervezett, egy idı után az emberek figyelmen kívül hagyják, egyszerően beleolvad a környezetbe a tekintetükben. A gyakorlati képzés vagy az átlagos felhasználók számára (például hogyan védjék a fizikai környezetet, a jelszavakat, jelentsék a biztonsági szabályok megszegését, stb.) vagy a gyakorlottabbak számára nyújt további ismereteket (például az adminisztrátorok hogyan implementáljanak, telepítsenek különbözı hozzáférés irányító rendszereket). Az oktatás háttértudást ad, mely gyakran az alkalmazottak karrierjének állomásait is jelenti. Egy példa, hogyan is nézhet ki egy hatékony oktatási program: • • •

•

A program határának, céljainak megállapítása Az oktatást végzı csoport létrehozása Az oktatást kapó célközönség kiválasztása (Nagyobb szervezeteknél a célközönség felosztására lehet szükséges. Például fel lehet ıket osztani a tudatosság szintjének, a munkakör, számítógépes tudás, használt rendszernek, technológiának, stb. megfelelıen) A vezetés és az alkalmazottak motiválása (Mindkét rész támogatását el kell nyerni. A vezetés tudatában van a biztonságból adódó veszteségeknek, az alkalmazottaknak meg kell érteniük, hogyan kapcsolódik a munkájukhoz az egész dolog)

•

A program elindítása, fenntartása, kipróbálása (Az oktatás módja, anyaga a hallgatóság számára szükséges legyen, igényeinek megfeleljen. Lehetıleg mindig naprakész legyen az oktatott anyag, hiszen a számítástechnika gyors fejlıdésével könnyen elavulttá válhat. Le lehessen mérni az adott program hatékonyságát, például a következıkkel: tesztek az oktatott anyag kapcsán, az oktatás elıtt és után bekövetkezett számítógépes incidensek száma, stb.)

9. Labor mőködtetése A laboratórium mőködése során több feltételnek kell megfelelni: • Szakmailag megalapozott színvonalú munkát kell végezni • Biztosítani kell a laboratórium infrastruktúrájának megfelelı mőködését • Az elvégzett vizsgálatok megfelelı dokumentáltságát biztosítani kell • Védeni kell mind a saját, mind pedig a bevizsgálás alatt álló rendszerrel kapcsolatos információkat

10.Vizsgálatok végzése A vizsgálatok végzésének folyamat a következı:

A tesztelés alapvetıen két fı szakaszból áll: • Teszt specifikálása o a vizsgálandó (biztonsági) funkciók meghatározása o az architektúra meghatározása o teszt készlet meghatározása o egyes teszt esetek elıállítása • Az teszt végrehajtása o teszt megtervezése o teszt konfiguráció meghatározása o teszt esetek végrehajtása o eredmények kiértékelése és jelentés készítése Az egyes tesztek meghatározása során elı kell állítani a tesztelendı biztonsági funkció feltétel meglétét vizsgáló teszt(ek)et. Ennek alapja a vonatkozó elıírás (szabvány, mőszaki leírás, stb.) A tesztkészlet elıállítása során a következı lépéseket kell megtenni: • a vizsgálandó biztonsági funkciók meghatározása – az egyes funkciókat meg kell határozni, mivel a teszt eseteket úgy kell majd elıállítani, hogy lehetıség szerint egy funkcióra koncentráljanak, ugyanakkor összességükben lefedjék az összes – értékelés célját képezı – funkciót. • az architektúra meghatározása – a teszthez szükséges architektúra meghatározása. Ide tartozik a vizsgált és a hozzá kapcsolódó rendszerek típusa, verziója, konfigurációja. A köztük lévı kommunikáció fajtája, konfigurációja, és más szükséges paraméterek. • teszt készlet meghatározása – azon teszt esetek készletének összeállítása, amely lefedi a vizsgált funkciót. Annak meghatározása, hogy mely eredményt esetén tekintjük sikeresnek az adott funkció vizsgálatát. • egyes teszt esetek elıállítása – a teszt készlet elemi lépéseit tartalmazó esetek elıállítása. A teszt eset létrehozása során meg kell határozni a következıket: o Elıfeltételek – a teszt eset futtatásához szükséges elızetes beállítások, állapotok, stb. o Teszt lépéseket – azokat a tennivalókat, amelyet a teszt végrehajtójának meg kell tennie a teszt végrehajtása érdekében.

o Értékelési feltételeket – azok a feltételek, amely alapján a teszt lépés sikeressége értékelhetı.

11.Infrastruktúra A vizsgáló laboratórium központi része az infrastruktúra. Ennek mőködtetése kritikus a laboratórium mőködése szempontjából. Amennyiben a laboratórium rendelkezik információvédelmi és minıségirányítási rendszerrel, akkor természetesen ezek elıírásait alkalmazni kell a rendszerre. Ezen túl azonban figyelembe kell venni, hogy az infrastruktúra részét képezi a vizsgálatoknak, így maximális precizitással kell a konfiguráció menedzsmentet végezni, mivel a vizsgálatoknak adott esetben megismételhetınek kell lenniük, illetve a rendszerben végzett változtatás. Célszerő az infrastruktúra mőködtetése során a következıket alkalmazni: • Legyen egyértelmő felelıse az infrastruktúranak, aki jóváhagyja az igényelt változtatásokat. • Legyen megfelelı felügyeleti és menedzsment rendszer, amely automatizált segítséget nyújt az infrastruktúra üzemeltetésében, • Legyen hibajegy kezelı rendszer, amely segítségével automatizálható a különbözı hibák és események kezelése és a megteendı javító és helyesbítı intézkedések. • Megfelelı tartalékok álljanak rendelkezésre, hogy a laboratóriumi infrastruktúrára meghatározott rendelkezésre állás biztosítható legyen.

12.Dokumentumkezelés A vizsgálatok dokumentáltsága alapvetı feltétele a laboratórium mőködésének. Ennek megfelelıen a laboratórium mőködése során a megfelelı dokumentumkezelı eljárásokat kell mőködtetni. Jelen esetben dokumentum alatt nem csak a szöveges jellegő dokumentumokat értjük, de minden olyan egyéb információtartalommal bíró adatot, amely a vizsgálat szempontjából lényeges. A vizsgálat során a dokumentumokat: • el kell készíteni • jóvá kell hagyni • ki kell bocsátani • módosítani • tárolni • és megsemmisíteni kell. A vizsgálatok elkészítésekor különös figyelmet kell arra fordítani, hogy a vizsgálat megállapításai kellı pontossággal legyenek rögzítve. Ez több lépéses folyamat. A vizsgálat során a jegyzıkönyv alapjául szolgáló nyers adatokat. Erre különbözı módszereket alkalmazhatunk: • Kézi jegyzetelés – lényeges az olvasható, világos, egyértelmő megoldás.

• Key-logger, screen-cam használata – minden billentyőleütést, illetve minden a képernyın történı változást regisztrál, késıbb egyértelmően visszakereshetık a vizsgálat során tett lépések • Hálózat-analizátor – a hálózatot is igénybe vevı vizsgálatok esetében indokolt lehet a teljes hálózati forgalom rögzítése. Az elkészült dokumentumokat felelıs által jóvá kell hagyni és biztosítani kell, hogy a minden olyan helyen elérhetı legyen, ahol szükség van rá. A dokumentumok egyértelmő azonosítására ki kell dolgozni a megfelelı eljárást. A dokumentumokban történt változtatásokat egyértelmően jelölni kell, és biztosítani kell, hogy az mindenhol az aktuális verzió álljon rendelkezésre. Az elavult dokumentumok elérhetıségét meg kell szüntetni, ügyelni kell arra, hogy érvénytelen dokumentum ne kerüljön felhasználásra. A dokumentumok tárolásának megkönnyítésére számos lehetıség van, célszerő valamilyen verziókontrollt is támogató dokumentum és/vagy csoportmunka rendszert bevezetni (pl.: subversion, Sharepoint, BSCW, stb.) A vizsgálatok során létrejött dokumentumok egy részét (általában a szerzıdéstıl függıen) bizonyítható módon meg kell semmisíteni.

13.Információ védelem A vizsgálatok során biztosítani kell az információ védelmet. Ha a vizsgáló laboratórium rendelkezik információvédelmi rendszerrel, akkor értelemszerően alkalmazni kell annak az elıírásait. Ezen túl azonban a következı pontokra különösen ügyelni kell: • A vizsgálat során idegen eszköz kerül a laboratóriumba. Ügyelni kell arra, hogy akár a hibás mőködésbıl kifolyólag, akár szándékosan ez ne veszélyeztesse az infrmációbiztonságot. Ezért, ahogy az már az infrastruktúra kialakítása során is megjegyeztük, ilyen vizsgálatok mindenképpen szeparált környezetben kell folytatni. • Mivel a legtöbb vizsgálat önmagában is sok bizalmas információt tár fel (pl. üzleti titkokat a vizsgált rendszerrıl) különösen fontos, hogy az egyes különálló vizsgálatok anyagait is szeparálva kezeljük egymástól.

14. Rövidítések jelentése és fogalomszótár BS – British Standard, brit szabvány CC – Common Criteria, közös szempontrendszer CCRA – Common Criteria Recognition Arrangement, a közös szempontok szerint kibocsátott tanúsítványok kölcsönös elismerésérıl szóló nemzetközi megállapodás CLEF – Commercial Evaluation Facility, kereskedelmi értékelı labor COBIT – Control Objectives for Information and Related Technology, információs és hozá kapcsolódó technológiák ellenırzési céljai EAL1-7 – Evaluation Assurance Level 1-7, biztonsági szintek FTP – File Transfer Protocol, fájlátviteli protokoll IEC – International Electrotechnical Commission, elektrotechnikai szabványosító szervezet IIS – Internet Information Services, webszerver a Microsoft-tól IP – Internet Protocol ISO – International Organization for Standardization, nemzetközi szabványosító szervezet MIBA – Magyar Informatikai Biztonsági Ajánlások MIBÉTS – Magyar Informatikai Biztonsági Értékelési és Tanúsítási Séma MITS – Magyar Információs Társadalom Stratégia NFS – Network File system, hálózati fájlrendszer NIST – National Institute of Standards and Technology, amerikai szabványosító hivatal NVLAP – National Voluntary Laboratory Accreditation Program, nemzeti önkéntes laboratórium akkreditációs program Rootkit – feltört rendszerre telepített, illetéktelen hozzáférést segítı szoftver SAIC – Science Applications International Corporation, amerikai tudományos/mérnöki cég SAIC CCTL – SAIC Common Criteria Testing Laboratory, a SAIC tesztelı laboratóriuma Sniffer – hálózati forgalmat figyelı eszköz TCSEC – Trusted Computer System Evaluation Criteria, kritériumok a számítógéprendszerek megbízhatóságának kiértékeléséhez TTC – Telecommunication Technology Center, távközlési technológiai központ UKAS – United Kingdom Accreditation Service, brit akkreditációs szolgáltatás UK ITSec Scheme – brit IT biztonsági séma UML – User Mode Linux, felhasználói módú Linux

IT BIZTONSÁGI ÉRTÉKELİ LABORATÓRIUM KONCEPCIÓ

Recommend Documents