KÖZIGAZGATÁSI OPERATÍV PROGRAMOK IT BIZTONSÁGI KÖRNYEZETE AZ IT BIZTONSÁGI SZABÁLYZATMENEDZSMENT KÖVETELMÉNYEI

KÖZIGAZGATÁSI OPERATÍV PROGRAMOK IT BIZTONSÁGI KÖRNYEZETE AZ IT BIZTONSÁGI SZABÁLYZATMENEDZSMENT KÖVETELMÉNYEI 1

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: 2

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 Az IT Biztonsági szabályzatmenedzsment követelményei IT biztonság; IT biztonsági követelmény; ajánlás Az IT biztonsági szabályzatmenedzsment követelmények a biztonsági rendszer kialakításának és fenntartásának (menedzselésének) követelményeit írja a KOP életciklusában. Szöveg, táblázat, ábra E közigazgatási keretrendszer egyéb dokumentumai KOP-ok során megvalósuló projektek, központi IT fejlesztési projektek e-közigazgatási Keretrendszer Kialakítása projekt MEH EKK Stratis Kft. E közigazgatási keretrendszer.doc Magyar V1 Végleges EKK_ekozig_IT_bizt_szabalyzatmenedzsment_080919_V1.doc Korlátlan 3

2. Verziókövetési táblázat A dokumentum neve Közigazgatási Operatív Programok IT Biztonsági környezete. Az IT Biztonsági szabályzatmenedzsment követelményei A dokumentum készítıjének neve Stratis Kft. A dokumentum jóváhagyójának neve A dokumentum készítésének dátuma 2008.09.19. Verziószám V1 Összes oldalszám 40 A projekt azonosítója e-közigazgatási Keretrendszer Kialakítása projekt 4

2.1. Változáskezelés Verzió Dátum A változás leírása V1 2008.09.19. MeH-nek átadott verzió V2 V3 5

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 6

4. Tartalomjegyzék 1. Metaadat-táblázat 3 2. Verziókövetési táblázat 4 2.1. Változáskezelés 5 3. Szövegsablon 6 4. Tartalomjegyzék 7 5. Elıszó 8 6. Bevezetés 9 7. Alkalmazási terület 11 8. Fogalom meghatározások 12 9. Az informatikai szabályzatmenedzsment célja, helye, szerepe 14 9.1. Célok 14 9.2. Kierjedés 14 10. Informatikai szabályzatmenedzsment tervezésének elvei 16 10.1. Tervezési elvek 16 10.2. Tartalmi elvárások 18 10.3. Az Informatikai Biztonsági Menedzsment rendszer kialakítása 18 10.3.1. Helyzetfelmérés 19 10.3.2. Erıforrás leltár 20 10.3.3. Kockázatfelmérés (Fenyegetettség- és sebezhetıség-elemzés) 20 10.3.4. Kockázatelemzés 21 10.3.5. Kockázatkezelés 22 10.3.6. Szabályzati környezet kialakítása 22 10.3.7. Eljárásrendek 23 10.4. Az Informatikai Biztonsági Menedzsment bevezetésének lépései 23 10.5. Az Informatikai Biztonsági Menedzsment fenntartása 24 10.6. Az Informatikai Biztonsági Menedzsment szervezete, szerepkörök 24 10.7. Szempontok KOP környezetben 25 11. IT Biztonság szabályzatrendszer érvényesítése 26 12. Az IT biztonsági szabályzatrendszer ellenırzése 28 13. A KOP megvalósítás pályáztatási feladatai 29 14. Projekt adatlap 32 15. Rövidítésgyőjtemény 33 16. Mellékletek 34 16.1. 1.sz. Melléklet Helyzetfeltárás tartalom minta 34 16.2. 2.sz. Melléklet Leltárfelvétel tartalom minta 35 16.3. 3.sz. Melléklet Veszélyforrás felmérés tartalom minta 36 16.4. 4.sz. Melléklet Kockázati értékek meghatározásának szempontjait tartalom minta 37 16.5. 5.sz. Melléklet Védelmi intézkedések specifikálása tartalom minta 39 16.6. 6.sz. Melléklet IBSZ tartalom minta 40 7

5. Elıszó Az informatikai biztonsági tevékenység nem nélkülözheti a megfelelı szintő vezetıi támogatást, elkötelezettséget. Az informatikai biztonság létrehozása egy folyamat, nem lehetséges egyik pillanatról a másikra kialakítani a megfelelı biztonsági szintet. Nem helyes ha esetenként, kampányszerően foglalkozik egy szervezet a biztonsággal, mivel ez a megoldás nem hatékony, nem építi ki az önmagát fenntartó és megújító folyamatot. A helyes az a megoldás, amely beépül a szervezet életében és a mindennapok során az alaptevékenység szintjén is jelen van és az egész tevékenységi kört áthatja. Az e-közigazgatási keretrendszer követelményei a tárgykörbe tartozó projektre, pályázatokra vonatkoznak elsısorban, de hatásuk (remélhetıleg) ennél szélesebb körben, a szervezet (és a megvalósításban résztvevık) egyéb tevékenységeire (a teljes informatikára) is kifejtik pozitív hatásukat.. Jelen dokumentum az e közigazgatási keretrendszer részeként, az informatikai biztonsági tevékenység menedzselésére irányuló tevékenységek követelményeit és mikéntjét írja le. Közvetlen környezetében található követelmény dokumentumok: Közigazgatási Operatív Programok IT biztonsági környezete és követelményrendszere IT Biztonsági követelményrendszer érvényesítésének módja IT Biztonsági Stratégia követelményei IT Biztonsági Politika követelményei IT Biztonsági szabályzatok követelményei 8

6. Bevezetés A Közigazgatási Informatikai Bizottság az ITB, majd KIETB ajánlások sorában kiadta a 25- ös számú ajánlását Magyar Informatikai Biztonsági Ajánlások címmel (MIBA), amely a központi szervezetek számára határozza meg az Informatikai Biztonságirányítási Rendszer (IBIR) kiépítésére és fenntartására vonatkozó feladatokat. A MIBA figyelembe veszi a szabályozási környezetet (84/2007 Kormányrendelet), a hazai és nemzetközi releváns standardokat (MSZ ISO 27001), a legjobb gyakorlatot. Jelen dokumentumban megfogalmazott, az informatikai biztonsági politika kialakítására vonatkozó követelmények összhangban vannak a MIBA (IBIR) vonatkozó fejezetével. Elıírás MSZ/IEC ISO 2700x 84/2007 Korm. rendelet 195/2005 Korm. rendelet Ajánlás MIBA MIBIK Követelmény és alkalmazási útmutató E-közigazgatási keretrendszer - IT biztonság szabályozási rendszere Biztonsági szabályzat menedzsment rendszer IT Biztonsági Politika IT Biztonsági Stratégia IT Biztonsági Szabályzat e-kop projektek informatikai biztonsági követelmény rendszere A fenti ábra szemlélteti az e-kop keretei között létrejövı projektekre ható informatikai biztonsági elvárások rendszerét. Ebbıl látható, hogy a jelenlegi dokumentum az alsó szinten helyezkedik el és összhangban van az ıt meghatározó két felsı szinten elhelyezkedı elıírásokkal és ajánlásokkal, azoknak egy praktikus, az alkalmazást elısegítı eljárásokat is tartalmazó vetülete. Az informatikai biztonsági szint emelésére tett erıfeszítések nem hozhatnak optimális eredményt, nem hasznosulnak az elvárt módon, ha nem teszünk lépéseket az eredmények fenntartása érdekében. Az informatikai biztonsági munkára is jellemzı, hogy: 9

Elsıdleges a szakmai mőködési (üzleti) szempont, az informatikai biztonság ennek érdekében fejti ki hatását, Be kell építeni a mőködési folyamatokba, ez garantálja a fenntarthatóságot, Rendszerszemléleti alapon kell fejleszteni, és folyamatként kezelni, Az elızı alapján folyamatként kell fenntartani, vagyis menedzselni kell, Ki kell alakítani a szervezetét, a mőködtetéshez szükséges szerepköröket, meg kell nevezni a felelıseit, Ellenırizni kell az alakulását (monitoring), a változásokat értékelni és javítani kell és vissza kell csatolni a folyamatba, A mőködés részeként kell tervezni és erıforrásokat biztosítani a fejlesztéshez és fenntartáshoz. Jelen szabályzatmenedzsment témájú dokumentum tartalmazza az informatikai biztonság menedzselésével kapcsolatos követelményeket. Ezek a követelmények érintik a: A e-kop projektek életciklusát, A menedzsment szakaszokat (PDCA ciklusok szerint), A folyamat szereplıit (felelısségek, teendık). Az életciklus szakaszai (projektek és pályázatok egyes szakaszai: Projekt megfogalmazás, Pályázat kiírása, Projekt tervezés, Pályázat írás, elbírálás, szerzıdéskötés, Projekt megvalósítás, mérföldkövek, Pályázat megvalósítás szakaszai, PEJ, Projekt teljesítés, zárás, Pályázat zárás, Eredmények fenntartása, idıszakos ellenırzés, jelentések. A szabályzatmenedzsment feladatainak és felelıségek meghatározása és személyhez kapcsolása az alapja az ellenırizhetı munkavégzésnek. Az alábbiakban az egyes érintett szerepköröket soroljuk fel: Projekt szponzor (projekt gazda), Projekt felügyelı bizottság (PFB), Projektmenedzser Projekt tagok, Pályázat kiíró, támogató szervezet, Pályázó szervezet, Megvalósító szervezet. Tekintettel arra, hogy a szerepkörök leírásakor mind a projekt, mind a pályázati környezetre érvényesen határozzuk meg a felelısségeket és feladatokat, az egyes szerepkörök között átfedések lehetnek. További átfedést okozhat, hogy a pályázati rendszer is (a megvalósítási szakasz) projektszerő körülmények között mőködik. 10

7. Alkalmazási terület A KOP biztonsági követelmények alkalmazása ajánlott minden közigazgatási informatikai rendszer esetében, de kötelezı azoknak az IT rendszerek esetében, amelyek csatlakoznak a Központi Rendszerhez vagy a fejlesztéshez, mőködtetéshez állami támogatásokat használnak fel, jogszabály kötelez alkalmazására. A biztonsági követelmények alkalmazása szervezeti szempontból kiterjed az informatikai rendszert üzemeltetı és informatikai rendszert fejlesztı szervezetre és tevékenységekre. Idıben a követelmények alkalmazása kiterjed az informatikai rendszerek teljes életciklusára (tervezés, fejlesztés/beszerzés, mőködtetés). Jelen dokumentum ajánlott azoknak a szervezeteknek (projekteknek), ahol az informatikai biztonság kialakítása, illetve folyamatos mőködtetése a cél. Az ehhez szükséges szabályozási teendık, szervezet és szerepkörök és feladatlépések kerültek megfogalmazásra, valamint a mellékletben mintákat és már ismert Ajánlásokra való hivatkozásokat adtunk meg a könnyebb alkalmazhatóság kedvéért. 11

8. Fogalom meghatározások Csatlakozó rendszer: A KOP programban megvalósuló, annak tárgyát képezı fejlesztés. Csatlakozó szervezet: A csatlakozó rendszert megvalósító (a megvalósításban részt vevı) szervezet. Felhasználó szervezet: Az a közigazgatási szervezet, amely az igényeiknek megfelelı közigazgatási informatikai rendszert megtervezi, finanszírozza megvalósítását és üzemeltetését (függetlenül, hogy saját forrásból vagy pályázati úton szerzett támogatásból), illetve használja. Fenyegetettség: Olyan körülmény, eszköz vagy esemény, amely az informatikai erıforrás biztonságára (bizalmasság, sértetlenség, rendelkezésre állás) negatív hatással lehet. IBIR: Informatikai Biztonságirányítási Rendszer ITB: Informatikai Tárcaközi Bizottság KIETB: Kormányzati Informatikai Egyeztetı Tárcaközi Bizottság Kockázat: A fenyegetések realizálásának valószínősége Kockázat elemzés: A kockázatok értékelése a bekövetkezés valószínősége és hatásuk figyelembevételével Kockázat kezelés: Kockázatcsökkentı intézkedések MIBA: Magyar Informatikai Biztonsági Ajánlások PDCA: Plan, Do, Check, Act menedzsment életciklus fázisok PEJ: Projekt Elırehaladási Jelentés Sebezhetıség: A fenyegetések bekövetkezését a különbözı sebezhetıségek teszik lehetıvé. A sebezhetıség a biztonság alanyának egy olyan tulajdonsága, hiányossága, vagy gyengesége, amely lehetıséget teremt egy fenyegetést megvalósító [kölcsön]hatás érvényesülésére. Sebezhetıségi ablak: Az az idıintervallum, amely alatt a szolgáltatások (vagy egy minimálisan elegendı részük) visszaállításra kell hogy kerüljön a szervezet érdekeinek maradandó károsodása nélkül. Támadási potenciál: A támadási potenciál a támadás erıssége, amelyre a következı tényezık hatnak: a megszerezhetı elıny nagysága, a sikeres támadáshoz szükséges szakértelem, idı, eszköz bonyolultsága. 12

Üzemeltetı szervezet: Az a szervezet, amely a közigazgatási informatikai rendszer üzemeltetését végzi. Ez a szervezet lehet maga Felhasználó szervezet, vagy egy külsı szolgáltató. Veszélyforrás: A veszélyforrás az az objektum, amely a biztonság alanyát veszélyeztetı hatást közvetlenül, vagy közvetve (áttételesen) kiváltja, vagy a veszélyeztetı kölcsönhatásban érintett. Veszélyforrások lehetnek a természeti és az épített környezet (ezek egyes összetevıi); technikai eszközök; vagy emberek, csoportok, szervezetek, stb. 13

9. Az informatikai szabályzatmenedzsment célja, helye, szerepe A szabályzatmenedzsment szerepe, hogy az elvárt biztonsági szintnek megfelelıen kialakítsa, érvényre jutassa és fenntartsa a szükséges informatikai biztonsági követelményeket, illetve az ezeket kielégítı (védelmi) intézkedéseket és az ehhez szükséges infrastruktúrát. Ez azt jelenti, hogy az informatikai biztonsági tevékenységek menedzselését értjük alatta, ami megfelel az MSZ ISO 27001 szerinti informatikai biztonsági menedzsment fogalomnak. Abból a sajátosságból adódóan, hogy jelenleg az e-kop területre fogalmazunk meg informatikai biztonsági követelményeket jelen dokumentum is erre a feladatkörre koncentrál. Nehezen elképzelhetı azonban, hogy miközben a KOP kiterjedésére (scope-ra) a követelményeknek megfelelı informatikai menedzsment rendszert alakít ki egy szervezet, akkor egyéb tevékenységeire, területeire nem alkalmazza ezeket az eljárásokat. Az optimális megoldás, ha a szervezet teljes mőködésére kiterjesztik az informatikai biztonsági rendszert (Informatikai Biztonságirányítási Rendszert, IBIR-t), hiszen ekkor hasznosul legjobban a felhasznált erıforrás és nem alakul ki kettısség az informatikai mőködésben és a vele szemben támasztott elvárásokban. 9.1. Célok A projekt eredményeként létrejön az informatikai biztonságot folyamatosan mőködtetı és fejlesztı rendszer a hozzá tartozó szabályzatokkal, folyamatokkal, szervezeti egységgel és szerepkörökkel. A tevékenység végcélja természetesen a mőködési folyamatokhoz (üzleti tevékenységhez) szükséges, biztonságos informatikai háttér megfelelı szintő biztosítása. Célok részletesen: A projekt (pályázat) kapcsán létrejövı fejlesztés feleljen meg a vonatkozó informatikai biztonsági elıírásoknak, A szervezet biztonságtudatos viselkedése, biztonsági érettsége fejlıdjön, Alakuljon ki a biztonságot szem elıtt tartó, azt megkövetelı vezetés, informatikai menedzsment, Váljon mindennapos gyakorlattá az informatikai biztonság fenntartása és fejlesztése, Az informatikai biztonság épüljön be a munkafolyamatokba, képezze azok szerves részét, Legyen világos és elfogadott, hogy a biztonság anyagi és erıforrás áldozatokkal jár, amelyek hosszútávon hasznosulnak. 9.2. Kierjedés Az informatikai biztonsági követelmények a KOP-ban megvalósuló rendszerre terjednek ki alapvetıen. Ez sajátos megközelítés, mivel nehéz egy szervezetet biztonsági szempontból ketté vágni és azt mondani, hogy ettıl-eddig vonatkoznak rá a biztonsági követelmények és a többi folyamat nem tartozik a követelmények hatókörébe. Ez a szervezeten belüli sok kapcsolat, közös adatbázisok, stb. miatt sem életszerő. Sok esetben ugyanazon munkatársak dolgoznak az így kettéosztott területen, ami tovább bonyolítja a helyzetet. Azt gondoljuk, hogy a projekt által a szervezetbe bevitt a követelmények által kikényszerített új szemlélet a teljes szervezetre pozitív hatással van, hiszen emeli a biztonsági tudatosságot, beépül a mindennapok tevékenységei közé. 14

Jelen dokumentumban a szabályzatmenedzsment feladatait, szervezetét, szerepköreit írjuk le, de nem adunk teljes módszertani leírást az egyes feladatlépések (pld. kockázatmenedzsment) elvégzéséhez. Ezek a tudnivalók megtalálhatóak a szabályzási környezet dokumentumaiban, itt csak néhány gyakorlati tudnivalóval és sablonokkal segítjük ezt a munkát. 15

10. Informatikai szabályzatmenedzsment tervezésének elvei Az informatikai biztonsági szabályzatmenedzsment rendszer alapfeladata a szervezet számára biztonságos informatikai mőködés megvalósítása. Akkor beszélhetünk informatikai biztonságról, ha az informatikai erıforrások megfelelnek a: Bizalmasság, Sértetlenség, Rendelkezésre állás hármas követelményének. Informatikai erıforrás alatt az informatikai mőködést megvalósító összes szükséges erıforrást (humán, infrastruktúra, hardver, szoftver, hálózat, dokumentáció, szállítói szerzıdések, stb.) értjük. A biztonsági rendszer kialakításakor a jelenlegi biztonsági helyzetbıl kell kiindulni. A biztonsági helyzet értékelésekor a szakmai, mőködési (üzleti) kockázatokat kell figyelembe venni, tehát nem csupán az informatikai problémákra kell koncentrálni, hanem azok a mőködést negatívan befolyásoló hatásaira is. A rendszert (szükséges intézkedéseket, fejlesztéseket, beruházást, szervezési lépéseket) úgy kell tervezni és megvalósítani, hogy a projekt ideje alatt érje el, valósítsa meg az elvárt informatikai biztonsági színvonalat. A tervezési szempontok közül az alábbiakat tartjuk a legfontosabbnak: Teljeskörőség alatt értjük, hogy mind a felmérés, mind a tervezés és kivitelezés kiterjedjen az összes lehetséges területre, veszélyforrásra. IBIR kialakítása esetén jellemzı, hogy egyes területekre több figyelmet fordítanak (pld. tőzfal, vírusvédelem, fizikai védelem), míg más területre nem marad energia (humán biztonság, üzletmenet-folytonosság). Egyenszilárdság a védelem hasonló szintő erısségét, kiépítettségét jelenti minden területen. Itt is érvényesül a leggyengébb láncszem elve, vagyis a tudatos támadó megtalálja a legkönnyebben támadgató területet. Rendszerszemlélet a munka minden lépésében nélkülözhetetlen. Az egyes intézkedések nem önmagukban állóak, hanem hatással vannak egymásra is. Optimális (hatásában és költségeiben) védelem kialakítása csak az összefüggések figyelembe vételével, rendszerszemlélettel alakítható ki. Az informatikai biztonsággal nem kampány szerően kell foglakozni. Ennek kialakítása és mőködtetése egy folyamat, vagyis állandóan jelen kell lennie a szervezet életében. Akkor vagyunk a legeredményesebbek, ha beépül a mindennapi tevékenységek közé, a mőködési folyamat részévé válik. Új mőködési (ügyviteli, üzleti) folyamat csak akkor indítható, ha annak biztonsági elemei is kialakításra kerültek és az alapfolyamatba integráltak. 10.1. Tervezési elvek Az informatikai biztonságmenedzsment rendszer mőködési modellje (sok menedzsment rendszerhez hasonlóan) a PDCA (Plan, Do, Check, Act) folyamatokra épül: Plan, vagyis a tervezési folyamat, amely a rendszer egyes elemeinek, vagy a teljes rendszernek a tervezését, kialakítását jelenti, 16

Do, vagyis a rendszer, vagy új elemeinek implementációja, a megvalósított területek üzemeltetése, Check, vagyis folyamatos ellenırzés és felülvizsgálat annak érdekében, hogy a gyengeségek, nem megfelelıségek napvilágra kerüljenek és javíthatóak, a rendszer továbbfejleszthetı legyen, Act, vagyis javítás, fejlesztés, új funkciók beépítése a rendszerbe, amely a folyamatos fejlesztést szolgálja. ISO 27001 (BS7799-2) Plan IBIR Kialakítása Érintett felek Do IBIR Implementációja és mőködtetése Fejlesztés, karbantartás és javítás ciklusa Act IBIR Karbantartása és javítása Érintett felek Check Informatikai biztonsági követelmények IBIR monitorozása és felülvizsgálata Menedzselt informatikai biztonság PDCA ciklus A fenti ábra a menedzsment feladatokat szemlélteti. Az egymást követı lépések folyamatosan hozzák létre és javítják az informatikai biztonságmenedzsment rendszert, amely az informatikai biztonsági szint fejlesztésének feltétele. Az ábrából jól látszik, hogy ez nem egyszeri tevékenység, hanem önmagába mindig magasabb szinten visszatérı folyamat. Az informatikai biztonság fejlesztése akkor a leghatékonyabb, ha beépül az egyéb fejlesztési folyamatokba. Ilyen például, ha egy szakmai mőködési (üzleti) terület indul, akkor az ügyviteli folyamat szerves részeként, attól nem elkülönülten kerül sor az informatikai biztonság szempontjainak az érvényesítésére is. Plan (tervezés) fázisban a biztonságnövelı intézkedés tervezése történik. Ekkor kell meghatározni az intézkedés technikai, rendszerbeli, folyamat, erıforrás (humán és pénzügyi) szükségleteit a beruházás (megvalósítás) és üzemeltetés bontásban. A tervet a szervezet egyéb tervezési területeivel együttesen kell kezelni és jóváhagyni, az erıforrásokat pedig biztosítani kell. A terv alátámasztása érdekében az indokoltságot (kockázat csökkenés, megtérülés) ki kell mutatni, amivel a gazdasági döntéshozó tiszta kép alapján tud dönteni. A terv elfogadása után indul a fejlesztési fázis. Do (megvalósítás, implementáció, bevezetés, üzemeltetés) fázis a teljes megvalósítási folyamatot és aztán az üzemeltetés folyamatát takarja. Az IBIR bevezetése esetén ez egy teljes rendszert jelent valószínőleg a mőszaki feladatokon kívül folyamatszervezés és szervezetfejlesztési lépésekkel, szerepkörök meghatározásával együtt. Amennyiben ez már csak egy meglévı biztonsági rendszer javítását szolgálja a feladat annyival egyszerőbb, 17

hogy az új intézkedést, feladatot kell a meglévı rendszerbe és folyamatba illeszteni és megfelelıen dokumentálni (kommunikálni). Check (ellenırzés) jelenti a biztonsági rendszer mőködésének folyamatos (vagy eseti) felülvizsgálatát annak érdekében, hogy mindig eleget tegyen a környezet változásából és a folyamatos javítási szándékból álló követelményeknek. Az ellenırizhetıség érdekében a kockázati szinteket, a biztonsági rendszer eredményességét kell folyamatosan mérni és az eredményeket elemezni annak érdekében, hogy mindig a leghatékonyabb módon tudjunk beavatkozni a biztonsági szint emelése érdekében. Szükség lehet a javító intézkedésre akkor is, ha bıvül az IBIR scope-ja (pl. új feladat, új szervezeti egység, új alkalmazás, eszköz kerül a rendszerbe). Act (beavatkozás) az ellenırzés által feltárt (további) biztonsági követelmények kielégítése érdekében dönteni kell a rendszer továbbfejlesztésérıl. Ez a döntés az inputja a Plan lépésnek, amely ebben az esetben már a rendszer biztonságának magasabb szintre emelését jelenti. Ahogy a fenti ábra is szemlélteti ez a folyamat mindig magasabb biztonsági szintet eredményez és biztosítja a rendszer folyamatos mőködtetését, menedzsmentjét. Az informatikai biztonsági rendszer készítésének szabályai: Az informatikai biztonsági ténykedés a szervezeti célokat szolgálja. Az összes biztonsági intézkedés a szervezeti küldetést szolgálja. Az IT biztonsági cél meg kell jelenjen a szervezet elsıdleges stratégiájában is. Az informatikai biztonsági megközelítés (létesítése, mőködtetése, fejlesztése) illeszkedjen a szervezeti kultúrához. Az informatikai biztonság váljon szerves részévé a vezetésnek! Az informatikai biztonságot költség hatékonyan kell megvalósítani! Nem szabad többet költeni a megelızésre, mint ha a kár bekövetkezne. Az informatikai biztonsági felelısségeknek egyértelmőnek kell lennie, az nem átruházható! Az informatikai biztonság teljes körő és összetett megközelítést igényel! Az informatikai biztonságot rendszeresen felül kell vizsgálni! Kommunikálni kell az informatikai biztonság értékét. 10.2. Tartalmi elvárások Az IBIR létrehozásakor alapvetı a folyamat kialakítása, amely meghatározza a PDCA teljes ciklus minden lépésében minek kell történnie, milyen szervezet érintett az adott feladat megvalósításában, milyen felelıségek és szerepkörök vesznek részt az egyes lépésekben. Az alábbiakban a rendszer létrehozásának egyes lépései kerülnek leírásra. Meg kell említeni, hogy a feladatlépéseket egyszerősített módon érinti a dokumentum és a megvalósítás egy lehetséges, a követelményeknek minimum szinten eleget tevı megoldásokat tartalmaznak a példák, vagyis ezektıl a bıvítés irányában el lehet btérni. 10.3. Az Informatikai Biztonsági Menedzsment rendszer kialakítása Az informatikai menedzsment (szabályzat menedzsment) folyamatos, a megfelelı biztonsági szint megteremtése, fenntartása és fejlesztése érdekében végzett tevékenység. Ennek a 18

tevékenységnek meg kell felelnie a vonatkozó elıírásoknak, rendelkeznie kell megfelelı erıforrásokkal, szervezettel és felelısökkel. A szervezetben ki kell alakítani azt a folyamatot és dokumentációs rendszert (politika, stratégia, szabályzatok, eljárások) amely garantálja, hogy ez a rendszer hosszútávon, eredményesen mőködjék, rendszeresen ellenırzésre és kiigazításra kerüljön. A rendszer kialakításának és mőködtetésének lépései az alább felsoroltakat tartalmazzák. Tekintettel arra azonban, hogy jelen fejlesztési projekten (pályázaton) belül nem várható el egy teljes mélységő és az össze lépést szakértıi szinten elvégzı teljes informatikai biztonságszervezési feladatsor (teljes projekt) elvégzése, valamint az, hogy a szervezet teljes mértékben tisztában legyen a jelenlegi biztonsági kockázataival, egyes tevékenységek kifejtésénél célszerően egyszerősíteni vagyunk kénytelenek. A rendszer kialakításának és mőködtetésének lépései tehát: Az informatikai biztonsági követelmények megismerése és megértése, A jelenlegi biztonsági helyzet megismerése, Helyzetfeltárás, Informatikai erıforrás leltár (a rájuk irányuló fenyegetettség és kockázatok megállapításához szükséges mélységben), Kockázatfelmérés, Kockázat elemzés, Kockázatok kezelése, Szabályzati környezet kialakítása, Menedzsmentrendszer bevezetése, Menedzsmentrendszer mőködtetése, Szervezet és szerepkörök. 10.3.1. Helyzetfelmérés Tekintettel arra, hogy az elvárásokat tartalmazzák a követelményrendszer egyes dokumentumai (illetve az ezek alapját képzı standardok, rendeletek lásd 10. pont), a szervezetnek tudnia kell, hogy milyen lépéseket kell tenni ezek elérése, megvalósítása érdekében. Ehhez az elvárásokon kívül a pillanatnyi biztonsági szinttel (hol tart a szervezet) is tisztában kell lenni, mivel ennek alapján lehet meghatározni a szükséges fejlesztéséket, tenni valókat. A biztonsági helyzetfelmérés az a fázis, amely a jelenlegi biztonsági helyzet meghatározására irányul és eredményeként megválaszolható a hol tartunk most kérdés. A helyzetfeltárás alkalmával minden lehetıséget figyelembe kell venni, ami hatással lehet az informatikai biztonságra. Elfogadott megközelítés amikor az informatikai erıforrásokat vesszük számba és vizsgáljuk, hogy milyen biztonsági rések lehetnek ezek mőködtetése, állapota következtében. Ebbıl a szempontból erıforrás alatt értünk minden, az informatikai mőködést megvalósító, arra valamilyen befolyással bíró erıforrást. Vagyis ilyen erıforrás csoportok az alábbiak lehetnek: Hardverek Szoftverek Alkalmazások Adatbázisok Hálózat Infrastruktúra (terem, légkondicionálás, árnyékolás, elektromos betáp, stb.) Humán Szervezet Dokumentációk Folyamat 19

Természetesen a következı pontban tárgyalt erıforrás leltár ennek érdekében és a szükséges mélységben értendı. A fenti erıforrás típusok között kitüntetett szerepe van a folyamatnak. Folyamat alatt értjük, amikor egy (vagy több) inputból, egy (vagy több) lépésben és erıforrás hatására, azok felhasználásával egy (vagy több) eredmény, output jön létre. A folyamat alfolyamatokból (lépésekbıl) állhat, van felelıse (folyamatgazda) és jellemzıen a folyamatok támogatását szolgálja az informatikai mőködés (természetesen vannak informatikai folyamatok is). A Helyzetfeltárás egy lehetséges tartalomjegyzéke a 1.sz Mellékletben található. 10.3.2. Erıforrás leltár Erıforrás leltár alatt itt nem teljeskörő (vagyon vagy mőszaki) leltár felvételére gondolunk. Szempont, hogy olyan elemek kerüljenek be (azok viszont mind), amelyeknek lehet biztonsági hatásuk. A leltár mélységénél szintén ezt a szempontot kell figyelembe venni (tehát nem szükséges pld. egy desktop-ról tudni, hogy milyenek a grafikus képességei, mivel ennek nincs biztonsági hatása). Azokat az attribútumokat és körülményeket viszont, amelyek az eszköz pótláskor, rendszer újraindításakor, a rendszergazda berendelésekor fontosak össze kell győjteni. Célszerően a leltár készítésekor kell felmérni és dokumentálni az egyes erıforrások kapcsolatait, a rendszer topológiáját. Ez abból a szempontból fontos, hogy meg tudjuk határozni egy erıforrás sérülésekor, hogy mely egyéb erıforrásokra van hatással. Pl. ha egy hálózati kapcsolat sérül, tudni kell, hogy mely szolgáltatások, alkalmazások sérülnek, vagy ha egy klíma tönkremegy ismerni kell, hogy mely szervereket kell leállítani, azokat ki kezelheti, milyen mentések szükségesek, mi a leállási sorrend, mely szolgáltatások, alkalmazások fognak leállni, kiket kell errıl értesíteni, és természetesen ki fogja javítani vagy szállítani a hibátlan, megfelelı paraméterekkel rendelkezı klímát. A Leltárfelvételkor alkalmazható egy lehetséges leltárív a 2.sz Mellékletben található. 10.3.3. Kockázatfelmérés (Fenyegetettség- és sebezhetıség-elemzés) A kockázat felmérés kiindulópontja annak megállapítása, hogy mely informatikai erıforrások milyen fenyegetettségeknek vannak kitéve, azoknak milyen a sebezhetısége. Természetesen az erıforrások nem csak magukban, egyedülálló módon értelmezendıek, hanem összefüggésükben. Ez azt jelenti, hogy pld. egy szünetmentes áramforrás meghibásodásakor nem csak az UPS egységre kell koncentrálni, hanem az általa táplált eszközre, az eszközön futó alkalmazásra, az általa nyújtott szolgáltatásra, illetve a támogatott folyamatra. Ebbel látható, hogy a leltár felvételekor az egyes elemek összefüggéseinek megismerése alapvetıen fontos. 20

Kockázatelemzés lépései A felmérésnek ki kell terjednie a veszélyforrások ellen a szervezetben foganasított védelmi intézkedésekre (kontrollokra) is. Meg kell határozni, hogy mely veszélyforrás ellen, hatásának csökkentésére milyen védelmi intézkedést hoztak, az intézkedések hatásosak-e, illetve az intézkedéseket betartják-e az érintettek (vannak-e dokumentált védelmi intézkedések, azok megfelelıek-e, illetve mőködtetik-e azokat). A feladat itt is összetett, mivel egyes intézkedések kiválthatják, illetve erısíthetik, gyengíthetik egymást. Ez azt jelenti, hogy a vizsgálatot rendszerszerően, az egymásra hatások figyelembevételével kell elvégezni. A kockázatfelmérés módja a szabályzatok és azok megvalósításának vizsgálata. Gyakorlatilag a meglévı dokumentumok kerülnek elemzésre (szabályzatok, elızı vizsgálatok megállapításai, stratégiák), hogy tartalmazzák-e a szervezetre vonatkozó követelmények megvalósításának módját és ezek megfelelıen kerültek-e meghatározásra. Ezek után interjúk és helyszíni vizsgálatok alkalmával kell megállapítani, hogy a gyakorlatban hogyan tartják be a leírt eljárásokat. Pld. ilyen vizsgálat lehet, hogy van-e írásos hozzáférési rendszer, létezik-e erre vonatkozó szervezeti politika amelyben rögzítik az elveket, van-e azonosítási trendszer, ezeket milyen módon szabályozták, milyen eljárások vannak a hozzáférések kiosztására, visszavonására és ezek hogyan kerülnek megvalósításra. A kockázatfelmérés (veszélyforrás felmérés) eredményeit dokumentálni kell. A 3.sz. Melléklet egy erre vonatkozó sablont tartalmaz. 10.3.4. Kockázatelemzés A kockázatelemzés során a kockázatfelmérés eredményeire támaszkodva értékeljük a szervezet (vagy egyes területek, szolgáltatások) biztonsági helyzetét. A kockázatelemzés eredménye a veszélyforrások relatív sorrendje, amelyek lehetnek kockázati osztályok, illetve a kockázatok forintosított értékei. A kockázatelemzés lehet kvalitatív vagy kvantitatív, de mindkettı kiindulása szakértıi felmérésen és becslésen alapul. Kvantitatív esetben a felmérés részletesebb és pontosabb, így a kockázati értékek is pontosabban meghatározhatóak. A Kvalitatív esetben kockázati osztályokat (érték intervallumokat) határozunk meg és az egyes veszélyforrások kockázatait ezekbe soroljuk be. A kockázatelemzés eredményeként létrejön a veszélyforrások kockázati értéke, vagyis kockázati sorrendje, amely területenként vagy a szervezetre is jellemzı kockázati értéket képvisel, illetve jelöli a magas kockázatú területeket amelyek kezelésére mindenképp intézkedéseket kell hozni. 21

A kockázati értékek ismeretében vezetıi döntés kérdése, hogy mely kockázatok csökkentésére hozunk intézkedést és mely kockázatokat vállalja fel a vezetés (most már a veszélyforrás és a kockázati értékek ismeretében). A kockázati értékek meghatározásának szempontjait a 4.sz. Melléklet tartalmazza. 10.3.5. Kockázatkezelés Kockázat kezelés alatt a kockázatok csökkentésére hozott intézkedéseket értjük (védelmi intézkedések vagy kontrollok). Egy védelmi intézkedés általában több veszélyforrás kockázatát is csökkenti és természetesen a kontrollok hatnak egymás területeire is, tehát összefüggésében kell vizsgálni hatásukat. A védelmi intézkedések specifikálása után meghatározható, hogy annak megvalósítása mibe kerül (szükséges fejlesztési, beruházási, szervezési, fenntartási költségek), így a kockázati értékkel (értékekkel) szembe állítva egy egyszerő megtérülés is kalkulálható. Természetesen a kockázatok csökkentése egy folyamat, jellemzıen több lépcsıben valósul meg. Fontos, hogy a szükséges költségek bekerüljenek a szervezet költségvetésébe és terveibe. Elsıként az alacsony költségő és nagy hatású (azaz nagy kockázati értéket csökkentı) intézkedéseket kell meghozni (ezek jellemzıen szervezési, szabályozási intézkedések). A kialakított védelmi rendszernek a kockázatokkal arányos hatást kell biztosítani. Természetesen lesznek területek, amelyre nem érdemes (gazdaságos) kontrollokat kiépíteni. Ezek, valamint azok amelyekre még nem tudtunk intézkedést hozni a maradvány kockázatok. A kockázatkezelés folyamatát (felmérés-elemzés-kezelés) a PDCA ciklusnak megfelelıen idıszakonként el kell végezni, mivel mind a támadási lehetıségek, technikák, mind a védeni kívánt területek és módszerek folyamatosan változnak. A védelmi intézkedések specifikálásának egy lehetséges sablonját az 5.sz. Mellékelt tartalmazza. 10.3.6. Szabályzati környezet kialakítása Egyértelmően az egyik legfontosabb és legeredményesebb informatikai biztonsági intézkedéshalmaz a megfelelı IT biztonsági szabályzatrendszer megalkotása, fenntartása és érvényesítése. A szabályzati struktúra felülrıl lefelé épül. A vezetıi elvárások magas szinten az Informatikai Biztonsági Politikában fogalmazódnak meg, a középtávú célok és a biztonságfejlesztési vízió az Informatikai Biztonsági Stratégiában kerülnek megfogalmazásra. A tevékenységek operatív meghatározása az Informatikai Biztonsági Szabályzatban, a rendszer specifikus üzemeltetési feladatok az Eljárásrendekben kell, hogy megtörténjenek. A szabályzati környezetet, struktúrát alkotják: Az Informatikai Biztonsági Politika Az Informatikai Biztonsági Stratégia Az Informatikai Biztonsági Szabályzat Eljárásrendek A szabályzatok tartalmazzák a felhasználók és az informatikai szolgáltatások, eszközök viszonyát. Ilyenek lehetnek az igénybevétel rendje, a hozzáférés és azonosítás szabályai, az 22

elszámolás, eszközhasználat, help desk elérés és szolgáltatások. A szabályzat az általános, mindenkire érvényes intézkedésektıl halad a specifikus felé és rögzíti, hogy kinek, mikor, mit kell csinálni a szabályos mőködés érdekében. Az Informatikai Biztonsági Szabályzat konkrét tartalmát és formai javaslatait a 6.sz. Melléklet tartalmazza. 10.3.7. Eljárásrendek Az informatikai biztonság mőködtetésének rendszerszintő (technikai szintő) szabályozása az eljárásrendekben történik. Az eljárásrend egy bizonyos védelmi intézkedés alacsony szintő feladatinak végzését szabályozza. Ilyen lehet pld. egy vírusvédelmi eljárásrend, amely a vírusvédelmi szoftverrel és igénybevételével kapcsolatos tényleges teendıket rögzíti. Eljárásrend születhet a mentések elkészítésérıl, tárolásáról, a patch-elés módjáról. Az eljárásrend részletesen tartalmazza minden esetre, hogy kinek, mikor, mivel, mit kell csinálni, ki a felelıs, az engedélyezı, ki végzi a feladatot. Az eljárásrend olyan részletes, hogy segítségével a tevékenységet végig lehessen csinálni és az elvárt eredményt el lehessen érni. A szabályzatokat és eljárásrendeket rendszeresen oktatni kell és a munkaköri leírásokban hivatkozni lehet rájuk. 10.4. Az Informatikai Biztonsági Menedzsment bevezetésének lépései A szabályozási struktúra kialakítása után létre kell hozni azt a biztonsági környezetet, amely megfelel az elıírásoknak és a szervezet sajátosságainak. A vezetıi elkötelezettség és szerepvállalás, folyamatos támogatás és ellenırzés kiemelt fontosságú, mivel csak így várható el a munkában résztvevıktıl és az érintettektıl a tudatos rendszerépítés és a követelmények betartása. A biztonsági rendszert a 11.3 pontban leírtak szerint kell kialakítani. A védelmi intézkedések között várhatóan lesz amelyik nem szabályozási vagy szervezési kérdés, hanem fejlesztést, beszerzést és implementációt, tesztelést, bevezetést (változás kezelést) igényel. Ez azt jelenti, hogy az új eszköz, szoftver üzembe állítása a szervezet változás kezelési eljárása szerint kell hogy történjék. Természetesen új eszközök beszerzése, üzembe állítása, installálása, stb. Nem egy pillanat alatt történik, vagyis a biztonsági rendszer folyamatosan épül. Ennek tervszerően és fokozatosan kell történnie, amelyre érdemes lehet projekteket szervezni, indítani. A biztonsági rendszer kiépítésének lépéseire akciótervet (projekttervet) kell készíteni és ennek mentén kell a rendszert kialakítani. Amennyiben biztonsági rendszer kialakítása hosszabb távon történik, akkor szükséges az IT stratégiában is megjeleníteni, illetve a fenntartását, fejlesztését betervezni. Figyelembe kell venni, hogy a biztonsági környezet mőködtetése, a szabályzatok naprakészen tartása folyamatos tevékenység, tehát plusz erıforrás igénye van. A menedzsment folyamatok kialakításánál arra kell törekedni, hogy: minden szükséges feladatot azonosítsunk teremtsük meg a feladat elvégzésének feltételeit, rendeljünk hozzá erıforrásokat a feladatok elvégzésének módját szabályozzuk a feladatokhoz felelısöket, végrehajtókat rendelünk alakítsuk ki a mőködtetı folyamatokat 23

a végrehajtásának állását mérjük és értékeljük, az eredmények alapján visszacsatolunk javító intézkedéseket hozunk és vezetünk be 10.5. Az Informatikai Biztonsági Menedzsment fenntartása A kialakított rendszer akkor mőködik az elvárásoknak megfelelıen ha megfelelı figyelmet (erıforrást) biztosítunk a kontrollok mőködtetésére, felülvizsgálatára és javítására. A szabályzati struktúra, a szabályzatok tartalmi változtatására mindenképen szükség van, amennyiben: változik a szervezeti struktúra (új szervezeti egység alakul, új munkakört hoznak létre vagy szőnik meg) változik az IT eszközállomány, az architektúra vagy topológia (hardver, szoftver, alkalmazás, hálózat) változik a szabályozási környezet (a biztonsági szintre ható kényszerek) változik a tevékenységi kör, a kezelt adatok érzékenysége változik a támadási potenciál Természetesen a változást okozhatja a kockázatok csökkentésének igénye is. Jellemzı, hogy a mőködtetés és ellenırzés folyamatosan történik, a változtatások azonban esetiek és hosszabb távon fejtik ki hatásukat, vagyis ne csak a mára tervezzük azokat, hanem hosszabb távra. A változások bevezetésére (tesztelés, oktatás, élesítés) szerencsés esetben a szervezet rendelkezik változás kezelési eljárással és ezt alkalmazza a biztonsági rendszer változtatása esetében is. A szabályzatokban történı változtatásnak szintén kell legyen a szervezetben kialakított módja. A szabályzatok életciklusának fontosabb szakaszai: szabályzat alkotás (tartalmi és formai kialakítása, megírása) jóváhagyás kiadás, hatályba léptetés alkalmazás felülvizsgálat módosítás, verzió kezelés visszavonás, kivezetés Az informatikai biztonsági szabályzatokat a szervezet elsı számú vezetıje adja ki. 10.6. Az Informatikai Biztonsági Menedzsment szervezete, szerepkörök Az informatikai biztonság az informatika külön szakterülete, amely maga is igen sokrétő tudást és megközelítést igényel. Jellemzı, hogy a vele foglalkozó felelıs (biztonsági vezetı, menedzser, megbízott) az informatika területérıl kerül ki és az informatikai vezetı a közvetlen fınöke. Így alakulhat ki az az összeférhetetlen állapot, hogy azt a területet kell ellenıriznie, amely vezetıjétıl függ az egzisztenciája. Ez a gyakorlat tehát nem helyes, a függetlenített, vagy az elsı számú vezetı alá, vagy a biztonsági vezetı alá kell szervezni az informatikai biztonság szervezetét, felelısét. Kis szervezetben ez a szerepkör nem testesül meg külön függetlenített munkakörben, de az összeférhetetlenséget szem elıtt kell tartani. Informatikai Biztonsági Szervezet elhelyezése a szervezeti struktúrában tehát lehet: az elsı számú vezetı alá rendelt 24

a biztonsági szervezeten belül de mindenképen az informatikai vezetéstıl független. Sajátossága az informatikai biztonsági munkának, hogy tervezése és szervezése az informatikai biztonsági vezetı dolga, az ellenırzés és néhány funkció (pld. hozzáférési jogok meghatározása) a szakmai vezetés feladata. Az informatikai biztonság menedzselésére a továbbiakban egy felelıs vezetıi szerepkört írunk le, természetesen a hozzá delegált feladatok elvégzését a fenti elvek betartásával megoszthatja másokkal is. Az alábbiakban az Informatikai Biztonsági Vezetı feladatai soroljuk fel: tervezi, szervezi, ellenırzi az informatikai biztonsági feladatokkal kapcsolatos tennivalókat kialakítja a biztonságirányítási rendszert, gondoskodik a fenntartásáról képviseli az informatikai biztonsági területet, tartja a kapcsolatot a szervezeti vezetıkkel a szervezet minden dolgozójában tudatosítja az informatikai biztonság szerepét, fontosságát meghatározza és szabályozza az informatikai biztonságra irányuló tevékenységeket, a szabályzatokat érvényre juttatja gondoskodik a szükséges erıforrásokról a kockázatokkal arányosan, folyamatosan fejleszti az informatikai biztonsági területet a PDCA ciklusnak megfelelı rendszert alakít ki gondoskodik, hogy a szervezet informatikai biztonsági szintje feleljen meg a törvényi szabályozásnak, az irányadó standardoknak 10.7. Szempontok KOP környezetben A Kormányzati Operatív Programban való részvétel, vagy kiemelt projektek végrehajtása, pályázati támogatások felhasználása nem történhet az informatikai biztonság figyelmen kívül hagyásával. A létrehozandó új értékeknek, a fejlesztések eredményeinek, az ezekben résztvevı szervezeteknek meg kell felelniük az elvárható informatikai biztonsági szintnek, amelyet nem csak létrehozni, hanem fenntartani is szükséges. Tekintettel arra, hogy a fenti projektekben induló különbözı szervezetek különbözı informatikai biztonsági szintet, érettséget képviselnek szükséges egy általános követelmény rendszer, amelyet betartva garantálható, hogy: az informatikai biztonság egységesen legyen képviselve a megvalósítás során hogy a projekt eredményeként elkészülı rendszerben az informatikai biztonság egységesen legyen jelen hogy a résztvevı szervezetekben kialakuljon az informatikai biztonság elvárható szintő rendszere az informatikai biztonságirányítási rendszer a késıbbiekben is hatékonyan mőködjön, fenntartható legyen. 25

11. IT Biztonság szabályzatrendszer érvényesítése Az informatikai biztonsági szabályzatrendszer elemeit, tartalmi elvárásait az elızı fejezetekben soroltuk fel. A szabályzatrendszer kialakításának lépései, szervezete és felelıseinek feladatai, illetve az ezekkel kapcsolatos elvárások is ismertetésre kerültek. Az alábbiakban azon sajátosságokat igyekszünk összefoglalni, amely jelen követelményrendszer alkalmazására vonatkozik. A szabályzatmenedzsment rendszer nincs (egyformán vagy egységesen) kialakítva minden résztvevı szervezetnél. A résztvevı szervezetek nem rendelkeznek ezen a téren tapasztalattal, szakértıvel. Ezekbıl adódik, hogy nem azonos szintrıl indulnak a KOP-os projektek megvalósításában, viszont a velük szembeni elvárások erre nem lehetnek tekintettel. Tipikus lesz a projektek magvalósítása során, hogy a résztvevı szervezetek nem lesznek tisztában a pillanatnyi, valós informatikai biztonsági helyzetükkel, melynek hiányában nehéz lesz meghatározni, tervezni azokat a teendıket és erıforrásokat, idıszükségletet amely a kívánt szint eléréséhez szükséges (ebben nyújt segítséget az önértékelés amely a Biztonsági Stratégia Követelményei dokumentum egyik melléklete). Ez a nehézség csak körültekintı munkával és tartalékok beépítésével hidalható át. A projekt során a kíván szabályzatrendszer csak fokozatosan alakul ki. A benne meghatározott intézkedések bevezetése, a mőködtetéséhez szükséges feltételek (szervezeti, szervezési, mőszaki, infrastrukturális) csak hosszabb távon alakítható ki. Ezt a sajátosságot az ellenırzések során, a pályázatok, tervek elbírálásakor kell figyelembe venni. Az Informatikai Biztonsági Szabályzatrendszer aktualizálása: Eseti karbantartás: A karbantartás lehet eseti jellegő, ez szükséges ha a környezet, a szervezet a projekt, tehát a cél, a kiterjedés olyan változáson megy keresztül, amely korrekciót igényel a szabályozás területén is. Eseti aktualizálás szükséges abban az esetben is ha a jogszabályi környezet, a tulajdonosi elvárás olyan mértékben változik, hogy a meglévı szabályzatrendszer már nem felel meg az új elvárásoknak. Lehet ok eseti karbantartásra ha informatikai szolgáltatások szőnnek meg, új területek, szolgáltatások jelennek meg, új informatikai technológiák kerülnek bevezetése, informatikai technológiák alkalmazása szőnik meg, stb. Rendszeres karbantartás: Rendszeres karbantartás igényel a szabályzatrendszer az aktualitásának megtartása érdekében. Az Informatikai Biztonsági Szabályzatrendszer folyamatos karbantartása a KOPban résztvevı szervezet feladata. Amennyiben a változások valamely szabályzat, vagy szabályzatok módosítását teszik szükségessé, akkor ezt el kell végezni, és az adott szervezetre vonatkozóan a szervezet vezetıjéhez jóváhagyásra fel kell terjeszteni. A szükséges változtatásokat a megváltozott igények, célok felismerésekor, a kiegészítéseket lehetıleg az új tevékenység, szolgáltatás megkezdése elıtt kell kezdeményezni és megvalósítani. 26

Az egyes informatikai biztonsági dokumentum változtatása után felül kell vizsgálni és aktualizálni kell az összes érintett dokumentumot, mőködési és biztonsági területet, hogy amennyiben a változtatás érintette azokat, úgy az aktualizálást ott is el kell végezni. 27

12. Az IT biztonsági szabályzatrendszer ellenırzése Az szabályzatrendszer egyes dokumentumainak ellenırzési tevékenységeit az egyes dokumentumoknál ismertettük. Itt csak a rendszert érintı ellenırzésekre, az összefüggésekre koncentrálunk. Ellenırzött terület igen részben nem nem releváns A kialakított szabályzatrendszer felépítése megfelel az elvárásoknak A szervezet rendelkezik MSZ ISO/IEC 27001 tanúsítvánnyal, és az ott meghatározott módon készült az IBIR Vezetıi elfogadás megtörtént Szervezet kialakítása megtörtént Informatikai Biztonsági Vezetı (Felelıs) személye meghatározott Kialakításra került a PDCA szerinti szabályzatmenedzsment rendszer A kialakított rendszer integrált a napi tevékenységbe, folyamatokba A jogszabályokat, szabályzatokat, ajánlásokat figyelembe vették Az IT biztonsági felelısségek magas szinten meghatározásra kerültek az egyes szakterületeken Figyelembe vették a szervezet (a projekt) biztonsági érzékenységét A vezetıi elkötelezettség kellı hangsúllyal jelenik meg Az Informatikai Biztonsági Szabályzatrendszer meghatározza: Kockázat alapú megközelítést Periodikus (évente egyszer) felülvizsgálatát Kapcsolódást más szabályzatokhoz A szervezetben betöltött szerepét, vezetıi elkötelezettség fontosságát Biztonsági tudatosság fejlesztését Biztonságirányítási rendszer fenntartását Szervezetei és felelısség kérdéseket Az Informatikai Biztonságirányítási Rendszer életciklusa (kiadás, karbantartás, visszavonás) A szabályzatrendszert egyeztették, és érvénybe léptették Elfogadható megoldás 28

13. A KOP megvalósítás pályáztatási feladatai Szakasz Szponzor Pályázat készítı, pályázó szervezet Kiírás A kiíró feladata az, hogy egyértelmő elvárásokat fogalmazzon meg az e- közigazgatási keretrendszer ismeretére, alkalmazására vonatkozóan. A téma/mőszaki tartalom megfogalmazásakor kell meghatároznia, hogy az IT biztonsági követelmények melyik szintjét jelöli meg (melyik erısségi fokozatát) mint elérendı célt. A kiírásnak kell tartalmaznia az értékelés szempontjait, a súlyozás értékeit, amely mellett az értékelés történni fog. A kiírásban szerepelnie kell az elszámolás és átvétel feltételeinek, a szakmai beszámolók és pénzügyi elszámolás tartalmi elemeinek, a megvalósulásra jellemzı indikátorokat és számszerő mutatókat Pályázatkészítés A pályázat készítésekor (a pályázat megfogalmazásának idıszakában) tisztában kell lenni a pályázó saját biztonsági helyzetével, védelmi képességeivel. Ismerni kell azt a biztonsági szintet, amit a tervezés idıszakában pályázó képvisel, mivel ezt kell összevetni azokkal a követelményekkel, amit az e- közigazgatási keretrendszer elvár az adott projekt esetében. A pályázatban kell leírni, hogy a szabályzatrendszerbıl az elkészítendı Informatikai Biztonsági Politika megfelel (amennyiben már létezik), illetve az elsı szakaszban a követelményrendszer szerint elkészül.. Értékelés A kiírásban meghatározott pontrendszer szerint kell értékelni követelmények kielégítésének jelenlegi állapotát és a keretrendszer érvényesítésének vállalásait. Projekttervezés Tervezéskor kell megtervezni azokat 29

Szakasz Szponzor Pályázat készítı, pályázó szervezet a szakmai lépéseket és a szükséges erıforrásokat, amelyek szükségesek a keretrendszerben meghatározott Informatikai Biztonsági Szabályzatmenedzsment rendszer kialakításához. Figyelemmel kell lenni arra, hogy az ellenırzés kiterjed a megvalósított rendszer fenntartási idıszakára is. Szerzıdés A Támogatási/Megbízási szerzıdésnek kell nevesítenie azokat a konkrét e-keretrendszer hivatkozásokat, amelyekben a kívánt követelmények meg vannak határozva. Garanciákat kell kialakítani és szankciókat nevesíteni a követelmények betartásának elmulasztása esetére, meg kell fogalmazni az ellenırzések és elszámoltatás rendjét mind a projekt mind a fenntartás idıszakára. Megvalósítás Ellenırzés, idıszakos beszámoltatás Átvétel / teljesítés Az idıszakos pályázati beszámolóknak, a projekt elırehaladási jelentéseknek kell tartalmazniuk a keretrendszer követelményeinek teljesítését, annak állását jellemzı mutatókat, indikátorokat. Csak a keretrendszer követelményeit megfelelı szinten realizáló teljesítés fogadható el (elutasítás, pótlás, új határidı, szerzıdésmódosítás). A szerzıdéses szakaszban kell figyelni arra, hogy a követelmények a teljes projektre érvényesek, vagyis ha több szereplı van (konzorcium pályázik, alvállalkozók vannak), akkor egyes követelmények minden érintettre kiterjednek. A megvalósítás ideje alatt kell kialakítani a fenntartási garanciákkal együtt az Informatikai Biztonsági Szabályzatmenedzsment rendszert. A pályázatok megvalósítását és aztán fenntartását egy monitoring rendszer alapján ellenırzik. Ebben meghatározott idıszakonként szakmai és pénzügyi elszámolást kell teljesítenie a projektet megvalósító szervezeteknek. Az elszámolások formája és tartalma is szigorúan meghatározott és alapvetı célja, hogy a felügyelı szervezet folyamatában lássa a projekt menetét, és tervezni tudja a támogatás címén kifizetendı összegeket. Ezekben az elszámolásokban az informatikai biztonsági feladatok állását és a pénzügyi felhasználásokat a meghatározott módon kell jelenteni. A teljesítés, amikor a projekt elérte célját és megvalósultak a szerzıdés mőszaki és pénzügy mellékletében vállaltak és elfogadásra kerültek a projekt elszámolásai és termékei. Ezek között kell lennie az 30