ÚTMUTATÓ AZ IT BIZTONSÁGI SZINTEK MEGHATÁROZÁSÁHOZ ÚTMUTATÓ 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
Meta adat-táblázat Megnevezés Leírás Cím (dc:title) Útmutató az IT biztonsági szintek meghatározásához Kulcsszó (dc:subject) IT biztonság; IT biztonsági szint; útmutató; IT biztonsági követelmény Leírás (dc:description) Az e-közigazgatási projektek tervezése és megvalósítása során elengedhetetlen, hogy az adott projekt megfelelı IT biztonsági mőszaki követelmények alapján végezze a munkát. Annak elkerülésére, hogy a projektek önkényesen határozzák meg, vagy akár teljesen figyelmen kívül hagyják ezeket a tényezıket, elkészült egy háromszintő besorolás, és mindhárom kategóriához meghatározásra került egy olyan minimális vagy tipikus IT biztonsági mőszaki követelményeket tartalmazó követelményrendszer, amely az adott projektre nézve kötelezıen elıírandó, betartandó és ellenırizendı. Jelen Útmutató a konkrét projektek IT biztonsági osztályba sorolásának módszerét írja le. Típus (dc:type) szöveg Forrás (dc:source) Kapcsolat (dc:relation) Terület (dc:coverage) Létrehozó (dc:creator) e-közigazgatási Keretrendszer Kialakítása projekt Kiadó (dc:publisher) MEH Résztvevı (dc:contributor) HunGuard Kft. Jogok (dc:rights) Dátum (dc:date) 2008.08.22. Formátum (dc:format) MS Word doc Azonosító (dc:identifier) Nyelv (dc:language) magyar Verzió (dc:version) 1.01 Státusz (State) átadott verzió Fájlnév (FileName) EKK_ekozig_ITbiztonsagiszintekmeghatarozasa_080822_V101.doc Méret (Size) 378 KB Ár (Price) Felhasználási jogok (UserRights) 3
Verziókövetési táblázat (a szabvány második oldala) 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 2008.08.22. Verziószám 1.01 Összes oldalszám 39 A projekt azonosítója EKK_ekozig Útmutató az IT biztonsági szintek meghatározásához HunGuard Kft. Változáskezelés Verzió Dátum A változás leírása V0.8 2008.07.07. Elıminısítésre átadott verzió V0.9 2008.07.24. Ellenırzött, javított verzió V1.0 2008.07.25 Átadott verzió V1.01 2008.08.22 Hivatkozások táblázatos megadása 4
Tartalomjegyzék Meta adat-táblázat... 3 Verziókövetési táblázat (a szabvány második oldala)... 4 Változáskezelés... 4 Tartalomjegyzék... 5 1. Elıszó... 6 2. Bevezetés... 6 3. Alkalmazási terület... 7 4. Rendelkezı hivatkozások... 8 5. Fogalom-meghatározások... 10 6. Az IT biztonsági szintek meghatározása... 11 6.1. A kockázatkezelés általános megközelítése... 11 6.1.1. A kockázatkezelés fıbb szempontjai... 11 6.1.2. Kockázatbecslés/felmérés... 12 6.1.3. A kockázatok csökkentése... 15 6.2. Az IT biztonsági szintek meghatározása a biztonsági kategorizálás módszerével... 17 6.2.1. Biztonsági célok és kihatási szintek... 18 6.2.2. Információ típusok és kihatási szintek meghatározása... 20 6.2.3. Informatikai rendszerek biztonsági kategorizálása... 23 6.2.4. A rendszer biztonsági osztályba sorolás egyéb szempontjai... 24 6.3. Minimális IT biztonsági követelmények... 25 6.3.1. A kezdeti alapkészlet kiválasztása és testre szabása... 26 6.3.2. A testre szabott alapkészlet kiegészítése... 31 6.3.3. A biztonsági intézkedések aktualizálása... 33 7. Mellékletek... 36 8. Bibliográfia... 37 9. Rövidítésgyőjtemény... 38 10. Fogalomtár... 39 5
1. Elıszó A közigazgatásban alkalmazott rendszerekkel szemben támasztott egyik követelmény, hogy informatikai biztonsági szempontból megfelelıek legyenek. Az IT biztonsági mőszaki követelmények olyan óvintézkedések (ellenintézkedések), melyeket az informatikai rendszer valósít meg, illetve hajt végre, a rendszer hardver, szoftver vagy förmver összetevıiben megvalósuló mechanizmusok segítségével. Jelen projekt keretében készített Követelmény elıírás az egyes biztonsági szintekhez határozza meg a biztonsági mőszaki követelményeket. Jelen Útmutató dokumentum a konkrét alkalmazások IT biztonsági osztályba sorolásának módszerét írja le. Jelen dokumentum szorosan kapcsolódik az alábbi dokumentumokhoz: Minta biztonsági kategorizálás c. Segédlet [03], IT biztonsági mőszaki követelmények a különbözı biztonsági szintekre c. Követelmény elıírás [02], Rendszerekre vonatkozó értékelési módszertan c. Útmutató dokumentum [06]. 2. Bevezetés Az e-közigazgatási projektek tervezése és megvalósítása során elengedhetetlen, hogy az adott projekt megfelelı IT biztonsági mőszaki követelmények alapján végezze a munkát. Annak elkerülésére, hogy a projektek önkényesen határozzák meg, vagy akár teljesen figyelmen kívül hagyják ezeket a tényezıket, jelen projekt keretében elkészült egy minimális vagy tipikus IT biztonsági mőszaki követelményeket tartalmazó követelményrendszer [02]. Ahhoz, hogy a biztonsági mőszaki követelmények általában elérjék céljukat, és az adott szolgáltatás tényleges biztonságát szolgálják, kielégítsék a velük szemben támasztott reális követelményeket, elég erısek és hatékonyak, ugyanakkor megvalósíthatóak legyenek, a szolgáltatás (IT termék, vagy rendszer) alapfeladataiból, a mőködési környezetbıl és feltételekbıl kiindulva kell meghatározni ıket. A meghatározás módja többféle lehet, a nemzetközi és hazai szakirodalom, valamint a szabványok és legjobb gyakorlatok különbözı eljárásokat kínálnak, de minden esetben egy fáradtságos és hosszú folyamat eredményeként adhatók meg. A megoldások általában a fenyegetettségek feltárásával, részletes kockázatbecslés után, kockázatkezelési eljárás keretében (MSZ ISO/IEC 17799 [04], ISO/IEC 27001 [05]) születnek meg, vagy magas szintő és jelentıs mértékő elızetes szakmai munkát követıen (pl. Common Criteria Védelmi Profiljai [08]) azok felhasználásával vezethetnek eredményre. A projekt keretében kidolgozásra került követelmény elıírás háromszintő besoroláson alapul, melynek fontossága abban rejlik, hogy egy szolgáltatás, vagy IT rendszer esetében könnyen meghatározható a megkívánt IT biztonsági szint, és mindhárom szinthez konkrét IT biztonsági mőszaki követelmények tartoznak. Az amerikai kormányzati és közigazgatási rendszerekben is használt, javasolt eljárás használatával (NIST SP 800-53 [07], FIPS PUB 6
199 [11], FIPS PUB 200 [12]) általános esetekben jóval gyorsabban lehet az adott projekt IT biztonsági mőszaki követelményeit meghatározni. Speciális esetekben a biztonság egy-egy igényelt területen tovább növelhetı, az igények részletesebb feltárásával. Ennek a testre szabási, ún. tailorizálási (testre szabási) tevékenységnek a fokozatos növelésével egyre pontosabb és pontosabb közelítése érhetı el az eredeti kockázatkezelési módszeren alapuló procedúrának. Jelen útmutató a fenti módszertan figyelembe vételével konkrét projektek IT biztonsági osztályba sorolásához nyújt iránymutatást az alábbi szerkezetben: A 6.1 fejezet a kockázatkezelés általános megközelítését írja le. Az informatikai rendszerekkel kapcsolatban számos szempontot figyelembe kell venni. A mőszaki szempontok egy teljes közigazgatási rendszernek egyik szeletét jelentik, de célszerő ezt a szeletet is a kockázatkezelés általános módszerét felhasználva áttekinteni. A kockázatkezelés módszertanának rövid áttekintése az amerikai NIST SP 800-30 [13] dokumentumon alapul, melyet ugyancsak módszertani alapként használt fel [01] ajánlás tervezet is. Ugyanakkor a kockázatkezelés bonyolult, összetett, gyakorta nem látszik egy rendszer életciklusa elején az összes tényezı, de azt, hogy milyen információkat akarnak feldolgozni, már a folyamat legelején is jól körülhatárolható. Az is megállapítható, hogy ezen információk az adott szervezet feladatainak ellátása tekintetében milyen biztonsági érzékenységgel bírnak, amibıl következik, hogy milyen IT biztonsági célok teljesítését kell megoldani. Az információkkal kapcsolatos biztonsági célokat, illetve az információ típusok és informatikai rendszerek biztonsági kategorizálását tekinti át a 6.2 fejezet. A 6.3 fejezet foglalkozik a minimális követelményekkel, pontosabban a minimális követelményekbıl összeállított alapkészlet testre szabásának szempontjaival. Bár jelen dokumentum is tartalmaz példákat az IT biztonsági szintek meghatározására javasolt eljárás megértésére, de a könnyebb olvashatóság érdekében külön dokumentumban több részletre kiterjedı, nagyobb terjedelmő példákat is adunk. [03]) 3. Alkalmazási terület Ez a dokumentum az informatikai rendszerek és informatikai biztonság szakértıinek készült beleértve: informatikai rendszerek és informatikai biztonság irányításával és felügyeletével foglalkozó vezetık (pl. informatikai igazgatók, magas beosztású informatikai tisztviselık és IT biztonságért felelıs vezetık); az informatikai rendszer fejlesztéséért felelıs személyek (program és projekt menedzserek, feladat/alkalmazás tulajdonosok, rendszertervezık, rendszer és alkalmazás programozók); az informatikai rendszer megvalósításáért és üzemeltetéséért felelıs személyek (pl. az informatikai rendszer tulajdonosai, az információ tulajdonosai, az informatikai rendszer rendszergazdái, az informatikai rendszer biztonsági tisztviselıi); az informatikai rendszer és informatikai biztonság felmérésével és megfigyelésével foglalkozó személyek (pl. auditorok, általános ellenırök, értékelık és tanúsítók). 7
Az informatikai termékeket és rendszereket vagy informatikai biztonsággal kapcsolatos rendszereket készítı, vagy informatikai biztonsággal kapcsolatos szolgáltatásokat nyújtó kereskedelmi vállalatok szintén hasznosíthatják az itt leírt információkat. 4. Rendelkezı hivatkozások [01] Az Informatikai és Hírközlési Minisztérium ajánlása a közigazgatás informatikai célrendszereinek kockázatfelmérésére, biztonsági osztályokba sorolására (Tervezet) 2006. április 24. [02] IT biztonsági mőszaki követelmények a különbözı biztonsági szintekre BME IK 2008. [03] Minta biztonsági kategorizálás BME IK 2008. [04] MSZ ISO/IEC 17799:2006 Az információbiztonság irányítási gyakorlatának kézikönyve [05] MSZ ISO/IEC 27001:2006 Az információbiztonság irányítási rendszerei. Követelmények [06] Rendszerekre vonatkozó értékelési módszertan BME IK 2008. [07] National Institute of Standards and Technology Special Publication 800-53, Recommended Security Controls for Federal Information Systems, December 2007 [08] Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model Version 3.1 Revision 2 [09] Common Criteria for Information Technology Security Evaluation Part 2: Security functional components Version 3.1 Revision 2 [10] Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components Version 3.1 Revision 2 [11] National Institute of Standards and Technology Federal Information Processing Standards Publication 199, Standards for Security Categorization of Federal Information and Information Systems, February 2004. [12] National Institute of Standards and Technology Federal Information Processing Standards Publication 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006. [13] National Institute of Standards and Technology Special Publication 800-30, Risk Management Guide for Information Technology Systems, July 2002 [14] Közigazgatási Informatikai Bizottság 25. számú Ajánlása Magyar Informatikai Biztonsági Ajánlások (MIBA), 1.0 verzió, 2008. június [15] Magyar Informatikai Biztonsági Ajánlások Magyar Informatikai Biztonsági Irányítási Keretrendszer 3. számú kiadványa, Az informatikai biztonság irányításának vizsgálata (IBIV), 1.1 verzió, 2008. február [16] 24/2006. (IV. 29.) BM-IHM-NKÖM együttes rendelet a közfeladatot ellátó szerveknél alkalmazható iratkezelési szoftverekkel szemben támasztott követelményekrıl. 8
Az alábbiakban megadjuk a rendelkezı hivatkozások elérhetıségeit. Cím Külföldi elérhetıség Magyar elérhetıség Az Informatikai és Hírközlési Minisztérium ajánlása a Informatikai célrendszerek kockázatfelmérése közigazgatás informatikai célrendszereinek kockázatfelmérésére, biztonsági osztályokba sorolására (Tervezet) 2006. április 24. IT biztonsági mőszaki --- követelmények a különbözı biztonsági szintekre BME IK 2008. Minta biztonsági kategorizálás --- MSZ ISO/IEC 17799:2006 Az információbiztonság irányítási gyakorlatának kézikönyve MSZ ISO/IEC 27001:2006 Az információbiztonság irányítási rendszerei. Követelmények Rendszerekre vonatkozó értékelési --- módszertan National Institute of Standards and Technology Special Publication NIST SP 800-53 800-53, Recommended Security Controls for Federal Information Systems, December 2007 Common Criteria for Information Technology Security Evaluation CC 3.1 Part 1 Part 1: Introduction and general model Version 3.1 Revision 2 Common Criteria for Information Technology Security Evaluation CC 3.1 Part 2 Part 2: Security functional components Version 3.1 Revision 2 Common Criteria for Information Technology Security Evaluation CC 3.1 Part 3 Part 3: Security assurance components Version 3.1 Revision 2 National Institute of Standards and Technology Federal Information FIPS 199 Processing Standards Publication 199, Standards for Security Categorization of Federal Information and Information Systems, February 2004. National Institute of Standards and Technology Federal Information FIPS 200 Processing Standards Publication 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006. MSZ ISO/IEC 17799:2006 MSZ ISO/IEC 27001:2006 9
Cím Külföldi elérhetıség Magyar elérhetıség National Institute of Standards and NIST SP 800-30 Technology Special Publication 800-30, Risk Management Guide for Information Technology Systems, July 2002 Közigazgatási Informatikai MIBA Bizottság 25. számú Ajánlása Magyar Informatikai Biztonsági Ajánlások (MIBA), 1.0 verzió, 2008. június Magyar Informatikai Biztonsági IBIV Ajánlások Magyar Informatikai Biztonsági Irányítási Keretrendszer 3. számú kiadványa, Az informatikai biztonság irányításának vizsgálata (IBIV), 1.1 verzió, 2008. február 24/2006. (IV. 29.) BM-IHM- NKÖM együttes rendelet a 24/2006. (IV. 29.) BM-IHM- NKÖM közfeladatot ellátó szerveknél alkalmazható iratkezelési szoftverekkel szemben támasztott követelményekrıl. 5. Fogalom-meghatározások Jelen dokumentum nem tartalmaz fogalom-meghatározásokat. 10
6. Az IT biztonsági szintek meghatározása 6.1. A kockázatkezelés általános megközelítése Egy sikeres, egész szervezetet átfogó informatikai biztonsági program megvalósításának kulcsa a kritikus információvagyon pontos meghatározása és védelme, amit egy alapos és teljes kockázatkezelési program tesz lehetıvé. A hatékony kockázatkezelési folyamatok alkalmazásától függ egy szervezet azon képessége, hogy meg tudja oldani a kritikus infrastruktúrájával, költség-hatékony biztonságával és az üzemelés folyamatosságával kapcsolatban felmerülı aktuális problémáit. A kockázatkezelés alapvetı vezetıi (menedzsment) feladat, és át kell fognia egy informatikai rendszer teljes életciklusát, azaz ki kell terjednie a rendszerrel kapcsolatos legkorábbi döntésektıl egészen a rendszer visszavonásával kapcsolatos tevékenységekig. Az informatikai infrastruktúráért általános felelısséggel tartozó vezetésnek (a szervezet általános vezetıinek vagy az informatikáért felelıs felsı vezetıknek) kell meghatároznia és biztosítania a hatékony, a szervezet minden részlegére kiterjedı kockázatkezelési program megvalósítását. A közigazgatási rendszerek esetén a versenyszférához hasonló módon szükséges kezelni az informatikai rendszerekkel kapcsolatban felmerülı kockázatokat, ugyanakkor figyelembe kell venni a közigazgatási terület által megszabott keretrendszert. A versenyszférához képest a hangsúlyok eltolódhatnak a célokban: nyereségorientáltság mellett/helyett adott esetben a fókusz a szolgáltatást használók biztonságának megteremtése felé tolódhat el; a versenyszférától eltérıen más törvények, szabályzók érvényesek, melyek megoldása a meglévı módszerek és eszközök új szempontok szerinti kombinációját követeli meg. A közigazgatási szervezetek által biztosított/használt elektronikus szolgáltatásoknál figyelembe kell venni ezen szervezetek közötti együttmőködés, egymásra utaltság szempontjait is, és így tovább sorolhatnánk a speciális közigazgatási szempontokat. 6.1.1. A kockázatkezelés fıbb szempontjai Kockázat alatt egy sebezhetıség kihasználásának negatív hatását értjük, melyet az elıfordulás valószínősége és kihatása egyaránt befolyásol. A kockázatkezelés a következı három folyamat összessége: a kockázatbecslés, a kockázatok csökkentése, értékelés és felülvizsgálat. A kockázatkezelés végrehajtásának célja: a) a közigazgatási szervezetek által használt vagy használni tervezett rendszerek biztonságosabbá tétele, illetve ezen biztonságossá tételhez a mai informatikai kihívásoknak megfelelı biztonsági szint és az ezzel járó követelmények szabványokon, bevált gyakorlatokon alapuló kiválasztása, b) a kockázatkezelési döntések meghozatalának megalapozása, 11
c) a kockázatkezelés végrehajtásának eredményeként létrejövı dokumentációval a vezetés támogatása abban, hogy informatikai rendszereit engedélyeztessék (vagy akkreditálják). Jelen útmutató közvetve vagy közvetlenül mindhárom cél végrehajtását támogatja. A kockázatkezelés beillesztése a rendszerek életciklusába A kockázatkezelés iteratív folyamat, és az életciklus minden szakasza tartalmaz megfelelı tevékenységeket. Egy informatikai rendszer életciklusa általában öt szakaszból áll: kezdeti, fejlesztési/beszerzési, megvalósítási/integrálási, üzemeltetési/karbantartási és visszavonási szakasz. Az alábbi táblázat összefoglalja az életciklus egyes szakaszaihoz kapcsolódó kockázatkezelési tevékenységeket. Életciklus szakasz 1. Kezdeti szakasz 2. Fejlesztési /beszerzési szakasz 3. Megvalósítási/ integrálási szakasz 4. Üzemeltetési/kar bantartási szakasz 5. Visszavonási szakasz A szakasz jellemzıi Megfogalmazzák az informatikai rendszer szükségességét, dokumentálják a rendszer célját és hatáskörét. Az informatikai rendszer tervezésének, megvásárlásának, programozásának, fejlesztésének vagy egyéb módon való létrehozásának szakasza. E szakaszban a rendszer biztonsági tulajdonságait kell beállítani, engedélyezni, tesztelni és ellenırizni. A rendszer üzemel. Általában a rendszer folyamatosan módosul további hardver és szoftver hozzáadásával, és a szervezeti folyamatok, politikák és eljárások módosulása révén. Információ, hardver és szoftver visszavonása. Ide tartoznak: információ átmozgatása, archiválása, leselejtezése vagy megsemmisítése és a hardver, szoftver törlése. A kockázatkezelési tevékenységek által nyújtott támogatás Az itt meghatározott kockázatokat a rendszerrel szemben támasztott követelmények kialakításához használják, beleértve a biztonsági követelményeket és a mőködtetés biztonsági koncepcióját (stratégiát). Az itt azonosított kockázatok az informatikai rendszer biztonsági elemzéséhez használhatók fel, mely elemzések eredményeként szerkezeti és tervezési változtatásokra lehet szükség a rendszer fejlesztése során. A kockázatkezelési folyamat támogatja annak felmérését, hogy a rendszer megvalósítása mennyire felel meg a rendszerrel szemben támasztott követelményeknek a modellezett üzemeltetési környezetben. Az azonosított kockázatokkal kapcsolatos döntéseket a rendszer üzembe állítása elıtt kell meghozni. Kockázatkezelési tevékenységekre az idıszakos rendszer újraengedélyezés (ismételt akkreditáció) érdekében kerül sor, vagy pedig akkor, amikor lényeges változások történnek az informatikai rendszer üzemeltetési, gyártási környezetében (pl. új rendszerinterfészek megjelenése). A kockázatkezelési tevékenységek a visszavonandó vagy lecserélendı rendszerelemekre történnek, a hardver és szoftver visszavonás, illetve a maradványadatok kezelésének megfelelısége, valamint a rendszer migráció biztonságos és módszeres végrehajtása érdekében. 1. táblázat A rendszer életciklus lépései és a kockázatkezelés összefüggései 6.1.2. Kockázatbecslés/felmérés A kockázatkezelés a kockázatbecslési folyamattal kezdıdik. A szervezetek a kockázatbecslést arra használják, hogy meghatározzák egy informatikai rendszerhez kapcsolódó potenciális veszély és a kockázat mértékét a rendszer életciklusa során. A kockázatbecslés eredménye 12
segít abban, hogy a kockázatcsökkentés végrehajtásakor megtaláljuk a kockázat csökkentését vagy teljes kiküszöbölését szolgáló megfelelı óvintézkedéseket. A kockázat annak a valószínőségnek a függvénye, hogy egy adott veszélyforrás kihasznál egy lehetséges sebezhetıséget, illetve annak a kihatásnak a függvénye, melyet ez a negatív esemény gyakorol a szervezetre. Egy jövıbeli kártékony esemény valószínőségének meghatározásához elemezni kell az informatikai rendszert fenyegetı veszélyeket, a lehetséges sebezhetıségekkel és az informatikai rendszerbe épített óvintézkedésekkel együtt. A kihatás egy sebezhetıség kihasználása által okozott kár nagyságát jelenti. A kockázatbecslés teljes folyamata az alábbi kilenc lépésbıl áll, melynek részletes leírását [14] alapján a [15] dokumentum tartalmazza. 1. lépés - A rendszer leírása Az elsı lépés a kockázati szempontból jelentıséggel bíró rendszer hatókörének meghatározása, beleértve a vizsgált rendszer határait, és minden érintett információt, erıforrást. Ezek magukban foglalnak hardver és szoftver komponenseket, belsı és külsı rendszerinterfészeket, a rendszer által felhasznált vagy elıállított adatot és információt, az alkalmazottak tevékenységét, a felhasználói interfészeket, a végrehajtott folyamatokat, a rendszer, illetve rendszeradatok kritikusságát és érzékenységét. 2. lépés A veszélyforrások meghatározása Egy veszély az a lehetıség, hogy egy adott veszélyforrás (veszélyokozó egyed) sikeresen kihasznál egy sebezhetıséget. A sebezhetıség olyan gyengeség, melyet véletlenül vált ki valami vagy valaki, illetve szándékosan visszaélnek meglétével. Egy veszélyforrás nem jelent kockázatot kihasználható sebezhetıség nemléte esetén. Egy veszély valószínőségének a meghatározásakor tekintetbe kell venni a veszélyforrásokat, a potenciális sebezhetıségeket és a létezı óvintézkedéseket. E lépés célja a lehetséges veszélyforrások azonosítása, és a vizsgált informatikai rendszer potenciális veszélyforrásairól egy lista összeállítása. 3. lépés A sebezhetıségek meghatározása Az informatikai rendszerre veszélyes tényezık elemzésének tartalmaznia kell a rendszer környezethez kapcsolódó sebezhetıségek elemzését is. E lépés célja egy olyan lista elkészítése, mely a lehetséges veszélyforrás által kihasználható sebezhetıségi pontokat (hibákat vagy gyengeségeket) győjti össze. 4. lépés Az óvintézkedések elemzése E lépés célja azon megvalósított vagy tervezetett óvintézkedések elemzése, melyek egy adott sebezhetıség esetén, egy veszély bekövetkezési valószínőségét igyekeznek minimalizálni. Az elemzés eredménye hatással van a következı lépésben meghatározott összegzett valószínőségre. 5. lépés A valószínőségek meghatározása Az összegzett valószínőségi osztályzatok (mely egy-egy potenciális sebezhetıség kihasználhatóságát jelzi a kapcsolódó veszély-környezetben) megállapítása, az alábbi befolyásoló tényezık figyelembe vételével: 13
A veszélyforrás motivációja és képességei, a sebezhetıség jellege, a jelenlegi óvintézkedések megléte és hatékonysága. Egy sebezhetıség kihasználásának esélyét három valószínőségi szint valamelyikébe soroljuk: magas, közepes, alacsony. 6. lépés Hatáselemzés E lépés célja egy sebezhetıség kihasználása esetén mérhetı káros hatás meghatározása. Egy biztonsági esemény káros hatása leírható a bizalmasság, a sértetlenség, a rendelkezésre állás, az elszámoltathatóság és a garancia biztonsági célok egyikének, vagy ezek bármely kombinációjának elvesztésével vagy jelentıs csökkenésével. Egy sebezhetıség valamilyen kihatását az alábbi osztályok egyikébe soroljuk: kritikus, súlyos, mérsékelt, kis mértékő. 7. lépés A kockázati szint meghatározása A lépés célja az informatikai rendszer kockázati szintjének felmérése. A kockázatok meghatározása egy adott veszély-sebezhetıség párra kifejezhetı az alábbiak függvényeként: az a valószínőség, hogy egy adott veszélyforrás megpróbál visszaélni egy sebezhetıséggel, a következmény nagysága, amennyiben egy veszélyforrás sikeresen visszaél a sebezhetıséggel, a tervezett vagy meglévı biztonsági óvintézkedések alkalmassága a kockázat csökkentésére vagy kiküszöbölésére. Egy adott veszély-sebezhetıség párra az általános megközelítés szerint a meghatározott kockázat lehetséges értékei: alacsony, mérsékelt, magas, kritikus. Az informatikai rendszer kockázati szintje a veszély-sebezhetıség párokra meghatározott legsúlyosabb kockázat lesz. 8. lépés Javaslat óvintézkedésekre E lépésben azokat az intézkedéseket veszik számba, melyek csökkentik vagy megszüntetik az azonosított kockázatokat. A javasolt óvintézkedések célja, hogy elfogadható szintre csökkentsék az informatikai rendszert és annak adatait veszélyeztetı kockázat szintjét. A javasolt óvintézkedések és alternatív megoldások kiválasztásánál az alábbi szempontokat tanácsos figyelembe venni: az ajánlott lehetıségek hatékonysága (pl. rendszer kompatibilitás), törvények és szabályozások, szervezeti szabályzatok, mőködtetési kihatások, biztonság és megbízhatóság. 9. lépés Az eredmények dokumentálása A kockázatbecslés befejezése után az eredményeket dokumentálni kell egy hivatalos jelentésben vagy összefoglalóban. A kockázatbecslésrıl szóló jelentés olyan vezetıi tájékoztató, amely a szervezet felsı vezetését segíti a biztonsági szabályzatokkal, az eljárási, költségvetési, rendszerüzemeltetési és irányítási változtatásokkal kapcsolatos döntéseik meghozatalában. Az átvilágítási vagy átvizsgálási jelentéssel szemben, amelyek a szervezetben zajló negatív jellegő tevékenységeket kutatják, a kockázatbecslés eredményeit összefoglaló jelentés nem vádjegyzıkönyv, hanem módszeres és elemzı megközelítése a kockázatok felmérésének, hogy a felsı vezetés megértse a kockázatokat és erıforrásokat 14
biztosítson a lehetséges veszteségek csökkentése vagy a veszteség utáni helyreállítás érdekében. 6.1.3. A kockázatok csökkentése A kockázatok csökkentése a kockázatbecslés során ajánlott kockázat-csökkentı óvintézkedések rangsorolását, értékelését és megvalósítását jelenti. Mivel az összes kockázat kiküszöbölése általában nem praktikus vagy szinte lehetetlen, ezért a felsı vezetés, valamint az üzleti és a szakterületi vezetık felelıssége a legmegfelelıbb óvintézkedések megvalósítása a szervezet alapfeladatát érintı kockázatok elfogadható szintre csökkentése céljából, úgy, hogy eközben a szervezet erıforrásaira és feladataira a lehetı legkisebb kedvezıtlen következmények háruljanak (költség-hatékony kockázatkezelés). A kockázatok csökkentése a felsı vezetés által használt módszeres eljárás a szervezet feladatait veszélyeztetı kockázatok csökkentése céljából. Alacsonyabb kockázati szint érhetı el az alábbi kockázatcsökkentési lehetıségek bármelyikével: A kockázat felvállalása A lehetséges kockázat elfogadása és az informatikai rendszer mőködtetésének folytatása, vagy óvintézkedések foganatosítása a kockázat elfogadható szintre csökkentéséhez. A kockázat elkerülése A kockázat elkerülése az okok és/vagy a következmények kiküszöbölésével (például a rendszer bizonyos funkcióinak használatáról való lemondás vagy a rendszer teljes lezárása kockázatok azonosítása esetén). A kockázat bekövetkezésének korlátozása A kockázat bekövetkeztének korlátozása olyan óvintézkedések megvalósításával, melyek minimalizálják azt a káros hatást, mely egy sebezhetıség kihasználásával jár (például megelızı, korlátozó és észlelı óvintézkedések). Kockázat tervezés A kockázatok kezelése kockázatcsökkentési terv kialakításával, amely rangsorolja, megvalósítja és életben tartja az óvintézkedéseket. Kutatás és beismerés A kockázat csökkentése a sebezhetıség vagy hiba meglétének beismerésével, és megoldások keresése a sebezhetıség kijavítására. Kockázat átvitel A kockázat átvitele a károk ellensúlyozását biztosító egyéb lehetıségek körébe (például biztosítás kötés). Költség-haszon elemzés és maradványkockázat A javasolt új vagy javított óvintézkedések költség-haszon elemzése az alábbiakat foglalja magába: az új vagy javított óvintézkedések hatásának meghatározása, 15
az új vagy javított óvintézkedések elmulasztásából eredı következmények meghatározása, a megvalósítás költségeinek becslése, mely többek között a következıket tartalmazza: hardver és szoftver vásárlás; csökkentett mőködési hatékonyság, ha a rendszer teljesítménye vagy funkcionalitása a fokozottabb biztonság érdekében csorbát szenved; kiegészítı szabályzatok és eljárások megvalósítási költségei; a javaslatoknak megfelelı új alkalmazottak bérköltségei; oktatási költségek; karbantartási költségek, a megvalósítás költségeinek és hasznának felmérése a rendszer és az adatok kritikusságának tükrében, meghatározandó az új óvintézkedések bevezetésének fontosságát azok költségének és relatív kihatásának függvényében. A szervezetek megvizsgálhatják, hogy az új vagy javított óvintézkedések következtében milyen mértékben csökkent a kockázati szint az ezt meghatározó két paraméter (a veszélyek kisebb bekövetkezési valószínősége, illetve a veszélyek következménye) szempontjából. Az új vagy javított óvintézkedések megvalósítása után maradt kockázat a maradványkockázat. Gyakorlatilag nincs kockázatmentes informatikai rendszer, és nem minden megvalósított óvintézkedés képes kivédeni vagy nulla kockázati szintre vinni azt a kockázatot, melynek kiküszöbölése elvárható tıle. Amennyiben a maradványkockázat nem csökken le egy elfogadható szintre, a kockázatkezelés ciklikus folyamatát meg kell ismételni, mindaddig, amíg nem találunk valamilyen módszert a maradványkockázat kellı csökkentésére. Amennyiben az informatikai infrastruktúráért felelıs vezetı úgy értékeli, hogy a kockázat meglévı szintje elfogadható, alá kell írnia egy nyilatkozatot, mely kimondja, hogy a rendszer teljes üzembe helyezésének engedélyezését vagy akkreditációját megelızıen elfogadják a maradványkockázat szintjét. Értékelés és felülvizsgálat A kockázatelemzés eredménye csupán a kezdete egy folyamatnak, melynek célja, hogy csökkenjenek egy informatikai biztonsági esemény által okozott, a szervezet feladatait érintı negatív következmények. A legtöbb informatikai rendszer, és környezete folyamatosan változik. Új kockázatok jelennek meg, a korábbi kockázatbecslések érvényüket veszthetik. Ezért a kockázatkezelés folyamatosan jelen lévı, fejlıdı kérdéskör. Szükség van elıre ütemezett, rendszeres felülvizsgálatra, jelentıs változások pedig azonnali elemzést, értékelést is igényelhetnek. Szükség van idıszakos újraértékelésre a rendszerbiztonság állásának pontos feltérképezéséhez is. Az eredmények ismeretében akár a szervezet biztonságpolitikáját is módosítani kell. A sikeres kockázatkezelés elemei Egy sikeres kockázatkezelés az alábbi elemeken múlik: a felsı vezetés elkötelezettsége a szükséges erıforrások és idı biztosításához; az informatikai csoport teljes támogatása és részvétele; a kockázatkezelést végzı csapat hozzáértése; a felhasználói közösség tagjainak tudatos magatartása és együttmőködése; az informatikával kapcsolatos üzleti kockázatok folyamatos értékelése és elemzése. 16
6.2. Az IT biztonsági szintek meghatározása a biztonsági kategorizálás módszerével Ez a fejezet az információ típusok meghatározását, a biztonsági célokat, ez utóbbiak sérülésének kihatásait, valamint mindezen tényezık adott informatikai rendszerrel kapcsolatos meghatározását tárgyalja. Az alábbi ábra a biztonsági kategorizálás módszerének lépéseit ábrázolja. A folyamatot minden informatikai rendszer esetén javasolt végrehajtani. 1 Informatikai rendszer meghatározása 2 Információ típusok meghatározása 3 Kihatási szintek meghatározása Kihatási szintek felülvizsgálata (testre szabás) Információ kihatási szintek véglegesítése Rendszer biztonsági kategória véglegesítése 5 4 1. ábra A biztonsági kategorizálás folyamata Az ábrán számokkal jelölt lépések az alábbiak: 1. Az informatikai rendszer meghatározása: Egy informatikai rendszer lehet általános támogató rendszer, fıalkalmazás, vagy helyi, illetve speciális célrendszer. 2. Az információ típusok meghatározása 3. A kihatási szintek meghatározása 4. A kihatási szintek felülvizsgálata és véglegesítése 5. A rendszer biztonsági kategória végsı meghatározása 17
6.2.1. Biztonsági célok és kihatási szintek 6.2.1.1. Informatikai biztonsági célok A közigazgatási szolgáltatásokat megalapozó információk és informatikai rendszerek biztonsági kategóriái három biztonsági cél, és az ezekkel kapcsolatos veszélyeztetettségi (kihatás) szinteken keresztül definiálhatók. Jelen útmutató a nemzetközi szakirodalom alapján- a következı három biztonsági célra alapozza az informatikai rendszerek biztonsági kategorizálását: a) bizalmasság, b) sértetlenség, c) rendelkezésre állás. Bizalmasság: Olyan biztonsági tulajdonság, amely lehetıvé teszi, hogy az információ jogosulatlan egyedek (emberek, folyamatok) számára ne legyen elérhetı, vagy ne kerüljön nyilvánosságra. A bizalmasság elvesztése az információ illetéktelenek általi hozzáférését, megismerését jelenti. Sértetlenség: Olyan biztonsági tulajdonság, amely azt jelenti, hogy az adatot, információt vagy programot csak az arra jogosultak változtathatják meg és azok észrevétlenül nem módosulhatnak és nem törölhetık, semmisíthetık meg. A sértetlenség elvesztése az információ jogosulatlan módosítását vagy megsemmisítését jelenti. A sértetlenség fogalmába jelen dokumentum megközelítése szerint beleértendı az információk letagadhatatlansága és hitelessége is. Letagadhatatlanság: Olyan biztonsági tulajdonság, amely megfelelı bizonyítékokkal szolgál az informatikai rendszerben végrehajtott tevékenységek késıbbi ellenırizhetıségét illetıen. Hitelesség: A hitelesség az entitás olyan biztonsági tulajdonsága, amely egy vagy több hozzá kapcsolódó tulajdonságot más entitás számára bizonyíthatóvá tesz. Rendelkezésre állás: A biztonság azon szempontja, amely lehetıvé teszi, hogy a feljogosított szubjektum (humán közremőködı vagy gépi folyamat) által támasztott igény alapján az adott objektum elérhetı és használható legyen. A rendelkezésre állás elvesztése azt jelenti, hogy az információhoz vagy az informatikai rendszerhez való hozzáférés vagy annak használata akadályokba ütközik, vagy adott idıtartamra vagy teljes mértékben megszőnik. 6.2.1.2. Informatikai biztonsági célok elvesztésének kihatásai A fenti biztonsági célok sérülésével járó, szervezetekre, illetve egyénekre gyakorolt potenciális hatások (kihatás szintek) az alábbiak: Alacsony: amennyiben a bizalmasság, sértetlenség vagy rendelkezésre állás elvesztése várhatóan korlátozott hátrányos hatást gyakorol a közigazgatási szervezet mőveleteire vagy a szervezet eszközeire, illetve a szervezettel kapcsolatba kerülı egyénekre. 18
A korlátozott hátrányos hatás azt jelenti, hogy a bizalmasság, sértetlenség vagy rendelkezésre állás elvesztése: a) a szolgáltatási képességet oly mértékben és olyan idıtartamra csökkentheti, hogy a szervezet képes végrehajtani ugyan elsıdleges funkcióit, de a funkciók hatásossága észrevehetıen csökken; vagy b) a szervezeti eszközök kisebb mértékő károsulását eredményezi; vagy c) kisebb mértékő pénzügyi veszteséget okoz, vagy d) a jogbiztonságot kisebb mértékben veszélyezteti. Fokozott: amennyiben a bizalmasság, sértetlenség vagy rendelkezésre állás elvesztése várhatóan komoly hátrányos hatást gyakorol a közigazgatási szervezet mőveleteire, vagy a szervezet eszközeire, illetve a szervezettel kapcsolatba kerülı egyénekre. A komoly hátrányos hatás azt jelenti, hogy a bizalmasság, sértetlenség vagy rendelkezésre állás elvesztése: a) a szolgáltatási képességet oly mértékben és olyan idıtartamra csökkentheti, hogy a szervezet képes végrehajtani elsıdleges funkcióit, de a funkciók hatásossága jelentıs mértékben csökken; vagy b) a szervezeti eszközök jelentıs károsulását eredményezi; vagy c) jelentıs pénzügyi veszteséget okoz, vagy d) a jogbiztonságot jelentıs mértékben veszélyezteti. Kiemelt: amennyiben a bizalmasság, sértetlenség vagy rendelkezésre állás elvesztése várhatóan súlyos vagy katasztrofális hatást gyakorol a közigazgatási szervezet mőveleteire, vagy a szervezet eszközeire, illetve a szervezettel kapcsolatba kerülı egyénekre. A súlyos vagy katasztrofális hátrányos hatás azt jelenti, hogy a bizalmasság, sértetlenség vagy rendelkezésre állás elvesztése: a) a szolgáltatási képességet olyan mértékben és olyan idıtartamra csökkentheti, illetve akár meg is szüntetheti, hogy a szervezet nem képes végrehajtani egy vagy több elsıdleges funkcióját; vagy b) a szervezeti eszközök lényegi károsulását eredményezi; vagy c) lényegi pénzügyi veszteséget okoz, vagy d) a jogbiztonságot alapvetı mértékben veszélyezteti. 19
6.2.2. Információ típusok és kihatási szintek meghatározása 6.2.2.1. Információ típusok Az információ a hozzá meghatározott információ típus szerint kerül biztonsági kategorizálásra. Az információ típus az információ egy konkrét kategóriája (például személyes adat, magántitok, különleges adat, üzleti titok, pénzügyi információ, rendszer információ). Konkrét informatikai rendszerek esetén ritka az olyan eset, hogy a rendszer tisztán egy kategóriába esı információ típust dolgozna fel, általában igaz, hogy eltérı típusú és érzékenységő információkat tároló, feldolgozó, továbbító rendszereket kell kialakítani. Az információ típusok meghatározására az alábbi lépések egymás utáni következetes végrehajtása javasolt: a vizsgálat alatt álló rendszer által támogatott alapvetı üzleti területek (menedzsment és háttértámogatás) vagy küldetési területek (küldetés-alapú szervezetek esetén: például katasztrófa-védelem) meghatározása; minden üzleti vagy küldetési területre az ágazat vagy mőködési területek meghatározása, amelyek leírják a rendszert funkcionális szempontból; az alfunkciók meghatározása, amelyek az egyes mőködési területek vagy üzletágak tevékenységének végrehajtásához szükségesek; a meghatározott alfunkciókhoz kapcsolódó alapvetı információ típusok kiválasztása, amennyiben ez elvégezhetı; a rendszer által feldolgozott minden információ típus meghatározása, amire vonatkozóan törvény, rendelet, vagy közigazgatási ágazati szabályozás különleges kezelést követel meg (például jogosulatlan megismerés elleni speciális kezelési utasítások). Ez az információ felhasználható az információ típus vagy a rendszer biztonsági kihatás szint finomhangolására. A közigazgatási ágazatok a közigazgatás körébe tartozó tevékenységeket olyan magas szintő kategóriákba sorolják, amelyek a kormányzás, közigazgatás céljaival, a célok eléréséhez alkalmazott mechanizmusokkal, a közigazgatási tevékenység végrehajtását támogató háttérfunkciókkal, valamint a kormányzás minden területét érintı, azaz általános erıforráskezelési tevékenységekkel kapcsolatosak. A [03] dokumentum információ típusokat mutat be egyes közigazgatási ágazati információkra (például közegészségügyi információk), illetve általános (például biztonsági menedzsment) információ típusokra. 20