Útmutató az IT biztonsági szintek meghatározásához ÚTMUTATÓ AZ IT BIZTONSÁGI SZINTEK MEGHATÁROZÁSÁHOZ ÚTMUTATÓ

Útmutató az IT biztonsági szintek meghatározásához

Ú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 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 Útmutató az IT biztonsági szintek meghatározásához IT biztonság; IT biztonsági szint; útmutató; IT biztonsági követelmény 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. szöveg

e-Közigazgatási Keretrendszer Kialakítása projekt MEH HunGuard Kft. 2008.08.22. MS Word doc magyar 1.01 átadott verzió EKK_ekozig_ITbiztonsagiszintekmeghatarozasa_080822_V101.doc 378 KB

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 Verziószám Összes oldalszám A projekt azonosítója

Útmutató az IT biztonsági szintek meghatározásához HunGuard Kft. 2008.08.22. 1.01 39 EKK_ekozig

Változáskezelés Verzió V0.8 V0.9 V1.0 V1.01

Dátum 2008.07.07. 2008.07.24. 2008.07.25 2008.08.22

A változás leírása Elıminısítésre átadott verzió Ellenırzött, javított verzió Átadott verzió 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]

[02] [03] [04] [05] [06] [07]

[08] [09] [10] [11]

[12]

[13] [14] [15]

[16]

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. 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 BME IK 2008. 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 BME IK 2008. National Institute of Standards and Technology Special Publication 800-53, Recommended Security Controls for Federal Information Systems, December 2007 Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model Version 3.1 Revision 2 Common Criteria for Information Technology Security Evaluation Part 2: Security functional components Version 3.1 Revision 2 Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components Version 3.1 Revision 2 National Institute of Standards and Technology Federal Information Processing Standards Publication 199, Standards for Security Categorization of Federal Information and Information Systems, February 2004. National Institute of Standards and Technology Federal Information Processing Standards Publication 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006. National Institute of Standards and Technology Special Publication 800-30, Risk Management Guide for Information Technology Systems, July 2002 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 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 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 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. 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 800-53, Recommended Security Controls for Federal Information Systems, December 2007 Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model Version 3.1 Revision 2 Common Criteria for Information Technology Security Evaluation Part 2: Security functional components Version 3.1 Revision 2 Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components Version 3.1 Revision 2 National Institute of Standards and Technology Federal Information Processing Standards Publication 199, Standards for Security Categorization of Federal Information and Information Systems, February 2004. National Institute of Standards and Technology Federal Information Processing Standards Publication 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006.

Külföldi elérhetıség

Magyar elérhetıség Informatikai célrendszerek kockázatfelmérése

---

---

MSZ ISO/IEC 17799:2006 MSZ ISO/IEC 27001:2006 ---

NIST SP 800-53

CC 3.1 Part 1

CC 3.1 Part 2

CC 3.1 Part 3

FIPS 199

FIPS 200

9


Cím National Institute of Standards and Technology Special Publication 800-30, Risk Management Guide for Information Technology Systems, July 2002 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 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 24/2006. (IV. 29.) BM-IHMNKÖM együttes rendelet a közfeladatot ellátó szerveknél alkalmazható iratkezelési szoftverekkel szemben támasztott követelményekrıl.

Külföldi elérhetıség NIST SP 800-30

Magyar elérhetıség

MIBA

IBIV

24/2006. (IV. 29.) BM-IHMNKÖM

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

A szakasz jellemzıi

A kockázatkezelési tevékenységek által nyújtott támogatás Megfogalmazzák az informatikai Az itt meghatározott kockázatokat a rendszerrel rendszer szükségességét, szemben támasztott követelmények kialakításához dokumentálják a rendszer célját és használják, beleértve a biztonsági követelményeket hatáskörét. és a mőködtetés biztonsági koncepcióját (stratégiát). 2. Az informatikai rendszer tervezésének, Az itt azonosított kockázatok az informatikai Fejlesztési megvásárlásának, programozásának, rendszer biztonsági elemzéséhez használhatók fel, /beszerzési fejlesztésének vagy egyéb módon való mely elemzések eredményeként szerkezeti és szakasz létrehozásának szakasza. tervezési változtatásokra lehet szükség a rendszer fejlesztése során. 3. E szakaszban a rendszer biztonsági A kockázatkezelési folyamat támogatja annak Megvalósítási/ tulajdonságait kell beállítani, felmérését, hogy a rendszer megvalósítása mennyire integrálási engedélyezni, tesztelni és ellenırizni. felel meg a rendszerrel szemben támasztott szakasz 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. 4. A rendszer üzemel. Általában a Kockázatkezelési tevékenységekre az idıszakos Üzemeltetési/kar rendszer folyamatosan módosul rendszer újraengedélyezés (ismételt akkreditáció) bantartási további hardver és szoftver érdekében kerül sor, vagy pedig akkor, amikor szakasz hozzáadásával, és a szervezeti lényeges változások történnek az informatikai folyamatok, politikák és eljárások rendszer üzemeltetési, gyártási környezetében (pl. új módosulása révén. rendszerinterfészek megjelenése). 5. Visszavonási Információ, hardver és szoftver A kockázatkezelési tevékenységek a visszavonandó szakasz visszavonása. Ide tartoznak: információ vagy lecserélendı rendszerelemekre történnek, a átmozgatása, archiválása, leselejtezése hardver és szoftver visszavonás, illetve a vagy megsemmisítése és a hardver, maradványadatok kezelésének megfelelısége, szoftver törlése. 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.

Informatikai rendszer meghatározása

Információ típusok meghatározása

1

2

Kihatási szintek meghatározása 3

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


6.2.2.2.

Információ típusok kihatási szintje

Egy információ típus megfelelı biztonsági kategóriájának megállapításához az adott információ típusra vonatkozóan meg kell határozni a három biztonsági célra gyakorolt potenciális hatást (kihatás szintet). Ezek segítségével egy információ típus biztonsági kategóriája az alábbi általános képlettel fejezhetı ki: BIZTONSÁGI KATEGÓRIA/információ típus = {(bizalmasság, hatás), (sértetlenség, hatás), (rendelkezésre állás, hatás)} A hatás (kihatás szint) lehetséges értékei: nem értelmezhetı (-), alacsony, fokozott, kiemelt. A fenti kategorizálás alkalmazható mind az elektronikus, mind a nem elektronikus formában levı információkra, bár jelen útmutató csak az elsı megjelenési formára koncentrál. (A nem értelmezhetı kihatás csak a bizalmasság biztonsági célra vonatkozhat.). Az alábbi példák az információ típusa szerint biztonsági kategorizálást szemléltetik. 1. Példa: Egy közigazgatási szervezet –mely nyilvános információkat tesz elérhetıvé honlapján keresztül–, megállapítja, hogy ezen nyilvános információk bizalmasságának elvesztésébıl nem származik potenciális hatás (vagyis a bizalmasság védelmére nem kell külön követelményeket támasztania és kielégítenie), ugyanakkor alacsony potenciális hatás éri a sértetlenség és a rendelkezésre állás elvesztése esetén. A fentieket az alábbi biztonsági kategória fejezi ki: BK/nyilvános_információ = {(bizalmasság, -), (sértetlenség, alacsony), (rendelkezésre állás, alacsony)} 2. Példa: Egy közigazgatási szervezet, mely érzékeny személyes adatokat kezel, azt állapítja meg, hogy ezen személyes adatok vonatkozásában a bizalmasság és a sértetlenség elvesztésébıl fokozott, míg a rendelkezésre állás elvesztése esetén alacsony potenciális hatás éri. Ezt az alábbi biztonsági kategória fejezi ki: BK/személyes_ információ = {(bizalmasság, fokozott), (sértetlenség, fokozott), (rendelkezésre állás, alacsony)} 3. Példa: Egy közigazgatási szervezet (személyes adatokat nem tartalmazó) adminisztratív információkat kezelı pénzügyi részlegének informatikai alrendszerére megállapítja, hogy az adminisztratív információkat a bizalmasság és a sértetlenség elvesztése esetén egyaránt alacsony potenciális hatás éri, ugyanakkor a rendelkezésre állás kihatás szintje kiemelt. Ezzel az alábbi biztonsági kategóriát határozta meg: BK/adminisztratív_információ = {(bizalmasság, alacsony), (sértetlenség, alacsony), (rendelkezésre állás, kiemelt)} 6.2.2.3.

A biztonsági kihatás szintjének kiválasztását segítı tényezık

Az egyes információ típusokra vonatkozóan tanácsos megfontolni, hogy az adott típus esetén az alábbi kérdésekre milyen válaszok adhatók, illetve azt itt tárgyalt szempontokat hogyan veszi figyelembe a szervezet.

21


6.2.2.3.1.

Általános bizalmassági tényezık

― Egy ellenséges szándékú fél hogyan tudná felhasználni az információt, hogy korlátozott/komoly/súlyos károkat okozzon a szervezet tevékenységében, értékeiben vagy a szervezettel kapcsolatban álló személyeknek? ― Egy ellenséges szándékú fél milyen módon használhatja fel az információt ahhoz, hogy ellenırzést szerezzen a szervezet értékei felett, aminek következtében illetéktelenül tudja módosítani vagy megsemmisíteni az információt, vagy szolgáltatás megtagadási támadást kivitelez, és ezáltal korlátozott/komoly/súlyos károkat okozzon a szervezet tevékenységében, értékeiben vagy a szervezettel kapcsolatban álló személyeknek? ― Az információ típus elemeinek illetéktelen megismerése, felfedése, nyilvánosságra hozatala sértene-e bármilyen vonatkozó törvényt, rendeletet, jogszabály? Az információ típus minden egyes használati esete és a típusba tartozó minden ismert információváltozat figyelembe vételével kell megállapítani a bizalmasság biztonsági cél kihatási szintjét.

6.2.2.3.2.

Általános sértetlenségi tényezık

Az információk illetéktelen módosítása vagy megsemmisítése számos formát ölthet. A módosítások lehetnek nagyon kicsik, alig észlelhetık, de szerteágazóak, áthatóak is. Néhány példa a lehetséges hatásokra: ― a nyilvánosság szervezet felé megnyilvánuló bizalmának megingatása, csökkentése; ― pénzügyi nyereség csalással; ― személyi döntések befolyásolása; ― törvénykezés, jogszabályalkotás befolyásolása; ― hamisított vagy helytelen eljárások terjesztése zavar vagy ellentmondásos helyzet létrehozása céljából; ― kormányzati információkhoz, szolgáltatásokhoz jogosulatlan hozzájutás, hozzáférés. A sértetlenség elvesztésének legsúlyosabb kihatása az információ módosításából és a módosított információ más szervezetek vagy nyilvánosság számára történı továbbításából származik. A sértetlenség elvesztésének következménye lehet közvetlen (például: pénzügyi tétel, egészségügyi vagy bőnügyi rekord módosítása), és lehet közvetett is (például: érzékeny vagy személyes adatokhoz való hozzáférés lehetıvé tétele, vagy szolgáltatás megtagadás elıidézése). Az információkhoz és informatikai rendszerekhez való rosszindulatú írási hozzáférés megszerzése a szervezet küldetésében felbecsülhetetlen károkat okozhat, és más rendszerekhez való továbblépési pontként is felhasználható. A jogosulatlan információ módosítás vagy megsemmisítés az esetek nagy százalékában korlátozott következményeket jelent a szervezet életében, de vannak olyan esetek, amikor

22


igen súlyos kihatással kell számolni a sértetlenség elvesztése esetén. Különösen igaz ez az idı-kritikus rendszerek és információk esetében. 6.2.2.3.3.

Általános rendelkezésre állással kapcsolatos tényezık

E biztonsági cél elvesztésének kihatását vizsgálva azt kell megnézni, hogy a szóban forgó információ vagy célrendszer mennyi ideig marad elérhetetlen. Számos információ típus esetén a rendelkezésre állás elvesztése súlyos következményekkel járhat. Például a költségvetés végrehajtása, adóbehajtás, biztonsági menedzsment adatbázisok rendelkezésre állásának elvesztése majdnem minden szervezet számára súlyos kihatást jelentene a mőködıképességre. A legtöbb esetben a korlátozott ideig tartó rendelkezésre állási kiesések a szervezettel szemben tapasztalható bizalom és a szervezet tevékenységeiben csak kisebb negatív következményekkel járnak. Azonban, az idıkritikus információ típusok (például on-line adóbevallás visszaigazolása) esetén a rendelkezésre állás elvesztése utáni helyreállás valószínőleg azután történne meg, miután érvényesülnek a nagyobb hátrányok a szervezet értékei, feladatai vagy humán kapcsolatai vonatkozásában. Emiatt a rendelkezésre állás kihatásainak elemzésekor ajánlatos az információ idıkritikus jellegét figyelembe venni. 6.2.2.4.

Információ típusok kihatási szintjének felülvizsgálata és véglegesítése

A rendszer által kezelt információ típusok meghatározási folyamata alatt több olyan tényezı is felmerülhet, mely módosíthatja egy-egy információ típus esetén az elsı körben megállapított kihatási szintet. Elıfordulhat, hogy hasonló információ típusnak más kihatási szintet állapítanak meg a különbözı szervezeteknél a helyi körülmények függvényében. Ezen kívül, az információ különbözı életciklus szakaszaiban is változhat a hozzá rendelt kihatási szint. Elıfordulhat, hogy adott információ típus csak rövid ideig bír érzékenységgel a bizalmasság biztonsági cél tekintetében, de az alatt a rövid idı alatt azonban kritikus szempont, hogy illetéktelen ne ismerje meg. Tehát az életciklusa elején fokozott bizalmasság kihatási szintet rendelnek hozzá, míg az életciklus végén alacsony is elegendı. (Például a Magyar Nemzeti Bank Monetáris Tanácsának kamatdöntést elıkészítı információi.) 6.2.3. Informatikai rendszerek biztonsági kategorizálása Az informatikai rendszer által feldolgozott egyes információ típusok kihatási szintjének meghatározása után a következı lépés a teljes rendszer besorolása a bizalmasság, sértetlenség és rendelkezésre állás biztonsági célok alapján az alábbi biztonsági osztályok egyikébe: a) alacsony kihatású (biztonsági osztály), b) fokozott kihatású (biztonsági osztály), c) kiemelt kihatású (biztonsági osztály). Az informatikai rendszerek biztonsági kategorizálása az információ típusok szerinti kategorizáláshoz képest további szempontok mérlegelését igényli: meg kell vizsgálni a rendszerben tárolt, feldolgozott, továbbított minden információ típus biztonsági

23


kategorizálását, és ezen információk alapján kell megállapítani a rendszerhez rendelt kihatási szintet. A három biztonsági célra (bizalmasság, sértetlenség, rendelkezésre állás) vonatkozóan különkülön meg kell határozni a rendszerszintő kihatást, az egyes információ típusokra kapott legmagasabb értékek megállapításával. Ezután az úgynevezett „high water mark” elv alkalmazásával a teljes informatikai rendszerre kell megállapítani a kihatás szintjét: a) az alacsony kihatású rendszer olyan, amelyben mindhárom biztonsági cél szerinti kihatás alacsony szintő, b) a fokozott kihatású rendszer esetén legalább az egyik biztonsági cél fokozott szintő, és nincs fokozottnál erısebb szintő biztonsági cél, végül, c) a kiemelt kihatású rendszer olyan informatikai rendszer, amelyben legalább az egyik biztonsági cél szerinti kihatás kiemelt szintő. Egy informatikai rendszer biztonsági kategóriája az alábbi általános képlettel fejezhetı ki: BIZTONSÁGI KATEGÓRIA informatikai rendszer = {(bizalmasság, hatás), (sértetlenség, hatás), (rendelkezésre állás, hatás)}, ahol a lehetséges kihatás étékek: alacsony, fokozott, kiemelt. A kihatási szint meghatározási módszer egyszerő és jól megalapozott elven alapul: a szervezetek informatikai rendszereinek biztonsági kategóriájának megállapítását, majd a rendszerek megfelelı védelmét biztosító intézkedések alkalmazását jelöli ki. Az egyes informatikai rendszerekre alkalmazott biztonsági intézkedéseknek arányban kell állniuk a bizalmasság, sértetlenség vagy rendelkezésre állás elvesztésének a szervezet feladataira, értékeire vagy személyekre gyakorolt lehetséges kihatásával. A „high water mark” elv alkalmazásának oka, hogy a bizalmasság, sértetlenség és rendelkezésre állás biztonsági céljai között jelentıs összefüggések vannak. Sok esetben az egyik biztonsági cél kompromittálódása maga után vonja a többi sérülését vagy elvesztését is. Ennek megfelelıen, a [02] dokumentumban a biztonsági intézkedések nem biztonsági célok szerint vannak osztályozva, hanem alapkészletenként csoportosítottak, hogy a kihatási szint alapján adjanak általános védelmi képességet informatikai rendszer osztályaira. A hatásköri útmutató alkalmazása lehetıvé tesz szelektív biztonsági intézkedés készlet testre szabását. 6.2.4. A rendszer biztonsági osztályba sorolás egyéb szempontjai 6.2.4.1.

Aggregálás

Bizonyos információk kevéssé vagy egyáltalán nem érzékenyek más információktól elszigetelve, de aggregátumként magas érzékenységi szintet képviselhetnek. Például, adott információ típus nagy mennyiségő összesítése érzékeny mintákat és/vagy terveket, trendeket árulhat el, vagy érzékeny, kritikus rendszerhez való hozzáférést tesz lehetıvé; illetve több különbözı és látszólag ártalmatlan információ összességének lehet hasonló hatása. Általában igaz, hogy valamely adatelem érzékenysége a kontextusában valószínőleg nagyobb, mint elszigetelve (például bankkártya szám hozzárendelése egy személyhez). Amennyiben a vizsgálat az információ összesítés magasabb érzékenységét mutatja ki, akkor az informatikai

24


rendszer kategóriáját magasabb szintre kell beállítani, mint amit az egyedi információ típusokra megállapított kihatási szint elsı lépésben mutat. 6.2.4.2.

Kritikus rendszer funkciók

Egyes információ típusok kompromittálódásának alacsony kihatása lehet a rendszer elsıdleges funkcióinak vonatkozásában, de ez a következmény jelentısebbnek ítélhetı, ha más környezeti feltételek alapján vizsgáljuk, úgymint: ― Más rendszerekre gyakorolt hatás, amelyhez az érintett rendszer kapcsolódik. Egy alacsony kihatási szintbe sorolt információkat kezelı rendszerhez való hozzáférési információk elsı látásra alacsony kihatási tulajdonságokkal rendelkeznek. Azonban, ha ezen rendszerhez való hozzáférés hálózaton keresztül más rendszerekhez kapcsolódik, akkor minden ilyen közvetett módon elérhetı rendszerhez érzékenységét és kritikusságát figyelembe kell venni. ― Más rendszerek, amelyek a szóban forgó rendszerben kezelt információktól függnek: például önmagukban nem kritikus vagy érzékeny idıjárási információkat rendkívül érzékeny vagy kritikus funkciókkal dolgozó rendszerek, légi irányítási rendszerek használnak, és ezek sértetlenségének, rendelkezésre állásának, idıbeliségének vagy más összefüggéseinek elvesztése súlyos következményekkel járhat.

6.3.

Minimális IT biztonsági követelmények

Az informatikai rendszerek bizalmasságának, sértetlenségének és rendelkezésre állásának megırzése érdekében kiegyensúlyozott informatikai biztonsági program keretében gondoskodni kell a menedzsment, a mőködtetési és mőszaki szempontok vizsgálatáról. A mőszaki szempontok alapvetıen az alábbi hat területet fedik le, és a [02] dokumentum e területeken fogalmaz meg követelményeket a különbözı kihatási szintő rendszerekre. A mőszaki területek: a) azonosítás és hitelesítés (AH) b) hozzáférés ellenırzés (HE) c) naplózás és elszámoltathatóság (NA) d) rendszer és kommunikáció védelem (RV) e) Konfiguráció kezelés (KK) f) Rendszer és információ sértetlenség (RS) A közigazgatási szervezetnek teljesítenie kell a követelményrendszerben meghatározott minimális követelményeket, a rendszerre meghatározott biztonsági kihatási szintnek megfelelı intézkedések kiválasztása által. Ugyanakkor –mivel egy rendszer sosem önmagában áll, hanem valamilyen környezetbe ágyazódik bele–, szükség lehet ezen intézkedéskészlet módosítására, a helyi környezethez történı adaptálására. Ennek a szempontjait tárgyalja ez a fejezet.

25


6.3.1. A kezdeti alapkészlet kiválasztása és testre szabása Miután megtörtént az informatikai rendszer végsı kihatási szintjének meghatározása, következhet a [02] dokumentumban szereplı biztonsági intézkedések közül a kezdeti alapkészlet kiválasztása a vonatkozó alacsony, fokozott vagy kiemelt csoportból. A rugalmasság érdekében a kezdeti kiválasztás testre szabható jelen útmutatóban lefektetett feltételek és kitételekkel figyelembe vétele mellett. A testre szabási tevékenységek magukba foglalják: ― a kezdeti alapkészletre a megfelelı hatóköri útmutató alkalmazását; ― szükség esetén a helyettesítı biztonsági intézkedések meghatározását; ― ahol megengedett, a szervezet által definiált paramétereket a biztonsági intézkedésekben. Ahhoz, hogy az egész szervezetre kielégítı információbiztonságot nyújtó, költség-hatékony, kockázat-alapú megközelítés lépjen életbe, a biztonsági intézkedések testre szabási tevékenységeit a megfelelı illetékesnek kell összehangolnia és jóváhagynia (vezetı információs tisztviselı, információ biztonsági felügyelı stb.), illetve megfelelı módon dokumentálni kell. Az alapkészletbıl származó biztonsági követelményeket, illetve a testre szabási tevékenységbıl következı döntéseket egy értékelésre benyújtandó rendszer esetén az informatikai rendszer biztonsági elıirányzatában (SST) [[02] és [06]] kell dokumentálni, és ebben az elıírt szerkezetben és tartalommal kell leírni a rendszer biztonsági jellemzıit, céljait, követelményeit, funkcióit. 6.3.1.1.

A hatókörök meghatározása

A hatókörrel, alkalmazási területekkel kapcsolatos szempontok a biztonsági intézkedések alapkészletében szereplı egyedi biztonsági intézkedések alkalmazhatósága és megvalósítása speciális feltételeinek és megszorításainak figyelembe vételére világítanak rá. Az alábbi bekezdésekben több ilyen tényezı szerepel, amelyek adott esetben befolyásolhatják, hogy az alap biztonsági intézkedéseket hogyan kell a szervezetre vonatkoztatni. Általános biztonsági intézkedésre vonatkozó szempontok Az általános biztonsági intézkedések egy vagy több szervezeti informatikai rendszerre egyaránt érvényes intézkedések, és vonatkozhatnak: ― a szervezet felügyelt alá tartozó összes informatikai rendszerre, ― egy terület informatikai rendszereire vagy informatikai rendszerek egy csoportjára a szervezeten belül, ― általános célú informatikai rendszerekre, alrendszerekre, alkalmazásokra. A szervezetek által általános biztonsági intézkedésnek azonosított biztonsági intézkedéseket a legtöbb esetben nem az informatikai rendszer tulajdonosa, hanem más szervezethez tartozó egyed kezeli. Az általános intézkedésekként meghatározandó biztonsági intézkedésekre vonatkozó szervezeti döntések nagymértékben befolyásolhatják az egyes informatikai rendszer tulajdonosokat egy adott alapkészlet intézkedéseinek megvalósítása tekintetében.

26


Egy alapkészlet minden intézkedését teljes mértékben figyelembe kell vennie a szervezet vagy az informatikai rendszer tulajdonosának. Mőködtetéssel, környezettel kapcsolatos szempontok A mőködtetési környezet jellegétıl függı biztonsági intézkedések csak akkor alkalmazhatók, ha az informatikai rendszert az intézkedéseket szükségessé tevı környezetben használják. A fizikai infrastruktúrával kapcsolatos szempontok A szervezeti létesítményekkel kapcsolatos biztonsági intézkedések (zárak, ırök, környezeti paraméterek: hımérséklet, páratartalom stb.) csak a létesítmény azon részeire alkalmazhatók, amelyek közvetlenül nyújtanak védelmet vagy biztonsági támogatást az informatikai rendszernek vagy kapcsolatosak azzal (ideértve az IT értékeket, mint például e-mail, web szerverek, szerver farmok, adatközpontok, hálózati csomópontok, határvédelmi eszközök és kommunikációs berendezések). A nyilvános hozzáféréssel kapcsolatos szempontok A nyilvánosan hozzáférhetı információkra vonatkozó biztonsági intézkedéseket körültekintıen kell számba venni, és óvatosan kell alkalmazni, mivel a meghatározott alap intézkedés készlet egyes biztonsági intézkedései (például azonosítás és hitelesítés, személyi biztonsági intézkedések) nem alkalmazhatók az informatikai rendszerhez nyilvános interfészeken keresztül hozzáférı felhasználókra. Például, míg az alapkészlet intézkedések között szerepel a nyilvános szolgáltatásokat biztosító informatikai rendszer fenntartását és támogatását végzı alkalmazottak azonosítása és hitelesítése követelmény, ugyanezen intézkedések nem alkalmazhatók a nyilvánosan közzétett információkhoz hozzáférık esetén. Másrészt, bizonyos esetekben az informatikai rendszerhez nyilvános interfészeken keresztül hozzáférı felhasználók azonosítása és hitelesítése is kötelezı lehet például a személyes információikhoz való hozzáférés vagy azok módosítása esetén. Technológiával kapcsolatos szempontok A specifikus technológiára (például vezeték nélküli kommunikáció, kriptográfia, PKI) vonatkozó biztonsági intézkedések csak akkor alkalmazhatók, ha ezeket a technológiákat használják az informatikai rendszerben vagy elıírják ezek használatát. A biztonsági intézkedések az informatikai rendszer csak azon komponenseire vonatkoznak, amelyek az intézkedés által megcélzott biztonsági képességet biztosítják vagy támogatják, és az intézkedés által csökkeneti kívánt lehetséges kockázatok forrásai. Például, a naplózási intézkedések az informatikai rendszer olyan komponenseire alkalmazandók, amelyek naplózási képességeket biztosítanak, vagy kell biztosítaniuk (például szerverek), és nem feltétlenül kell minden felhasználó munkaállomására alkalmazni. A szervezetnek körültekintıen kell felmérni az informatikai rendszert alkotó komponensek készletét, annak meghatározásához, hogy milyen biztonsági intézkedések alkalmazhatók a különbözı komponensekre. A technológiai fejlıdéssel az IT eszközök is egyre többre képesek, nagyobb képességekkel és változatosabb funkcionalitással rendelkeznek (PDA-k, mobiltelefonok), ami a biztonsági intézkedések alkalmazását a szervezeti kockázatelemzéssel

27


összhangban követelheti meg. A testre szabási útmutató megengedheti –mint az elızı naplózási példában-, hogy nem szükséges egy adott biztonsági intézkedést valamely komponens esetén alkalmazni, azonban az intézkedés hiányából származó maradványkockázattal foglalkozni kell, és a szükséges mértékben enyhíteni kell a szervezet feladatainak, tevékenységének, értékeinek és a személyek kielégítı védelme érdekében, illetve az intézkedés alkalmazásának mellızését a megfelelı módon indokolni és dokumentálni kell. Abban az esetben, amikor egy informatikai rendszer komponensei egyfelhasználósak, nem hálózatba kötöttek, vagy csak helyi hálózatban mőködnek, ezen tulajdonságok közül egy vagy több megfelelı indoklást adhat arra, hogy az adott komponensre a kiválasztott intézkedéseket ne kelljen alkalmazni. Azok a biztonsági intézkedések, amelyeket automatizált mechanizmusokkal explicit vagy implicit módon lehet támogatni, nem igénylik az ilyen mechanizmusok kifejlesztését, ha a mechanizmusok még nem léteznek vagy nem állnak készen rendelkezésre kereskedelmi vagy kormányzati késztermékként. Amikor automatizált eszközök nem készen elérhetık, költséghatékonyak vagy technikailag nem kivitelezhetık, akkor nem automatizált mechanizmusokkal vagy eljárásokkal megvalósított kompenzációs biztonsági intézkedéseket kell foganatosítani az adott biztonsági intézkedés vagy intézkedés bıvítés teljesítésére (lásd a helyettesítı intézkedések alkalmazásának feltételeit a következı alfejezetben). Biztonsági politikával, szabályozással kapcsolatos szempontok A közigazgatás területén tervezett vagy már mőködtetett informatikai rendszerekre alkalmazott biztonsági intézkedése kialakítása során figyelembe kell venni a rendszer célja által meghatározott vonatkozó törvényi, jogszabályi hátteret is. Például iratkezelı rendszerek alkalmazása esetén érvényre kell juttatni a [16] rendeletben foglaltakat, mind a funkcionalitásra, mind pedig a biztonságra vonatkozó követelmények tekintetében. Amennyiben a közigazgatási informatikai rendszer személyes adatokat is kezel, akkor a személyes adatok kezelésére vonatkozó jogszabályok alkalmazása is megvalósítandó feladat a rendszerben. A skálázhatósággal kapcsolatos szempontok A biztonsági intézkedések skálázhatók az intézkedés megvalósításának határáig és szigorúságáig. A skálázhatóságot a védendı informatikai rendszerek biztonsági kategorizálása alapján lehet megvizsgálni. Például egy magas kihatási szintő informatikai rendszer esetén a rendkívüli helyzetek kezelésére vonatkozó terv elég hosszú is lehet, és jelentıs mennyiségő implementációs részletet is tartalmazhat. Ezzel ellentétben egy alacsony kihatási szintő rendszer katasztrófaterve meglehetısen röviden és kevésbé részletezetten is kielégítı. A szervezeteknek a tényleges környezetek skálázhatósági szempontjainak figyelembe vételével kell a biztonsági intézkedéseket alkalmazni. Ez a megközelítés költség-hatékony, kockázat alapú biztonsági intézkedés kidolgozást és megvalósítást tesz lehetıvé, ami a szükségesnél több erıforrást nem köt le, ugyanakkor megfelelı mértékben csökkenti a kockázatokat és kielégítı biztonsági garanciát nyújt.

28


A biztonsági célokhoz kapcsolódó szempontok Azok a biztonsági intézkedések, amelyek kizárólagosan támogatják a bizalmasság, sértetlenség és rendelkezésre állás biztonsági célokat, visszasorolhatók egy alacsonyabb alapkészletben lévı megfelelı intézkedésre (vagy megfelelıen módosítható illetve kivehetık, ha az alacsonyabb szinten nincsenek meghatározva), akkor és csak akkor, ha ez az alacsonyabb osztályba sorolás: ― összhangban van a vonatkozó bizalmassági, sértetlenségi vagy rendelkezésre állási biztonsági célra a „high water mark” elv alkalmazása elıtt megállapított szinttel. A biztonsági kategorizálás során a „high water mark” elv alkalmazásakor az eredeti bizalmassági, sértetlenségi és rendelkezésre állási biztonsági célok esetén elıfordulhatott, hogy magasabb biztonsági intézkedés szintre sorolták be azokat. E folyamat részeként, a bizalmasságot, sértetlenséget vagy rendelkezésre állást kizárólagosan támogató biztonsági intézkedéseket szükségtelenül sorolták feljebb. Következésképp, ajánlott, hogy a szervezetek alkalmas és megengedett visszasorolást tehessenek a biztonsági intézkedések költség-hatékony, kockázat alapú biztosítása érdekében. ― a szervezetre végrehajtott kockázat felmérés támasztja alá; és ― nem befolyásolja a biztonsági szempontból fontos információkat az informatikai rendszeren belül. A rendszer szintjén biztonsági szempontból fontos információk (például jelszófájlok, hálózati útvonalválasztó táblák, kriptográfiai kulcskezelési információk) elkülönülnek az informatikai rendszer felhasználói információitól. Egy informatikai rendszeren belül bizonyos biztonsági intézkedések támogatják mind a rendszer, mind pedig a felhasználói információk bizalmasságát, sértetlenségét. Körültekintıen kell eljárni a bizalmassággal vagy sértetlenséggel kapcsolatos biztonsági intézkedések alacsonyabb osztályba sorolásakor, hogy ennek ne legyen káros mellékhatása (azaz nem kielégítı védelem biztosítása) az informatikai rendszer biztonsági szempontból fontos információira. A biztonság-kritikus információkat a „high water mark” elv alapján kell védeni, annak biztosítása céljából, hogy a felhasználói információkhoz kapcsolódó bármelyik biztonsági célra a kívánt védelmi szint teljesüljön. Az alábbi mőszaki biztonsági intézkedések esetén javasolt megfontolni az alacsonyabb osztályba sorolást: ― bizalmasság: [HE-15, RV -4, RV -9]; ― sértetlenség: [RV -8]; ― rendelkezésre állás: [RV -6]. Egyes mőszaki biztonsági intézkedések, amelyek kizárólagosan hozzárendelhetık a bizalmasság, sértetlenség vagy rendelkezésre állás céloknak, és amelyeknél szóba jöhet az alacsonyabb osztályba sorolásra (például: HE-16, NA-10, AH-7, RV-5, RV -13, RV -14, RV 16) nem szerepelnek az elızı listán, mert vagy mindegyik alapkészlet tartalmazza ezeket és nincs olyan bıvítés, ami visszasorolható lehetne, vagy pedig opcionális intézkedések, és nem szerepelnek egyik szinten sem. Ezen kívüli egyéb intézkedések alacsonyabb osztályba sorolása során nagyon kell arra vigyázni, hogy a folyamat során az alacsonyabb osztályba sorolás tevékenység tárgyául szolgáló biztonsági célon kívül másik célra ne legyen kihatása ennek a döntésnek.

29


6.3.1.2.

Helyettesítı biztonsági intézkedések

A mai informatikai rendszerek szerteágazó képességei, különbözı jellege miatt a szervezetek szükségesnek ítélhetik adott esetben, hogy helyettesítı biztonsági intézkedéseket határozzanak meg és alkalmazzanak. A helyettesítı biztonsági intézkedés olyan menedzsment, mőködtetési vagy mőszaki intézkedés (azaz védelmi garancia vagy ellenintézkedés), amelyet a szervezet az alacsony, fokozott vagy kiemelt szinten javasolt biztonsági intézkedés helyett alkalmazni kíván, és egyenértékő vagy összemérhetı védelmet nyújt az informatikai rendszerre fenyegetést jelentı veszélyforrások ellen, illetve egyenértékő módon biztosít valamilyen külsı, belsı követelménynek (például törvényeknek) való megfelelést. Elıfordulhat, hogy egynél több helyettesítı intézkedés szükséges valamely, eredetileg a készletben szereplı intézkedés egyenértékő vagy összemérhetı kiváltására. Például, egy szervezetnél a nagymértékő személyzeti leépítés miatt nehézségekbe ütközik a felelısségi körök szétválasztása, de ennek kiegyenlítésére alkalmazhatják a naplózás, elszámoltathatóság és a személyekre vonatkozó biztonsági intézkedések megerısítését. Egy informatikai rendszer esetén a szervezet csak az alábbi feltételek teljesülése esetén alkalmazhat helyettesítı intézkedést: ― A szervezet a [02] dokumentumban szereplı helyettesítı intézkedést választja, vagy ha ebben nincs megfelelı helyettesítı intézkedés, akkor a szervezet alkalmazhat egy, az adott helyzetben megfelelı helyettesítı intézkedést. (A helyettesítı intézkedések kiválasztásánál a szervezetnek meg kell kísérelnie, hogy a katalógusból válasszon intézkedést. A szervezet által meghatározott helyettesítı intézkedéseket csak végsı esetben szabad használni, amennyiben a biztonsági intézkedések katalógusa nem tartalmaz az adott viszonyok között alkalmazható intézkedést.) ― A szervezetnek teljes és meggyızı indoklást kell adnia arra, hogy a helyettesítı intézkedések hogyan biztosítják az informatikai rendszer egyenértékő biztonsági képességeit, illetve védelmi szintjét, és miért nem használhatók a vonatkozó alapkészlet biztonsági intézkedései. (Az indoklás részletezettségének és szigorúságának az informatikai rendszerre megállapított kihatási szintnek megfelelınek kell lennie, alacsony biztonsági kihatású rendszer esetén jóval kevesebb magyarázattal, mint magas kihatású rendszer esetén.) ― A szervezet felméri és formálisan elfogadja a helyettesítı intézkedés alkalmazásával kapcsolatos kockázatot. A helyettesítı biztonsági intézkedések alkalmazását dokumentálni kell, és az illetékes tisztviselıvel jóvá kell hagyatni. A rendszer biztonsági környezetét, valamint a rendszer által megvalósítandó követelményeket leíró dokumentációban, a rendszer biztonsági elıirányzatban (SST) [02] a jóváhagyott helyettesítı intézkedésnek megfelelı módon kell kiválasztani a CC 2. részbıl [09]vagy 3. részbıl [10] származó követelményeket. Ugyanakkor ekkor is körültekintıen kell eljárni, hiszen figyelembe kell venni a [09] és [10] követelményekben megadott függéseket. Elıfordulhat, hogy egy intézkedés helyett választott helyettesítı intézkedés egészen más jellegő, újonnan felmerült mőszaki támogató intézkedéseket követel meg (például a fenti példában a felelısségi körök szétválasztása helyett alkalmazott naplózáshoz tudni kell az eseményt kiváltó felhasználót, az eseményt a sértetlenségét megırzı módon kell tárolni, megırizni a naplóban, kezelni kell a tárhelyet,

30


megbízható idıt kell a naplóbejegyzésbe beírni). A CC követelményeinek [09] és [10] szigorú hierarchikus felépítése, a függések teljesítésének megkövetelése a mőszaki intézkedések esetén nagymértékben segíti azt, hogy belsı ellentmondásoktól mentes biztonsági követelmény-készlet jöjjön létre egy rendszerhez. 6.3.1.3.

A szervezet által meghatározott biztonsági intézkedések paraméterei

A szervezet által meghatározandó paramétereket tartalmazó biztonsági intézkedések (azaz értékadás, és/vagy választási mőveletek) rugalmasságot jelentenek a szervezetek számára, hogy a helyi szervezeti követelmények vagy célok támogatása érdekében rugalmasan tudják meghatározni az intézkedések kiválasztott részeit. Például a [02] követelményi között szerepel a HE-7 Sikertelen bejelentkezési kísérletek intézkedés, melyet mindhárom biztonsági szint megkövetel: Intézkedés: Az informatikai rendszer egy [értékadás: a szervezet által definiált szám]-ként megadott korlátot juttat érvényre egy felhasználó egymást követı bejelentkezési kísérleteire, amelyek egy [értékadás: a szervezet által definiált idıtartam]-on belül történtek. Amennyiben a sikertelen kísérletek a maximális számot túllépik, az informatikai rendszer automatikusan [választás: zárolja a felhasználói fiókot/csomópontot [értékadás: a szervezet által definiált idıtartamig], késlelteti a következı bejelentkezési kísérletet egy az [értékadás: szervezet által definiált késleltetési algoritmusnak megfelelıen]]. Az ebben szereplı mőveletek (értékadás és választás) szervezet által meghatározott paraméterekkel történı befejezése után egy konkrét helyzetre, rendszerre elkészített intézkedés lehet például: Az informatikai rendszer egy felhasználó egymást követı bejelentkezési kísérleteinek számát 3 percen belül 5-ben korlátozza. Amennyiben a sikertelen kísérletek a maximális számot túllépik, az informatikai rendszer automatikusan zárolja a felhasználói fiókot/ 2 percig. A hatókör kijelölés és a helyettesítı biztonsági intézkedések kiválasztása után a szervezetnek át kell néznie a biztonsági intézkedéseket az értékadási és választási mőveletek szempontjából, és meg kell határoznia a megfelelı szervezetre jellemzı értékeket a paraméterekhez. Ahol ez szükséges, az értékekre vonatkozó minimum és maximum értékeket összhangba kell hozni a vonatkozó jogszabályok, szabályzatok, vagy szabványok elvárásaival is. A szervezet által megállapított biztonsági intézkedés paramétereket dokumentálni kell az informatikai rendszer biztonsági elıirányzatában, ami a [02] dokumentum által elıírt követelmények CC [09] követelményekkel és az adott rendszerre vonatkozó értékekkel konkretizált specifikációt jelent. 6.3.2. A testre szabott alapkészlet kiegészítése A testre szabott alapkészlet az informatikai rendszerek egy adott osztályára (a 6.2 fejezet szerinti biztonsági osztályba sorolásból származó, valamint a helyi feltételek, környezeti paraméterek alapján megfelelıen módosított testre szabott készlet) azt a kiindulópontot jelenti, ahonnan el lehet és el kell indulni a biztonság szükséges szintjének kellı

31


körültekintéssel történı meghatározásának folyamatában, valamint annak bizonyításában, hogy a szervezet az értékei és feladatai védelmében milyen lépéseket tesz meg. A végleges biztonsági intézkedés készlet a szervezetre végrehajtott kockázatelemzés eredményétıl is függ, és az elvárás az, hogy a szervezet által végzett feladatokat, szervezeti értékekre vagy egyéneket fenyegetı kockázatokat kielégítı módon csökkentsék. Számos esetben további biztonsági intézkedésekre van szükség, vagy az intézkedések bıvítését kell elvégezni specifikus, helyi szinten veszélyek vagy sebezhetıségek kezelése, vagy a vonatkozó törvényeknek, jogszabályoknak való megfelelés biztosítása céljából. Ebben a szakaszban a kockázat felmérés a biztonsági intézkedések kiválasztási folyamatában fontos bemenetet jelent annak megállapításához, hogy kielégítık-e a biztonsági intézkedések a testre szabott készletben, azaz alkalmasak-e a szervezet mőködésének (ideértve küldetését, feladatait, jó hírét, elismertségét) megfelelı védelmére. A szervezeteket ösztönözni kell a biztonsági intézkedések katalógusának maximális felhasználására, hogy egyszerőbbé váljon a biztonsági intézkedések bıvítésének folyamata vagy további intézkedések hozzáadása a testre szabott készlethez. Ennek támogatásához a biztonsági intézkedések katalógusa számos intézkedést és intézkedés bıvítést tartalmaz, amelyek csak a kiemelt kihatású rendszerekre vonatkozó készletben szerepelnek, vagy egyik alapkészletben sem. Elıfordulhatnak olyan helyzetek, amikor a szervezet felismeri, hogy nincs birtokában annak a technológiának, amivel megfelelıen tudná védeni a kritikus és/vagy lényeges feladataival kapcsolatos értékeket és mőveleteket, azaz, a szervezet nem tudja megfelelıen csökkenteni vagy enyhíteni a kockázatokat. Ekkor alternatív stratégia kidolgozása válik szükségessé, ami figyelembe veszi a szervezet alapfeladataira vonatkozó azon kockázatokat, amelyeket az információtechnológia fokozott használata idéz elı. Az informatikai rendszerek használati korlátozásai a kockázatok csökkentésének vagy mérsékelésének alternatív módját adják, például a következı esetekben: ― a biztonsági intézkedések nem valósíthatók meg a technológia és erıforrás korlátozások által szabott kereteken belül, vagy ― a biztonsági intézkedésekhez nem kapcsolódik az azonosított veszélyekkel szembeni hatékonyság ésszerő elvárása. Az informatikai rendszer használatára vonatkozó korlátozások néha az egyetlen ésszerő és gyakorlati megoldást nyújtják az erısen motivált támadók ellenében végrehajtott feladatteljesítést illetıen. A megkövetelt rendszer használatra vonatkozó korlátozások megállapítását a szervezet illetékes tisztviselıinek kell elvégezni, aki kompetens és felelıs pozícióban van ahhoz, hogy a szervezet küldetésének teljesítésével kapcsolatos döntéseket hozzon. E tisztviselıi körbe tartozik például az informatikai rendszer tulajdonosa, a szolgáltatás tulajdonosa, az engedélyezı illetékes alkalmazott, vezetı információ biztonsági tisztviselı, vezetı információs tisztviselı. A használati korlátozásokra példák: ― az informatikai rendszer által feldolgozható, tárolható, továbbítható információ korlátozása vagy annak a módnak a korlátozása, ahogyan egy feladat automatizált; ― külsı informatikai rendszerek letiltása a kritikus szervezeti információkhoz való hozzáférésrıl, a kiválasztott rendszerösszetevık hálózatból való eltávolítása által (azaz légrés alkalmazása);

32


― fokozott vagy magas kihatási szintő információk olyan informatikai rendszer összetevın való kezelésének tiltása, amelyhez nyilvános hozzáférés is lehetséges, kivéve, ha az ilyen hozzáférést explicit engedélyezés nem tette lehetıvé. A szervezetek számára nagyon fontos a biztonsági intézkedések kiválasztási folyamatában a döntések dokumentálása, és ahol ez lehetséges, világos indoklás elkészítése. Ez a dokumentáció fontos szerepet tölt be az informatikai rendszer végsı biztonsági szempontjainak vizsgálatakor a lehetséges kihatások tekintetében. A végleges, jóváhagyott biztonsági intézkedések a kiválasztási döntéseket leíró kiegészítı indoklással és bármilyen rendszer használati korlátozással az informatikai rendszer biztonsági elıirányzatának (lásd [02] és [06]) a részét kell, hogy képezzék.

Az alábbi ábra összegezve tekinti át a biztonsági intézkedések kiválasztási folyamatát, ideértve a kezdeti biztonsági intézkedés alapkészlet testre szabását, és az ebben tett minden további módosítást, ami a szervezeti kockázat felmérésen alapul.

KEZDETI BIZTOSÁGI INTÉZKEDÉS KÉSZLET (alacsony, fokozott, kiemelt)

A testre szabási útmutató alkalmazása

Testre szabás elıtt

Hatókörök meghatározása Helyettesítı intézkedések paraméterezése

TESTRE SZABOTT BIZTONSÁGI INTÉZKEDÉS ALAP-KÉSZLET (alacsony, fokozott, kiemelt) Testre szabás után

Szervezeti kockázat értékelés

A testre szabott intézkedés alapkészlet kiegészítései a nem elfogadható kockázatok csökkentésére

JÓVÁHAGYOTT BIZTONSÁGI INTÉZKEDÉSEK (alacsony, fokozott, kiemelt) Kockázatfelmérés után

MINDEN FÁZISBAN A BIZTONSÁGI INTÉZKEDÉS KIVÁLASZTÁS DÖNTÉSEINEK DOKUMENTÁLÁSA (Indoklás, hogy a jóváhagyott biztonsági intézkedés készlet, illetve az informatikai rendszer használati korlátozásai megfelelı védelmet nyújtanak a szervezet mőveleteire, értékeire, és az informatikai rendszerrel kapcsolatba kerülı egyénekre)

2. ábra A biztonsági intézkedések kiválasztási folyamata

6.3.3. A biztonsági intézkedések aktualizálása A szervezet által rendszeres idıközönként alkalmazott biztonsági ellenırzési program keretében a közigazgatási szervezeteknek lépéseket kell kezdeményezniük annak megállapítása érdekében, hogy szükséges-e az életben lévı, jóváhagyott, a rendszer biztonsági elıirányzatban rögzített és az informatikai rendszerben megvalósított biztonsági intézkedések

33


aktualizálása. A szervezetnek rendszeres idıközönként felül kell vizsgálnia, hogy a rendszerei megfelelnek-e a korábbi biztonsági besorolásnak, illetve, hogy a környezet és az igények változásai nem igénylik-e a besorolás módosítását, új fenyegetések kivédését, új kockázatok mérlegelését. Továbbá, lehetnek olyan események, amelyek az informatikai rendszer biztonsági állapotának azonnali értékelését, és ennek eredményétıl függıen az érvényben lévı biztonsági intézkedések frissítését, aktualizálását igénylik, például: ― Egy biztonsági esemény az informatikai rendszerben a biztonság megsértését okozta, aminek kihatása a rendszer által feldolgozott, tárolt vagy továbbított információk bizalmasságának, sértetlenségének vagy rendelkezésre állásának megırzésébe vetett bizalom elvesztése. ― szervezet feladatait, értékeit, vele kapcsolatos személyeket fenyegetı, új, valószerő, megalapozott információforrás által azonosított veszély bukkan fel. ― Az informatikai rendszer konfigurációját érintıen jelentıs módosítások történtek új hardver, szoftver vagy förmver elem hozzáadása, régi eltávolítása miatt, vagy a mőködtetési környezetben történt változások potenciálisan ronthatják a rendszer biztonsági állapotát. Amennyiben a fentiekhez hasonló események történnek, a szervezetnek minimálisan az alábbi lépéseket kell tennie: Az informatikai rendszer és a rendszer által feldolgozott, tárolt és/vagy továbbított információ kritikusságának illetve érzékenységének újbóli meghatározása, az érvényben lévı paraméterek megerısítése. Ehhez a 6.2 fejezetben részletezett útmutatás alapján újra meg kell vizsgálni az informatikai rendszer kihatási szintjét, ami a változó környezet miatt új szempontokat hozhat a rendszer végsı fontosságának megállapításába, amivel a szervezet feladatainak teljesítéséhez hozzájárul. Az informatikai rendszer aktuális biztonsági állapotának értékelése és az aktuálisan számításba vett kockázatok újbóli értékelése a szervezet feladataira, értékeire és a vele kapcsolatba kerülı egyénekre vonatkoztatva. A szervezetnek meg kell vizsgálnia az informatikai rendszer sebezhetıségeit, amiket egy veszélyforrás képes kihasználni, valamint a rendszerben érvényben lévı, a biztonsági elıirányzatban leírt biztonsági intézkedéseket. Egy sebezhetıség veszélyforrás általi kihasználása az alábbiak közül egy vagy több tényezıre vezethetı vissza, de más szempontok is szóba jöhetnek még: ― az érvényben lévı biztonsági intézkedés hibája, sikertelen mőködése; ― hiányzó biztonsági intézkedés; ― a biztonsági intézkedések nem kielégítı erıssége; ― a veszélyforrás képességeinek vagy hozzáértésének, lehetıségeinek növekedése. Az aktuális biztonsági állapot értékelésének eredményeit felhasználva a szervezetnek újra kell értékelnie a kockázatokat, amelyek a szervezet informatikai rendszereinek mőködésével kapcsolatosak, és a szervezet feladatait, értékeit vagy a vele kapcsolatos személyeket érintik.

34


A szükséges javító intézkedések megtervezése és kezdeményezése Az aktualizált kockázat felmérés eredményei alapján a szervezetnek meg kell határoznia, milyen további biztonsági intézkedésekre és/vagy intézkedés bıvítésére lehet szükség a felmerült eseményekkel kapcsolatos sebezhetıségek kezelése érdekében, illetve milyen javító intézkedések lehetnek képesek helyesbíteni a kevéssé hatékonynak bizonyult érvényes intézkedéseket. Ezután az informatikai rendszer biztonsági elıirányzatát kell aktualizálni, szükség esetén értékelését elvégezni, hogy tükrözze a javító intézkedéseket. Dokumentálni kell a tapasztalt problémákat egy intézkedési tervben, amelyeket nem azonnal lehet javítani, és rögzíteni kell a biztonsági intézkedések frissítésének megvalósítását és további intézkedéseket. Miután az új vagy aktualizált biztonsági intézkedések megvalósultak és minden észrevételezett probléma javításra került, az intézkedéseket meg kell vizsgálni hatékonyság szempontjából, melynek során meg kell állapítani, hogy a biztonsági intézkedést jól valósították-e meg, a terveknek megfelelıen mőködnek, és a szervezet biztonsági szabályzatát kielégítı módon a kívánt hatást érik el.

35


7. Mellékletek Jelen dokumentum nem tartalmaz mellékleteket.

36


8. Bibliográfia National Institute of Standards and Technology Special Publication 800-12, An Introduction to Computer Security: The NIST Handbook, October 1995 Common Methodology for Information Technology Security Evaluation; Evaluation Methodology September 2007 Version 3.1 Revision 2 MSZ ISO/IEC 15408-1:2003 Informatika – Biztonságtechnika – Az informatikai biztonságértékelés közös szempontjai – 1. rész: Bevezetés és általános modell, 2. rész: A biztonság funkcionális követelményei, 3. rész: A biztonság garanciális követelményei Magyar Informatikai Biztonsági Ajánlás - Magyar Informatikai Biztonsági Értékelési és Tanúsítási Séma - 1. számú segédlet: Modell és folyamatok Magyar Informatikai Biztonsági Ajánlás - Magyar Informatikai Biztonsági Értékelési és Tanúsítási Séma - 2. számú segédlet: Útmutató a megbízók számára Magyar Informatikai Biztonsági Ajánlás - Magyar Informatikai Biztonsági Értékelési és Tanúsítási Séma - 3. számú segédlet: Útmutató a fejlesztık számára Magyar Informatikai Biztonsági Ajánlás - Magyar Informatikai Biztonsági Értékelési és Tanúsítási Séma - 4. számú segédlet: Útmutató az értékelık számára Magyar Informatikai Biztonsági Ajánlás - Magyar Informatikai Biztonsági Értékelési és Tanúsítási Séma - 5. számú segédlet: MIBÉTS értékelési módszertan Arrangement on the Recognition of Common Criteria Certificates in the field of Information Technology Security /CCRA 2000 May/ BSI: Transition guide for ALC, ACM, ADO and AGD /Version 2.0, 22.01.2008/ BSI: Guidelines for Developer Documentation according to Common Criteria Version 3.1

37


9. Rövidítésgyőjtemény AH: azonosítás és hitelesítés CC: Common Criteria (Közös Szempontok) HE: hozzáférés ellenırzés BK: biztonsági kategória BM: Belügyminisztérium IHM: Informatikai és Hírközlési Minisztérium IT: Information Technology (információ technológia) NA: naplózás és elszámoltathatóság NKÖM: Nemzeti Kulturális Örökség Minisztériuma KK: Konfiguráció kezelés PDA: Personal Digital Assistant PKI: Public Key Infrastructure (nyilvános kulcsú infrastruktúra) RS: Rendszer és információ sértetlenség RV: rendszer és kommunikáció védelem SST: System Security Target (rendszer biztonsági elıirányzat)

38


10. Fogalomtár Bizalmasság: A bizalmasság egy olyan biztonsági tulajdonság, amely lehetıvé teszi, hogy az információ a jogosulatlan szubjektumok számára ne legyen elérhetı, vagy ne kerüljön nyilvánosságra. Biztonsági cél: A biztonsági cél az azonosított fenyegetések elleni fellépésrıl és (vagy) a szervezeti biztonsági szabályzatoknak és feltételezéseknek való megfelelésrıl szóló szándéknyilatkozat. High water mark: (elıforduló legmagasabb biztonsági szint kiválasztásának elve) Egy objektum (például rendszer, információk összessége) valamely biztonsági tulajdonságának (például bizalmasság elvesztésének kihatási szintje) megállapítása oly módon, hogy az objektum elemeihez rendelt biztonsági tulajdonságok értékei közül az adott vonatkoztatási halmazban elıforduló legmagasabb érték kerül kiválasztásra. Hitelesség: A hitelesség az entitás egy 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. A hitelesség (adatok esetében) az adat olyan biztonsági tulajdonsága, amely arra vonatkozik, hogy az adat (bizonyíthatóan) egy elvárt forrásból származik. Ehhez az szükséges, hogy az informatikai kapcsolatban lévı partnerek kölcsönösen (és egyértelmően) felismerjék egymást, és ez az állapot a kapcsolat teljes ideje alatt fennálljon. Életciklus: Egy rendszer tervezésétıl a visszavonásáig vagy megsemmisítéséig tartó, egymás utáni állapotok által meghatározott folyamat, a következı fı szakaszokkal: kezdeti, fejlesztési/beszerzési, megvalósítási/integrálási, üzemeltetési/karbantartási és visszavonási szakasz. Kockázat: Egy sebezhetıség kihasználásának negatív hatása. Kockázatkezelés: Az informatikai rendszerekkel kapcsolatos kockázatok azonosításának, felügyeletének és csökkentésének teljes folyamata. Felöleli a kockázatbecslést, a költségek és nyereségek összehasonlítását, az óvintézkedések kiválasztását, megvalósítását, tesztelését és biztonsági értékelését. 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. Rendelkezésre állás: A rendelkezésre állás az informatikai rendszer olyan jellemzıje, amely az adatok és információk meghatározott módon, helyen, mennyiségben, minıségben, idıben stb. történı elérésére vonatkozik. Rendelkezésre álláson azt a valószínőséget értjük, amellyel egy meghatározott idıintervallumon belül az informatikai rendszer a tervezésekor meghatározott funkcionalitásnak megfelelıen, a feljogosított felhasználók által használható, azaz a rendszer mőködıképessége sem átmenetileg, sem pedig tartósan nincs akadályozva.

39


Rendszer biztonsági elıirányzat: Az SST egy szolgáltató rendszer megvalósított biztonsági képességinek specifikációját adja meg, ahogyan azokat egy adott üzemeltetési környezetben a felmért kockázatok kivédésre és/vagy a megfogalmazott szervezeti biztonsági szabályzatok érvényre juttatására alkalmazzák, annak érdekében, hogy a maradványkockázat elfogadható szintjét érjék el. Sebezhetıség: A rendszer biztonsági eljárásaiban, tervében, megvalósításában vagy a belsı intézkedésekben fellelhetı hiba vagy gyengeség, ami (véletlenül vagy szándékosan) aktivizálható és kihasználható, és a biztonság vagy a rendszer biztonsági szabályzatának megsértésével jár. Sértetlenség: A sértetlenség egy 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. A sértetlenséget általában az információkra, adatokra, illetve a programokra értelmezik. Ez az alap-veszélyforrás a programokat is érinti, mivel az adatok sértetlenségét csak rendeltetésszerő feldolgozás és átvitel esetén lehet biztosítani. A sértetlenség fogalma alatt gyakran értik a sérthetetlenségen túli teljességet, továbbá az ellentmondás mentességet és a helyességet, együttesen: adat-integritást. Az integritás ebben az összefüggésben azt jelenti, hogy az információ valamennyi része rendelkezésre áll és elérhetı. Tailorizálás: A biztonsági intézkedések testre szabásának a folyamata, melynek során a biztonsági kategorizálás alapján a szóban forgó szintre meghatározott minimális biztonsági követelményeket az adott rendszer mőködési környezetének megfelelıen módosítják. Veszély: Az a lehetıség, hogy egy adott veszélyforrás (veszélyokozó egyed) sikeresen kihasznál egy sebezhetıséget.

40

Útmutató az IT biztonsági szintek meghatározásához ÚTMUTATÓ AZ IT BIZTONSÁGI SZINTEK MEGHATÁROZÁSÁHOZ ÚTMUTATÓ

Recommend Documents