INFORMATIKA ELLENŐRZÉSI KÉZIKÖNYV

Kirner Attila (CISA) és Pichler Attila (CISA)

INFORMATIKA ELLENŐRZÉSI KÉZIKÖNYV

avagy

GYAKORLATI TANÁCSOK AZ INFORMATIKAI

KONTROLLOK MŰKÖDTETÉSÉHEZ

2007

Szerzők: Kirner Attila, CISA, a PSZÁF Informatika Felügyeleti

Főosztályvezetője, az ISACA Hu Vezetőségi tagja Pichler Attila, CISA, a Raiffeisen Bank Zrt. IT Auditora, az

ISACA Hu Vezetőségi tagja

Lektor: Fésűs Zoltán, CISA, a PSZÁF Informatika Felügyeleti Főosztályának

vezető informatikai főfelügyelője, az ISACA tagja

Szerkesztette: Pichler Attila, CISA, a Raiffeisen Bank Zrt. IT Auditora, az

ISACA Hu Vezetőségi tagja

Köszönjük a

támogatását!

Copyright © ISACA Hu

ISBN: 978-963-9493-39-1

Műszaki szerkesztő: Pichler Attila A borító és a kötés tervezője: Pichler Attila ([email protected]) Megjelent 16,5 (A5) ív terjedelemben , 500 példányban Betűtípus: Times New Roman Nyomda: www.konyvmuhely.hu - Tel.: 46/532-085.

Tartalomjegyzék BEVEZETŐ................................................................................................. 1

1. FÜGGETLEN INFORMATIKAI ELLENŐRZÉS........................ 3

1.1. AZ INFORMATIKAI ELLENŐRZÉS TERVEZÉSE ..................................51.2. AZ INFORMATIKAI ELLENŐRZÉS ELŐKÉSZÍTÉSE .............................81.3. AZ INFORMATIKAI ELLENŐRZÉS VÉGREHAJTÁSA ...........................91.4. AZ IT ELLENŐRZÉSEK NYOMON KÖVETÉSE..................................12

2. A KOCKÁZATOK MENEDZSELÉSE ........................................ 13

2.1. KOCKÁZATMENEDZSELÉSI MÓDSZERTAN ....................................152.2. KOCKÁZATÉRTÉKELÉS.................................................................172.3. A KOCKÁZATÉRTÉKELÉS EREDMÉNYÉNEK HASZNOSÍTÁSA..........18

3. A SZABÁLYOZÁS SZEREPE ...................................................... 19

3.1. A VONATKOZÓ SZABÁLYOZÁS ÁTTEKINTÉSE, STRUKTÚRÁJA.......203.2. A SZABÁLYOZÁS TARTALMA........................................................23

4. A FELADATOK ÉS FELELŐSSÉGEK ELHATÁROLÁSÁNAK ÁTTEKINTÉSE........................................................................................ 25

4.1. VÁLLALATI KULTÚRA ..................................................................254.2. ÖSSZEFÉRHETETLENSÉGEK..........................................................264.3. SZERVEZETI REND SZABÁLYOZÁSA..............................................27

5. INFORMATIKAI NYILVÁNTARTÁSOK VIZSGÁLATA....... 28

5.1. A NYILVÁNTARTÁSOKKAL KAPCSOLATOS FELADATOK

VIZSGÁLATA ............................................................................................295.2. A NYILVÁNTARTÁSOK TARTALMA ...............................................295.3. A FELHASZNÁLÓI TÁMOGATÁS MŰKÖDÉSÉNEK VIZSGÁLATA ......30

6. DOKUMENTÁLTSÁG VIZSGÁLATA ....................................... 32

7. A JOGOSULTSÁGMENEDZSMENT VIZSGÁLATA .............. 36

7.1 JOGOSULTSÁGKEZELÉS SZABÁLYOZÁSA .....................................37

8. AZ IT STRATÉGIA VIZSGÁLATA............................................. 39

9. FEJLESZTÉS .................................................................................. 44

10. TESZTELÉS VIZSGÁLATA......................................................... 49

10.1. A TESZTELÉSEK VIZSGÁLATÁNAK ELŐKÉSZÍTÉSE ....................49

10.2. TESZTELÉSI MÓDSZERTAN, ESETEK..........................................5010.3. TESZTELÉSEK MENEDZSELÉSE .................................................5110.4. TESZTADATOK VIZSGÁLATA ....................................................5210.5. A TESZTELÉS MONITOROZÁSA..................................................5210.6. TESZTEREDMÉNYEK ÉRTÉKELÉSE ............................................5310.7. ÉLESBEÁLLÍTÁS .......................................................................53

11. VÁLTOZÁSKEZELÉS .................................................................. 53

12. RENDKÍVÜLI HELYZETEK KEZELÉSE ................................. 55

12.1. ÜZLETMENET-FOLYTONOSSÁG MENEDZSELÉS VIZSGÁLATA ....5512.2. DRP TERVEK ELLENŐRZÉSE.....................................................5612.3. BCP/DRP TERVEK TESZTELÉSE ...............................................6112.4. A BCP/DRP TERVEK AKTUALIZÁLÁSA....................................63

13. A KÜLSŐ SZOLGÁLTATÓK MENEDZSELÉSE ..................... 64

13.1. SZERZŐDÉSKÖTÉS....................................................................6513.2. SZOLGÁLTATÁSI SZINT MÉRÉS .................................................66

14. A NAPLÓZÁS ELLENŐRZÉSE................................................... 67

14.1. NAPLÓZÁSI KONCEPCIÓ ...........................................................6914.2. NAPLÓZÁSI BEÁLLÍTÁSOK........................................................7014.3 NAPLÓÁLLOMÁNY ELEMZÉSEK ........................................................72

15. OKTATÁS ÉS IT BIZTONSÁG-TUDATOSSÁG ....................... 74

16. TOVÁBBI IT BIZTONSÁGI KONTROLLOK ........................... 77

ÖSSZEFOGLALÁS.................................................................................. 81

MIRE JÓ EZ A KÉZIKÖNYV? ......................................................................81MIT ÉRDEMES FELTÉTLENÜL MEGJEGYEZNI? ...........................................81

IRODALOMJEGYZÉK........................................................................... 83

MELLÉKLETEK ..................................................................................... 87

1. SZ. MELLÉKLET – A PDCA MODELL ................................................872. SZ. MELLÉKLET – A MINŐSÉGIRÁNYÍTÁSI RENDSZER MODELLJE ......883. SZ. MELLÉKLET – A KOCKÁZAT MENEDZSELÉS ÁLTALÁNOS LÉPÉSEI894. SZ. MELLÉKLET – AZ IT BIZTONSÁG MENEDZSELÉSE .......................905. SZ. MELLÉKLET – ÖSSZEFÉRHETETLENSÉGI TÁBLÁZAT....................916. SZ. MELLÉKLET – KONTROLL KÉRDÉSEK A COBIT ALAPJÁN ............92

Ajánlás

A Raiffeisen Bank Zrt. 20 éves folyamatos üzleti és IT fejlődése során egyre nagyobb hangsúlyt helyez a kockázatok meghatározására – felismérésére – kezelésére – monitorozására és elfogadható szintre történőcsökkentésére. A Bank termékpalettájának fejlődése, és az azokat támogató informatikai megoldások bonyolultsága évről évre nőtt, újabb kockázat típusok jelentek meg. Ezzel együtt az informatikában található kockázatok vonatkozásában egyre nagyobb mértékben támaszkodtunk a Bank (illetve a Bankcsoport) IT Auditorainak tevékenységére, így velük közösen határoztuk meg az általuk vizsgált területen végrehajtandó legszükségesebb feladatokat, intézkedéseket.

Az IT Auditorok segítségével mélyebben ismerhettük meg -többek között- a CobiT – BS7799 - COSO - ITIL módszertanokat, irányelveket. Ezek fehasználásával az informatikai üzemeltetésen és szervezésen, valamint a bankbiztonsági területeken dolgozó munkatársaim új felfogásban, de legfőképpen a kontroll tudatos szemléletrendszerében végzik napi feladataikat.

Nagy öröm számomra, hogy a Raiffeisen Bank Zrt. IT Auditora, a PSZÁF két kitűnő szakemberével közösen egy olyan kézikönyvet készített el, amely elsősorban a tevékenységük gyakorlati tapasztalatait mutatja be, az érintett IT iparági sztenderdek hivatkozásaikra építve azokat. A könyvben feldolgozott témák felölelik napjaink informatikájának legfontosabb területeit, valamint nemcsak az IT Audit, hanem IT kockázat vonatkozásában meghatározzák a kor követelményeit.

Kiemelten fontosnak tartom, ezért pár sorban kitérnék a könyvben is többször említett IT Auditor és IT vezetés közötti viszonyra. Rendkívül fontosnak tartom azt, hogy e területek illetve személyek szerepe, feladat- és felelősségi köre egyértelműen szabályozott, egymástól jól elhatárolt legyen. Ugyanakkor az együttműködés tartalma és működési módja jól kidolgozott alapjainak megfelelően végezzék tevékenységüket. Megfelelőnek, de folyamatosan fejlesztendőnek ítélem meg a Raiffeisen Bank Zrt. ebbéli tevékenységét, hiszen nálunk a Bank, valamint az IT vezetés, illetve az IT Auditor között fennálló –az audit szakma független, továbbá szakmai alapokon történő tevékenységének maximális tiszteletben tartása és annak biztosítása mellett- a kapcsolat, minden esetben a kockázatok minimalizálására és az egységes kockázatok lehetséges kezelésére irányulnak.

A Bank IT szakterületei (informatikai infrastruktúra fejlesztés és üzemeltetés, szervezet- és alkalmazásfejlesztés, projektum portfolió menedzsment és informatikai biztonság ) tevékenységeiket egyre összehangoltabb és az IT Audit szakmai ismeretei illetve az általa megfogalmazott követelmények messzemenő figyelembevételével végzik munkájukat.

Mindazonáltal nem tévesztjük szem elől, hogy míg a fejlesztők és üzemeltetők feladata az új rendszerek létrehozása és üzemeltetése, azok ügyfél szempontú megfelelőségi szintjének állandó biztosítása, addig az IT Audit fő feladata az idő és a szolgáltatási követelmények állandó nyomása alatt működő IT szervezetek tevékenységének, működési módjának szinte folyamatos ellenőrzése, ily módon azok támogatása.

Ezen gondolatokkal ajánlom e könyvet elsősorban a tárgyban - hozzám hasonlóan - irányítási illetve feladat megvalósítási tevékenységet folytató kollégáimnak, de ajánlom a módszertani továbbfejlesztés céljából a kérdés elméletével foglalkozó valamennyi érdeklődőnek.

Verő Péter – Raiffeisen Bank Zrt. Vezérigazgató-helyettese

Ajánlás Mottó: „A termék vagy a szolgáltatás olyan tulajdonságainak és jellemzőinek összessége, amelyek hatással vannak a terméknek vagy a szolgáltatásnak arra a képességére, hogy kifejezett vagy elvárható igényeket kielégítsen” (ISO 8402:1986 – A minőség definíciója).

Kedves Olvasók!

Mindennapi életünket átszövik az információs társadalom eszközei, módszerei és ismeretei. Az IT rendszerek tárgyilagos szakmai kontrollja azonban nem valósulhat meg a felkészült auditálás és a biztonsági kockázatok kivédése nélkül. A nemzetközi információ ellenőrök szervezete (ISACA – Information Systems Audit and Control Association) már 1967-es megalakulása óta a máig is érvényes küldetéssel jött létre. Az ISACA küldetésének lényege, hogy az üzleti vezetők informatikai ellenőrök napi munkájában használható, általánosan elfogadott információ-technológiai irányítási elvek hiteles, naprakész, nemzetközi rendszerének kutatása, fejlesztése, közzététele és terjesztése valósuljon meg. Az ISACA magyarországi tagszervezetének célja, hogy a fenti küldetés szemelőtt tartásával minél szélesebb körben valósuljon meg az informatikai ellenőri szakma professzionális kiterjesztése. Az ISACA HU célja, továbbá, hogy az informatikai menedzserek és ellenőrök munkáját támogató legmagasabb minőséget és tudásbázist biztosító szakmai tömörüléssé, szövetséggé váljon és útmutatásai segítségével világszínvonalú informatikai kultúra honosodjék meg. Az eredményes informatikai irányítás segít annak biztosításában, hogy az informatika támogassa az üzleti célokat, optimalizálja az informatikai beruházásokat és ennek megfelelően menedzselje az informatikával kapcsolatos kockázatokat és lehetőségeket.

A jelen kézikönyv megírásának is célja, hogy közelebb kerüljünk az ISACA által kitűzött célokhoz és ezzel is támogassuk a magyarországi vállalkozásokat üzleti céljaik elérésében. Ehhez kívánok sok sikert és kitartást mindenkinek.

Üdvözlettel:

Dr. Nyíry Géza – az ISACA Hu Vezetőségénék Elnöke

Gyakorlati tanácsok az informatikai kontrollok működtetéséhez.

- 1 -

BevezetőÁltalánosságban is elmondható, hogy nem szeretjük az ellenőrzést és ennek természetes velejárója az, hogy nem szeretjük az ellenőröket sem. Ez – sokszorosan – igaz az informatikai szakmára is. A gazdasági élet valamennyi területén az informatika befolyása az elmúlt időszakban jelentős mértékben megnőtt, de ezzel együtt megjelentek új informatikai fenyegetettségek (kockázatok) is, amelyeknek súlya, illetve üzemzavar esetén negatív és pénzben nagyon jól mérhető hatása hihetetlen mértékben megnövekedett. Az üzleti élet szereplői már régen felismerték – és sok esetben saját bőrükön meg is tapasztalhatták – a bekövetkezett informatika kockázatok negatív hatásait, így egyre többen döntöttek úgy, hogy informatikai kontrollok bevezetésével és informatikai auditorok által megfogalmazott javaslatokkal támogatják a hatékony és kontrollált formában megvalósuló IT működést. Ebből adódóan Mi, IT Auditorok egyre többen lettünk és napról napra bonyolultabb informatikai rendszerek és folyamatok megismerésével, IT iparági sztenderdek, valamint törvényi és Európai Uniós ajánlások implementálásával adunk hozzáadott értéket az adott szervezet számára. Általánosságban elmondhatjuk, hogy az IT auditorokhoz és az általuk végzett tevékenységekhez való IT hozzáállás szintje az elmúlt években javult, de még mindig találkozunk olyan vezetőkkel, beosztottakkal, akik szükséges rossznak tekintik az általunk végzett munkát, így nem minden esetben igénylik az informatikai ellenőrök szakmai tudását, önzetlen segítségét. Nekik, és minden leendő, illetve gyakorló IT Auditornak, informatikai auditot végző személynek, IT vezetőnek és munkatársaiknak, a gazdasági élet közép és felső vezetőinek, tanácsadóknak, IT fejlesztőknek készítettük ezt a könyvet!

Elsődleges célunk, hogy csökkentsük az informatika működtetéséért és az informatikai ellenőrzésért felelős munkatársak között fennálló – néha kibékíthetetlen – ellentétet, valamint gyakorlati tanácsokkal és az irodalomjegyzékben felsorolt hivatkozásokkal hívjuk fel mindkét oldal figyelmét az IT Auditorok által végzett tevékenységek értékeire, hasznosságára. Sok esetben az informatikus számára sem világos, hogy mit értenek az auditorok a kontroll szó alatt. A nemzetközi informatika ellenőri szervezet (az ISACA – Information Systems Audit and Control Association) erre is ad egy definíciót (a CobiT – Controll objectives for Information and Related Technology legújabb, 4.1. verziójában a „kontroll” szó 494-szer szerepel), amely szerint: „Az üzleti célkitűzések megvalósítása és a nem-kívánatos események megelőzése, felderítése és korrigálása céljából kialakított szabályok, eljárások, normák és szervezeti struktúrák”.


- 2 -

A definícióból következően tehát, minden olyan tevékenység, amely az üzleti célok megvalósítását és a nem kívánt események kiküszöbölését szolgálja, kontrollnak tekintendő. Úgyszintén az ISACA által megfogalmazottakat tekintjük nagyon hangsúlyosnak miszerint: „Az informatika értékének biztosítására, az informatikával kapcsolatos kockázatok kezelésére és az információk feletti kontroll, szigorodó követelményeire vonatkozó igény ma már a vállalat irányítás kulcsfontosságú eleme. Az érték, a kockázat és a kontroll az informatikai irányítás lényege. Az informatikai irányítás a felső vezetés és az igazgatótanács felelőssége, az informatikai irányítás lefedi azokat a területeket – a vezetést, a szervezeti struktúrát és folyamatokat – amelyek biztosítják, hogy a vállalat informatikai szolgáltatásai hozzájáruljanak a szervezet stratégiáinak és célkitűzéseinek fenntartásához, kiterjesztéséhez.”.

A kontrollok területén biztosan hallott már mindenki a széles körben elfogadott és gyakorlatban is használt a PreDeCo módszerről. Ez a módszertan a védelmet három egymásra épülő és egymást kiegészítő részre: a megelőző (preventív), a felismerő (detektív) és az elhárító (korrektív) kontrollokra bontja. A kontroll kifejezés azt a személetet tükrözi, hogy a rendszer védelménél az adott veszélyek fölötti kontrollra kell helyezni a hangsúlyt és nem feltétlenül a veszélyek bekövetkezésének teljes kizárására (ami általában egyébként sem megoldható). Jelen kézikönyvünk legfőbb célja, hogy felhívjuk a figyelmet: - a napi informatikai menedzselési, üzemeltetési és ellenőrzési gyakorlatban általunk leginkább fontosnak tartott fókuszpontokra, illetve - rávezessük az informatikával foglalkozó szakembereket (vezetőket, beszerzőket, fejlesztőket, ellenőröket) a nemzetközi informatika ellenőri szervezet által kiadott nyílt szabványok és kézikönyvek használatára, részt vállalva ezzel az általunk valóban fontosnak tartott és a CobiT kézikönyvek mindegyikének elején megfogalmazott küldetés megvalósításában: „Az üzleti vezetők és az ellenőrök napi munkájában használható általánosan elfogadott információtechnológia irányítási elvek hiteles, naprakész, nemzetközi rendszerének kutatása, fejlesztése, közzététele és terjesztése”. A kézikönyv olvasásával az informatikai szakemberek figyelmét arra szeretnénk ráirányítani, amit az ISACA Bázel2 megfelelési kézikönyve (IT control objectives for Bazel2) a következőképpen fogalmaz meg: „A jelenlegi legfontosabb üzleti prioritások az Irányítás, a Kockázatmenedzselés és a Jogszabályi megfelelés (GRC – Governance, Risk, Compliance)”!

A fentiek megvalósításához kívánnak sok sikert és jó olvasást a Szerzők!


- 3 -

1. Független informatikai ellenőrzés Miért kell ellenőrizni? Ha kontrollokról beszélünk, akkor elsőként mindenkinek az ellenőrzés jut az eszébe és ez természetes is, hiszen a jól működő kontroll környezet legfontosabb része a rendszeres ellenőrzés („Jó a bizalom, de legjobb az ellenőrzés”). A tevékenységet végző személyétől független, rendszeres ellenőrzés a biztosítéka a szabályozásnak megfelelő, folyamatosan magas minőségi kritériumokat teljesítő munkának (lásd a 2. számú mellékletet). Ebből adódóan a belső ellenőrnek mindig függetlennek, objektívnek és szabálykövetőnek kell lennie. A bevezetőben említett kontroll definíciót figyelembe véve – természetesen - az ellenőrzés egyedül nem biztosítja a kontrollok folyamatos működését, sőt kifejezetten rossz, ha csak az ellenőrzéstől való félelem közvetlen fenyegetésétől vezérelve végzik el a dolgozók a szükséges dokumentálási, szabályzási, technológiai vagy munkavédelmi kötelezettségeket. A tapasztalatok alapján éppen a jól működő vállalatok sajátja az, ha minden részletében, teljes mértékben áthatja a kontroll tudatos szemléletmód, amely a tervezés fázisától kezdve a fejlesztésen, az üzembe helyezésen és a működtetésen át, egészen az ellenőrzés fázisáig terjed és egyidejűleg a vállalati kultúra részévé válik. Az első fejezetben áttekintésre kerülnek azok az alapvető és az informatikai ellenőrökre nézve szinte kötelezően betartandó feladatok, amelyek elengedhetetlenek a magas színvonalon történő ellenőrzési program elkészítéséhez, az ellenőrzési folyamat menedzseléséhez. A fejezetben tárgyalt témákat, folyamatokat, tevékenységeket az adott Társaság szabályzataiban részletesen ki kell dolgozni.

Mit értünk informatikai ellenőrző rendszer alatt? Az informatikai ellenőrző rendszer alatt nem egy adott célalkalmazást kell érteni, hanem az informatikairányítás működését felügyelőkontrollkörnyezet kiépítettségét és működését, amelybe beletartoznak mindazon irányelvek, folyamatok, eljárások, gyakorlatok, napi rutinok, eszközök, emberi erőforrások és szervezeti struktúrák, amelyek ezt lehetővé teszik. Itt említhetjük meg az informatikai fejlesztési – szabályozási – üzemeltetési, illetve az informatikai biztonsági területet is.

Mely feladatokat célszerű elvégezni, ha jól szeretné kontrollálni az informatikát? Egy adott kontrolltevékenység szintjének meghatározására a mérés szolgál. A vezetésnek mérnie kell (a külső és belső szolgáltatási szint megállapodásokban meghatározott teljesítménymutatók, illetve kritikus sikertényezők alapján) a kulcsalkalmazások terén az informatikai részleg


- 4 -

által nyújtott szolgáltatásokat és össze kell hasonlítania azokat a tervezett szintekkel, illetve az – egyedi – megállapodásokban rögzített értékekkel. Az informatikai részleg teljesítményét rendszeres jelleggel és folyamatosan értékelni kell. A vezetésnek rendszeres időközönként meg kell vizsgálnia, hogy a felhasználók milyen mértékben elégedettek az informatikai részleg szolgáltatásaival és azok hatékonyságával. Jelentéseket kell készíteni a vezetés számára a kitűzött szervezeti célok megvalósításának irányában történt előrelépések áttekintéséhez, és a kockázatok csökkentése érdekében végrehajtott lépések megítéléséhez. Figyelemmel kell kísérni azt, hogy a belső ellenőrzési eljárások eredményesen működnek-e a szervezet szokásos eljárásrendjén belül. Az áttekintések alapján meg kell tenni a szükséges vezetői intézkedéseket és lépéseket. A belső ellenőrzési eljárások akkor működnek eredményesen, ha a preventív kontrollok gyorsan felderítik a hibákat és ellentmondásokat, és a szervezet kijavítja azokat, még mielőtt befolyásolnák a rendszer üzemszerűműködését, a szolgáltatásnyújtást, illetve konkrét kárt okoznának. A preventív kontrollok működőképessége és a munkatársak proaktivitása kulcsfontossággal bírnak. Gondoskodni kell az üzemeltetési biztonság és a belső ellenőrzés rendszeres felülvizsgálatáról, és ennek kapcsán önértékelés vagy független ellenőrzés formájában meg kell vizsgálni, hogy a biztonsági, valamint belsőellenőrzési eljárások a meghatározott, illetve alkalmazott biztonsági és belsőellenőrzési követelményeknek megfelelően működnek-e, vagy sem. A vezetésnek, saját felelősségi körében, fel kell tárnia a sebezhető pontokat és a biztonsági problémákat. A vezetésnek ki kell dolgoznia egy, az ellenőrzési területre vonatkozó szabályzatot, amelyben fel kell vázolni a feladatait, hatáskörét, beszámolási kötelezettségét és a számonkérhetőség módját. Ezen szabályzatot rendszeres időközönként felül kell vizsgálni és az aktualizáltságát fenn kell tartani. Az ellenőrnek függetlennek kell lennie a vizsgált részlegtől (tényleges és érzékelt függetlenség), hogy objektív ellenőrzést tudjon végezni. A kritikus fontosságú új informatikai szolgáltatások bevezetése előtt célszerűfüggetlen szakértői értékelést szerezni az érintett rendszerek biztonsági és belső ellenőrzési eljárásaira vonatkozóan. A szolgáltatás bevezetését követően rendszeres időközönként meg kell ismételni a független auditot. Külső szolgáltatók szolgáltatásainak igénybe vétele (kiszervezés) előtt úgyszintén érdemes független szakértői vizsgálatot végezni az adott szolgáltató biztonsági és belső ellenőrzési eljárásaira vonatkozóan.


- 5 -

A független szakértő lehet a szervezet belső ellenőre is, ha rendelkezik mindazokkal a szakmai, műszaki – technikai ismeretekkel – képességekkel – tapasztalatokkal – végzettséggel (CISA – Certified Information Systems Auditor), amelyek az ilyen jellegű feladatok hatékony és eredményes ellátásához szükségesek .

1.1. Az informatikai ellenőrzés tervezése

Hogyan tervezzünk? Minden alkotó folyamat első lépése a célok meghatározásával kezdődik. Az IT ellenőrzés célja egyértelműen � az informatikában található kockázatok felismerése és csökkentése, � a kontrollok kiépítésére vonatkozó intézkedések meghatározása, � az IT működési és üzemi kockázatok feltérképezése, majd azok

csökkentésére irányuló javaslatok meghozatala, valamint � a kontrollok tudatos működtetési szemléletmód megteremtésében való

közreműködése.

A célok eléréséhez szükséges első lépés, a Tervezés. Az IT ellenőrzéseket, a többi ellenőrzéshez hasonlóan legalább egy évre előre ajánlott megtervezni. A legnehezebb feladat meghatározni azt, hogy „mit, mikor és hogyan” vizsgáljon az IT ellenőr.

Mit vizsgáljunk? A vizsgálandó terület kiválasztásához – legyen az rendszer, alkalmazás, IT folyamat, vagy egy adott kontroll funkció működése – a legnagyobb segítséget az IT biztonsági kockázatelemzés (lásd a 2.1. fejezetet) és annak eredménye nyújt, amelyet legalább kétévente felül kell vizsgálni. Ahol ez nem áll rendelkezésre, ott az IT ellenőr számára nélkülözhetetlen adatok hiánya jelentősen megnehezít(het)i a tervezést. Az IT kockázatelemzés a következő fejezetekben még többször is említésre fog kerülni, de jelen esetben, mint elérhető és magas szintű dokumentum meglétét feltételezzük. A szakszerűen lefolytatott IT kockázatelemzésből megtudható, hogy az adott vizsgált területen (ha még nem volt vizsgálva) léteznek-e kockázatok és kontroll hiányosságok, illetve (ha már előzőleg is volt vizsgálva) milyen pozitív vagy negatív irányú változásokon ment keresztül az elmúlt időszakban, Meg kell tudni, hogy az egyes kockázati szintek hogyan, milyen irányban, illetve mekkora mértékben változtak. Abban az esetben, ha egy adott területen azonosított kockázati érték szemmel láthatóan – esetleg különösebb magyarázat nélkül felfelé változott, akkor érdemes kiemelt figyelmet fordítanunk rá, és felvenni azt az éves vizsgálati tervbe.


- 6 -

Vajon mi indukálta az adott terület kockázati szintjének változását? Milyen kontrollok hiánya vagy hatása befolyásolta ezen változást? A kérdések megválaszolása itt kulcsfontosságú lehet. Figyelemmel kell követni az elfogadott törvényi változásokat. Magyarországnak, az Európai Unióhoz való csatlakozásával törvényi szinten számos EU-s kötelezettségnek, direktívának kell megfelelnie. A pénzintézeti szektorban dolgozó IT ellenőröknek az ágazati törvényekben (Hpt., Tpt., Öpt., MNypt.) leírtaknak történő megfelelés vizsgálata jól megfogalmazható feladatokat határoz meg. Ezek mellett az olyan új szabályok, törvények megjelenése, mint például a Bázel2 (CRD) vagy MIFID az IT ellenőrök számára új kihívásokat és egyben megoldandó feladatokat ad. A tervezési szakaszban jól használhatóak az egyes, üzletileg kritikus rendszerekre vagy folyamatokra vonatkozó előre (nem) tervezett leállások, a BCM és a DRP események számosságát bemutató adatok. Az IT Help Desk-re érkező hívások okainak, a megoldott bejelentések és hibák arányának vizsgálatával szintén rendkívül hasznos információkhoz juthatunk a tervezési szakaszban. Az üzleti, számviteli és az IT témájú vizsgálatok együtt tervezése hasznos, hiszen tudhatjuk: „Ma már az IT nélkül nincsen üzlet!”. Az üzleti és az IT ellenőrzéseket végző auditorok között szoros és bilaterális kapcsolat kialakítása ajánlott.

Mit tartalmazzon egy hosszabb távú IT vizsgálati terv? A koncepcionális elképzelések kialakítása az ellenőrzésben is fontos, ezért szükség van hosszú távú vizsgálati tervre, amelyből látszik, hogy a kevésbé kockázatos, de nem elhanyagolható területek is ellenőrzés alá kerülnek. A belső ellenőri terveket is a legfőbb kockázatokra koncentrálva, egy adott kockázatelemzési módszertan alapján, a főbb kockázatok beazonosításával és kockázati térkép kialakításával érdemes elkészíteni. Kockázati térképet (vagy más néven kockázati ábrát) lehet készíteni – és azt követően folyamatosan aktualizálni – a részletesen kidolgozott IT Stratégiára is, így ennek mentén készíthető el a hosszú távú vizsgálati terv is. A vizsgálati tervnek tartalmaznia kell minden olyan hosszútávra tervezett és a jövőben használandó IT fejlesztést (legyen az szoftver, hardver, IT folyamat, stb. fejlesztés), amely döntően befolyásolhatja az adott szervezet jövőbeni működését. A tervezés elkészítéséhez nélkülözhetetlen az IT vezetői elképzelések, a felhasználói igények és szokások valamint a lényegesebb informatikai trendek megismerése.


- 7 -

A hosszú távú tervezés támogatására, belső ellenőröknek (is) ajánlott a COSO ERM Framework („Vállalati kockázatkezelés keret rendszere”) valamint a „2. A kockázatok menedzselése” fejezetben ismertetendőalapelvek figyelembe vétele és alkalmazása.

Miért kell minden adott IT vizsgálatot részletesen megtervezni? A rövid időtartamú, de összességében hatékony vizsgálat lefolytatásához szükség van egy részletes „vizsgálati terv”-re. A vizsgálati tervben a vizsgálat fontosabb lépéseit, jelentősebb területeit, menetét kell szerepeltetni, amelyeknek összhangban kell lenni a vizsgálat tárgyával (audit scope). A részletes tervben szerepeltetni lehet az előre elkészített ellenőrzési kérdéssorokat (checklist) is. A hatékonyság érdekében az adott témára vonatkozóan érdemes a vizsgált terület által kérdőív formájában kitöltött kockázati önbevallást használni, amely az ellenőrzést a hiányos területekre irányítja, és így a későbbiekben a mélységi vizsgálatokat a kontrollhiányos pontokra fókuszálva lehet lefolytatni. Az IT rendszer vizsgálatok során, például a dokumentációs környezet (lásd. 6. fejezet), vagy a jogosultságmenedzsment feladatok (lásd. 7. fejezet) elsődleges vizsgálatára remekül használhatóak ezek a kérdéssorok. Fontos! A kérdéssorok nem helyettesíthetik a helyszíni ellenőrzést, így kizárólag a felkészülésben segítik a vizsgálatot végző személyt. A kérdéssorokra adott válaszok csupán „tájékoztató jellegűek”, így azokat követniük kell egy vagy több személyes megbeszélésnek is. A részletes terv mindig átláthatóvá teszi a vizsgálatot, támogatja az audit lefolytatását.

Mikor vizsgáljunk? Ajánlott figyelembe venni az adott szervezeten belüli, elsősorban IT jellegűvagy IT érintettségű projektek tervezett kezdeti idejét és várható időtartamát. Nem kifizetődő olyan területet, rendszert stb. vizsgálni, amely egy projekt fókuszának markáns része, de egyben egy későbbi vizsgálatunk tárgya is. Előre (nem) tervezett külső vizsgálatot követően rögtön nem ajánlatos ugyanazon terület vizsgálata. A külső audit jelentésének elolvasásával, értelmezésével számos, a későbbiekben hasznos információkhoz juthatunk. Ha a vizsgálandó területen jelentős személyi változások történtek, esetleg a területen végzendő feladatokat újradefiniálták, akkor érdemes az adott területnek adni egy kis időt a „feltöltődésre”. A vizsgálati tervben – a mindenki által – elfogadott vizsgálatokat, azok várható időpontját érdemes előzetesen egyeztetni a vizsgált terület vezetőjével. Az audit, ezen ún. pozitív üzenete, amely a közreműködés egyik jele, a későbbiekben még kifizetődő is lehet.


- 8 -

Hogyan vizsgáljunk? A nemzetközi audit szervezetek (pl. IIA, ISACA) által lefektetett elvek – metódusok – ajánlásai egyértelműen kategorizálják az ellenőrzések típusait és az auditok lefolytatásának követelményeit. Ezen követelmények megismerését és mélyebb elsajátítását az ISACA Magyarországi Tagszervezete (a továbbiakban ISACA-HU), saját rendezvényein és tanfolyamain keresztül támogatja / oktatja. A vizsgálat során törekedni kell az interjúk alatt elhangzottak maximális dokumentálására. Vitás esetek alkalmával „perdöntőek” lehetnek a dokumentumban szereplő bejegyzések, így ajánlott az emlékeztetők elfogadtatása a másik féllel is. A fokozatosság elvét követve ajánlatos egyre nehezebb és bonyolultabb vizsgálatokat tervezni, valami az ellenőrzés hatókörének (Audit Scope) meghatározását ezek szerint kialakítani.

1.2. Az informatikai ellenőrzés előkészítése

Hogyan kezdjük az ellenőrzést? Egy-egy adott vizsgálatra minden esetben fel kell készülni. A vizsgálatra történő felkészülés más-más módon zajlik, akkor, hogy ha külső, vagy ha belső szakember fogja elvégezni, illetve különböző lehet, ha előre tervezett vagy ad-hoc vizsgálatot szándékozunk végezni. Minden esetben az adatgyűjtéssel kell kezdeni, az elérhető nyilvános, vagy hivatalosan beszerezhető (megküldött, vagy a hosszú távú terv elkészítésének időszakában már beszerzett) dokumentumok, információk feldolgozásával. Belső vizsgálat esetén a felkészülési szakaszban helyzeti előnyhöz juthatunk a belső működési folyamatok (erőviszonyok) ismeretével, amellyel természetszerűleg egy külső auditor nem, vagy nem olyan mértékben rendelkezik. A vizsgálat irányvonalát és kiterjedésének mélységét már itt célszerű legalább elvi szinten meghatározni. Mindenképpen meg kell határozni a vizsgálatra fordított időt és erőforrásokat, a bevonni szándékozott szakemberek számát stb. is. Ezek a döntések határozzák meg a Vizsgálati Program konkrét tartalmi összetevőit.

Miért kell megbízólevél, és melyek a leglényegesebb tartalmi elemei? A Megbízó levél tulajdonképpen a vizsgálatra történő felhatalmazás, amelyben a vizsgálatvezető megkapja a szervezet felső vezetésétől és a Felügyelő Bizottságtól (ha van) az elvégzendő auditra vonatkozó megbízást. Tartalmaznia kell az ellenőrzésben résztvevő személyek nevét, beosztását (külső személyek esetén egyéb azonosítókat is), valamint az audit tárgyát és időtartamát. A megbízólevelet mindig meg kell küldeni a vizsgált területek vezetőinek.


- 9 -

Gyakorlatilag ez az a dokumentum, amely felkéri (felszólítja) vizsgált területeket az IT ellenőrökkel történő együttműködésre, a szükséges vizsgálati anyagok átadására. Felhívjuk a figyelmet, hogy a belsőellenőröknek (beosztásukból és munkakörükből adódóan) a vizsgált területen, valamennyi dokumentumba, döntési dokumentációba, üzleti és személyes adatba és naplófájlba korlátlan betekintési joguk van!

Mit tartalmazzon egy vizsgálati vagy ellenőrzési program? Ellenőrzési program tartalmazza a vizsgálat tárgyát és hatókörét – ez lehet a vizsgálat egyik „Achilles sarka”–, hiszen itt kell rögzíteni a vizsgálat során a vizsgált egységeket – folyamatokat – a rendszerek csoportosítását – a rendszerek konkrét megnevezését – stb. A megfelelő szinten kialakított ellenőrzési program mindenki számára egyértelműsíti a vizsgálat kereteit, mozgásterét, láthatóvá teszi annak célját. Fontos! A vizsgálatot végző ellenőrnek lehetősége van a vizsgálat során a hatókört (audit scope) kibővíteni / megváltoztatni, de ezen döntését minden esetben a vizsgálati jelentésben indokolnia kell, és a jelentésben megállapításokkal, adatokkal (dokumentumokkal) alá kell támasztania. Az ellenőrzési programot ajánlott jóváhagyás céljából a belső ellenőrzés vezetőjének és tájékoztatás céljából a vizsgált terület vezetőjének megküldeni.

1.3. Az informatikai ellenőrzés végrehajtása

Hogyan vezessük le a vizsgálatot? Mivel az informatikai rendszerek vizsgálata leggyakrabban csak a helyszínen végezhető, ezért az informatikai ellenőrnek ott kell meggyőződnie az informatikai szolgáltatás helyzetéről és annak megfelelőségéről. A vizsgálat témájának megfelelően interjúkkal és a helyszínen beszerzett dokumentumokkal kell alátámasztania a megállapításait. A vizsgálat céljától függően át kell tekinteni a Szervezet releváns szabályzatait, nem elfeledve azt a külső környezetet (törvényi és egyéb szabályok), amelyben az adott Szervezet a tevékenységét végzi. Az informatikai ellenőrnek minden esetben az első lépése a vizsgált infromatikai rendszer megismerése (a lehető legrövidebb idő alatt). Az ehhez szükséges dokumentumokat vagy a vizsgálat előkészítésekor, vagy a vizsgálat kezdetén be kell szerzeni. A „leglényegesebb” dokumentumok a vizsgálat céljától függően változhatnak, de általában a következőkre mindig szükség van:


- 10 -

� A vizsgálat tárgyát képező IT rendszert alkotó infrastruktúra elemek (kiszolgálók, szerverek, hálózati és biztonsági eszközök, munkaállomások stb.) listája.

� Az IT architektúra ábra. Amely mutatja a hálózati kapcsolatokat és a felépítést.

� A rendszerek adatkapcsolati ábrája. Megmutatja, hogy az egyik rendszer hogyan és milyen módon ad át adatot egy másik rendszernek, és azok miként kapcsolódnak egymáshoz.

� A használt alkalmazások listája, másnéven a szoftver leltár. Itt nem a főkönyvi nyilvántartásról beszélünk, hanem az IT rendszereken futó alkalmazások listájáról.

� A vizsgált rendszerekről, a vizsgálat céljának eléréséhez szükséges dokumentumok (pl. biztonsági követelmények és beállítások, jogosultsági mátrixok, rendszer és a rendszeradminisztrálás szabályai, a változáskezelés módja és dokumentumai).

A rendszer megismerését követően interjúkkal és a vizsgálat tárgyát képezőtevékenységek gyakorlati végzése közben történő megfigyeléssel fel kell mérni, hogy az egyes informatikai feladatok elvégzése a gyakorlatban hogyan történik. Ekkor célszerű rákérdezni a szabályozás és a gyakorlati feladatvégzés közötti különbözőségek okaira, akadályaira. Amennyiben ezek a tények (problémák) az ellenőrzés megállapításai között szerepelnek (vagy későbbiekben szerepelni fognak), akkor azok dokumentálásra kiemelt figyelmet kell fordítani. Amennyiben nem tudjuk dokumentálni az adott problémát (a semmit, vagy a nem létező dolgokat valóban nehéz dokumentálni) célszerű egy közösen elkészített és elfogadott emlékeztetőben (nem jegyzőkönyv) rögzíteni a releváns adatokat (állapotot). A dokumentálásra vonatkozó javaslatokról a későbbiekben még részletesen is szó lesz (lásd a 6. fejeztet).

Mit tartalmazzon a vizsgálati jelentés tervezet? Az IT vizsgálati jelentés tervezetben legyen egy vezetői összefoglaló, amely a vizsgálat által feltárt leglényegesebb problémákat súlyozottan és kockázatokkal kiegészítve írja le. Ez lehetőleg ne legyen több egy oldalnál, és ne legyen kiemelve 5-7 problémánál több. A jelentés fő része tartalmazza az adott vizsgálat: � részletes eredményét, � főbb megállapításait, � az adott probléma hatását, vagy lehetséges hatását is, � és az ellenőrök által javasolt intézkedéseket – ezek egyeztetése a

vizsgált területtel már a vizsgálat alatt is megtörténhet, függően a Társaságnál alkalmazott eljárástól.


- 11 -

A jelentés elkészítésekor célszerű megvizsgálni a korábbi jelentések és javító intézkedések nyilvántartását (Follow Up), hogy az éppen megállapítani szándékozott probléma nem szerepel-e már egy korábbi jelentésben, mert akkor arra hivatkozva kell megállapítani azt, hogy az adott probléma kijavítása azóta – miért – nem történt meg. A jelentés tervezetet a vizsgálatot végző csoportnak el kell elfogadnia és ezt követően meg kell küldeni véleményezés céljából a vizsgált terület vezetőjének. Véleményezés során az érintett területeknek lehetőségük van véleményezni és megjegyzésekkel ellátni az adott jelentést. A véleményezési feladatra jutó időtartam az adott szervezettől függ (általában 8-10 munkanap). A véleményezési folyamat során még lehetőség van pontosítani a jelentésben foglaltakat, a pontatlanságokat és téves megállapításokat a visszajelzések alapján korrigálni kell, de ekkor már jelentős és döntő változtatások nem kerülhetnek a jelentésbe. Léteznek olyan jelentések, amelyek nem tartalmaznak javaslatokat (pl.: megfelelőségi vizsgálatok esetében), ezeknél a javító intézkedéseket külön dokumentumban (intézkedési terv) célszerű rögzíteni. Néhány esetben előfordulhat, hogy nincs olyan megállapítása egy vizsgálatnak, amely további intézkedést igényel, ekkor ezt a megállapításban (comment) ajánlatos rögzíteni.

Hogyan zárjuk le és véglegesítsük a jelentést? A vizsgálati jelentés megtárgyalása, és lezárása során az adott Szervezet felső vezetése és / vagy Felügyelő Bizottsága, az érintett területek vezetői, valamint a vizsgálatot végző csoporttal közösen értékelik a vizsgálati jelentésben foglaltakat. Javasolt minden kifogást, pontosítást, ezen a megbeszélésen megtárgyalni. A tárgyalást követően dokumentálni kell a végső döntést, és ezzel a dokumentációval együtt lehet csak lezártnak tekinteni a vizsgálatot. Fontos, hogy minden megállapítás és intézkedés esetében konkrét döntés szülessen (a feladat, felelős, határidő pontos meghatározása, vagy az adott probléma felvállalásával történő további működés). Ha nem lehet konkrét döntést hozni, akkor feladat, felelős, határidőkijelölésével kell gondoskodni a döntéshez szükséges további adatok beszerzéséről. A jelentés lezárási folyamatának lépései az adott szervezet belső hierarchiájától és tulajdonosi felépítésétől függően kissé módosulhat, de jelentős eltérés nem ajánlott.

Mit ellenőrizzünk a vizsgálati jelentésben? Mivel az IT ellenőrök sem tévedhetetlenek, érdemes az elkészült vizsgálati jelentés minőségbiztosításáról gondoskodni.


- 12 -

A kész vizsgálati jelentés minőségbiztosítására érdemes – az ellenőrzési szervezet létszámától függően – a vizsgálatban nem résztvevőmunkatársnak átadni, aki az alábbi szempontokat ellenőrzi le: � a jelentés teljesíti-e a belső ellenőri szabályzatban megkövetelt formai

szempontokat (fedőlap, aláírások, összefoglaló, megállapítások, javaslatok, határidők, felelősök stb.),

� az ellenőrzések esetén szükséges dokumentációk csatolva vannak-e (kiértesítő levél, megbízó levél, a megállapításokat alátámasztó dokumentumok stb.)

� nyelvtanilag megfelelő-e (a szóhasználat egységes, nincs túl sok helyesírási hiba, a nevek helyesek, illetve aktualizáltak-e stb.)

� vannak-e félreérthető vagy kategórikus megállapítások (nincs, nem létezik stb.)

� a megállapítások megfelelően csoportosítottak-e (összhangban a vizsgálati programmal), illetve konzisztensek-e (nincsenek egymásnak ellentmondó megállapítások)

� a prioritások megfelelők-e (a főbb megállapítások kiemelésre kerültek-e, helytállóak-e, tartozik-e hozzájuk javaslat, a javaslatok összhangban vannak-e a megállapításokkal stb.)

1.4. Az IT ellenőrzések nyomon követése

Milyen feladatok vannak egy ellenőrzés után? Amennyiben a vizsgálatnak nem volt olyan megállapítása, amely valamilyen javító intézkedést írt volna elő, akkor nincs további teendő. Azonban az esetek többségében a megállapításokban rögzített hibák, problémák kijavítására intézkedések kerülnek előírásra, amelyek végrehajtását is a vizsgálatot végzőknek (vagy az adott társaság belsőellenőrzésének) kell ellenőrizni. Mivel általában több vizsgálat történik egy év alatt, – főleg egy nagyobb társaságnál – és a vizsgálatoknak egyenként is több megállapítása szokott lenni, így a konkrét javító intézkedések fejben történő nyomon követése, végrehajtásuk megítélése nem megoldás. A megállapításokat és az elfogadott javító intézkedéseket célszerű egy informatikai rendszerrel támogatott nyilvántartásban vezetni (ha mást nem egy excel táblában), mert így elkerülhető, hogy egy le nem járt határidejűjavító intézkedés miatt fennálló problémát ismételjünk, másrészt nem vész el egy intézkedési előírás, amelyet a Társaság vezetése feladatként előírt. Az intézkedések végrehajtásának ellenőrzésére több módszer használható, ezek között két alapvető különbség van, vagy beszámol az intézkedésre kötelezett az intézkedés elvégzéséről, majd ezt értékelik, vagy helyszíni utóvizsgálat keretében vizsgálják meg az intézkedések megfelelővégrehajtását.


- 13 -

Az IT ellenőrnek kötelessége az elhangzott információk hitelességét ellenőrizni, majd az eredményeket az eredeti intézkedéssel megfeleltetni. Ezen ellenőrzési tevékenységet minden esetben végre kell hajtani! Abban az esetben, ha az intézkedések a megadott határidőn túl sem teljesülnek úgy azokat össze kell gyűjteni egy utóellenőrzési (Follow Up) jelentésben, és azokat be kell mutatni az adott Társaság felső vezetésének és / vagy Felügyelő Bizottságának. Az utóellenőrzési jelentés formájában és tartalmában különbözik normál jelentésektől, kizárólag a korábbi javaslatok és intézkedések teljesülését vizsgálja.

Az ellenőrzések informatikai támogatására használt alkalmazással szemben milyen követelményeket támasszunk? Az IT, de valamennyi vizsgálati jelentés menedzselése során biztosítani kell a teljes ellenőrzési folyamat hitelességét és az utólagos nyomon követhetőséget (a megbízólevél elkészítésétől kezdődően, a vizsgálati jelentés lezárásán keresztül, az intézkedések státusz változásainak időpontjain és megfelelőségük vizsgálatán át a teljes lezárásig). Minden vizsgálat, de különösen az IT vizsgálati jelentés szigorúan bizalmas jellege miatt, az ellenőrzési folyamatokat, ellenőri jelentések életútját és egyeztetési, valamint jóváhagyási lépéseit támogató informatikai alkalmazásnak meg kell felelnie az alábbi feltételeknek: � Életciklus követése, amely az adott folyamat, illetve dokumentum

létrehozásától az utolsó hozzáférésig rögzíti a legfontosabb lényegi információkat. A döntési és jóváhagyási pontokat minden esetben rögzíteni kell.

� Hozzáférés kezelés, amely biztosítja, az ellenőri jelentésekhez való hozzáférés kellő részletezettségét, és kizárólag a megfelelőcsoportszintű hozzáférések használatát.

� Sérthetetlenség, amely biztosítja, hogy a lezárt jelentések, a vezetői vélemények, és jóváhagyások tartalmán utólagosan ne lehessen módosítani.

�� A kockázatok menedzselése Miért van szükség kockázatmenedzsmentre? Az emberek alapvető szükséglete a biztonságra való törekvés. Amikor valaki azt mondja az életrajzában vagy a felvételi interjúk során, hogy „szeretem a kihívásokat”, feltételezhetően akkor sem mérlegelés vagy felkészülés nélkül „ugrik neki” a feladatoknak. Mindenki minél biztosabban szeretné tudni, hogy mire számíthat egy-egy újabb feladat vagy újabb vállalkozás előtt. Így van ez az élet minden területén.


- 14 -

A gazdasági vállalkozások esetén pedig hatványozottan érvényes, hogy a szűkös pénzügyi- és beruházási lehetőségeket mindenképpen a legjövedelmezőbb területekre, csak a legszükségesebb fejlesztésekre szeretnék fordítani, ahol a legnagyobb a várható haszon és persze minimális a kockázat.

Hogyan definiáljuk a kockázatokat? A kockázat röviden megfogalmazva annak a fokmérője, hogy egy adott szervezet milyen mértékben van kitéve veszélyeknek. A kockázatok függnek az eszközértékektől (hatás), illetve a vagyontárgyakat fenyegetni képes veszélyek, sebezhetőségek és ezen hatások súlyosságát csökkenteni képes meglévő ellenintézkedések (kontrollok) bekövetkezési lehetőségétől (valószínűség). A kockázatok tehát a kockázatoknak kitett vagyontárgyak értékéből és a potenciális kedvezőtlen üzleti hatásokat okozó fenyegetések, az azonosított fenyegetések által a sebezhetőségek kihasználása könnyűségének, valamint mindazon – a kockázatokat csökkentő – meglévőellenintézkedéseknek valószínűségéből számított számérték. A kockázat kezelés lépései a legtöbb módszertanban a vagyontárgyak felméréséből, a vagyontárgyakat fenyegető veszélyek, sebezhetőségek és meglévőellenintézkedések azonosításából, az ezen információkból kalkulált kockázat kiszámításából, a kockázatokat csökkentő további ellenintézkedések meghatározásából és a kockázati táblázat vezetői jóváhagyásából (kockázatok felvállalása vagy intézkedések foganatosítása) áll. Bármilyen módját is válasszuk a kockázat mértékének meghatározására, a felmérés eredménye egy lista kell, hogy legyen a számított és sorrendbe állított kockázatokról, amely a vezetés számára világosan mutatja, hogy mely kockázatokkal szükséges elsőként foglalkozni. Az alkalmazott módszernek megismételhetőnek és nyomon követhetőnek kell lennie. A kockázatfelmérésnek, elemzésnek és menedzselésnek igazodnia kell a Társaság legkritikusabb üzleti folyamataihoz, és ki kell terjednie a tervezés, a fejlesztés, a beszerzés, az üzemeltetés, a kiszervezés és az ellenőrzés területére is. A munkadokumentumok elkészítése és a menedzselt kockázatonként a védelmi intézkedések bemutatása elengedhetetlen a kockázatfelmérés és elemzés megfelelőségének megítéléséhez. A kockázatelemzésnek minden olyan rendszerelemre ki kell terjedni (a kiszervezési szolgáltatónál) is, amely a szolgáltatáshoz kapcsolódik (külső szolgáltatók, kiszervezett tevékenységek is). Ezek megléte nélkül a szolgáltatás megfelelősége nem biztosítható. A kockázatelemzés rendszeres elvégzését belső szabályozás szintjén kell megfogalmazni, és annak megfelelően kell eljárni (a szabályzatokban dokumentálni kell a módszertant, annak megismerhetőségét – ellenőrizhetőségét és az újbóli végrehajthatóságát).


- 15 -

A kockázatok felmérését és elemzését új rendszerek üzembe helyezését követően, a környezeti változásokat figyelembe véve, illetve előre meghatározott rendszerességgel (lehetőleg évente) végre kell hajtani. A kockázatelemzést minden rendszerre (szoftver és hardver) el kell végezni.

2.1. Kockázatmenedzselési módszertan

Mi a kockázatkezelés menete? Arra, hogy hogyan lehet mégis a leghatékonyabban, a legkisebb befektetéssel a legnagyobb haszonra szert tenni, a legáltalánosabban elterjedt megoldás a kockázatmenedzselés (lásd a 3. számú mellékletet). Ez biztosítja a hosszú idő átlagában legkiegyensúlyozottabb és leghatékonyabb működést. De hogyan lehet ezt megvalósítani? Természetesen a már ismert legjobb példák (legjobb gyakorlatok – „best pracitces”) jelen esetben a kockázatmenedzselési megoldások követésével. A kockázatmenedzselésre vonatkozó szakirodalom alapján ez a tevékenység, egy általunk kiválasztott kockázatelemzési módszertan szisztematikus véghezvitelét jelenti. A kiválasztott kockázatmenedzselési módszertan leírja a kockázatelemzés menetét, amely segítséget nyújt abban, hogy a rendszert leginkább fenyegető tényezőket azonosíthassuk, és ennek ismeretében a szükséges kockázatarányos védekezést kialakítsuk, valamint ezzel együtt a legköltséghatékonyabb megoldást választhassuk. A megfelelően megalapozott kockázatelemzés hiányában ugyanis nem biztosítható, hogy a biztonság fokozására fordított kiadások a legkisebbek legyenek. A kockázatarányos védekezés azonban nem csak a költségek minimalizálása szempontjából fontos. Ez biztosítja a teljes körű rendszerszemléletet is, ugyanis értelmetlen dolog például csak a fizikai biztonságra fordítani milliókat, ha ugyanakkor az internet felőli támadásokra vagy a logikai biztonságra egy fillért sem költünk („a lánc olyan erős, mint a leggyengébb láncszeme”).

Milyen módszertant válasszunk? Az informatika biztonsági kockázatok kezelése érdekében javasolt egy olyan kockázatelemzési módszertan kiválasztása, amely az informatikai biztonsági kockázatok szisztematikus felmérését és menedzselését teszi lehetővé. A kockázatfelmérésnek, elemzésnek és menedzselésnek igazodnia kell a pénzügyi intézmény legkritikusabb üzleti folyamataihoz és ki kell terjednie a tervezés, a fejlesztés, a beszerzés, az üzemeltetés, a kiszervezés és az ellenőrzés területére is. A munkadokumentumok elkészítése és a menedzselt kockázatonként a védelmi intézkedések bemutatása fontos a kockázatfelmérés és elemzés megfelelőségének megítéléséhez.


- 16 -

A kockázatelemzés tehát az IT biztonság lényeges eleme, azonban ennek rendszeres kivitelezését megnehezíti a rendszerek, emberek és folyamatok rendkívül bonyolult összefonódása. Annak érdekében, hogy ez kezelhetőlegyen, segédeszközökre, módszertanra van szükségünk. A választott módszertannal szemben tulajdonképpen csak annyi elvárást érdemes támasztani, hogy az megfelelően megbízható, azaz a kockázatok szisztematikus felmérése alkalmas legyen. A legtöbb nyilvánosan elérhető módszertan tartalmazza a � kockázatkezelési elmélet alapjait, � kockázat felmérés lépéseit, � veszélyforrások és fenyegetések meghatározásának elveit, � kockázati érték számítás módszerét, a maradék kockázat csökkentő

lépések gyakorlati meghatározását. A nyilvánosan elérhető kockázatmenedzselési módszertanok közül néhányat a dokumentumjegyzékben is felsoroltunk. A legtöbb módszer táblázatokat használ a kockázatok felsorolására és priorizálására, kombinálva azokat szubjektív és tapasztalati mutatószámokkal. Általában, nincs jó vagy rossz használható módszer. Sokkal fontosabb, hogy a szervezet olyan módszert használjon, amelyik számára kényelmes, amelyben bízik, és amely megismételhető eredményeket hoz. A legtöbb kockázatértékelés legfőbb haszna, a szisztematikus kockázatelemzés során végzett figyelemfelhívó munka, amelynek segítségével ráébresztik a munkatársakat a kockázatokra és a kockázattudatos gondolkozásra.

A kockázatkezelés esetében is (mint általában mindig) a módszertan csak annyit ér, amennyit a gyakorlatban megvalósítunk belőle. A kockázatmenedzselésről általánosságban is igaz, amit a COBIT 4.1. ír: „A kockázatkezeléshez szükség van arra, hogy a szervezet felső vezetői tisztában legyenek a kockázatokkal, hogy egyértelmű legyen az, hogy a vállalat milyen kockázattűrő képességgel rendelkezik, hogy ismertek legyenek a megfelelőségi követelmények, hogy átláthatóak legyenek a vállalat jelentős kockázatai és, hogy a kockázatkezelésért való felelősséget a szervezet minden szintjén meghatározzák.”

Mik a kockázat menedzselés fontosabb elemei? A kockázatok elemzése több fázisból áll, amelyek általában a következőek: � a vagyontárgyak azonosítása és értékelése, azaz a potenciális

kedvezőtlen üzleti hatások felmérése), � a fenyegetések felmérése, � a sebezhetőségek felmérése, � a kockázatok felmérése, valamint � a meglévő/tervezett ellenintézkedések meghatározása.


- 17 -

A vagyontárgyak, amelyek értékkel bírnak és bizonyos fokban sebezhetőek, mindenkor kockázatnak vannak kitéve, amikor a vagyontárgyat fenyegetőveszély fennáll. A kockázatok értékelésében ötvöződnek a nem kívánt incidensek potenciális kedvezőtlen üzleti hatásai, valamint a felbecsült fenyegetések és sebezhetőségek szintje. A kockázatok lényegében annak fokmérői, hogy egy adott rendszer és a vele kapcsolatban álló szervezet milyen mértékben lehet kitéve veszélynek. A működési kockázatok definíciója Bázel 2 szerint: „a nem megfelelő vagy rosszul működő belsőfolyamatokból, személyekből és rendszerekből, vagy külső eseményekből eredő veszteség kockázata, amely magában foglalja a jogi kockázatot is”. A kockázatok függnek a(z) � eszközértékektől (hatás), � vagyontárgyakat fenyegető veszélyektől és azok előfordulási

valószínűségétől, � sebezhetőségek könnyű kihasználhatóságától, � sebezhetőségek, fenyegetések és hatásaik súlyosságát esetleg

csökkenteni képes meglévő és tervezett ellenintézkedésektől. A kockázatelemzés célja, azonosítani és felmérni azokat a kockázatokat, amelyeknek az informatikai rendszer és vagyontárgyai ki vannak téve, annak érdekében, hogy a megfelelő és indokolt biztonsági ellenintézkedéseket meghatározzák és kiválasszák. A kockázatok felmérésekor több tényezőt (legfőképpen a hatást és a valószínűséget) veszünk figyelembe.

2.2. Kockázatértékelés

Mire figyeljünk a kockázatértékeléskor? A nemzetközi informatika irányítási módszertanokkal és irányelvekkel összhangban a felügyeleti vizsgálatok is a pénzügyi szervezeteknél fennálló kockázatok feltárására irányul. A vizsgálatokat lezáró határozati kötelezések továbbá javaslatok a kockázatok csökkentését célozzák meg. Ebből a szempontból a problémák gyökere leggyakrabban a működési kockázatok nem rendszeres kiértékeléséből és az alacsony színvonalú kontroll rendszerből adódik. Az intézmények nagy részénél (és főleg a kisebb szervezeteknél), gyakran a rendelkezésre álló erőforrások és nem pedig a fennálló kockázatok határozzák meg a feladatvégzés alapját. A legjobb gyakorlat -és a pénzügyi szervezetekre vonatkozó jogszabály szerint is- az informatikai feladatokat (szabályozottság, szervezeti és működési rendek, fizikai, logikai, adat és vírusvédelem, nyilvántartások, üzletmenet-folytonosság, stb.) a „biztonsági kockázatelemzés” alapján kell végrehajtani.


- 18 -

Ez a szemlélet alkalmas arra, hogy pénzügyi szervezetek a rendelkezésre álló erőforrásokat a legfontosabb teendők köré csoportosítsák, megfelelőkontrollkörnyezetet építsenek ki, és azt elfogadtassák a tulajdonosokkal, ügyfelekkel és a partnerekkel (felügyelettel). A megfelelő színvonalú kockázatkezeléshez fontos a kockázat elemzési módszertan kiválasztása, dokumentálása, szabályozása és működtetése. A pénzügyi szervezetekre vonatkozó jogszabály csupán kereteket ad és ezáltal szabad kezet biztosít a megfelelő módszertan kiválasztásában. A kockázatkezelési módszertanoknak széles választéka elérhető – akár ingyenesen is – az interneten keresztül, illetve nagyon sok tanácsadó cég kínál ilyen terméket. A kockázatkezelési módok megválasztása is szabadon választott, azonban a következményeit továbbra is vállalni kell, a kezelése a vezetőség feladata és felelőssége. A magas kockázatok figyelmen kívül hagyása és kontrollálatlansága pénzügyi szervezeteknél minden esetben felügyeleti javaslatot eredményez.

2.3. A kockázatértékelés eredményének hasznosítása

Milyen haszna van a kockázatértékelés rendszeres végrehajtásának? A kockázatértékelés eredményének hasznosítása a legfontosabb. Ne csak adminisztratív kötelességből, a külső auditorok vagy belső ellenőröknek, független szakértőknek való megfelelési kényszerből készítsünk kockázatelemzést, hanem azért mert annak eredménye a beruházási döntések és az IT menedzselési döntések miatt szükségesek. A kockázatelemzés eredménye csak akkor válik használhatóvá, ha a kockázati valószínűség és a várható veszteség értéke mellett feltüntetésre kerül egy számérték (maga a kockázat), amely megmutatja, hogy mi a problémák (kockázatok) prioritási sorrendje és mellettük feltüntetésre kerülnek a kockázat csökkentő intézkedések (kinek, milyen határidővel, mit kell tennie, hogy a kockázatokat csökkenthesse). A kockázat elemzésben meg kell jelenniük a kockázat csökkentőintézkedéseknek és a beruházások (fejlesztések) megvalósulását követőkockázati érték csökkenésnek, amelyből a vezetés le tudja mérni az intézkedések hatását. Ha a technológiaváltások, az új beruházások, az erőforrás növelések és a kontroll környezet javítására tett erőfeszítések nem látszódnak a kockázatelemzésben, akkor teljesen természetes, hogy a vezetőség feleslegesnek fogja érezni a kockázat menedzselésre fordított energiákat. Ellenőrzési tapasztalat az is, hogy bár sok esetben a kockázatelemzés ténye nem csökkenti a vállalat kitettségét, azonban a vállalat egészére kiterjedőkockázatelemzés nagy hatással van a kockázat tudatosságra, amely már önmagában kockázat csökkentő tényező.


- 19 -

Mint minden kontroll tevékenység, a kockázatmenedzselés sem egyszeri, hanem folyamatos feladat, tehát rendszeres (minimum évente történő) elvégzéséről gondoskodni kell. Ha valaki – a világszerte terjedő tendencia (pl. SOX, Bázel2, Solvency II előírások) ellenére - még mindig nem látná be a kockázat elemzés fontosságát, akkor annak a pénzügyi szervezetekre vonatkozó jogszabályok informatikai rendszer biztonságával foglalkozó részére hívnánk fel a figyelmét, ahol is a legtöbb paragrafusban a „kockázatokkal arányosan” megfogalmazás szerepel.

Mit jelent a kockázatarányosság? Az elmúlt években, esetekben parázs vita alakult ki az IT Auditorok és az informatika között a „kockázattal arányos” megfogalmazás értelmezésében. A „kockázattal arányos” megfogalmazás egy lehetőség, amely alapján a különböző méretű és tevékenységű intézményekre ugyanazon kontroll alapelvek használhatók, illetve a vezetőség eldöntheti, hogy mekkora az a veszély, amelyet felvállal és mekkora az a veszély, amelyre már kockázatcsökkentő lépést kezdeményez. A kockázat menedzselés sok jogszabályban kötelező elemként is megjelenik, viszont támogatja azt, hogy hogyan lehet különböző méretű, tevékenységű, kulturális és technológiai hátterű intézményekre ugyanazokat az előírásokat alkalmazni. A kockázat felmérés - kockázatelemzés - kockázatértékelés - kockázat mendzselés között szoros kapcsolat van. A már megismert és így a Szervezet által azonosított kockázatok és azok csökkentésére hozott döntések közötti arányt nevezhetjük akár kockázati aránynak is. Minden esetben cél az, hogy az adott Szervezet / Társaság kizárólag csak akkora összeget költsön egy ismert kockázat csökkentésére, amekkora indokolt.

�� A szabályozás szerepe Miért kell szabályozni? Az auditorok szájából a „kontroll” szó mellett a második leggyakrabban kimondott szó a „szabályozás”! A legtöbben a szükséges „rossz”-at látják, pedig a megfelelően elkészített és karbantartott szabályozási környezet, nagymértékben segíti a napi munkavégzést, egyenlő arányban védi a munkavállalót és munkaadót, valamint biztosítja az adott szervezet hatékony működését. Változtassuk meg a rossz beidegződésket!


- 20 -

3.1. A vonatkozó szabályozás áttekintése, struktúrája

Mit kell vizsgálni a szabályozás témakörében? A „szabályozási rendszer”-el kapcsolatban meg kell vizsgálni, hogy a szabályozási struktúra megfelelő-e, a legfontosabb informatikára vonatkozó szabályozások elkészültek-e. Célszerű, ha a szabályozási rendszer hierarchiája az „irányelvek - szabályzatok - eljárásrendek” hármas struktúrát követi. A szabályozások mennyiségére, formai követelményeire vonatkozóan nincsenek szigorú elvárások, azonban a szabályozások és a napi gyakorlatban végrehajtott feladatok összhangját biztosítani kell. A szabályozási rendszerből ki kell derülnie, a szabályozások hatályba léptetési idejének (módosított szabályzat érvénybeléptetési idejének), aktualizáltsági fokának, hatókörének és a megismerés mértékének. A szabályozási környezet az IT esetében tartalmazza az Informatikai biztonsági politikát (politika), az Informatikai biztonsági szabályozásokat (szabályozást), és az „Informatikai rendszerek üzemeltetési rendjét (eljárások). Ezen hármason belül rendezni kell a hozzáférések- és jogosultságok kezelését, a vírusvédelmi szabályozást, a mentések és archiválások kezelését, a kockázatok elemzésének és kezelésének módszerét (dokumentált módszertant, amely alapján a kockázatelemzést elvégzik), a tesztelések- és változások kezelését, illetve az alkalmazottak általi elérhetőség és megismertetés követelményeit. Ezeket a legalapvetőbb szabályozási részeket minden társaságál el kell készíteni (ez a minimum).

Elengedhetelen, hogy a szabályzatok elkészítésére, bővítésére, módosítására, kiadásának menetére és formai követelményeire vonatkozóan is legyenek irányelvek (szabályzatok szabályzata), illetve a szabályozási rendszer karbantartásának is legyen kijelölt felelőse. A szabályozási rendszer azonban mégis csak akkor éri el célját, ha a belső működési gyakorlat összhangban van a szabályozásokkal, és ellentmondás esetén vagy a meghonosodott gyakorlat, vagy a vonatkozó szabályozás módosítására kerül úgy, hogy figyelembe veszi a hatékonysági és üzleti célokat. Az irányelveket - szabályzatokat - eljárásrendeket rendszeresen (évente legalább egyszer), vagy az üzleti, illetve a működési környezetben történt jelentős változások esetén felül kell vizsgálni és szükség esetén módosítani kell. A vezetésnek emellett figyelemmel kell kísérnie azt is, hogy időszerűek-e az alkalmazott irányelvek, és ki kell alakítani egy megfelelő rendszert és eljárást a normák, alapelvek, célkitűzések, irányelvek és eljárások időszakos felülvizsgálatára és jóváhagyására vonatkozóan.


- 21 -

Célszerű ellenőrizni, hogy minden IT felhasználóval megismertették-e a rá vonatkozó informatikához kapcsolódó biztonsági szabályokat, és gondoskodtak-e arról, hogy minden felhasználó teljes mértékben megértse a biztonsági szabályok fontosságát. Az oktatásnak (lásd. 15. fejezet) azt az üzenetet kell közvetítenie, hogy az informatika biztonsága az intézmény egészének, vagyis minden dolgozónak közös érdeke, amelyért mindenki felelős. Az „információ technológiával szemben támasztott követelmények” értelmezésében javasolt a CobiT kézikönyvek figyelembe vétele.

Mit vizsgáljunk a külső szabályokkal kapcsolatban? Természetes az, hogy a belső szabályozási rendszernek összhangban kell lennie a törvényi előírásokkal és nem mondhat ellent a hazai és EU-s jogszabályoknak, direktíváknak, irányelveknek. Törvényi előírások hiánya esetén, javasolt az informatikára vonatkozó hazai- és nemzetközi sztenderdek figyelembe vétele. Fontos ellenőrizni, hogy a társaság által alkalmazott külső szolgáltatókra mennyiben érvényesek a Társaság belsőszabályai, illetve meghatározni azt, hogy azokat a külső szolgáltatók milyen szinten tartják be. Kiszervezés esetén a szabályzatok elkészítése, módosítása a szerződésben rögzítettek szerint történik, de mindkét félnek gondoskodnia kell a releváns szabályzatok saját magánál történő érvénybe helyezéséről és a felhasználók megfelelő tájékoztatásáról.

Hogyan épül fel egy jó szabályozási rendszer? A szabályozási környezetet a politikák, szabályzatok, előírások, utasítások, belső eljárásrendek, ajánlások, ügyrendek, munkafolyamat – termékek, valamint a munkaköri leírások stb. alkotják. Legmagasabb szinten az SZMSZ (Szervezeti és Működési és Szabályzat) szabályoz, majd hierarchikus felépítésben következik a többi. Közös bennük az, hogy: � egy adott területet, munkafolyamatot, feladatot, tevékenységet stb.

szabályoznak, � felelősségi köröket, felelősséget rendelnek adott munkakörökhöz /

szerepkörökhöz, � „best practice” megoldást kínálnak, � vezetői jóváhagyást követően lettek bevezetve.

Egy jó szabályozási környezettel szemben a következő elvárásokat kell támasztani (ezek segítenek az auditornak, hogy milyen elv szerint ajánlott végezni az adott szervezet szabályozási környezetének vizsgálatát).


- 22 -

� A szabályozás felépítését belső szabályzatban áttekinthetően kell rögzíteni – amely alapján az auditor egyértelműen megkezdheti a szabályozási környezet vizsgálatát. Ezt a belső szabályzatot „konyhanyelven” az adott szervezetnél a „szabályzatok szabályzatának”, vagy a „Szabályozás struktúrájának” nevezik, hiszen itt rögzítik az egyes szabályzat típusok tartalmi-, formai-, engedélyezési követelményeit, hierarchia és kapcsolatrendszerét.

� Az IT szabályozások, megfelelő véleményezési és hatálybaléptetési folyamatokon keresztül legyenek bevezetve (megfelelően a szabályzatok szabályzatának). Itt meg kell különböztetnünk kizárólag IT jellegű (pl. IT ügyeletesi és helyettesítési rend, IT Help-Desk működése stb.) és a több szervezetet is érintő IT szabályzatokat (pl. Archiválási szabályzat, Jelszókezelési szabályzat stb.).

� A szabályzat megfelelő szinten kezelje, valamint egyértelműen nevezze meg az adott szabályzatban a felelősöket és felelősségi köröket. A szabályzatokat, ugyanúgy, mint az IT fejlesztéseket tesztelni, és felelősökkel véleményeztetni ajánlott. A nem megfelelő módon elkészített szabályzat nem támogatja, sőt negatív irányba befolyásolja a szabályozásokon alapuló munkavégzést.

� A szabályzatok legyenek egyértelműen megfogalmazva és mindig legyenek elérhetők (a legutolsó módosítás szerinti változatban). A nem kellő odafigyeléssel és szerkezetben megírt, vagy nem aktuális szabályzat nem szolgáltat hozzáadott értéket, így nem segíti elő a szabályzattudatos működés megteremtését.

Ha az adott szervezet szabályozási környezete a fenti minimum feltételeknek megfelel, akkor a munkavállalók kötelessége a vonatkozó szabályzatban foglaltak betartása, vezetők esetében pedig a szabályzatok betartatása.

� Valamennyi életbe léptetett szabályzat központi elérhetőségét (szabályzattár) célszerű biztosítani. A szabályzattárban található szabályzatok legyenek mindenki számára könnyen elérhetők, a bennük történt változások legyenek utólag is nyomon követhetőek. Lehetőség szerint az egyes munkakörökre, termékekre, területekre, érintettekre vonatkozó szabályzatok legyenek külön megjelenítve és a szabályzatokban való szövegre / szövegrészletre való keresés legyen támogatva.


- 23 -

3.2. A szabályozás tartalma

Mit kell szabályozni? A szabályozási struktúra legfeleső szintjén az irányelvek és politikák (policy) állnak, amelyek vezetői szinten nyilvánítják ki a vezetői elkötelezettséget bizonyos elvek és követendő célok mellett. Mindenképp érdemes irányelveket megfogalmazni legalább a biztonság, a kockázat menedzselés, a beszerzések és beruhzások, a fejlesztések, az üzletmenet-folytonosság, a naplózás és a független ellenőrzések területére. A szabályozási struktúra második szintje, az irányelvek megvalósítását részletesen leíró utasítások (ki, mikor, milyen rendszerességgel, mit, milyen főbb lépésekben stb.). Ajánlatos ezek többségét a legmagasabb szinten bevezetni ezeket „V”-vel jelöltük. � Biztonsági szabályzat (V), amely rögzíti az adott szervezet fizikai és

logikai biztonsággal kapcsolatos szabályait, megnevezi az adott biztonsági területért felelős személyeket és a személyekhez rendelt felelősségi köröket. Az adott szervezettől függően bővíthető a szabályzat tartalma az információosztályozással és log elemzésekkel kapcsolatos elvárásokkal is.

� Adat és titokvédelmi szabályzat (V), amely a személyes adat, az üzleti és egyéb minősített titkok (pl.: banktitok, biztosításititok stb.) fogalmának definiálását követően rögzíti az említett titokkategóriákba tartozó konkrét adattípusokat, az adatok védelmének alapelveit, módszereit.

� Jelszókezelés és használat szabályzat (V), amely rögzíti az informatikai rendszerekben kötelezően betartandó jelszóképzési és használati szabályokat.

� Vírusvédelmi szabályzat (V), amely rögzíti a szerver és munkaállomás környezeteken használandó vírusvédelmi rendszereket, azok működési környezetét, biztosítja az aktualizáltság fenntartásának folyamatát. Itt kell rögzíteni egy esetleges vírusfertőzés során betartandó riasztási mechanizmusokat, védelmi intézkedéseket.

� Mentési és Archiválási szabályzat (V), amely első körben definiálja a mentés és az archiválás fogalmát, majd rögzíti a számítógépes állományok mentési, archiválási mechanizmusát – idejét – rendszerét – állományait – üzleti felelőseit – a médiák tárolási környezetét és nyilvántartó rendszerét, továbbá rendelkezik a visszatöltési eljárások menetéről.

� Üzletmenetfolytonosság menedzselési (BCM – Business continuity management) és Katasztrófaelhárítás tervezési (DRP – Disaster Recovery Plan) szabályzat (V), amely a sikeres teszteléseket követően teljeskörűen mutatja be a fent említett BCM és DRP esetek során


- 24 -

felálló ún. BCM szervezet felépítését, az egyes résztvevők feladatait és rendelkezik a sikeres hibakezelést követő visszaállítási lépésekről.

� IT fejlesztési módszertan, amely rögzíti az adott szervezetben végrehajtott alapvető fejlesztési követelményeket. Tartalmazza a platformok, irányok kitesztelt, így biztonsággal alkalmazható módszerek és kódolási technikák, eljárások, interfész leírások, valamint kötelezően elkészítendő fejlesztési dokumentációk leírását.

� Informatikai tesztelési szabályzat (V), amely rögzíti a fejlesztéskor előforduló üzemi kockázatok csökkentésére irányuló és adott platformra, IT környezetre vonatkozó tesztelési folyamatokat, a támogató tesztkörnyezetek architektúrális felépítését, tesztadatokkal való tesztelések és a tesztrendszerhez való hozzáférés feltételeit, a hibák rögzítését és kiértékelési mechanizmusát, továbbá a tesztelésekben résztvevő szereplőket és egyes feladataikat.

� IT verziókezelés és patch management szabályzat, amely kapcsolódik az előbb említett „Informatikai tesztelési szabályzathoz” és rögzíti az egyes IT alkalmazás, rendszer verzióinak változtatásakor szükséges és kihagyhatatlan, maximálisan dokumentált feltételrendszer mentén lezajló lépéseket, a változtatáskor elvégzendő biztonsági kockázatkezelés határait.

� IT Üzemeltetési dokumentációk, amelyek egyértelműen meghatározzák a magas szinten és minimális üzemeltetési kockázattal működő IT üzemeltetés során kötelezően végrehajtandó (napi, heti, havi, éves) rutin jellegű feladatokat. Ezeken kívül itt kap helyet a monitoring - riasztási - naplózási - hibakezelési mechanizmusok általános követelmény rendszere is. Az IT üzemeltetéshez szükséges dokumentációs környezet felsorolását és minőségi mutatóit is ezen a helyen kell rögzíteni (operációs és alkalmazási rendszerleírások, interfész és adatbázis leírások stb.).

� Ügyeletesi és helyettesítési rend, amely rögzíti az IT üzemeltetésen, rendszerszervezői és biztonsági osztályokon dolgozók törzsidőn kívüli időszakban lehetséges elérésüket, valamint egyértelműen definiálja a helyettesítő személyeket és elérhetőségeiket.

� Titkosítási szabályzat, amely definiálja az adott szervezeten belül alkalmazható és támogatott titkosítási és hitelesítési algoritmusokat, valamint meghatározza a biztonságos módon történő távoli eléréshez szükséges feltételrendszert.

� IT szolgáltatási szabályzat, amely rögzíti az IT és a biztonsági területek által nyújtott alapvető szolgáltatások (user management, user mozgatás, új munkaállomás kialakítása, rendszerhozzáférések kezelése, IT Help-Desk működés stb.) szolgáltatási szintjét, feladatvállalási idejét és a kapcsolódó folyamatokat.


- 25 -

A szabályozási hierarchia harmadik szintjén pedig a szabályozás legapróbb részleteit is kifejtő eljárásrendek, végrehajtási és használati utasítások, állnak. Ezekben általában a legapróbb részletekig definiálják az adott teendők során végrehajtandó lépéseket (karbantartási-, szoftverfejlesztési útmutatók, eszköz paraméter beállítások, részletes tesztelési leírások stb.).

�� A feladatok és felelősségek elhatárolásának áttekintése

Miért van szükség feladat- és felelősségek elhatárolására? A legtöbb kontrollrendszerbeli hiányosság a feladatok és felelősségek nem megfelelő elhatárolására vezethető vissza. Az egyik informatikus kolléga mondása szerint „Nem az a baj, ha valamilyen feladatot nem hajtunk végre, hanem az, ha nem is tudjuk, hogy mit kellett volna még elvégeznünk.”. Ez pedig nem megy anélkül, hogy végig ne gondolnánk, hogy mely feladatokat, kinek kell elvégeznie (lásd a 3. fejezetet - Szabályozás), illetve adott feladatok, hogyan ellenőrizhetők, milyen dokumentációkkal kell igazolni azok elvégzését (lásd a 6. fejezetet - Dokumentálás fontossága). A hatékony működés alapeleme a megfelelő feladat és felelősség elhatárolás, amely azonban nem mindig történik meg teljes körűen. Sokszor összeférhetetlen feladatokat kell ellátnia ugyanazon személynek, főként kisebb intézményeknél, ami az alacsony létszámból adódik. A nemzetközi irányelvek szerinti összeférhetetlenségekre (lásd az 1. számú mellékletet) azonban még alacsony létszám esetén is lehet szorosabb kiegészítőkontrollokat kialakítani.

4.1. Vállalati kultúra

Miért fontos a feladatok- és felelősségek elhatárolása�A feladatok és felelősségek elhatárolása elvezet minket a szabályozáson és a dokumentáláson túl a vállalati kultúra kérdéséhez, azaz hogyan kezelhetők a belső folyamatvégzésben felmerülő problémák és hibák, ezek bekövetkezése esetén milyen javító folyamatoknak kell elindulnia és milyen számonkérés, felelősségre vonás kapcsolódik egy adott típusú problémához. A személyek feladatait és felelősségi köreit világosan meg kell határozni és az összeférhetetlenséget el kell kerülni (lásd a 5. számú mellékletet). Szét kell választani a feladatokat és felelősségi köröket, olyan módon, hogy ne legyen lehetőség arra, hogy egyetlen személy kezében összpontosuljon valamely kritikus eljárás irányítása, végrehajtása és ellenőrzése, amely így visszaélésre ad lehetőséget.


- 26 -

Amennyire alapvető, hogy szabályozási és gyakorlati működés szintjén is tudni kell, hogy mit kell tennie a munkatársaknak, milyen napi rutin feladatai vannak az üzemeltetőknek, azt is definiálni kell, hogy mi a teendőa rendkívüli helyzetek bekövetkezésekor (BCP, DRP!), illetve milyen folyamatba épített vezetői, rendszeres IT biztonsági, valamint alkalomszerűfüggetlen ellenőrzési feladatokra van szükség.

4.2. Összeférhetetlenségek

Melyek a legfontosabb feladatok és azokat ki(k)re bízzuk? Annak eldöntésére, hogy a rendelkezésre álló szűkös erőforrások között milyen feladatokat kell feltétlenül elvégezni és azt hogyan kell személyekre lebontani, erre vonatkozóan számos elméleti anyag áll rendelkezésre (lásd az irodalomjegyzéket). Ami az ellenőrzési gyakorlatban legtöbbször előfordul, illetve ami „informatikai ökölszabály”-nak tekinthető az: � a vezetői és a végrehajtói, � az operatív feladatvégzési és az ellenőrzési, � valamint a fejlesztői és az üzemeltetői feladatok szétválasztása. Az elvek gyakorlati megvalósítását sokszor akadályozza az erőforráshiány, illetve a szakmai hozzáértés hiánya. A problémák megoldáshoz külsős erőforrásokat is igénybe lehet venni, ezek azonban újabb technikai és hozzáférés menedzselési kérdéseket vetnek fel. A külső erőforrások alkalmazása esetén sem szabad figyelmen kívül hagyni, hogy a felelősség nem hárítható át, nem kiszervezhető!

Milyen feladatok összeférhetetlenek? Sajnálatos módon azokban az esetekben is, ahol a létszám ezt nem indokolja, ott is előfordul lényeges feladatkör átlapolás, illetve azonosítható a felelősök kijelölésének hiánya vagy összeférhetetlen feladatok központosítása. A tapasztalatok azt mutatják, hogy számos esetben előfordul, az hogy: � a fejlesztők vagy rendszerszervezők egyben üzemeltetnek is, � nincsenek kijelölt adatgazdák, � a fejlesztő egyben a változásmenedzser is, vagy nincsen kijelölve

változásmenedzser, illetve egyáltalán nincs változásmenedzseri funkció,

� a szoftver könyvtárosi funkció nem működik, � felhasználók (a kényelmi vagy egyszerűbb jogosultság-kialakítási

okokból) adminisztrátori, vagy egyéb más magas jogosultságot kapnak, � az IT vezető egyben biztonsági felelős vagy IT belső ellenőr is, � a belső ellenőr operatív feladatokat végez, � a felhasználók egyben fejlesztési feladatokat is végeznek,


- 27 -

� az IT üzemeltetők közvetlen adatmódosítással napi üzleti feladatokat is ellátnak,

� a felhasználók, vagy az üzemeltetők hozzáférnek a forráskódhoz, illetve fejlesztői dokumentációkhoz,

� az üzleti specifikációk elkészítése az informatikai szervezet feladata, � a felhasználói teszt elvégzése az informatikai üzemeltetők feladata, � az üzletmenet-folytonossági terv elkészítése az informatikai szervezet

feladata.

Józan megfontolás alapján is érezhető, hogy milyen veszélyekkel járhat az, ha az adatrögzítéssel megbízott munkatárs egyben jóvá is hagyhatja a tranzakciót (pl. pénzátutalásnál). Úgyszintén nem egészséges, ha az informatikai rendszer működtetésével megbízott munkatársra bízzák a kritikus üzleti alkalmazásban jogosult dolgozók szerepkörének meghatározását vagy az üzleti specifikációk elkészítésének feladatát. A Társaságok egy részére (pénzügyi szervezetek) vonatkozóan a jogszabályok is tartalmaznak előírást, mivel előírják a biztonsági kockázatokkal arányosan meghatározott „szervezeti és működési rendek”, valamint a „felelősségi, nyilvántartási és tájékoztatási” továbbá a „folyamatba épített ellenőrzési” szabályok kialakítását és működtetését.

4.3. Szervezeti rend szabályozása

Mit kell szabályozni? Egy szervezet működtetéséhez elengedhetetlen a belső szervezeti működési rendek, felelősségi, nyilvántartási és tájékoztatási szabályok definiálása, amely tulajdonképpen az informatikai részleg szervezeti felépítésének és kapcsolatainak meghatározását, dokumentálását és folyamatos karbantartását (SZMSZ, szervezeti ábrák, munkaköri leírások stb.) jelenti. A vezetésnek gondoskodnia kell arról, hogy a szervezet minden alkalmazottja tisztában legyen az információs rendszerekkel kapcsolatos feladataival és felelősségével. Minden alkalmazottnak megfelelő hatáskört kell biztosítani ahhoz, hogy végre tudja hajtani a rá bízott feladatokat, és tájékoztatni kell arról, hogy milyen mértékű ellenőrzési és biztonsági felelősséggel tartozik. A vezetésnek ki kell neveznie egy „informatika biztonsági felelőst”, aki a szervezet informatikai eszközeinek fizikai és logikai biztonságáért egyaránt felel és közvetlenül a szervezet felső vezetőjének számol be munkájáról. A vezetésnek ki kell dolgoznia egy eljárást az adatok tulajdonosainak (adatgazda) és kezelőinek hivatalos kijelölésére vonatkozóan és gondoskodnia kell arról, hogy minden informatikai eszköznek (adatok és


- 28 -

rendszerek) legyen egy kijelölt tulajdonosa (adatgazda), aki dönt az adatosztályozásról és hozzáférési jogosultsági szintekről. Az adatgazda a nyilvántartó rendszerek esetében nem informatikus, hanem az üzleti területről egy felhasználó, aki általában a leginkább érintett funkcionális terület vezetője (számlavezetés, könyvelés stb.). Az informatikai kiszolgáló alkalmazásoknak adatgazdája informatikus (Windows vagy Novell rendszer, Active Directory, adatátviteli hálózat vezérlő alkalmazás, naplógyűjtő és elemző alkalmazás stb.). A szükséges dolgozói létszámot rendszeres időközönként felül kell vizsgálni annak érdekében, hogy helyettesítések esetére is megfelelő számú és a munkakörre előírt képzettségű dolgozóval rendelkezzen az informatikai részleg. A vezetésnek gondoskodnia kell az informatikai munkaköri leírások kidolgozásáról és rendszeres aktualizálásáról. A munkaköri leírásokban (nem csak informatikai munkakörökben) világosan rögzíteni kell mind a hatásköröket, mind a felelősségi köröket, beleértve az adott munkakör ellátásához szükséges képzettséget és gyakorlatot is. A külső szolgáltatók sem jelenthetnek kivételt a feladatok meghatározása és az ellenőrzése tekintetében, de természetszerűleg ezen feladatok alapvetően a szolgáltatási vagy kiszervezési szerződésben rögzítettek és nem feltétlenül jelentik a szervezet összes szabályozásának rájuk vonatkozó hatályát (az erre vonatkozó tanácsokat lásd a 11. fejezetben).

�� Informatikai nyilvántartások vizsgálata Miért van szükség a nyilvántartásokra? Annak érdekében, hogy az informatikai részleg el tudja végezni a felelősségi körébe tartozó tervezési, szabályozási, üzemeltetési, karbantartási, menedzselési és egyéb feladatait, ahhoz megbízható és naprakész nyilvántartásokra van szükség. Működő szervezetek életében számos különféle nyilvántartás létezik. Gondolhatunk itt a munkaügyi nyilvántartásokra, bér jellegű kifizetések nyilvántartására, felhasználók által igényelt rendszerhozzáférések nyilvántartására, tárgyi eszközök nyilvántartására, fejlesztési-, verzió- és konfigurációkezelési folyamatok során kialakult historikus adatok tárolására szolgáló nyilvántartásra stb. A mindennapi életünket a legkülönfélébb szinten behálózzák a nyilvántartások, így az informatikai eszközök menedzselése érdekében is foglalkoznunk kell az informatikai eszközök és erőforrások nyilvántartásával is. Annak érdekében, hogy menedzselni tudjuk az IT erőforrásokat az informatikai eszközök és rendszerek (hardver és szoftver eszközök, a szervereken és munkaállomásokon lévő alkalmazások, rendszertechnikai és adatkapcsolati ábrák stb.) teljes körű és naprakész nyilvántartásának


- 29 -

rendelkezésre kell állnia (ez az alapja a már említett kockázatelemzésnek is). Az informatikai részleg vezetésének gondoskodnia kell arról, hogy a konfiguráció tartalmazza a nyilvántartásban lévő minden egyes tétel aktuális státuszát, a múltbeli változtatások jelzésével együtt. Nyomon kell követni a konfiguráció-elemek változásait is a változáskezelési szabályzatnak megfelelően (pl. új elemek, ‘fejlesztés alatt’ stb.). Megfelelő eljárások révén gondoskodni kell arról, hogy csak engedélyezett és azonosítható konfiguráció elemek kerüljenek be a beszerzéskor (konfiguráció) és selejtezéskor (értékesítéskor) ki a leltárból. Rendszeresen ellenőrizni kell az informatikai részleg által vezetett konfiguráció-nyilvántartás meglétét és a bejegyzések konzisztenciáját. A szoftvereket nyilvántartásba kell venni és megfelelő engedéllyel kell rendelkezni használatukra vonatkozóan. Nem képezhet kivételt (zéró tolerancia), a fokozott biztonságú helyekre (pl. gépterem) mozgatott eszközök nyilvántartása sem.

5.1. A nyilvántartásokkal kapcsolatos feladatok vizsgálata

Mire jók az informatikai nyilvántartások? Az informatikai eszközök naprakész � nyilvántartásával pillanatok alatt felmérhető adott szervezet IT

tagozódása, � nyilvántartásának segítségével ellenőrizhető a használt hardvare és

szoftver komponensek mennyisége és annak minősége, � nyilvántartása segítségével vizsgálható az IT Stratégiában rögzített és

az IT jelenlegi felépítésének egyezősége, � nyilvántartása alapadatokkal segíti az IT ellenőröket a rendszerauditok

felkészülési szakaszában, � nyilvántartásából elkészíthető riportok hozzáadott értéket szolgáltatnak

az IT projektek számára, � nyilvántartásából kinyerhető adatok segítik az IT vezetést az IT

tervezési feladatok elvégzésében.

5.2. A nyilvántartások tartalma

Mit kell az informatika szintjén minimálisan nyilvántartani? Minden ellenőr számára fontos, hogy minél gyorsabban eligazodjon a rendelkezésre álló architektúrában, a működő folyamatokban és az adatáramlás menetében.


- 30 -

Ehhez megfelelő nyilvántartásokra, adatkapcsolati és architektúra ábrákra van szükség. Ebben a fejezetben foglalkozunk az informatikában alkalmazandó legfontosabb és nélkülözhetetlen nyilvántartásokkal, valamint az általuk szolgáltatott hozzáadott értékkel.

� Hálózati topológia nyilvántartás, amely bemutatja: - a LAN (Local Area Network) és WAN (Wide Area Network)

hálózatok, - a hálózati aktív eszközök (switch, router, hub stb.), - a virtuális hálózatok (VLAN), - a demilitarizált zónák (DMZ - DeMilitarized Zone), - a tűzfalak (Firewall), - az adatátviteli és backup vonalak (bérelt vonal, ISDN, ADSL,

műholdas kapcsolatok) kapcsolódásait és az adott intézményen belüli elhelyezkedését.

� Adatkapcsolati ábra, amely tartalmazza a főbb rendszerek közötti automatikus, manuális és egyéb formájú adatáramlást, a rendszerek közötti interfész kapcsolatokat, az adatáramlás főbb folyamatait és irányát.

� IT Architektúra nyilvántartás, amely egységes rendszerben kezeli és formában mutatja be a szervezet LAN, WAN hálózatában található szervereket, szerver funkciót ellátó PC-ket, azok kapcsolódásait és minimális szinten, de mutatja a rajtuk futó szoftvereket.

� Számítástechnikai hardware eszközök nyilvántartása, amely mutatja valamennyi számítástechnikai eszköz hardvare jellemzőit (gyártó, gyártási szám, egyéb paraméterek).

� Szoftvernyilvántartás, amely a hardver eszközön futó operációs rendszerek, segédprogramok, adatbázis-kezelők, futtató környezetek, middleware szoftverek, web szerverek, alkalmazások stb. aktuális verziójának adatait. Sok esetben kiegészíthető a szoftverlicensz nyilvántartással is.

� IT Hibabejelentések nyilvántartása. Az IT Help Desk által felvett és megoldott hibák nyilvántartása.

5.3. A felhasználói támogatás működésének vizsgálata

Mik az elvárások a felhasználói támogatással (IT Help Desk) kapcsolatban? A felhasználói problémák kezelését mindenképpen meg kell oldani, ugyanis ez a legfőbb fokmérője az informatika működésének. Ez alapján dönthetőel, hogy az informatika mennyire támogatja az üzleti célok elérését.


- 31 -

A jól működő IT Help Desk kialakítása és működtetése számít talán a legnagyobb reklámnak az informatika számára és nagyban segítheti az üzleti felhasználók és az informatikai üzemeltetők közötti kapcsolat pozitív megítélésének kialakítását. Fontos, hogy a felhasználók úgy érezzék, hogy az informatika a megfelelőfeladatokat végzi, a lehető leghatékonyabb módon, a felhasználók számára értéket teremtve (működnek a funkciók, a kérések időben és optimális költséggel valósulnak meg). Az IT Help Desk-nél megvalósított központi tudásbázis kialakítása és menedzselése nagyon fontos segédeszköz a hatékony és gyors problémakezelésben, amely egyben nélkülözhetetlen a tipikus hibákra történő azonnali kérdések megválaszolásához. Célszerű lehet egy probléma nyilvántartó és kezelő alkalmazás bevezetése, amely utólag visszakereshetően és jól riportolhatóan támogatja a problémák megoldásának folyamatát.

Mit vizsgáljunk az IT Help Desk működésében? A fenti feladatok elvégzésének működésével kapcsolatban tehát az alábbiakat érdemes ellenőrizni: � Létezik-e szabályozás az IT Help Desk működésére vonatkozóan? � A gyakorlat a szabályozásnak megfelelően működik-e? � „Egykapus”-e a felhasználó kérések bejelentése és kezelése? � Ha több kontaktpont van, akkor egységesen kezelik-e a felhasználókat? � Minden bejelentés dokumentált-e? � Mennyire könnyű és hatékony a felhasználói támogatás? � Milyen IT alkalmazást használnak a bejelentések nyilvántartására? � Létezik-e tudásbázis a hasonló problémák előfordulásáról? � Milyen szinten és milyen rendszerességgel készülnek statisztikák az IT

vezetés számára? � Milyen teljesítménymérés van (össszes kérések száma, átlagos

válaszidő, átlagos megoldási idő, ismétlődő problémák száma, probléma megoldás költsége stb.)?

� Mennyi nem kezelt vagy nagyon régóta megoldatlan probléma van? � Milyen gyakran szoktak felhasználói elégedettség mérést végezni? � Az elégedettség mérés eredménye milyen változásokat indukál (pl.

fejlesztéseket)? � A bejelentett problémák a vállalt határidőn belül kijavítására kerülnek-

e?


- 32 -

�� Dokumentáltság vizsgálata Miért kell dokumentálni? Az informatikai ellenőrzések jellegéből adódóan utólagosak és elsősorban a potenciális, azaz jövőben esetlegesen bekövetkező károkra, problémákra hívják fel a figyelmet. Van, aki azt kérdezi, hogy miért nem hiszünk a szóbeli ígéreteknek? Arról, hogy a szabályozások vagy a „józan ész” alapján elvárható feladatok végrehajtásra kerültek-e csakis dokumentumokból győződhetünk meg (például üzemeltetési dokumentációkból és naplókból, jogosultságigénylő lapokból stb.). Miért van rá szükség? A kétkedőknek adott válasz elsősorban talán az lehet, hogy visszakérdezünk: Mikor, hogyan és mi alapján ellenőrizhetők az elvégzett tevékenységek? A hazai tapasztalatok szerint a szabályozások mellett sokszor a dokumentációk azok, amelyekre a legkevesebb gondot fordítanak a szervezetek, így ebben a fejezetben a dokumentáltság fontosságával, illetve az alapvető, a dokumentumokkal kapcsolatos legfontosabb elvárásokkal foglalkozunk. Az IT – de általánosságban már az elején kimondható, hogy valamennyi – dokumentációs környezet megléte nélkül a „legrosszabb rémálmunk is valóra válhat” akkor, ha a megnövekedett üzemi kockázatok mellet, megnövekszik a hiba észleléshez és a javításához szorosan kapcsolódó időis. Ennek oka egyszerű, hiszen az érintett IT munkatárs a megfelelődokumentumok és lényegi, helytálló információk nélkül, nem tudja megkezdeni a hibajavítást. Nem szabad elfeledkezni arról, hogy a rendszergazdák – kizárólag a fejükben megtalálható – tudása az IT auditor számára nem használható (elfogadható), így a dokumentálás megteremtése alapvető érdek minden érintett számára. Az informatikai részlegnek egységes és szabványos eljárásokat kell kialakítania az informatikai rendszerek üzemeltetésére vonatkozóan (a hálózati üzemeltetést is beleértve), és megfelelően dokumentálnia kell ezeket. Minden alkalmazott informatikai megoldást és platformot a fenti eljárásoknak megfelelően kell működtetni. Az eljárások megfelelőségét és betartását rendszeres időközönként ellenőrizni kell és az informatikai terület vezetésének gondoskodnia kell arról, hogy az üzemeltető személyzet megfelelő ismeretekkel és gyakorlottsággal rendelkezzen az üzemeltetési feladatok dokumentálása terén is. Megfelelő eljárások révén gondoskodni kell arról, hogy a feldolgozás az operátori műszakváltás alatt is folyamatos legyen, és ennek érdekében meg kell határozni a munkafeladatok átadására, az állapot jelentésének aktualizálására és a feladatokért viselt felelősségről szóló jelentésekre vonatkozó szabályokat.


- 33 -

Megfelelő eljárások révén gondoskodni kell arról, hogy az üzemeltetési naplókban rögzítésre kerüljenek azok a szükséges kronológiai információk, amelyek lehetővé teszik az adatfeldolgozási folyamatok és a feldolgozáshoz kapcsolódó, azt segítő egyéb tevékenységek idősorrendjének rekonstruálását, áttekintését, kivizsgálását. Dokumentálási igénye van a munkafolyamat eredményeinek rögzítésének, a munkafolyamatok előírt ütemezésétől történő eltérésnek és a szolgáltatási szint megállapodásokban (SLA – Service Level Agreement) rögzített teljesítmény mérésének is. A vezetésnek gondoskodnia kell a speciális nyomtatványok és a bizalmas jellegű output eszközök megfelelő fizikai védelméről. Távműködtetés esetén külön eljárásokat kell kidolgozni a távműködtetőmunkaállomásokhoz történő csatlakozás, illetve leválás meghatározására és végrehajtására vonatkozóan.

Mit és hogyan (papíron vagy elektronikusan) dokumentáljunk? A "Szó elszáll, a papír megmarad" jut eszünkbe a régi mondás, azonban manapság már nem biztos, hogy a legkorszerűbb, a legolcsóbb vagy a leghatékonyabb megoldás a papír alapú bizonylat. A dokumentációk mérete, az archiválás megvalósítása, vagy a bennük való kereshetőség a legtöbb esetben már indokolja egy elektronikus dokumentálási rendszer bevezetését. Néhány dokumentálandó tevékenység: � napi üzemeltetési feladatok (üzemeltetési checklist - napló, mentési

napló stb.) � paraméter beállítások (tűzfal, szerver, Active Directory, NDS stb.) � jogosultságok (operációs rendszer, adatbázis, alkalmazás szinten,

hozzáférések, szerepkörök stb.) � változáskezelés (nyilvántartásban, szoftverekben stb.) � szabályozásban (ki, mikor, mit aktualizált stb.).

Mik a követelmények az IT Üzemeltetési dokumentációkkal kapcsolatban? Az alábbiakban megkülönböztetjük a boltban kapható, nagyon sok vásárló számra elérhető ún. dobozos (gyári) termékeket és az egyedi vásárlói igényeket kielégítő ún. saját fejlesztésű szoftvereket.

„Gyári” IT üzemeltetési dokumentációk: Egy multinacionális cég termékének bevezetésekor általában az tapasztalható, hogy a dokumentációs készlet jó minőségű, színvonalas és rendkívül terjedelmes (pl. ún. „Red Book” vagy „White Paper”). Ez persze nem azt jelenti, hogy könnyedén hátradőlhet mindenki, hiszen előfordulhat az is, hogy az átadott anyag csak egy bizonyos operációs rendszerre /


- 34 -

platformra / szerverkonfigurációra, vagy architekturális kialakításra vonatkozik, így a „hazai környezet” eltérő kialakítása miatt nem minden esetben használható. Triviális dolognak tűnhet, de volt már rá példa, hogy az átvett program/alkalmazás (pl. 4.2), illetve az átadott dokumentációban tárgyalt program verziószáma (pl. 4.0) nem egyezett meg. Ilyen esetben el kell kérni az aktuális verziót, vagy a módosítások jegyzékét, részletes leírását.

Követelmény a „gyári” dokumentációknál, hogy: � az átadott dokumentációkban szereplő platform, IT környezet teljes

mértékben legyen azonos az használt környezettel, � a dokumentációban szereplő hardver és szoftver – a minimális

követelményeknek, rendszerbeállításoknak teljes mértékben feleljen meg,

� a dokumentáció sorolja fel azokat a minimális hardver és szoftver feltételeket – környezeti változókat – beállításokat, amelyek a biztonságos üzemeltetéshez szükségesek,

� az idegen nyelven átadott dokumentációk lehetőség szerint legyenek elérhetőek magyar nyelven is,

� az átadott dokumentáció megfelelő szinten és részletességgel tartalmazza a napi, heti, havi üzemeltetési és karbantartási feladatokat,

� az átadott dokumentáció megfelelő szinten és részletességgel tartalmazza a rendszer/alkalmazás által nyújtott monitoring és riasztási lehetőségeket,

� az átadott dokumentációs készlet tartalmazza az interface leírásokat, security beállításokat, audit funkciók leírását, tipikus hibák kijavítására vonatkozó teendőket,

� a dokumentáció tartalmazza az adott alkalmazás kommunikációjára vonatkozó adatokat (TCP, UDP, FTP stb.)

� a dokumentáció megfelelő szinten és részletességgel tartalmazza a rendszeridőre, naplózási eljárásra, rendszerfelügyeleti beépített eljárásokra vonatkozó beállításokat.

„Saját készítésű” IT Üzemeltetési dokumentációk: Egyre többször tapasztalható az, hogy az adott szervezet saját fejlesztésű, vagy külsős fejlesztők bevonásával létrehozott alkalmazással (programmal) kíván megfelelni az üzleti területek által megfogalmazott igényeknek. Az ilyen esetekben, az implementálás során átvett dokumentációk (tisztelet a kivételnek) gyengébb minőségűek, mint az előző pontban tárgyalt nagyobb gyártóké.


- 35 -

Ebből adódóan az átadás-átvételi procedúrában maximális figyelmet kell fordítani az előre meghatározott dokumentációs készlet tartalmi és minőségi megfelelőségének ellenőrzésére!

A saját készítésű (fejlesztetett) alkalmazások IT Üzemeltetési dokumentációjára vonatkozóan a következő kritériumokat támasszuk: � Az előzetes fizikai és logikai tervekben leírt és a leszállított, majd

dokumentált elemek között teljes megfelelés legyen azonosítható. � A dokumentáció részletessége támogassa IT-t a magas szintű

üzemeltetési feladatok ellátásában. � Az esetekben még alkalmazott „text”, „drive”, „folder share” interface

vagy file transfer megoldások dokumentálása legyen teljes körű, és legyen leírva a biztonsági megoldásaik implementálási módja.

� A dokumentáció tartalmazza a felhasználói kézikönyvet, az üzemeltetési kézikönyvet valamint a rendkívüli helyzetekre vonatkozó helyreállítási teendőket, illetve a megfelelő szinten írja le és válassza szét a rendszer üzemeltetői és az „átlag” felhasználói jogosultságokat.

Mit vizsgáljunk az IT fejlesztési dokumentációkban?Álljon egy, vagy több millió sor programkódból az alkalmazás, minimum egy közös van bennünk, mégpedig az, hogy jó esetben a fontosabb programrészek – utasítások, eljárások, ciklusok – és egyedi speciális műveletek mellé ún. „comment”-et (megjegyzést) helyez el a fejlesztő. A fejlesztés során használt fejlesztői platformtól függ a commentek kivitelezése, viszont a későbbi hibakeresésében, további fejlesztésben kulcsszerepe lesz! Ahol nem alkalmazzák a commentezést, vagy nem készül részletes fejlesztési dokumentáció, ott a későbbiekben többszörösére fog nőni a fejlesztésre – hibakeresésre fordított idő. Hogy ezen időveszteséget csökkenthessük, vagy elkerülhessük, az IT Auditornak vizsgálnia kell az alábbiakat: � Az alkalmazott fejlesztői platform nevét, verzióját, a fejlesztés alatt, a

fejlesztéshez használt szoftverkörnyezetet. � Az adott fejlesztéshez tartozó üzleti specifikációt. � A fejlesztés során használt adatmezők típusát, a mezőre vonatkozó

előírásokat, az adatbevitel során alkalmazott validációs szabályokat. � A származtatott mezőértékek feltételrendszerét. � Az adatbeviteli és megjelenítési szabályokat. � Az adatbázis leírását, logikai és fizikai rendszertervek hivatkozásait. � Az autentikációs és autorizációs eljárásokat és azok kapcsolatait. � A jogosultágkezeléskor használt csoportok hozzáféréseit és alkalmazási

területeit.


- 36 -

� Az interfészek alkalmazási környezetét és az interfészeken / fájltranszfereken áthaladó adatok mennyiségi és minőségi ellenőrzési mechanizmusait.

� Az adott alkalmazás naplózási eljárásait, naplózott eseményeit, illetve azok védelmét, valamint a hibakezeléskor látható üzenetek részletes leírását.

� Az előző fejlesztés során elvégzett módosításokat. � Az adatvédelmi beállításokat és riportolási lehetőségeket.

A fejlesztői dokumentációk kritériumait a fejlesztési módszertanban ajánlott rögzíteni és a fejlesztési vezetőnek minden egyes dokumentációt jóvá kell hagyni.

Mit vizsgáljunk egy adott alkalmazás IT Biztonsági dokumentumában? Az egyre növekvő informatikai és biztonsági kockázatok megkövetelik a biztonsági és biztonságtechnikai megoldások kialakítását és azok dokumentációinak meglétét. Ezen dokumentációk elengedhetetlenek az adott szervezet belső és külső védelmi vonalainak létrehozásához, magas szintjének fenntartásához. A biztonsági dokumentációnak tartalmazniuk kell a(z): � alkalmazás tcp, udp, ftp, http stb. protokoljainak és a használt

portoknak a leírását, � alkalmazás belső és külső kapcsolatainak működési elvét,

mechanizmusát, � adminisztrátori és kiemelt userek használatának körülményét –

feltételeit, � adatbázishasználat módját, felhasználóját, � alkalmazott jelszókezelési és belső / külső titkosítási – hitelesítési –

mechanizmusokat.

�� A jogosultságmenedzsment vizsgálata Miért fontos a jogosultságok menedzselése? Az informatikai biztonság egyik legalapvetőbb kérdése, hogy hogyan kezeljük a rendszerekhez való hozzáféréseket. Az ellenőrzési tapasztalatok alapján azonban mégis számos alapvetőhiányosság fedezhető fel a jogosultságok kezelésében, menedzselésében. A visszaélések, elkövetett hibák (gondatlanságból vagy véletlenül) a legtöbb esetben a birtokolt jogosultságra vezethetőek vissza. Ahhoz, hogy ezeket elkerülhessük, az alábbiakban a legfontosabb kontroll teendőket soroljuk fel.


- 37 -

Milyen elvárások vannak? A vezetésnek olyan eljárásokat kell kialakítania, amelyek gondoskodnak arról, hogy kellő időben megtörténjenek a szükséges intézkedések a felhasználói jogosultságok kérésével, rögzítésével, kiadásával, felfüggesztésével és lezárásával kapcsolatban (szabályzat). A rendszeres időközönként (alkalmazás, vagy szervezeti, működési struktúra lényeges változásakor, de legalább negyedévente) felül kell vizsgálni és meg kell erősíteni a hozzáférési jogokat. Az informatika biztonsági felelősnek gondoskodnia kell arról, hogy a biztonságot érintő eseményekről nyilvántartást vezessenek, továbbá arról, hogy a rendszer a biztonsági intézkedések megsértésére utaló jelzésekrőlazonnal értesítse az összes, belső és külső érintett felet, valamint kellőidőben kezdjék meg a szükséges válaszlépéseket. Lehetőség szerint gondoskodni kell arról, hogy a felhasználók azonosítását és hozzáférési jogait, valamint a rendszerek és az adatgazdák azonosítását egyetlen, központi rendszer kezelje az átfogó hozzáférési jogosultság ellenőrzés hatékony és egységes megvalósítása érdekében. A felhasználói jogosultságok adminisztrálása kapcsán rendszerenként kell meg határozni, felhasználói funkciócsoportonként (könyvelő, számlavezető, pénztáros stb.) a kiosztható jogokat és lehetőség szerint a felhasználók csak a csoportok jogait kaphassák meg.

7.1 Jogosultságkezelés szabályozása

Hogyan szabályozzuk? Olyan eljárásokat kell kialakítani, amelyek gondoskodnak arról, hogy kellőidőben megtörténjenek a szükséges intézkedések a felhasználói jogosultságok igénylésével, beállításával, felfüggesztésével és visszavonásával kapcsolatban (lásd. 3. fejezet - Szabályozás). Ezzel összefüggésben ki kell dolgozni egy hivatalos engedélyezési eljárást, amelynek keretében az adatok, illetve a rendszer tulajdonosa (adatgazda) engedélyezi a hozzáférést (hozzáférési szintek). A külső felek hozzáférésének biztonságát szerződés szintjén is meg kell határozni és ennek kapcsán, ki kell térni az adminisztrációhoz és az adatok bizalmas kezeléséhez kapcsolódó követelményekre is.Kiszervezés esetén a felek között megkötött szerződésben kell kitérni a kockázatok és az információs rendszerekhez, hálózatokhoz kapcsolódó biztonsági ellenőrzések és eljárások kérdésének tisztázására, szabályozására is.


- 38 -

Mi az elvárás? A jogosultsági rendszer felépítése legyen: � szerepkör alapú, így az „olyat, mint a Gizikének” típusú igénylés

kerülendő, � az operációs rendszer, adatbázis és alkalmazási rendszer szinten is

meghatározva, � olyan, amely nem támogatja a nem megszemélyesített (másnéven

anonim) felhasználók (pl. Admin, administrator, system, adatrögzítőstb.) használatát,

� olyan, amely elválasztja a rendszerüzemeltetéshez -rendszerszervezéshez - fejlesztéshez - minőségbiztosításhoz szükséges jogosultságokat.

A vezetésnek ki kell alakítania egy megfelelő eljárást, amely elrendeli, hogy az adatok tulajdonosainak (adatgazdáknak) osztályozniuk kell az adatokat bizalmassági fokuk szerint, formális döntés keretében, az adatosztályozási rendszer előírásai alapján (hozzáférési szintek a felhasználók funkciói alapján).

Mit kell dokumentálni? Kézenfekvő, hogy az igényléseket és a konkrét beállításokat dokumentálni kell. A jogosultság engedélyeken szerepelnie kell az engedélyezőaláírásának, vagy elektronikus engedélyezés esetén a rendszer által biztosított (bizonyítható) módon adott engedélynek. Az engedélyező lapokat (elektronikus, vagy papír) úgy kell kialakítani, hogy abból egyértelműen kiderüljön az engedélyezett jog. Az engedélyezett jogokat nyilvántartásba kell venni (jogosultság nyilvántartó rendszer). A nyilvántartás egy historikus adatokat tároló rendszer, amelyben egy adott felhasználó minden joga, ami az informatikai rendszerben van (volt) lekérdezhető (akár a teljes jogosultsági története is). A rendszerekben lévőfelhasználói jogoknak meg kell felelni az engedélyekben és a jogosultság nyilvántartó rendszerben tárolt adatoknak. A szabályzat és a nyilvántartás elkészítésekor figyelembe kell venni a kiemelt jogú felhasználókat (rendszergazdák, technikai felhasználók), a rendszerek alkotóelemeinek (operációs rendszer, adatbáziskezelő, alkalmazás stb.) sokrétűségét és az adminisztrációnak mindezekre ki kell terjedni. A jogosultságok változtatásának naplózását a rendszerekben aktiválni kell, és olyan eljárást kell kialakítani, amely biztosítja a felhasználói jogok változásának, változtatásának ellenőrzését. A hibákat szankcionálni is kell, és ennek mértékét az adott szervezetnek kell szabályozni, a vezetésnek elfogadni és ez alapján kell minden hiba felderítési vizsgálatot lefolytatni. A hiba, és a szankció publikálása visszatartó erejű lehet.


- 39 -

Mi áll az ellenőrzések fókusz pontjában? Természetes, hogy a kockázatelemzési fejezetben már említett legfontosabb veszélyforrások kiküszöbölésével kell kezdeni a jogosultságok menedzselését is. Ebből következően a „zéró toleranciát” kell alkalmaznunk a magas jogosultságok, illetve a főbb rendszergazdai jogok esetén felmerülőhiányosságokban. Mindenkor rendelkezésre kell állni tehát, az összes operációs-, adatbázis- és alkalmazásrendszergazda kijelölésének, egy a vezetőség (akár az IT vezetés) által jóváhagyott dokumentumban. Dokumentálni kell továbbá minden magas szintű jogosultság igénylését és változását, valamint az ellenőrzését annak, hogy teljes körűen megfelelnek a beállított jogok az engedélyeknek. Az összes kiemelt jogosultságra vonatkozóan szabály, hogy nevesítettnek kell lennie (ne férjen hozzá például az összes informatikus adminisztrátor joggal az Active directory-hoz az „admin” vagy „isten” névvel) és az ezzel végzett tevékenységek naplózásra kerüljenek, azaz az utólagos számonkéréskor mindig beazonosítható legyen, hogy ki, mikor, milyen tevékenységet hajtott végre. Az elkerülhetetlen, közösen használt technikai felhasználók (pl. root, dba) jelszava pedig kerüljenek borítékolásra, amely borítékok felnyitása úgyszintén szabályozott és dokumentált keretek között történjen. Ezek használatára a legtöbb esetben léteznek technikai eljárások, amelyek biztosítják az utólagos azonosítás lehetőségét (pl. a root használatához a „su” alkalmazásba vétele).

� Az IT stratégia vizsgálata Miért van szükség IT stratégiára? Az üzleti életben manapság már elkerülhetetlen az informatika használata és a vállalkozások egyre inkább kiszolgáltatottá válnak az informatika működésének. Ebből következően az üzleti célok teljesülésének alapfeltétele az informatikai folyamatos rendelkezésre állása. Ahhoz, hogy ez hosszútávon biztosítható legyen, hosszú távú megoldásokra és tervekre van szükség. Érdemes továbbá figyelembe venni a világviszonylatban fellépő jogalkotási tendenciákat, amelyek például a gazdasági társaságok beszámolási rendszere (lásd: SOX), vagy a hitelintézetek tőkemegfelelése (Bázel2, CRD) kapcsán a vállalatirányításra vonatkozóan szigorú előírásokat támasztanak. A hitelintézetekre vonatkozó szabályozás pedig a kockázatvállalással kapcsolatban például megköveteli, hogy „hatékony, átfogó statégiával és eljárással” rendelkezzen, illetve azt „legalább évente felül kell vizsgálni” annak érdekében, hogy összhangban legyen az intézmény tevékenységével.


- 40 -

Mit tartalmazzon a stratégia? A vezetés felel azért, hogy olyan hosszú- és rövidtávú tervek kerüljenek kidolgozásra, végrehajtásra, amelyek megfelelnek a pénzügyi intézmény hosszú távú célkitűzéseinek és rövid távú céljainak. Az informatikai tervezési eljárásnak figyelembe kell vennie a kockázat-elemzések eredményeit, az üzleti, a környezeti, a technológiai és az emberi erőforrásokhoz kapcsolódó kockázatokat, valamint az időszerű és szükséges változások átvezetésének módját. Az IT stratégia célja definiálni a vállalatok elkövetkezendő években elérendő céljaihoz szükséges informatikai technikai és architekturális jövőképet, körvonalazni a jelen és a jövőkép közötti eltéréseket, valamint felvázolni a megvalósítás feladatait. Az IT stratégiát javasolt legalább évente áttekinteni és a változásoknak megfelelően aktualizálni, biztosítva a stratégia folyamatos frissítését és a stratégiai időtáv kiterjesztését (gördülőtervezés). Alapvető elvárás, hogy a stratégia az érintettek körében ismert legyen, támogatást nyújtson a koncepcionális, valamint az operatív informatikai döntésekhez.

A stratégiának iránymutatást kell adni a következő évek IT költségvetésének pénzügyi tervezéséhez olyan formában, hogy a költség és beruházás tervszámok alulról felépíthetők legyenek. Ezért szükséges, hogy a megvalósítási projektek magas szintű erőforrásbecslést is tartalmazzanak.

Hogyan kapcsolódik a stratégia a mindennapi munkához? A 3 évnél hosszabb kitekintést nyújtó hosszú távú (stratégiai) elképzelésekkel összhangban kell lennie az 1-3 évre szóló és rövid- vagy középtávú (taktikai) terveknek, illetve az 1 évnél rövidebb időtávra vonatkozó (operatív) feladatoknak. A legátfogóbb, legáltalánosabb célok természetesen a stratégiai célok, majd a célhierarchia alacsonyabb szintjein a taktikai, végül pedig az operatív célok találhatók. Ezek közül a stratégiai célok jelentősége a legnagyobb, hiszen ezek nélkülözhetetlenek mind a stratégiai jellegű döntések meghozatalánál, mind az alacsonyabb szintűcélok kitűzésénél. A célok pontos ismerete nélkül racionális irányítás nem valósítható meg. Az átfogó informatikai biztonsági célkitűzések hosszabb távra érvényesek és az informatikai rendszer működésének nagyobb jelentőségű folyamataira vonatkoznak. Az informatikai biztonsági célkitűzések a biztonsági filozófiánál és a biztonságpolitikánál jobban behatárolják a jövőbeli cselekvések mozgásterét és irányítási célra is jobban alkalmazhatók.


- 41 -

Mit érdemes vizsgálni az IT stratégiával kapcsolatban? Az IT stratégiával kapcsolatban a leggyakrabban felmerülő kérdések az alábbiak: � Van-e egyáltalán IT stratégia? � Milyen rendszerességgel aktualizálják és hogyan kommunikálják? � Az IT stratégia készítésére és aktualizálására vonatkozóan van-e

szabályozás? � Összhangban van-e az üzleti stratégiával? � Kik a felelősei a stratégia készítésének és mi a folyamata? � Milyen – az IT stratégiával összefüggő – kapcsolódó átfogó tervek (IT

biztonsági stratégia, IT fejlesztési stratégia, kockázatkezelési stratégia, üzeltemenet-folytonossági stratégia stb.) vannak?

� Összhangban van-e az éves tervezéssel és az IT beruházásokkal? � Az IT stratégia tartalmazza-e a szervezeti változásokra, a

szabályozásra, a jogszabályváltozásokra, az emberi erőforrások biztosítására, az IT infrasturktúrára, a külsős szolgáltatók menedzselésére, a beszerzésekre, a fejlesztésekre, a biztonságra, a kockázatok menedzselésére, az üzletmenet-folytonosságra, az ellenőrzésekre vonatkozó elképzeléseket?

Hogyan kapcsolódik a stratégia az IT biztonsághoz? Az informatika biztonsági beruházások akkor lehetnek igazán hatákonyak, ha már specifikációs és fejlesztési fázisban gondoskodunk a biztonsági szempontok érvényesüléséről. Annak érdekében pedig, hogy a biztonsági szemléletmód már az informatikai életciklus legelején érvényesüljön, arra van szükség, hogy ezek már a vezetői elkötelezettségben megmutatkozzék, azaz stratégiai szinten is megjelenjen. Az informatikai biztonság menedzselésének folyamatában alapvető kérdés, hogy milyen átfogó szintű kockázat fogadható el a szervezet számára (lásd a 4. számú mellékletet). Az elfogadható kockázatok helyes szintje, és következésképpen a megfelelőbiztonsági szint az eredményes biztonságmenedzselés kulcsa. A biztonság kellően átfogó szintjét azok az informatikai biztonsági célkitűzések határozzák meg, amelyeket egy szervezetnek szükségszerűen teljesítenie kell. E biztonsági célkitűzések értékelése céljából ajánlatos a vagyontárgyak számbavétele, és annak meghatározása, hogy azok mennyire értékesek a szervezet számára. Ezt főként az informatikának a szervezet üzletvitelének támogatásában játszott fontos szerepe határozza meg; magának az informatikának a költségei az értékeknek csak egy kis részét jelentik. A lehetséges kérdések annak megítélésére, hogy egy szervezet üzleti tevékenysége mennyiben függ az informatikától, a következők:


- 42 -

� Melyek az üzlet azon nagyon fontos részei, amelyek informatikai támogatás nélkül nem folytathatók?

� Melyek azok a feladatok, amelyeket csak informatikai segítséggel lehet megoldani?

� Melyek azok a lényegi döntések, amelyek az informatika által szolgáltatott információk pontosságától, sértetlenségétől vagy rendelkezésre állásától függenek, vagy mennyire naprakészek ezek az információk?

� Milyen feldolgozott bizalmas információkat szükséges védeni? � Milyen következményekkel jár a szervezetre nézve egy nem kívánt

biztonsági esemény?

Ezen kérdések megválaszolása segítségünkre lehet egy szervezet biztonsági célkitűzéseinek meghatározásában. Például, ha az üzlet fontos vagy nagyon fontos részei függenek az információ pontosságától és napra készségétől, akkor ennek a szervezetnek az egyik biztonsági célkitűzése lehet, hogy az informatikai rendszerekben feldolgozott információ sértetlensége és időszerűsége biztosított legyen. A biztonsági célkitűzések megállapításakor ugyancsak ajánlatos figyelembe venni a fontos üzleti célokat és azok viszonyát a biztonsághoz. A biztonsági célkitűzések függvényében, ezen célkitűzések elérésére célszerűstratégiában megállapodni. A választott stratégiának célszerű arányban állnia a védendő vagyontárgyak értékével. Például, ha az előbbi kérdések közül egyre vagy többre a válasz igen, akkor valószínű, hogy a szervezet magas biztonsági követelményeket állított fel, és olyan stratégiát ajánlatos választani, mely elegendő erővel bír e követelmények teljesítéséhez. Az informatikai biztonsági stratégia általánosságban azt vázolja fel, hogyan éri el egy szervezet informatikai biztonsági célkitűzéseit. Egy ilyen stratégia témakörei, azon célkitűzések számától, típusától és fontosságától függ, amelyeket a szervezet általában fontosnak ítél meg ahhoz, hogy a szervezet egészében egyformán foglalkozzanak vele. Jellegüket tekintve, a témák lehetnek eléggé specifikusak, vagy igen átfogóak is. Az előzőekre példa, hogy egy szervezetnek lehet az az elsődleges informatikai célja, hogy miután ezt üzletvitelének jellege megkívánja, valamennyi rendszerét magas rendelkezésre állás mellett tartsa fenn. Ebben az esetben, egy stratégiai téma irányulhat a vírusfertőzés csökkentésére úgy, hogy szervezetben antivírus-szoftvereket telepítenek vagy vírusellenőrzés céljából kiválasztott helyeket jelölnek ki, amelyeken valamennyi kapott szoftvernek át kell haladnia). Ez utóbbi illusztrálására, egy átlagos szinten, egy szervezetnek lehet az az informatikai célkitűzése, mivel üzleti tevékenysége során saját informatikai szolgáltatásait értékesíti, hogy potenciális vevői számára bizonyítsa rendszereinek biztonságát.


- 43 -

Ebben az esetben, stratégiai téma lehet, hogy valamennyi rendszer biztonságosságát egy elismert harmadik fél igazolja. Az informatikai biztonsági stratégia egyéb lehetséges témakörei, a specifikus célkitűzések vagy azok kombinációi miatt, felölelhetik a(z) � szervezet egészében alkalmazandó kockázatelemzési stratégiát és

módszereket, � minden egyes rendszer esetében az informatikai rendszerbiztonsági

politika szükségességét, � minden egyes rendszer esetében a biztonsági üzemeltetési eljárások

szükségességét, � szervezet egészére érvényes információérzékenységi besorolási sémát, � összeköttetések biztonsági feltételeinek szükségességét, amelyeket

teljesíteni és ellenőrizni szükséges, valamint az � általánosan alkalmazandó incidenskezelési sémát.

A biztonsági stratégiát és az azt alkotó témaköröket ajánlatos vállalati informatikai biztonságpolitikába foglalni.

Milyen stratégiák és irányelvek kellenek? A stratégia (egyre több helyen politika) meghatározza egy adott terület fejlődésének irányát, kitűzi a legfontosabb céljait és meghatározza az eléréshez szükséges feltételeket. A stratégia egyben egy tükörként is funkcionál, hiszen az elképzelésekről, célokról számos fontos információt tudhatunk. Fontos! A lent említett stratégiák kidolgozási szintje mélysége, mindig igazodjon az adott Társaság méretéhez, fejlettségi szintjéhez, erőforrásaihoz és legfőképpen az üzleti tervéhez, így ezeket a legmagasabb szinten kell megvitatni és jóváhagyni.

� IT stratégia, amely tartalmazza az informatikai terület legfontosabb egységeit és feladatát, operációs rendszereit, szervertípusok és egyéb fontosabb hardver és szoftverjellemzői mellet, az IT folyamatokat is (pl. IT Help Desk, változáskezelés). Meg kell határozni (az IT fejlesztés bevonásával), hogy az elkövetkezőidőszakban milyen irányban és milyen lépéseken keresztül milyen szintre kíván eljutni ezekben az IT szervezet. A SWOT (Strengths – Weaknesses – Opportunities - and Threats) analízis lefolytatása itt is hasznos. Az IT stratégia tervezésekor az üzleti statégiát kell figyelembe venni, azzal kell összhangban lenni.

� IT biztonsági stratégia (politika) a legfontosabb dokumentum a biztonság tudatosságnak erősítése és a biztonsági szabályoknak való megfelelés elősegítése szempontjából.


- 44 -

A politika bemutatja a biztonsági szervezet felépítését, annak működését és folyamatait, dokumentációs készletét és bemutatja az ide vonatkozó törvényi elvárásokat is. Kiemelten foglakozik az információbiztonsággal az üzleti és információ felelősök meghatározásával.

� IT hálózati biztonsági politika, amely a belső hálózathoz való hozzáférést, illetve a kívülről történő (távoli) bejelentkezések elvárásait, használt és kötelezően használandó elemeit, a használható protokollokat, titkosítási, valamint hálózat szegmentálási elveket, illetve a felhasználó és jogosultságkezelési alapszabályokat rögzíti.

� IT fejlesztési stratégia, amely bemutatja az adott szervezeten belül működő fejlesztési osztály belső működését, az IT fejlesztési platformjait – fejlesztőkörnyezeteit – fejlesztőeszközeit. Rögzíti azt, hogy milyen üzleti igényre, milyen fejlesztői környezetben, milyen megoldással készülhetnek alkalmazások, és hivatkozik az egyes fejlesztői platformok használata során kötelezően használt programozói megoldásokat, eljárásokat, technikákat magába foglaló szabályzatokra.

� IT Kockázatkezelési stratégia Az IT kockázatok gyűjtésére vonatkozó törvényi hivatkozások felsorolása mellet, rögzíti az IT kockázatgyűjtés metodikáját, résztvevőit, a kockázatgyűjtés folyamatát tartalmazó szabályozási hivatkozásokat. A kockázatérzékényeségre, illetve az IT kockázatok csökkentésére vonatkozó legmagasabb színtű kijelentéseket és elvárásokat, valamint ahhoz szükséges mérföldkövek meghatározását.

� Fejlesztés Milyen elvárások vannak a fejlesztésekkel szemben? Természetesen a fejlesztéssel kapcsolatban is alapkövetelmény a megfelelőszabályozási környezet.

A szabályozásnak tartalmaznia kell a(z) � fejlesztéssel kapcsolatos irányelveket (külső vagy belső fejlesztés,

platformok, fejlesztési irányok, választott operációs rendszerek, adatbáziskezelők, alkalmazott programozási nyelvek stb.),

� követendő fejlesztési módszertanokat (SSADM, OO, RUP stb.), � fejlesztések konkrét lebonyolítására vonatkozó szabályokat (ki, mikor,

hogyan igényelhet, kinek kell dönteni a fejlesztés megvalósíthatóságáról, az egyes fejlesztési fázisokat ki, hogyan hajtja végre stb.),

� fejlesztés egyes fázisaiban a feladatokat (részletesen kinek, mikor és mit kell tenni).


- 45 -

Milyen fontosabb fázisokat kell ellenőrizni? A fejlesztéssel kapcsolatban minimum 5 fázis különítendő el: igénylés, specifikáció, fejlesztés, tesztelés, üzembe helyezés (üzemeltetés). A fejlesztési fázisokat különböző döntési pontok választják el, amelyekhez az adott fejlesztési fázishoz tartozó dokumentumok tartoznak. A döntési pontok dokumentumait érdemes szúrópróbaszerűen választott fejlesztésekre vonatkozóan ellenőrizni. Ezen döntési pontok és a hozzátartozó dokumentumok az alábbiak:

Ssz Fázis Döntési pont Dokumentáció 1. Igénylés Döntés a

fejlesztésről Igénylő lap, megvalósíthatósági tanulmány, gazdaságossági előterjesztés, CBA (Cost Benefit Analisys) stb.

2. Specifikáció Átadás-

átvétel a fejlesztőnek

Igény specifikáció, rendszerterv, átadás-átvételi dokumentumok, stb.

3. Fejlesztés Átadás-

átvétel tesztelésre

Fejlesztői dokumentáció, rendszer leírás, felhasználói leírás, üzemeltetői leírás, forráskód (letét), tesztelési terv, átadás-átvételi dokumentumok, telepítési utasítás stb.

4. Tesztelés Átadás-

átvétel üzembe helyezésre

Felhasználói tesztjegyzőkönyvek, hibalisták, átadás-átvételi dokumentumok, üzembe helyezés engedélyezése, telepítés visszaigazolása stb.

5. Üzemeltetés

A fejlesztés befejezését az üzemeltetésre történő átadás jelenti, amely azonban a fejlesztés vizsgálatának szerves részét kell, hogy képezze (e nélkül nincs befejezve a fejlesztési tevékenység). A módosításokból eredő újabb fejlesztéseket pedig a változáskezelés vizsgálatához soroljuk, bár annak ellenőrzése tulajdonképpen ugyanezen elvek szerint történhet.


- 46 -

A Társaságnak a fejlesztési módszertanában meg kell határozni a programok dokumentációjára vonatkozó szabványokat és az informatikai rendszer-fejlesztési, illetve módosítási feladatok részeként kifejlesztett szoftverek teszt-követelményeire, valamint a tesztelés ellenőrzésére, dokumentációjára és fenntartására vonatkozó szabványokat. A társaság rendszerfejlesztési életciklus módszertanában meg kell határozni, hogy milyen esetekben szükséges a régi és új rendszerek párhuzamos futtatása, illetve elő kell írni azt, hogy minden informatikai rendszer-fejlesztési, megvalósítási, illetve módosítási projekt során kell meg őrizni az elvégzett tesztek dokumentált eredményeit. A vezetésnek ki kell alakítania egy megfelelő eljárást a külsőrendszerfejlesztőkkel történő kapcsolat biztosítására az elfogadási, az átadás/átvétel kritériumai, a változtatások kezelése, a fejlesztés során jelentkező problémák megoldása, a felhasználói szerepek, a technikai berendezések, a műszaki környezet, a fejlesztő-eszközök, a szoftverek, a szabványok és az eljárások területén. Külső fejlesztő alkalmazása esetén a szerződésben rendelkezni kell arról, hogy a fejlesztett szoftver reprodukciójához szükséges információkat (forráskódját, adatbázis definícióját stb.) vagy át kell adni, vagy letétbe kell helyezni, hogy a fejlesztő társaság megszűnése esetén a szervezet az informatikai rendszerének folyamatos működése érdekében hozzájusson.

Mit vizsgáljunk a specifikációs szakasszal kapcsolatban? Az igények legnagyobb részt az üzleti területtől erednek, így a kívánt új funkciók meghatározása (specifikáció) is az üzleti terület felelősségi körébe kell, hogy tartozzon. Az igények összegyűjtésének és a specifikációk kialakításainak kereteit a már említett fejlesztési szabályozásoknak kell tartalmaznia.

A fejlesztések jellegétől függően természetesen megkülönböztethetők kisebb (rövidebb idő alatt kivitelezhető, kevesebb ember bevonását igénylő, kisebb költséggel megvalósítható) és nagyobb (hosszabb kifutású, nagy beruházás igényű, bonyolultabb, több ember munkájával projekt keretében megvalósítható) fejlesztéseket.

A nagyobb méretű fejlesztések esetén természetesen a projekt működését (projektalapítás, projektmódszertan, projektszabályozás, projekt működtetés, projekt ütemezés és dokumentálás, projekt minőségbiztosítás stb.) kell vizsgálni. A felhasználókat elsősorban az érdekli, hogy � működnek-e a szükséges funkciók, � mennyire megbízható az alkalmazás, � a rendelkezésre állás mennyiben biztosított (elérési idők, állásidő),


- 47 -

� mennyire könnyen használható, � mennyire hatékony és gazdaságos, � hogyan fejleszthető tovább, � milyen egyszerű transzportálni más környezetbe.

A szoftverminőség jellemzői a � funkcionalitás, � megbízhatóság, � használhatóság, � hatékonyság, � karbantarthatóság és a � hordozhatóság.

Az informatikai vizsgálatok során természetesen a fejlesztési feladatok informatika szempontjait, a fejlesztési gyakorlatnak a szabályzatokkal való összhangját, az előírt dokumentumok meglétét és tartalmát, a minőségbiztosítási feladatok végrehajtását, a logikai-, az adatbiztonsági- és jogosultsági szempontok érvényesülését kell ellenőrizni.

Mit vizsgáljunk a fejlesztési szakaszra vonatkozóan? A szervezet fejlesztési metodikájának részeként ki kell alakítani egy megfelelő eljárást a felhasználói szoftverek teljesítményének optimalizálására az új és jelentős mértékben módosított, megváltoztatott szoftverek üzemeltetéséhez szükséges erőforrások előrejelzése érdekében. Az elért előrehaladás mérésére - az érintett felek által jóváhagyott - megvalósítási tervet kell kidolgozni. A végrehajtási tervnek az alábbi kérdésekre kell kitérnie: � helyszín előkészítése, � eszközök beszerzése és telepítése, � felhasználók képzése, � operációs rendszer módosításainak telepítése, � üzemelési eljárások bevezetése és áttérés.

A szervezet fejlesztési metodikájában elő kell írni, hogy a régi rendszer szükséges elemeit minden egyes informatikai rendszer-fejlesztési, megvalósítási illetve módosítási projekt esetében át kell emelni az új rendszerbe az erre vonatkozó előre kidolgozott tervek szerint.

Mit érdemes vizsgálni migráció esetén? Migráció esetén a vezetésnek elő kell írni olyan adat-átalakítási terv elkészítését, amely meghatározza az átalakítandó adatok összegyűjtésének és ellenőrzésének módszereit és emellett feltárja, valamint megoldja az átalakítás során talált hibákat (adat-átalakítás és konverzió).


- 48 -

Migráció esetén vizsgálni kötelező azt, hogy a folyamat és a benne szereplőmunkatársak, hogyan és milyen módon biztosította a migrált adatok � sérthetetlenségét, � hitelességét, � konzisztenciáját, � -a forrásból a célrendszerbe történő áttöltéskor a- minőségi és

mennyiségi egyezőségét, � sérülésekor, vagy nem várt probléma esetén az alkalmazható

visszaállítási folyamat lefolytatásának sikerességét.

Biztosítani kell, hogy a migráció közben az adatok ne kerüljenek „illetéktelen kézbe”, illetve azt, hogy a sikeres migráció esetén az adathordozó a későbbiekben a megfelelő helyre (pl. mentések mellé) el legyen zárva. Minden esetben dokumentálni kell a migráció � tényét � folyamatát, � annak időtartamát és helyét, � a használt adatok típusát és mennyiségét, � szereplők nevét, munakörét, � használt médiák neveit és cimkéit, valamint � sikerességét vagy sikertelenségét.

Mit vizsgáljunk a tesztelésekkel kapcsolatban? A rendszergazdának és az informatikai részleg vezetésének tesztelési terveket kell készíteniük. Az érintett felhasználói osztályok dolgozói és az informatikai részleg üzemeltetési csoportja számára a kidolgozott oktatási tervben foglaltaknak megfelelő képzést kell biztosítani. A vezetésnek gondoskodnia kell arról, hogy a változtatásokat a valós környezetben történő üzembeállítás előtt külön környezetben tesztelje egy a (rendszer-építőktől) független tesztelési csoport a hatás- és kapacitás-elemzésnek megfelelően. Az átvételi tesztelést a jövőbeni működési környezethez hasonló környezetben kell végrehajtani. Az informatikai tesztelések során ki kell térni arra, hogy az IT üzemeltetés –aki az élesbeállítást követőn üzemeltetni fogja az adott fejlesztést / alkalmazást / rendszert-, milyen szinten és mélységben volt bevonva tesztelési folyamatokba. Erősen ajánlott, hogy a tesztelések során az IT üzemeltetés végezzen teljesítményméréseket, elemezze ki a tesztelési időszak során tapasztalt futási értékeket és figyelje a rendszerlogok hibabejegyzéseit. A teszteléssel kapcsolatban a jelen kézikönyv egy külön fejezete (lásd a következő 10. fejezet) foglalkozik.


- 49 -

Milyen elvárások vannak az üzembe helyezésre vonatkozóan? Szoftverváltozások esetén az új, illetve módosított rendszerek végleges elfogadási, átvételi, illetve minőségbiztosítási tesztelési eljárásának részeként a tesztelési eredményeket formálisan is jóvá kell hagynia az érintett felhasználói osztály(ok) és az informatikai részleg vezetésének. A vezetésnek elő kell írnia, hogy az üzemeltetési részleg és a felhasználói osztályok vezetőinek formálisan is el kell fogadniuk a teszt-eredményeket és a rendszerek biztonsági szintjét az elfogadott kockázati szinttel együtt. A vezetésnek ki kell dolgoznia, és végre kell hajtania azokat a formális eljárásokat, amelyek szabályozzák a rendszer átadását a rendszerfejlesztéstől kezdve a tesztelésen keresztül az üzembe helyezésig. A vezetésnek elő kell írnia, hogy az új rendszer csak, sikeres teszteredményeket követően, a rendszer tulajdonosának engedélyével (adatgazda) helyezhető üzembe. Az egyes alkalmazások eltérő rendeltetésű környezeteit (fejlesztési, tesztelési, üzemeltetési) külön kell választani és gondoskodni kell azok korrekt védelméről. A társaság fejlesztési szabályozásában elő kell írni, hogy a megvalósítást követően az informatikai rendszerre vonatkozó üzemeltetési-követelmények (kapacitás, áteresztőképesség stb.) megvizsgálása alapján értékelni kell a rendszer felhasználói megfelelőségét.

�� Tesztelés vizsgálata

10.1. A tesztelések vizsgálatának előkészítése

Mikor hatékony és kontrollált egy a tesztelési folyamat? Bár a fejlesztési- és változáskezelési eljárás szerves részét képezi, a tesztelési feladatokat fontosságuknál fogva kiemelten kezeljük. Hangsúlyosságát egyrészt az adja, hogy ennél a feladatnál derülhetnek ki olyan előre nehezen megjósolható, a gyakorlati működéskor fellépőproblémák, amelyek a tervezési- és fejlesztési tevékenységek során nem mindig jönnek elő. A tesztelés fontosnak tekinthető másrészt azért is, mivel egyértelműen az üzleti terület felelősségi körébe tartozó felhasználói teszt (User Acceptance Test - UAT) minden esetben elengedhetetlen. Annak érdekében, hogy a fejlesztési- és változáskezelési feladatokban mindenképpen megtörténjen a tesztelés, szükséges az ezért felelős szervezeti egység (változásmenedzsment, minőségbiztosítás stb.). A minőségbiztosítás célja, hogy � a megfelelő rendszerismeret mellett meghatározza a tesztelési

feladatokat, � elkészítse a tesztelési tervet és meghatározza a tesztelési eseteket,


- 50 -

� megszervezze a teszteléseket, � értékelje a tesztelések eredményét, � majd a sikeres teszteléseket követően az IT-val közösen megtervezze és

megszervezze az élesbe állítást, valamint gondoskodjon az esetleges visszaállítási folyamatról.

A fenti felsorolás és a továbbiakban leírt, majd a működésüket kötelezően vizsgálandó kontrollok, az azonosítható üzemeltetési kockázatok csökkentésére irányulnak. A tapasztalat azt mutatja, hogy az informatikai minőségbiztosításnak az üzleti oldal és az IT közös "támadásában" kell dolgozniuk, hiszen a tesztelések időt vesznek el, így erőforrásokat vonnak el szinte valamennyi terület munkatársaitól, továbbá sikertelen teszteredmények esetén „megakaszthatják” az átadási folyamatot. Ennek ellenére számos helyen lehet találkozni olyan szervezetekkel, amelyek már tudatosították és elfogadták magukban az informatikai minőségbiztosítás helyét és szerepét az adott környezetben, megteremtették és biztosítják a hatékony működésének kereteit, valamint elfogadtatta a szerepét az üzleti, illetve az IT területekkel.

Mit ellenőrizzünk? Az alábbiakban felsorolásra kerülnek azok, az IT ellenőrök által kötelezően ellenőrizendő kontroll pontok, amelyek a terület kontrolltudatos működési szintjének meghatározásához adnak segítséget. A „klasszikus hármasnak” nevezett, IT környezetek meglétének vizsgálatával ajánlatos kezdeni az ellenőrzést. Az éles, a teszt és a fejlesztői környezet megléte, annak elszigeteltsége, avagy átjárhatósága, illetve kontrolljainak működése stb. az alapvetően auditálandó területekhez kell, hogy tartozzon. Az IT környezet vizsgálatakor ki kell térni a: � kritikus rendszerek éles - teszt - fejlesztői környezet elhatárolásának, � azok kontrollált és szabályokon alapuló átjárhatóságának, � hardver és szoftver paraméterek és komponensek egyezőségének, � tesztadatok mennyiségének és minőségének, � fizikai és logikai szeparációjának ellenőrzésére.

10.2. Tesztelési módszertan, esetek

Létezik-e tesztelési módszertan egyáltalán, és az hogyan néz ki��A Tesztelési Módszertan általában külön szabályzatban, vagy a szabályzat egyik mellékleteként szerepel.


- 51 -

A Tesztelési Módszertannak tartalmaznia kell, hogy milyen rendszert/alkalmazást, milyen esetekben, illetve milyen típusú módosítások alkalmával, milyen mélységű tesztelésnek kell alávetni. Az MSZ EN ISO 9001 (Minőségirányítási Rendszerek Követelménye) számos dologban nyújt segítséget. A könyv abból indul ki, hogy a vizsgált terület rendelkezik már elfogadott tesztelési módszertannal, így az IT környezet vizsgálatakor ki kell térni: � a tesztelési módszertan naprakészségének és az MSZ EN ISO 9001

komform szint elemzésére, � az egyes tesztelési típusok szofisztikáltságának ellenőrzésére, � arra, hogy a biztonsági jellegű tesztelések esetében milyen módszer

szerint történik a biztonsági terület bevonása, � arra, hogy a tesztelések során milyen mértékben térnek ki az egyes

fejlesztési platformokban fejlesztett alkalmazások sajátosságaira, � a fejlesztési módszertan és a tesztelési módszertan közötti egyezőség

meghatározására, � a külső kapcsolattal rendelkező alkalmazások / rendszerek, esetében

kötelező a speciális biztonságtechnikai tesztelés lépéseinek ellenőrzésére.

10.3. Tesztelések menedzselése

Hogyan menedzselik a tesztelési folyamatot? A tesztelési folyamatok esetében az egyes szereplők bevonásának körülményeit, a teszteredmények dokumentálását, az utólagos nyomon követhetőséget kell vizsgálni. Ajánlatos a tesztelések mendzselésének vizsgálatakor kitérni arra, hogy : � a folyamatok és az egyes tesztesetek definiálása és a valóságos élet

folyamatainak megfeleltetése milyen szintű, � a tesztelésben szereplő személyek milyen szinten fedik le az adott

munkafolyamatban résztvevő szereplőket, � a tesztelési eredmények mellékleteiben az adott hardver és szoftver

környezet legfontosabb futási és működési paramétereinek és adatainak elemzése miként valósul meg,

� milyen IT eszközzel támogatják az egyes tesztelési folyamatok lefolytatását,

� az egyes tesztelési tervek összehangolása a napi üzemszerű működés mellett hogyan és miként valósul meg,

� a tesztelési tervek mellett készülnek-e visszaállási tervek is, amelyek alapján az élesbe történő installálást követő -esetleges- súlyos hibák esetén vissza lehet térni az előző verzióra, a tesztesetek és az eredmények dokumentálása, valamint a továbbfejlesztett / alkalmazás


- 52 -

és rendszer forráskódjának követése milyen módon függ össze, és ez hogyan valósul meg?

10.4. Tesztadatok vizsgálata

A tesztelés során milyen adatokat használhatnak fel? Abban az esetben, hogy ha a tesztelések során éles, vagyis a termelőrendszerben megtalálható ügyfél adatokkal tesztelnek, úgy az éles rendszerben alkalmazott és használt biztonsági jellegű beállításokkal kell rendelkeznie a tesztrendszernek (jogosultságkezelés, naplózás stb.). Ha 'előre legyártott' teszt adatbázissal esetleg éles adatokból összekevert vagy elfedett (maszkolt) ügyféladatokkal dolgoznak, akkor biztonsággal szemben támasztott követelményekből lehet engedni a tesztrendszernél, de az éles működés megfelelőségét biztonság szempontjából is kell valahol tesztelni. Az input és az output adatok minősége, az adatduplikációk megszüntetése, valamint az adathozzáférés változása a vizsgálandó témák közé tartozik. A tesztadatok vizsgálata során ki kell térni : � az adatbeviteli mezők validálási eljárásainak, � az adott fejlesztés, listából kiválasztható adatbeviteli formájának és

szabad szöveges adatbeviteli lehetőségének alkalmazásának mértékének,

� az adatminőségi és biztonsági eljárások alkalmazásának, � a teszt és az éles adatbázisok közötti kontrollált kapcsolatok

biztosításának, � az éles adatokhoz való hozzáférések teljes körű naplózásának a kimenő

riportok adattartalmának, � a tesztadatok használatakor a felhasznált adatmennyiség, továbbá az

éles rendszerben megtalálható adatmennyiség nagyságának és arányának vizsgálatára / ellenőrzésére.

10.5. A tesztelés monitorozása

Mit kövessünk nyomon a tesztelés folyamatában? Sok esetben a teszt és az éles rendszerek hardver és szoftver komponensei nem egyeznek meg, így a teszteléskor és az éles működés során az egyes műveletek futási idejei változhatnak. Fontos, hogy az IT üzemeltetők a tesztidőszak alatt is monitorozzák az adott teszt rendszert és az alkalmazások futását, valamint az éles rendszerhez minél inkább közelítő hardver és teszt adatbázis álljon rendelkezésre. A tesztadatok vizsgálata során ki kell térni: � a tesztrendszerekben használt monitorozó eszközök támogatási

szintjének,


- 53 -

� a tesztrendszer futásának és kötelező monitorozásának, � a tesztesetek során tapasztalt és a monitorozás során előállt futási

eredmények kiértékelésének vizsgálatára és értékelésére.

10.6. Teszteredmények értékelése

Mikor fogadható el a tesztelés? A végfelhasználók által lefolytatott tesztelések eredménye, a fejlesztők és rendszerszervezői tapasztalatok, valamint az egyes tesztesetek végeredménye mellett, az IT üzemeltetés által tapasztalt információkat is figyelembe kell venni a végső kiértékelés a során. Meg kell vizsgálni, hogy a kiértékelés folyamata mennyi lépcsőt tartalmaz, milyen értékelési kritériumok és mekkora súllyal számítanak bele a végsőértékelésbe. Az átvételi kritériumok közé kell sorolni a megfelelő szintűdokumentációs környezet is. A tesztelés végén mindenképpen el kell készülnie a felhasználói elfogadási jegyzőkönyvnek.

10.7. Élesbeállítás

Mit vizsgáljunk az éles üzembe helyezéskor? A megfelelő eredményt követően -már csak- az élesbe történő installálás marad hátra. A visszaállási terv fontosságára már az előzőekben felhívtuk a figyelmet, így itt az időzítésen az egyes IT és üzleti területek összehangolt működésén és a tervezésén van a hangsúly. Mindannyian tisztában vagyunk azzal, hogy olyan tökéletes tesztelés nincs, amely 100%-ban kiküszöböli a fejlesztési hibákat, viszont a megfelelően lefolytatott teszteléssel nagymértékben csökkenthető a potenciális működési kockázat. Az éles üzembe helyezést minden esetben csak a felhasználói elfogadást követően szabad végrehajtani. Az üzembe helyezés, a rendszergazda által történt átadás-átvételt követően, a telepítés megtörténtének igazolásával zárul (dokumentáció!).

�� Változáskezelés Mit értünk változáskezelés alatt? A társaság életében bekövetkező informatikai változásokat kezelni kell. A változás fogalmát jelen esetben kiterjedten használjuk, amely magába foglalja egyaránt a hardver-, a szoftver-, a konfiguráció-, az erőforrások-, az infrasturktúra- és a környezeti feltételek változását is. A változások (adatok, hardver, szoftver, infrastruktúra, technológia, emberi erőforrások stb.) kezelésére vonatkozó formális szabályokat és hivatalos eljárásokat


- 54 -

definiálni kell, valamint a változáskezelési feladatok menedzselése érdekében javasolt külön felelőst kijelölni (változásmenedzser). A vezetésnek elő kell írnia azt, hogy a változtatásokra, a rendszerkarbantartásokra és a szállítói (által végzendő) karbantartásokra vonatkozó kéréseket előre meghatározott formában kell benyújtani és annak megfelelően kell eljárni. A változtatási kéréseket kategorizálni kell, majd meg kell határozni prioritási fokukat. A sürgős esetekre vonatkozóan külön szabályozást kell kidolgozni. A változtatások kérelmezőit tájékoztatni kell a kérelmük státuszáról. Ki kell alakítani egy olyan eljárást, amely gondoskodik a változtatási kérelmek strukturált módon történő értékeléséről és figyelembe veszi az üzemben lévő rendszert és annak funkcionalitását érintő összes lehetséges – kockázatelemzés során figyelembevett – következményt. A vezetésnek gondoskodnia kell arról, hogy a változáskezelés, a szoftvermenedzselés és terítés megfelelően igazodjon az átfogó konfiguráció-kezelési rendszerhez. Az alkalmazási rendszerben végrehajtott változások megfigyelésére szolgáló rendszert automatizálni kell annak érdekében, hogy rögzítésre kerüljenek a nagy és bonyolult informatikai rendszereken elvégzett módosítások. Az informatikai vezetésnek meg kell határoznia a sürgősségi (pl. vészhelyzet) változtatások paramétereit és az ilyen változtatások menetét (a szabályozásban). Amennyiben azok kívül esnek a bevezetés előtti műszaki, üzemelési és vezetői értékelés normál eljárásán. A sürgősségi változtatásokat nyilván kell tartani, és előzetesen jóvá kell hagynia az informatikai vezetésnek. A változtatási eljárásra vonatkozó szabályokban elő kell írni, hogy amennyiben végrehajtásra kerül valamilyen rendszerváltoztatás, az ahhoz kapcsolódó dokumentációt és eljárásokat is aktualizálni kell. A vezetésnek gondoskodnia kell a karbantartó személyzet által elvégzendőmunkák kijelöléséről és megfelelő felügyeletéről. Ezen felül szabályozni kell hozzáférési jogaikat is, az automatizált rendszerekhez történőjogosulatlan hozzáférés elkerülése érdekében. Megfelelő folyamatba épített intézkedéseket kell kialakítani annak érdekében, hogy az egyes szoftverelemek sértetlenül a megfelelő helyre kerüljenek a megfelelő időben, és mindez ellenőrizhető legyen (pl. az ellenőrzési naplón keresztül).


- 55 -

�� Rendkívüli helyzetek kezelése Miért van szükség rendkívüli-helyzet kezelési tervekre? Ellenőri tapasztalataink alapján a jól ismert mondás, hogy „más kárán tanul az okos” az üzletmenet-folytonosság menedzselés (BCM – Business Continuity Management) területén nem mindig alkalmazható. Ugyanis, a nagy erőforrás ráfordítással járó tartalék helyszín kialakítása, tartalék eszközök beszerzése és karbantartása, az üzletmenet-folytonossági (BCP – Business Continuity Plan) és katasztrófa (DRP – Disaster Recovery Plan) tervek elkészítése, folyamatos aktualizálása, valamint rendszeres tesztelése nem mindig tűnik megtérülő beruházásnak. Ezt legtöbbször csak akkor tudja elkötelezetten, teljes odaadással képviselni a menedzsment, ha már saját maga is részt vett egy nem várt esemény kezelésében, saját bőrén is megtapasztalta, hogy milyen érzés pl.: � nyitáskor szembesülni azzal a ténnyel, hogy a klíma berendezés

meghibásodása miatt a géptermi szerverek leálltak, vagy � a kommunikációs hálózat megszakadása miatt a központi alkalmazások

nem elérhetők, illetve � az ATM eszközök szoftver problémája miatt több ezer ügyfél áll sorba

a bankfióknál, miközben a sajtó folyamatosan nyilatkozatokat kér. Röviden megfogalmazva a BCP az üzleti folyamat bármilyen okból való kiesése, sérülése vagy megszakadása esetére dolgoz ki alternatív eljárásokat a probléma elhárításának idejére. Ebből következően a BCP nem informatikai probléma, hanem a vállalatot átölelő üzleti feladat. A fenti és a még elő nem fordult, de hipotetikusan előforduló problémák elkerülése érdekében érdemes megfontolni az alábbi jótanácsokat. Az üzleti hatáselemzéssel kapcsolatos legfontosabb kérdések lehetnek: � Azonosították és osztályozták-e a lényeges és üzletileg kiritkus

(Business Critical) folyamatokat és adatokat? � Dokumnetált-e a kritikus folyamatok és adatok meghatározása,

osztályozása, jóváhagyása? � A felmérés kiterjedt-e az összes erőforrás típusra (hardver, szoftver,

emberek, irodai- és kommunikációs eszkök, telephelyek, stb.) A DRP (többnyire informatikai) erőforrások visszaállítására vonatkozó tervezés (kissé egyszerűsítve).

12.1. Üzletmenet-folytonosság menedzselés vizsgálata

Mely rendszerekre készítsünk BCP-t? Annak érdekében, hogy mennyi munkát fektessünk BCP és DRP tervek készítésébe szükség van kockázatelemzésre és a folyamatok, adatok osztályozására.


- 56 -

A vezetésnek meg kell vizsgálnia, hogy mely adatok és folyamatok kiemelt fontosságúak, illetve milyen erőforrások szükségesek ezek folyamatos fenntartásához, vagy üzemzavar utáni visszaállításához. Ez az első lépés ahhoz, hogy megállapítható legyen, hogy mely erőforrásokat kell a leginkább védeni és milyen üzletmenet-folytonossági, illetve rendkívüli-helyzet kezelési tervet kell készíteni. A vezetésnek gondoskodnia kell arról, hogy meghatározásra kerüljenek az informatikai rendszerek rendelkezésre állására és teljesítményére vonatkozó üzleti követelmények, és azok alapján kerüljenek kidolgozásra a rendelkezésre állásra vonatkozó feltételek és követelmények. A vezetésnek gondoskodnia kell egy olyan megfelelőrendelkezésre állási terv kidolgozásáról, amely biztosítja, figyelemmel kíséri és ellenőrzi informatikai szolgáltatások rendelkezésre állását, valamint gondoskodni kell arról, hogy a rendkívüli eseményekről kellőidőben megfelelő részletességű jelentés készüljön.

12.2. DRP tervek ellenőrzése

Mire figyeljünk a DRP tervek készítésekor? Az informatikai részleg vezetésének az üzletmenet-folytonossági terv alapján ki kell dolgoznia egy informatikai folyamatossági keretrendszert, amely meghatározza a feladatokat és felelősségi köröket, az alkalmazandó kockázat-alapú megközelítési módszert, valamint az informatikai folyamatossági terv dokumentálására és jóváhagyására vonatkozó szabályokat és struktúrákat. A vezetésnek gondoskodnia kell arról, hogy az informatikai folyamatossági terv összhangban álljon az üzletmenet-folytonossági tervvel. Az informatikai részleg vezetésének megfelelő eljárásokat kell kidolgoznia a változtatások szabályozására vonatkozóan annak érdekében, hogy a folyamatossági terv mindig naprakész legyen és igazodjon az üzleti/szervezeti követelményekhez. A folyamatossági terv eredményességének megőrzése érdekében a vezetésnek rendszeres időközönként értékelnie kell a terv megfelelőségét, illetve akkor, amikor jelentősebb változások történnek a szervezetben, az üzletvitelben vagy az informatikai infrastruktúrában. A katasztrófa-elhárítási módszertan keretében gondoskodni kell arról, hogy minden érintett fél rendszeres időközönként megfelelő képzést kapjon arra vonatkozóan, hogy rendkívüli esemény, illetve katasztrófa esetén milyen szabályok szerint kell eljárnia. A folyamatossági módszertanban gondoskodni kell arról, hogy a felhasználók megfelelő alternatív feldolgozási eljárásokat alakítsanak ki, amelyeket használhatnak addig, amíg az informatikai részleg teljes mértékben helyre nem állítja a rendszert a bekövetkezett leállást, illetve katasztrófát követően.


- 57 -

A folyamatossági tervben meg kell határozni a katasztrófa-helyzet utáni helyreállításhoz szükséges kritikus fontosságú alkalmazási programokat, külső szolgáltatókat, operációs rendszereket, munkatársakat, adatállományokat és a katasztrófa utáni visszaállításhoz szükséges időt. A vezetésnek gondoskodnia kell arról, hogy a folyamatossági módszertan alternatív tartalék telephelyek és hardverek meghatározását is előírja, valamint egy végleges alternatíva legyen kiválasztva. Amennyiben szükséges, szerződés keretében kell szabályozni az ilyen jellegűszolgáltatásokat. A helyreállításra és folyamatos üzletvitelre vonatkozó tervek kapcsán gondoskodni kell a kritikus back-up adathordozók, dokumentációk és egyéb informatikai erőforrások külső tárolásáról. A külső helyen tárolandó back-up erőforrások körének meghatározásába be kell vonni az üzleti folyamatokért felelős vezetőket és az informatikai részleg dolgozóit is.

Mit kell ellenőrizni az incidens kezeléssel kapcsolatban? Ha bármilyen nem várt esemény bekövetkezik, akkor azt természetesen észre kell venni (észlelés) és annak megfelelően reagálni. Arra vonatkozóan, hogy egy adott esemény azonnali intézkedést, egy nem sűrgős üzemeltetői rutin feladatot, egy hosszabb távú fejlesztést vagy egy sűrgős, több erőforrást igénylő feladatot jelent, valamilyen módon dönteni kell. Erre külön felelősöket kell megnevezni, illetve incidenskezelési eljárásokat kell kidolgozni. Az informatikai részleg vezetésének ki kell alakítania egy megfelelőprobléma-kezelő rendszert, amely gondoskodik a működés során tapasztalt nem szokásos események (rendkívüli esetek, problémák, hibák stb.) nyilvántartásáról, elemzéséről és megfelelő időben történő megoldásáról. A vészhelyzetekben alkalmazandó program eljárások megváltoztatását azonnal tesztelni kell, jóvá kell hagyatni azokat, és jelentést kell készíteni az esetről. Jelentősebb probléma esetén ún. „rendkívüli eseményjelentést” kell készíteni. A vezetésnek ki kell alakítania megfelelő probléma felterjesztési/ továbbítási eljárásokat (az illetékesek felé) a feltárt problémák lehetőleghatékonyabb módon és megfelelő időben történő megoldása érdekében. A fenti eljárásokban meg kell határozni az ezzel kapcsolatos prioritásokat. Az eljárás keretében dokumentálni kell az informatikai folyamatossági terv beindulására vonatkozó döntés-előkészítő eljárást is. A problémakezelő rendszer keretében ki kell alakítani olyan megfelelőellenőrzési naplókat, amelyek lehetővé teszik a problémák mögött meghúzódó okok felderítését a rendkívüli eseményből kiindulva az eredeti okig.


- 58 -

Milyen tartalék infrastuktúrára van szükség? Az üzletileg kritikus rendszerek esetében, amellyel kapcsolatban azonnali vagy csak nagyon rövid idejű kiesés engedhető meg, tartalék berendezésekre van szükség. Az üzletmenet-folytonosságal kapcsolatos kérdések az alábbiak: � Létezik hatályos, aktualizált üzletmenet-folytonossági terv? � Létezik szabályozás a BCP tervek készítésére, folyamatos

aktualizálására és tesztelésére vonatkozóan? � A BCP meghatározza-e a kritikus alkalmazásokat, üzleti

hatástanulmány (Business Impact Analysis – BIA) készült-e? � A BCP terv tükrözi-e az aktuális architektúrát (hardver-, szoftver

architektúra, feladatkörök stb.)? � A BCP meghatározza-e a helyreállításban résztvevők feladatát és

felelősségét? � A BCP meghatározza az alternatív feldolgozóhelyet és eszközöket

(tartalékeszközök, mentések stb.) � A BCP részletes utasításokat ad-e a helyreállítási munkálatok

elvégzésére (alternatív üzleti folyamatok, adatfeldolgozás, szolgáltatások, kommunikációs eszközök stb.)?

� A BCP-t az érintettek megismerték, elfogadták, megértették és oktatásban részesültek-e?

� Üzemzavar esetén a folyamatok újraindításáig megfelelő alternatív megoldások (kézi megoldások, alternatív automatikus eszközök) rendelkezésre állnak-e?

� Léteznek-e tartalék eszközök vagy azok hiányában a tartalékolást biztosító szerződések?

� A külső szerződések a minimálisan szükséges formai és tartalmi követelményeknek megfelel-e?

Mit ellenőrizzünk a mentéseknél? Mentési koncepció. Mivel a mentések rendelkezésre állásának kiemelt szerepe van a rendkívüli események kezelésében és ennek megvalósítása erőforrás igényeket támaszt, szükség van egy átfogó elképzelés, a mentési koncepció kidolgozására. A vezetésnek ki kell dolgoznia egy megfelelőstratégiát az adatok mentésére és helyreállítására vonatkozóan, amely kitér az üzleti követelmények áttekintésére, valamint a helyreállítási terv kidolgozására, megvalósítására, tesztelésére és dokumentálására is. Megfelelő eljárások keretében gondoskodni kell arról, hogy a mentések megfeleljenek a fenti követelményeknek. Megfelelő eljárások keretében gondoskodni kell arról, hogy a mentési műveletek a meghatározott mentési stratégiával összhangban kerüljenek végrehajtásra, továbbá rendszeres időközönként ellenőrizni kell a mentések


- 59 -

használhatóságát. Az informatikai adathordozókra vonatkozó mentési előírások keretében gondoskodni kell az adatállományok, a szoftverek és a kapcsolódó dokumentációk megfelelő tárolásáról, mind a szervezet telephelyén, mind azon kívül. A mentéseket biztonságos helyen kell őrizni és rendszeres időközönként ellenőrizni kell a tárolási hely fizikai hozzáférhetőségét, valamint az adatállományok és egyéb elemek biztonságát, meg kell győződni az elmentett adatok és rendszerek visszatölthetőségéről az esetleges szoftver és hardverkörnyezet megváltozása esetén.

� Megőrzési idők Az adathordozók szabályozott és biztonságos kezelése érdekében, a kockázatelemzés alapján, megfelelő adattárolási szabályokat kell kialakítani, figyelembe véve a visszakereshetőséggel kapcsolatos követelményeket, a költség-hatékonyságot és a biztonsági alapelveket is. Meg kell határozni a dokumentumok, adatok, programok, jelentések és üzenetek (bejövő és kimenő), valamint az ezek rejtjelezéséhez és hitelesítéséhez használt adatok (kulcsok, tanúsítványok) megőrzési idejét és tárolási feltételeit. A mentések megőrzési idejének meghatározása természetesen nem rendszergazdai feladat, hanem az üzleti területeknek kell nyilatkozni arról, hogy 5, 8 vagy 10 évig kell-e megőrizni az adott munkafolyamattalkapcsolatos információkat.

� Használhatóság Az már viszont valóban az informatikai szakemberek felelőssége, hogy a megadott adathordozók valóban a megadott ideig használhatóak, nem semmisülnek meg, nem íródnak felül vagy a rajtuk tárolt információk nem sérülnek meg.

� Nyilvántartás Természetes, hogy rendkívül helyzetben az üzletmenet visszaállításához szükséges adatok tárolását jelentő mentési médiumok kéznél legyenek, illetve megtalálhatók legyenek. Ennek érdekében szükség van egy naprakész, megbízható média nyilvántartásra, amelyből kiderül, hogy melyik helyszínen vannak a szükséges CD / DVD-k vagy mágnesszalagok. A vezetésnek gondoskodnia kell az adatokat tartalmazó tároló szisztematikus leltározásáról és arról, hogy a leltározás során talált eltérések időben rendezésre kerüljenek, továbbá megfelelőintézkedéseket kell hozni a tárolt adathordozók sértetlenségének megőrzése érdekében.


- 60 -

A vezetésnek gondoskodnia kell arról, hogy létezzen egy olyan eljárásrend és szabályzat, amely az adathordozó-tároló tartalmának védelmét szolgálja. Külön szabályokat és előírásokat kell kidolgozni a mentési adathordozók külsején megjelenő azonosító címkékre, az adathordozók tárolására és fizikai mozgatásuk nyomon követésére annak érdekében, hogy mindig el lehessen velük számolni. Ki kell jelölni az adathordozó könyvtár (mágnesszalagok, cserélhető szalag kazetták illetve egyéb cserélhetőadathordozó elemek, lemezek, CD, DVD) kezeléséért felelős személyeket. Alapkövetelmény, hogy a mentéseknek is ugyaolyan szintű és megfelelőségű védelemmel kell rendelkenznie, mint az eredeti adatfeldolgozó rendszernek.

Milyen követelmények vannak az archiválásokkal kapcsolatban? Az archiválásokkal kapcsolatban a mentésekhez hasonló kontrolloknak kell működniük (szabályozott-e, dokumentált-e, nyilvántartásuk megfelelő-e, valóban megtalálhatók és adott esetben használhatók-e stb.). A vezetésnek megfelelő szabályok és eljárások kialakításával gondoskodnia kell arról, hogy az adatok archiválására a jogi és üzleti követelményeknek megfelelően kerüljön sor, továbbá gondoskodni kell az archivált adatoknak az eredetivel megegyező megfelelő védelméről és nyilvántartásáról. Az adatgazdáknak kell meghatározniuk az adatok besorolását és megosztását, valamint azt, hogy szükség van-e, és ha igen mikor, a programok és fájlok megőrzésére, archiválására, illetve törlésére. A mentésekkel és archiválásokkal kapcsolatos kérdések: � A médiák nyilvántartása aktuális-e, a megfelelő adathordozók a

nyilvántartás szerinti helyen és tartalommal megtalálhatók-e? � A médiák tárolása megfelelő környezeti körülmények között, megfelelő

fizikai védelemmel ellátottak? � A mentések és archiválások elvégzését szabályozták, a gyakorlat

megfelel a szabályozásnak? � Léteznek megfelelő eljárások az adatok és a programok mentésére és

archiválásárá? � A mentéseket és archiválásokat egy előre meghatározott ütemterv

alapján, megfelelő gyakorisággal végzik és rotálják ahhoz, hogy az adatvesztéseket és komolyabb üzemzavarokat meg lehessen előzni?

� A mentés és archiválás során előforduló hiányosságokat dokumentálják és a hibák kezelését előre meghatározott szabályok szerint oldják meg?

� A mentések és archiválását visszatölthetőségét rendszeresen ellenőrzik, a teszteléseket dokumentálják?


- 61 -

12.3. BCP/DRP tervek tesztelése

Mennyit ér egy terv? Minden terv annyit ér, amennyit megvalósítanak belőle, tehát a lényeg ott van, hogy az mennyire használható, mennyire naprakész és mennyire ismert az abban érdekelt(ek) által. Például az üzletmenet-folytonosság tervek (BCP) kialakításakor a szevezetnek fel kell mérni a kritikus üzleti folyamatokat, azok üzleti és IT kapcsolatait, a kiszolgáló IT erőforrásokat, és az adott üzleti területtel meg kell határozni az egyes folyamatok ún.”zsugorodási szintjeit” és annak mértékét, majd ezeket követően kell kialakítani az ún. „helyettesítőfolyamatokat”. Ezekkel párhuzamosan létre kell, hozni a BCM szervezetet, amely koordinációs szerepet tölt bel a helyettesítő eljárások menedzselésében. Az üzletmenet-folytonossági tervnek tartalmaznia kell a: � BCM szervezeti hierarchiát és a szereplők neveit / elérhetőségeit,

továbbá a szervezetben elfoglalt felelősöket és felelőségi köröket, � helyettesítő folyamatok indításának - mendzselésének - lezárásának

folyamatát, � helyettesítő folyamatok leírását – folyamatábráját, valamint az egyes

lépések szereplőit és a használt dokumentumokat.

Ha az előbb említett BCP tervek és BCM folyamatok már léteznek és tesztelve voltak, akkor a DRP (katasztrófa elhárítási terv) elkészítése már „könyebb feladat”. A DRP-nek a BCM részeként kell megjelenni és egy esetlegesen bekövetkezett katasztrófahelyzet során szükséges információs – üzleti helyettesítő (ha lehet) – infomatikai és biztonsági folyamatokat kell hogy tartalmazza. Ezen kívük tartalmaznia kell a: � DRP szervezeti struktúrát, a szereplők neveit / elérhetőségeit, továbbá

a szervezetben elfoglalt felelősöket és felelőségi köröket, � mentések és archiválások helyeit, valamint elérhetőségét az egyes

visszatöltési lépéseket, � eszköztartalékolási stratégia hardver elemeit, � riadóztatási folyamat leírását és sorrendjét, � kárfelvételi – visszaállítási – helyreállítási folyamatok teljes körű

leírását, � oktatási - tesztelési és információszolgáltatási tervet.


- 62 -

Mikor használható? Akkor tekinthetjük a terveket használhatónak, ha azok naprakészek és sikeresen teszteltek, majd ezeket követően minden érintett területen jóváhagyásra kerültek.

A vizsgálat során meg kell győződni arról, hogy a(z) � BCP és a DRP tervek működőképességének tesztelése, rendszeresen

és dokumentáltan történik, � kidolgozásra kerültek-e a tesztelési tervek, � tesztelések dokumentáltak-e, illetve a hiányosságok kijavítására a

megfelelő folyamatok milyen szinten működnek, � tesztek eredményét kik, milyen gyakran, milyen módon értékelik, és

ezek alapján megfelelő szinten aktualizálják-e a terveket?

Hogyan teszteljünk? A tesztelésre vonatkozóan külön fejezetet állítottunk össze, amelynek elemei általánosságban az üzletmenet-folytonosságra illetve a rendkívüli helyzetek kezelésére vonatkozó tervek esetében is igazak. Semmiképp se tegyük kockára az éles üzemi környezeteket! A tesztelést „ésszel kell végezni”, leginkább egy nem éles üzemi háttér gépen. A teszt azonban ne olyan legyen, hogy a valós életben nem előforduló, szép fokozatos lekapcsolások és átállások folyamat, hanem egy életszerű hirtelen problémát szimuláló (pl. kapcsolat szakadás, egy gép hirtelen kiesése, egy szoftver hirtelen leállása stb.) probléma rekonstruálása. A környezeti kontrollokkal kapcsolatos kérdések: � Vannak-e megfelelő tűzvédelmi berendezések (pl. füstérzékelő, tűzoltó

készülék vagy tűzoltó rendszer), azokat felszerelték, rendszeresen felülvizsgálják és működtetik?

� Megfelelő kontrollok működnek egyéb környezeti tényezők (vízbetörés, klíma, földrengés stb.) elleni védekezésül?

� A légkondicionálás redundanciája biztosított-e? � Az épület közművezetékei nem veszélyeztetik a számítógépes

helyiségeket (minimális követelmény, hogy legyenek megfelelőzárcsapok a vezetékekben, és ezek pontos helyét is ismernie kell a személyzetnek)?

� Van-e szünetmentes tápellátás és áramfejlesztők, amelyeket rendszeresen felülvizsgálnak?

� Az áramellátás kimaradása esetén a szerverek automatikusan lekapcsolnak-e?

� A hő és füstérzékelők aktiválódása automatikusan riasztanak-e (be van-e kötve a tűzoltósághoz)?


- 63 -

� Az egyéb gépészeti berendezések meghibásodását a jelző rendszerek automatikusan érzékelik és riasztják-e a megfelelő személyeket?

� A gépészeti eszközök elhelyezése nyilvántartott-e, pontosan jelölik-e az eszközök (tűzjelző és tűzoltó berendezések, normál illetve kiegészítőelektromos kapcsolók, vízelzáró csapok, szellőző berendezések, illetve bármely más berendezés, amely vészhelyzetben fontos lehet) helyét?

� A gépészeti eszközök működését tesztelik-e és arról jegyzőkönyvek készülnek-e?

A teszteléssel és felkészültséggel kapcsolatos kérdések: � Az informatikai személyzet a megfelelő képzésben részesült-e, és

ismeri is a rendkívüli helyzetben rá háruló feladatokat, illetve felelősségeket?

� Az informatikai személyzet rendszeres továbbképzésben részesül vészhelyzeti (tűz, víz és egyéb riasztások) teendőiről?

� A rendkívüli helyzetek kezelésével kapcsolatos teendők megfelelően dokumentáltak?

� A hardver / szoftver karbantartásra vonatkozó szabályzatokat és eljárásrendeket kialakították?

12.4. A BCP/DRP tervek aktualizálása

Mit és hogyan aktualizáljunk? Annak ellenére, hogy már az eddigi törvényi előírások is tartalmazták a rendkívüli helyzetkezelési tervek elkészítésének kötelezettségét, sok esetben azok mégis hiányoznak, vagy nem aktualizáltak. Az üzletmenet-folytonossági tervek elkészítését a társaságok szükséges rossznak, illetve számos esetben az informatikai részleg feladatának tekintik. Az ellenőrzések során derült ki, hogy nemhogy a teljes üzleti tevékenységlista, de még a kritikus folyamatok felsorolása sem dokumentált. Így ezeket nem is követhette az üzletet akadályozó kockázatok és az arra vonatkozó helyettesítő tevékenységek átgondolása.

Legtöbb esetben a kritikus folyamatoknak csak töredék részére készülnek el az üzletmenet-folytonossági, illetve a rendkívüli helyzetkezelési tervek, ráadásul azok tesztelése is elmarad. Az új jogszabályok ezért részletesen leírják az erre vonatkozó kötelezettségeket és előírják a „szolgáltatások folytonosságát biztosító tartalék berendezések” illetve egyéb megoldások kialakítását, a biztonsági mentések, arhiválások és egyéb üzletmenet-folytonossági dokumentációk elkészítését.


- 64 -

�� A külső szolgáltatók menedzselése Miért alkalmazunk külsősöket? Amikor egy gazdasági társaság már nehezen bírkózik meg egy adott feladattal vagy valamilyen új tevékenységet kell gyorsan megoldania, illetve ha a nehezen és időigényesen megszerezhető, megfelelő szakmai tudás nincs a társaság birtokában, akkor a legtöbb esetben a speciális szakértelmet külsős vállalkozókkal oldja meg. A fentiek miatt számos intézmény vesz igénybe külső szolgáltatókat kiszervezés (outsourcing) vagy szolgáltatás menedzsment formájában.

A külső szolgáltatók tevékenységeit egyrészt ugyanazon kontrollokkal kell szabályozni, mintha saját alkalmazottak látnák el a feladatokat, de intézményen kívüli szereplőkről lévén szó további kontrollokat is életbe kell léptetni.

Hogyan felügyeljük a külső szolgáltatók teljesítményét? Az ellenőrzött szervezetnek tekintetbe kell vennie a külső ellenőrzés igényeit, és ezt a szolgáltatóval kötött szerződésbe bele is kell foglalnia. Ugyanis ellenőrzés során előfordulhat, hogy arról kell megbizonyosodni, hogy a külső szolgáltató által nyújtott adatok, kalkulációk nem tartalmaznak lényeges hibát, és ezt a bizonyosságot általában a szolgáltatónál szerezheti meg az ellenőr (közvetlen ellenőrzéssel). A külső szolgáltatónak továbbá ugyanúgy biztosítania kell a megfelelőellenőrzési nyomvonalat, hogy a vezetés és a külső ellenőrzés kellően felügyelhesse tevékenységét. A szerződésre vonatkozó kérdések a következők: � Milyen teljesítmény- vagy szolgáltatási szintet kell teljesítenie? � Milyen biztonsági követelményeket várunk el? � Ki milyen adat felett rendelkezik, mi az adattulajdonlás meghatározása? � Ki hogyan férhet az adatokhoz, milyen a szervezeti hierarchia?

A szolgáltatások meghatározása érdekében a felső vezetésnek meg kell határoznia egy olyan megfelelő keretrendszert, amely segíti a formális szolgáltatási-szint megállapodások (SLA-k) kidolgozását és meghatározza azok minimális tartalmát (rendelkezésre állás, megbízhatóság, teljesítmény, kapacitás, szolgáltatási díjak, változáskezelés stb.). A felhasználóknak és az informatikai részlegnek írásbeli megállapodást kell kötniük, amelyben mennyiségi és minőségi vonatkozásban is meg kell határozniuk a szolgáltatási szintet.


- 65 -

Megfelelő eljárások révén gondoskodni kell arról, hogy az érintett felek közötti kapcsolatokból (pl. titoktartási megállapodásokból) eredőkötelezettségek teljesítésének módja és felelőssége megfelelően meghatározásra kerüljön, koordinálva legyen és tájékoztatást kapjon arról minden érintett osztály. Az informatikai részleg vezetésének ki kell neveznie egy szolgáltatási szint felelőst, akinek figyelemmel kell kísérnie a meghatározott szolgáltatási kritériumok teljesítését. A vezetésnek rendszeres időközönként felül kell vizsgálnia a szolgáltatási-szint megállapodásokat, valamint meg kell újítania a külső szolgáltatókkal megkötött szerződéseket.

Milyen kockázatai vannak a kiszervezésnek? A legtöbb esetben kényelmi szempontból (ha már annyit bajlódtunk a kiválasztással, a feladatok meghatározásával, a szerződéskötéssel, a szolgáltatási szintek mérésével és betartatásával stb.) úgy gondolják a megbízók, hogy a külsősökkel minden rendben van és ezzel semmiféle kontrollt nem gyakorolnak. A feladatok megállnak a havi teljesítésigazolások aláírásával és a számlák kifizetésével. Azonban az összes (sőt jellegéből adódóan még több) biztonsági kockázat fennáll, ami a belsős feladatvégzés esetén (szabályozás, jogosultságkezelés, naplózás, incidenskezelés stb). Így a külső szolgáltatók alkalmazásakor fellépőkockázat, a kiszolgáltatottság és a külső szolgáltató feladatvégzésének fennakadásakor fellépő üzletmenet folytonosság a leggyakrabban előforduló probléma.

13.1. Szerződéskötés

Hogyan menedzseljük a külsős szolgáltatókat? A vezetésnek gondoskodnia kell arról, hogy a külső szolgáltatók által biztosított szolgáltatások köre pontosan legyen meghatározva és a szállítókkal kialakított technikai és szervezeti kapcsolat megfelelően legyen dokumentálva. A vezetésnek megfelelő eljárások keretében gondoskodnia kell arról, hogy a külső szolgáltatókkal kialakított kapcsolatokat olyan írásbeli szerződések szabályozzák, amelyeket még a munkák megkezdése előtt hivatalosan megkötöttek. Ettől eltérni rendkívüli helyzet esetében lehet, melyre a vonatkozó szabályzat térjen ki!A vezetésnek gondoskodnia kell arról, hogy a külső szolgáltatói kapcsolatok esetében olyan biztonsági megállapodások (pl. titoktartási megállapodások) kerüljenek kidolgozásra és megkötésre, amelyek megfelelnek az általános


- 66 -

üzleti normáknak, valamint a jogi és szabályozási követelményeknek, az anyagi, pénzügyi felelősségre vonatkozó követelményeket is beleértve. A vezetésnek gondoskodnia kell a külső szolgáltatók által nyújtott szolgáltatások teljesítésének folyamatos figyeléséről a szerződésben foglaltak betartásának ellenőrzése céljából.

Mit tartalmazzon a szerződés? A külsős szállítókkal szembeni elvárásokat természetesen szerződésbe szokták foglalni. A szerződéssel kapcsolatban az adott intézménynél megszokott szerződési formák lépnek életbe, ezért fontos megvizsgálni, hogy van-e egyáltalán belső előírás a szerződéskötések formai, tartalmi, jóváhagyási, számonkérési szabályaira (szabályozás). Mivel már a jól ismert közmondás is megállapította, hogy „az ördög mindig a részletekben rejlik”, ezért érdemes mindig átnézni, a szerződés tevékenységre vonatkozó konkrét elemeit, IT-s szerződések esetén a hatályos belső informatikai ökölszabályok érvényesülését a külsőszolgáltatóra (dokumentálás, beszámolási kötelezettség, titoktartás, jogosultságkezelés, fejlesztés, változáskezelés, rendkívüli-helyzet kezelés stb.). Külsősök esetén mindig probléma, hogy a szankcionálás hogyan is valósuljon meg, amelyre kézenfekvő megoldás a szolgáltatási szintek definiálása és az azokhoz történő szankciók rögzítése.

13.2. Szolgáltatási szint mérés

Mit kérjünk számon? Legfontosabb az, hogy legyen mit mérni, és ha az már biztosított, akkor megegyező mérési elvek szerint mérjenek a felek. A szolgáltatási vagy rendszertámogatási szerződések vizsgálatakor ki kell térni a: � rendelkezésreállás általános feltételeinek, � hibabejelentés módjának és formájának, illetve dokumentumainak

egyértelmű leírásának, � hibajavítások vállalt idejének és � szolgáltatási szint méréséhez szükséges adatoknak meglétének

ellenőrzésére. A számonkérhetőség egyik alapfeltétele (újra) a dokumentációs környezet megléte. A hiba bejelentésétől a hiba lezárásáig a külső félnek, valamennyi lépést dokumentálnia kell, és ezt a havi elszámoláskor kötelező jelleggel meg kell küldeni a megrendelő szervezet részére. Természetesen ez vonatkozik az adott szervezet IT munkatársaira is.


- 67 -

Az összesített hibajegyzék, a teljesítési igazolás mellékletelként ajánlott, hogy szerepeljen. A hibák kategórizálását, súlyozását, a hozzá rendelt hibajavítási időmeghatározását ajánlatos minden rendszertámogatási szerződéseben rögzíteni.

Hogyan lehet mérni? Legfontosabb, hogy a hibabejelentési folyamatban található egyes lépések között eltelt idő, a változás leírása dokumentált és mérhető legyen. Ha ezek a feltételek adottak, akkor a szolgáltatótól kapott részletes stasztikát kell összevetni a saját magunk által rögzített adatokkal. A szolgáltatási szint mérését a hibakezelés ideje mellett a � hibák javításának minőségével (visszatérő hibák statisztikája), � elégedettségi szint mérésének (kiszolgálás minősége) eredményeivel

is ki lehet egészíteni az általános kiértékelést.

�� A naplózás ellenőrzése

Miért van szükség a naplózásra? Nagyobb informatikai rendszerek (nagyobb társaságok) esetében szinte nincs olyan, ahol ne lenne valamilyen naplózás, mivel a rendszerek működtetése, az üzemelési, működési hibák keresése e nélkül elképzelhetetlen. Számos esetben előfordul, hogy egy biztonsági incidens, ügyfél panasz vagy szoftverhiba miatt utólag meg kell találnunk, hogy ki, mikor és milyen mértékben változtatott meg egy értéket az adatbázisban, egy paramétert az operációs rendszerben, egy eljárást a szoftverben, vagy éppen csak mikor tekintette meg olvasási szinten a munkájához nem feltétlen szükséges adatokat. Ezek a feladatok csak akkor végezhetők el, ha a menedzserek, szakemberek, biztonsági munkatársak, illetve auditorok által fontosnak tartott változások és események nyomai eltárolásra kerülnek. Ez az alapja a hibák kijavításának, a felelősök számonkérhetőségének. Amellett, hogy a kiritikus események nyomainak eltárolása szakmai „ökölszabály” a pénzügyi intézmények vonatkozásában például ez jogszabályi kötelezettség is. Számukra előírás, hogy a biztonsági kockázatelemzés eredményének értékelése alapján a biztonsági kockázattal arányos módon, gondoskodni kell olyan biztonsági környezetről, amely az informatikai rendszer működése szempontjából kritikus folyamatok eseményeit naplózza és alkalmas e naplózás rendszeres (esetleg önműködő) és érdemi értékelésére, illetve lehetőséget nyújt a nem rendszeres események kezelésére.


- 68 -

Tulajdonképpen ez a megfogalmazás az, amit minden informatikai biztonsággal foglalkozó menedzsernek meg kell valósítania. Már az informatikai beszerzések során, figyelembe kell venni a megfelelő„biztonsági környezet” kialakításának szempontjait, amelynek összhangban kell lennie az előzetesen lefolytatott kockázatelemzéssel. Megfelelő eljárások révén gondoskodni kell arról, hogy az üzemeltetési naplókban rögzítésre kerüljenek azok a szükséges kronológiai információk, amelyek lehetővé teszik az adatfeldolgozási folyamatok, a feldolgozáshoz kapcsolódó és azt segítő egyéb tevékenységek idősorrendjének rekonstruálását, áttekintését és kivizsgálását. Gondoskodni kell továbbá a kritikus rendszerek eseményeinek naplózásáról, a naplóállományok rendszeres ellenőrzéséről és mentéséről. A fejlesztési életciklus módszertanban (változáskezelés) is elő kell írni olyan eljárások és módszerek alkalmazását az új informatikai rendszer-fejlesztési projektek specifikációjának kidolgozásakor, amelyek gondoskodnak a szükséges naplózásról. A vezetésnek gondoskodnia kell arról, hogy a meglévő rendszerek jelentősebb módosítása esetén is az új rendszerek kifejlesztésére vonatkozó fejlesztési előírások szerint kelljen eljárni, amelyben szerepelnie kell a biztonsági (és így a naplózási) funkcióknak is. A fejlesztés, illetve módosítás alatt álló rendszerek alapvető biztonsági és belső ellenőrzési aspektusait a rendszer koncepcionális szintűmegtervezésével egy időben kell meghatározni annak érdekében, hogy a biztonsági szempontokat a tervezés lehető legkorábbi szakaszában be lehessen építeni. A rendszerek által készített naplók biztonsági szempontú elemzését folyamatosan, dokumentált módon kell végezni. Több rendszer, vagy nagyobb szervezet esetén a naplóelemzés megfelelő informatikai támogatásának biztosítása szinte elengedhetetlen a megfelelő színvonalú és költséghatékony munkához. Az intézményeknek ki kell alakítania azokat a megfelelő eljárásokat, amelyek biztosítják (ahol szükséges), hogy az alkalmazási programok olyan funkciókat is tartalmazzanak, amelyek rutinszerűen ellenőrzik a szoftver által elvégzett feladatokat, segítve ezzel az adatok sértetlenségének megőrzését, és amelyek gondoskodnak az adatok épségének helyreállításáról a tranzakciók visszagörgetése, illetve más eszközök révén. Figyelmet kell fordítani a rendszer-szoftverek paramétereinek megfelelőbeállítására és aktualizálására (is).


- 69 -

14.1. Naplózási koncepció

Milyen elveket kövessünk? A legkézenfekvőbb megoldás az lehetne, ha gondolkodás nélkül a „naplózzunk mindent” elvet alkalmazva, a lehetséges összes tranzakció és változás nyomait eltárolnánk, azonban ez bizonyos szervezeti méret felett fizikai képtelenség. A másik véglet (amely sajnos a gyakorlatban sokszor előfordul), hogy semmilyen naplót nem készítenek (vagy nem mentenek) az „úgysem használjuk azt semmire” elv alapján. Ez utóbbi esetben azonban semmi esély az illetéktelen vagy véletlen módosítások és visszaélések utólagos felderítésére és számonkérésére. Annak érdekében, hogy a rendelkezésre álló erőforrások ésszerűfelhasználásával, de a kockázatok alapján szükségesnek ítélt biztonsági szint megtartásával a naplóállományok biztonsági célú, érdemi értékelése megvalósulhasson, naplózási koncepciót kell kidolgozni. A naplózási koncepció alapján a szükséges biztonsági szabályozások kidolgozhatók, a biztonsági beállítások elvégezhetők és ellenőrizhetők, ezért a szükséges napló állományok gyűjtése és rendszeres értékelése megtörténhet. Ez az a dokumentum, amelyben célszerű a társaság szintjén eldönteni, hogy az általunk létrehozott kockázati kategóriák esetében (pl.: kritikus, magas kockázatú, alacsony kockázatú), milyen eseményeket kell naplózni. Könnyen belátható, hogy egy kritikus rendszernél jóval több esemény nyomát kell rögzíteni és utólag visszekereshetővé tenni, mint egy alacsony kockázatúnál. Ezek a döntések jelentősen módosíthatják a megfelelő naplózási rendszerre (kialakítására és üzemeltetésére) költendő összegek mértékét. Egy naplózási koncepciótól alaszinten elvárt, hogy:� a szervezet informatikai kockázatértékelésére épüljön, � legyen összhangban az informatika biztonsági politikával, az

informatika biztonsági szabályzattal, valamint a rendszerszintűbiztonsági szabályzatokkal (szabályozás),

� meghatározza a naplóállományok mentési és archiválási rendjének elveit, azok megőrzési idejével együtt (mentések, archiválások),

� szervezeti szinten kijelölje a fő felelősét a naplózási és naplófájl értékelési feladatoknak (dokumentálási szabályok, formanyomtatványok a felelősök kijelölésére stb.),

� rendelkezzen a napló állományok használatáról, a visszatölthetőség rendszeres ellenőrzéséről (tesztelés),

� tartalmazzon előírásokat az új informatikai rendszer-fejlesztési projektek specifikációjának kidolgozásához a szükséges naplózási funkciókról történő gondoskodásról (tervezés).


- 70 -

� az előírt naplózási és naplófájl elemzési feladatok a gyakorlatban kerüljenek végrehajtásra, valamint azok elvégzése és számonkérése rendszeresen kerüljön ellenőrzésre (végrehajtás, ellenőrzés),

� a napló állományok elemzésének elvégzéséhez szükséges automatizmusok és eszközök álljanak rendelkezésre (támogatás).

Nagyobb informatikai rendszerek esetében az informatikai támogatás elengedhetetlen, a naplózó és elemző rendszerrel szemben támasztott követelmények meghatározása is része lehet a naplózási koncepciónak.

14.2. Naplózási beállítások

Mit, hogyan naplózzunk (milyen eseményeknek őrizzük meg a nyomát)? Azokat az üzletmenet szempontjából fontos, kritikus eseményeket fontos naplózni, amelyek megtörténtét, módosítását (törlését) utólagosan is nyomonkövethetővé, számonkérhetővé kell tenni. A naplózási koncepcióban pontosan meghatározásra kerültek azok az elvek, amelyeket adott rendszer szintjén naplózni kell. A naplózást több szinten kell végezni az operációs rendszer, az adatbáziskezelő és az alkalmazás szintjén, mivel a kritikus (lényeges) informatikai események is különböző szinteken történnek. Az operációs rendszer szinten kell naplózni (log-olni) azokat az eseményeket, amelyek csak ezen a szinten zajlanak. Ilyenek például a kritikus rendszerfájlok létrehozása, módosítása és törtlése (Windows esetében ezeken felül a „Registry” módosítása is). A jogosultsági rendszert érintő változtatások, jogosultsági csoportok létrehozása és módosítása, a felhasználók létrehozása és módosítása, valamint a csoportokhoz rendelése stb. Szintén itt kell naplózni azokat a konfigurációs beállításokat, amelyek befolyásolják az adott operációsrendszer, vagy a rá telepített alkalmazás működését (beleértve az adatbázis kezelők telepítését és operációs rendszer szintű konfigurálását). A hozzáférést biztosító alkalmazások indításának és körülményeinek naplózása szintén kritikus lehet pl.: telnet, snmp stb. Természetesen itt is igaz, hogy a kockázatértékelésünknek megfelelően, másra kell figyeni és mást kell naplózni egy kritikus rendszer esetében (jóval több mindent és mélyebben) és mást egy alacson kockázatú rendszer esetében (csak a fő eseményeket és jóval kevesebb adattal). Az adatbázis szinten kell naplózni azokat az eseményeket, amelyek csak ezen a szinten zajlanak. Ilyenek például a közvetlen adatbázis hozzáférések (ki- és bejelentkezések, ki és mikor), az adatbázisban történt közvetlen változtatásokat (ki, mikor, mit, miről, mire), az adatszerkezet módosításokat stb.


- 71 -

A nem közvetlen hozzáféréseket, amelyek például az alkalmazáson keresztül módosítanak egy-egy adatot, azt az alkalmazás szintjén kell naplózni. A naplózáshoz maga az adatbázis-kezelő rendszer is adhat támogatást, de ez a legtöbb esetben elég kevés, ezért célszerű ilyen esetekben külső szállító által („third party”) készített szoftvereket alkalmazni. Az adatszerkezet módosításának naplózása erősen kapcsolódik a változáskezelés kontrolljaihoz is. Az alkalmazás szinten kell naplózni azokat az eseményeket, amelyek csak ezen a szinten zajlanak. Ilyenek az alkalmazásba történő a be és kijelentkezés, valamint a modulok indítása (ki, mikor, melyik modult) és a sikertelen próbálkozásokat (milyen felhasználói névvel, mikor). A rendszer kritikusságától függően naplózni kell a kritikus tranzakciókat (ki, mikor, mit változtatott, miről, mire), a paraméterek beállítását és megváltoztatásukat (ki, mikor, melyik paramétert, miről, mire). Minden alkalmazási rendszerben kritikus információ a felhasználók hozzáadása, módosítása és törlése (ki, mikor, melyik felhasználót, miről, mire) és a szoftverek módosítása (ki, mikor, melyik modult).

A következőben adunk egy felsorolást, hogy mi kerüljön ténylegesen a naplókba. Ezeket célszerű végiggondolni egy-egy adott rendszerelem esetében, a rendszerelem kritikusságának a figyelembe vétele mellett. A naplóállományoknak általánosságban tartalmazniuk kell: � a naplózás elindítását, leállítását és újraindítását, � a naplózási paraméterek megváltoztatását a naplóállomány törlését, � a naplózás tárolási hibája miatt végzett tevékenységeket,� a rendszer leállítását és újraindítását,� a rendszereseményeket, rendszerhibákat, rendszerkieséseket � a felhasználók hozzáadását, módosítását és törlését, felfüggesztését és

ismételt engedélyezését, � a felhasználók sikeres és sikertelen bejelentkezéseit, � a felhasználói csoportok adminisztrálását, � a programindításokat, leállításokat � a hibás belépéseket, � az állományok létrehozását, módosítását, törlését és a biztonsági

attribútumok változtatását, � a tranzakciók végrehajtását, � az alkalmazások hibajelentéseit, � a kommunikációs hibákat, � a nem engedélyezett kommunikációs portokat, � a sérülékenység-monitoring funkciókat, � a működtető rendszerek környezetében bekövetkező

eseményeketesemények.


- 72 -

A fentieket tehát ellenőrizni kell és lehetővé kell tenni, hogy a naplóbejegyzések szűrését az alábbi szabályok szerint: dátum és idő, felhasználó név, bejegyzés típusa, bejegyzés forrása, a sikeressége vagy sikertelensége naplózásra kerüljön! Az IT alkalmazást használók tevékenysége naplózott kell, hogy legyen, mivel a napló állományok képezik a biztonsági vizsgálatok egyik bizonyítékait. A napló állományok kötelezően tartalmazzák a felhasználó azonosítását és a rendszerbe történt be- és kijelentkezés idejét, az egyes munkavégzések (kísérletek) nyomait.

14.3 Naplóállomány elemzések Miért kell folyamatosan elemezni (vizsgálni) a naplóállományokat? A rendszerek normális működését veszélyeztető események bekövetkezése előtt a legtöbb esetben történnek olyan események (figyelmeztetések), amelyek a probléma bekövetkezését előre jelzik. Ez a megállapítás a rendszerek biztonságát fenyegető eseményekre is igaz (nem csak az üzemeletetésre vonatkozóan). Tehát a naplók rendszeres elemzése ad lehetőséget a prevencióra. A rendszerek által készített naplók és a naplózás konfigurálása minden esetben különböző, így általános program sem létezik arra, hogy mit és hogyan kell figyelni a naplókban. Ezért a folyamatos naplóelemzések és a bekövetkezett problémák miatti naplózási beállítás módosítások egy iterációs folyamat keretében fogják egyre jobban megközelíteni az elvárt biztonsági szintet és megelőzni a problémás események bekövetkezését. Mindemellett ezt az iterációs folyamatot az elszámoltathatóság érdekében is folytatni kell, hiszen ha nem került a naplókba, hogy ki hajtott végre bizonyos eseményeket, akkor a felelősök megtalálása is kérdésesé vállhat.

Kinek (kiknek) kell végrehajtani a naplók elemzését? Az üzemeltetési (működési problémákat jelző) események folyamatos vizsgálata az adott informatikai rendszer rendszergazdáinak a feladata és ez általában működni is szokott összetettebb rendszerek esetében. A rendszer informatikai biztonságát veszélyeztető események naplóinak elemzése azonban már egy erre a feladatra elkülönített személy (szervezet) feladata kell, hogy legyen. Ezt a személyt szokták a szakirodalomban indformatikai biztonsági felelősnek nevezni. Itt kerül elő a klasszikus kérdés, „Ki őrzi az őrzőket?”. A biztonsági célú naplókba kerül a rendszergazdák által végrehajtott tevékenységek nyoma is, így ez használható fel a rendszergazdák ellenőrzésére is és egy informatikai ellenőr is ezeket a naplókat vizsgálja akkor, amikor a rendszergazdák tevékenységének megfelelőségét kell megítélnie. Természetesen ezt csak akkor teheti, ha ezek a naplók léteznek.


- 73 -

Milyen követelmények vannak a biztonsági célú naplókra vonatkozóan? Ezen naplófájlokat csak a biztonsági terület erre kijelölt munkatársai által (biztonsági felelős) lehessen törölni, illetve azok működését leállítani és elindítani, vagy ezeknek a rendszergazda által sem módosítható nyomát kell rögzíteni. Az ilyen eseményeket, ha nem a biztonsági felelős végezte célszerű minden esetben megvizsgálni. A naplófájlokban történő keresésre és azok érdemi értékelésére szabályokat kell hozni (ezek jó része a naplózási koncepcióban meghatározzásra kerülnek/tek) és szükség esetén célalkalmazásokat kell üzembe helyezni. A naplóállományok gyűjtése, tárolása lehetőleg az érintett alkalmazást futtató rendszertől elkülönített „naplógyűjtő” rendszeren (szerveren) történjen. A biztonsági naplóállományokat rendszeresen ellenőrizni és archiválni kell, a megőrzési határidőket definiálni kell (koncepció), a naplóállományok kezelését dokumentálni kell. Célszerű meghatározni, hogy mely eseményeket kell jegyzőkönyvezni és mely eseményeket és, hogyan kell szankcionálni.

A naplózási koncepció már tartalmazza, hogy milyen eseménynaplózó és ellenőrző rendszerek kerülnek megvalósításra. Ezen belül viszont fontos, általános követelmények biztosítani a személyzet felelősségre vonhatóságát tevékenységéért az eseménynapló megőrzésén keresztül. A napló fájl feldolgozás gyakorisága: az erőforrásaihoz történő illetéktelen, vagy szokatlan hozzáférési kísérletek vonatkozásában folyamatos felügyelőés riasztó eszközöket kell biztosítani, hogy képes legyen időben reagálni ezekre. Ezen felül a szabályozásban előírt rendszeres napló fájl kiértékelésekről is gondoskodni kell. A napló fájl megőrzési időtartamát meg kell határozni, a naplóadatokat rendszeresen menteni és archiválni szükséges. A naplófájl védelme érdekében a naplózott adatállománynak tartalmaznia kell a naplózott esemény bekövetkezésének dátumát és pontos idejét, az esemény követhetőségéhez, rekonstruálásához szükséges adatokat, az események kiváltásában közreműködő felhasználó vagy más érintett személy nevét. A naplózott adatállomány minden bejegyzését védeni kell a módosítástól, illetve biztosítani kell, hogy a napló tartalmához csak arra feljogosított személy, elsősorban a független rendszervizsgáló férhessen hozzá. A napló kezelését olyan módon kell megoldani, hogy kizárható legyen a napló megsemmisítése, a napló bejegyzéseinek törlése, módosítása, a bejegyzések sorrendjének bármilyen módon történő megváltoztatása.


- 74 -

�� Oktatás és IT biztonság-tudatosságMiért tartjuk fontosnak az IT biztonság- tudatosság alapú oktatást? Az emberek többsége, amikor megvásárol egy híradástechnikai vagy háztartási berendezést, a kicsomagolást követően máris megkezdi a „Használati utasításban” (dokumentált oktatási anyag) leírtak olvasását, megértését és elsajátítását. Ezt követően a „Próbáljuk meg!” felkiáltással a tesztelési szakasz következik, amely során a tanultakat a tesztelési folyamat során feleleveníti a vásárló. Ha mindez sikeresen megtörtént, akkor nem marad más hátra, mint az élesbe állítást követően az adott készülék pozitív szolgáltatásait nap, mint nap használni. Az oktatás – ahogy a fenti példában is közvetlen módon történt – elsősorban a gyakorlati alkalmazás során (közvetlen formában) válik hatékonnyá. Ahhoz, hogy egy új munkatárs hatékonyan és biztonságosan tudja használni a munkájához szükséges informatikai alkalmazást, vagy egy újonnan bevezetendő alkalmazás használtára megtanítsuk a munkatársakat, oktatásra van szükség. A magas szintű és hatékonyan megszervezett, majd levezetett oktatás többek között: � megteremti a biztonságtudatosság alapjait, � hozzásegíti a munkatársakat a hatékony munkavégzéshez, � támogatja a tudatos munkavégzést és elősegíti az új alkalmazáshoz való

pozitív hozzáállást, � bemutatja az alkalmazás előnyeit és figyelmeztet a tipikus hibákra, � felhívja a figyelmet az adott alkalmazás fontosságára és gyakorlati

példákon keresztül, lerövidíti a betanulási időszakot, � a későbbiekben kockázatcsökkentő hatást eredményez.

Miért hasznos az IT biztonság- tudatosság oktatása?Az egyes cégek eltérő biztonsági, informatikai szinten és szabályzatok alapján működnek, így az új belépők oktatásakor minden esetben elkerülhetetlen az IT biztonság-tudatosság képzése, és egységes szintre való emelése. Már a munkába állás során meg kell győződni az új munkatárs általános informatikai tudásáról, biztonság tudatossági szintjéről valamint az eddig használt IT rendszerismeretek szintjéről. A beléptetést követően ezen információk birtokában kell megkezdeni a képzést, továbbképzést vagy átképzést. A megfelelő szintű, és az adott szervezeti kultúrához idomuló IT biztonság-tudatossági szint eléréséhez - az új belépőknek- az alábbi oktatásokon kell részt venni, és az ezeken való részvételt, elfogadást aláírással igazolni: � Az adott szervezet legfontosabb szabályzatainak oktatása (pl.

compliance, biztonsági, jelszó és azonosító használati, internet és elektronikus levelezés használati, üzleti és titokvédelmi, személyes


- 75 -

adatok védelmének szabályzata stb.). Ezen oktatási szakaszt követően a vizsgáztatás erősen ajánlott.

� A szervezetben működő alaprendszerek (core rendszerek) és azok működésének oktatása az egyes területeken elhelyezkedő munkatársak részére. Az oktatás ezen ciklusában, az azonos területen dolgozó munkatársakat ajánlott egy kurzusban és célirányosan oktatni. Ehhez szükséges egy jól megszervezett, a hétköznapok során használt munkafolyamatokon alapuló oktatói környezet, esetleg szimulátor. Az alaprendszerek oktatásában az internet biztonságos használatának (SSL, adathalászat veszélyei, károkozók, kéretlen levelek stb.), döntéstámogató - sok esetben levelezőrendszeren alapuló - alkalmazások használatának oktatására is szükséges kitérni.

� Az oktatás során az incidenkezelés - üzletmenet folytonosság - katasztrófa kezelés tematikájával, adott szervezeten belüli kezelési módokkal, az adott munkavállalóra vonatkozó feladatokkal is meg kell ismertetni az oktatásban szereplőket. Ezek elsajátítása a magas szinten történő ügyfélkiszolgálás során, illetve a rendszerkiesések során tapasztalható kellemetlenségek leküzdésének professzionális kivitelezésében támogatja a munkatársakat.

� Vannak olyan esetek, amikor az oktatások már késve, a termelésben való bekapcsolódást követő hónapokban történnek meg. Ez helytelen. Tekintettel arra, hogy az új munkatársak sok esetben az ország több pontján, nem egy időben és egy helyre lépnek be, így az ún. „E-learning” keretrendszer nyújthat segítséget a probléma leküzdésére. A minimális szinten kiadott oktatói rendszerhozzáférés segítségével az E-learning keretrendszer tananyagánal elsajátításával, az előre meghatározott munkakörhöz szükséges oktatási anyag elvégzése, majd ebből való vizsgáztatás előre tervezhetővé válik mindenki számára. Az E-learning rendszerekben az oktatási anyag bemutatását, az alaprendszerben való műveletek végrehajtását optimalizálják, de nem utolsó sorban kontrollálhatóvá és mérhetővé teszik az oktatási szakaszok eredményeit mindenki számára.

Mikor van szükség oktatásra? Átfogó és sok esetben nagy tömegeket érintő oktatásra van szükség például: � az újonnan fejlesztett és bevezetett rendszerek és alkalmazások esetén, � a megváltozott és több szereplőt érintő BCM és DRP folyamatokban

történő változás, � a több (szervezeti) egységet érintő összevonás vagy szétválás, valamint � a jelentős mértékben megváltozott jogosultsági környezet vagy

csoportszerep esetében.


- 76 -

Mit ellenőrizzünk az oktatásokkal kapcsolatban? A feladat és felelősség elhatárolás témakörénél már említettük, hogy a legfontosabb a megfelelő szakértelemmel rendelkező emberi erőforrás rendelkezésre állása. Ha nincs, aki működtesse az eszközöket - lehetnek azok akár a legkorszerűbbek is –, akkor azok nem fognak működni, illetve ha nem kontrolláljuk, megfelelően, akkor a legmodernebb automatizmus is csak magas kockázattal fog működni (legfontosabb a megfelelőkontrollkörnyezet!). Ahhoz, hogy a rendelkezésre álló eszközeinkből a maximumot tudjuk kinyerni, jól képzett szakember gárdára van szükség, amelyet csak a folyamatos, naprakész tudás megszerzését biztosító, rendszeres oktatással érhetünk el. A hatékonyság (csak a működéshez szükséges minimális tudás legyen jelen) pedig csak úgy biztosítható, ha a folyamatok végiggondolásával a megfelelő szabályozást és dokumentálást biztosítjuk. Az éves tervek kidolgozásakor javasolt tervet készíteni az informatikai oktatásokra is („A tudás pénzbe kerül, de a tudatlanság is drága!”). Informatikai ellenőrzéskor tehát érdemes rákérdezni: � az oktatási igények kezelésének folyamatára, felelőseire,

szabályozására, gyakorlatára, � a képzési tervek létére és tartalmára, � a belső képzések minőségére és automatizáltságára, � az új belépőknek tartandó képzések tartalmára és gyakorlatára, � a pozíciók betöltéséhez szükséges informatikai ismeretek előírására, � a rendszeres felfrissítő informatikai képzések meglétére, valamint � az IT biztonsági oktatások meglétére és dokumentálására.

Hogyan érhető el a vállalati szintű biztonság-tudatosság? Minden dolgozónak részt kell vennie egy az informatikai biztonság alapelveit – munkakörének megfelelő szinten – ismertető tanfolyamon, amelyet rendszeres jelleggel meg kell tartani. Az ilyen oktatáson belül kiemelt figyelmet kell fordítani a biztonsági kérdések tudatosítására és a rendkívüli események kezelésére.

Csak az informatikusoknak van szüksége IT képzésre?Mai világunkban az informatikai és az IT biztonsági tudás megszerzése és folyamatos karbantartása nem csak az informatikai eszközök üzemeltetésével és karbantartásával foglalkozók számára fontos. Minden dolgozónak a feladat ellátásához szükséges informatikai ismeretekkel kell rendelkeznie.


- 77 -

A munkakörökhöz szükséges informatikai képzettség és gyakorlat meghatározását belső szabályzatban (SZMSZ, munkaköri leírások stb.) célszerű meghatározni.

�� További IT biztonsági kontrollok Mire figyeljünk a biztonságos adatátvitellel kapcsolatban? A vezetésnek gondoskodnia kell a bizalmas információk adattovábbítás és szállítás közben történő megvédéséről, a jogtalan hozzáférések, a módosítások és a téves kézbesítések megakadályozásáról. Az Interneten, illetve más nyilvános hálózatokon keresztül történőadattovábbítások kapcsán a vezetésnek ki kell alakítania olyan eljárásokat, szabályokat, illetve számítástechnikai, hálózati protokollokat, amelyek gondoskodnak a bizalmas üzenetek sértetlenségének, bizalmasságának és letagadhatatlanságának megőrzéséről. A szervezethez kívülről érkező információk hitelességét és sértetlenségét megfelelő módon ellenőrizni kell, bármilyen kritikus fontosságú lépés megtétele előtt. Az adatok továbbításakor gondoskodni kell a megfelelőtitkosításról, illetve a biztonságos protokollok (https, ssl, ssh stb.) alkalmazásáról.

Figyelembe véve azt a tényt, hogy egyre kevésbé lehet támaszkodni a hagyományos értelemben vett földrajzi és időbeli határokra, a vezetésnek megfelelő eljárásokat és szabályokat kell kialakítania a bizalmas és kritikus elektronikus tranzakciók sértetlenségének és hitelességének biztosítása érdekében. Minden külső hálózattal kapcsolatos információ-áramlást ellenőrzés alatt kell tartani mindkét irányban. Az Internethez, illetve más nyilvános hálózatokhoz történő kapcsolódás vonatkozásában megfelelővédelmet (pl. tűzfal, behatolás védelmi eszköz stb.) kell kialakítani a belsőerőforrásokhoz történő jogtalan hozzáférések, illetve a szolgáltatások ellehetetlenítését célzó támadások (pl. Denial of Service) megakadályozása érdekében.

Milyen kontroll van a vírusvédelemre? A rossz szándékú szoftverek vonatkozásában, mint amilyenek a számítógépes vírusok vagy a “trójai programok”, a vezetésnek megfelelőmegelőző, észlelési és korrekciós mechanizmusokat, válaszlépéseket és jelentési eljárásokat kell kidolgoznia. A vezetésnek gondoskodnia kell arról, hogy a szervezet egészére kiterjedően megfelelő eljárások kerüljenek kialakításra a számítógépes vírusokkal szembeni védelem érdekében. A fenti eljárásoknak a vírusvédelemre, a vírusok felderítésére, a megfelelőválaszlépésekre és a jelentési kötelezettségekre egyaránt ki kell terjedniük.


- 78 -

Olyan szabályokat és szabályzatokat kell kialakítani és bevezetni, amelyek korlátozzák a személyes és az engedély nélküli szoftverek használatát. A szervezetnek, mindig az aktuális – kitesztelt és legfrissebb vírusmintával, valamint keresőmotorral rendelkező víruskereső és vírusirtó szoftvereket kell használnia minden olyan munkaállomáson és szerveren, amelyek alkalmasak vírusok futtatására. Az informatikai részleg vezetésének rendszeres időközönként ellenőriznie kell, hogy a szervezet személyi számítógépeire nem lettek-e telepítve engedély nélkül szoftverek.

Mit vizsgáljunk a határvédelmi eszközök esetén? A tűzfalak és behatolásvédelmi eszközök (pl. IDS-Intrusion Detection System vagy IPS-Intrusion Prevention System) egyre nagyobb szerepet töltenek be a logika védelmi vonalak megerősítésében. Vizsgálni kell a tevezés, a kivitelezés, valamint a döntés folyamatát, továbbá azt, hogy milyen kockázatértékelési alapokon nyugszik az adott eszközök elhelyezése. Érdemes továbbá tájékozódni arról, hogy ez elmúlt időszakban milyen változások, súlypont áthelyezések, bővítések történtek a határvédelmi eszközök tekintetében, és ezen változásokat milyen események indukálták.

Mire érdemes figyelni a fizikai védelemmel kapcsolatban? Bár nem kimondottan informatika ellenőrzési feladat, azonban sokszor (géptermek, operátori szobák stb.) nem lehet figyelmen kívül hagyni, a fizikai hozzáférési lehetőségek kockázatait, az alkalmazott fizikai hozzáférési kontrollok működését. Megfelelő intézkedéseket kell hozni az informatikai eszközök fizikai védelme és az eszközökhöz történő hozzáférés ellenőrzése céljából, beleértve az informatikai eszközök telephelyen kívül történő felhasználását is. A fizikai biztonság és hozzáférés ellenőrzését a rendszer elemeinek összekapcsolásához használt kábelezési egységekre, a segítőszolgáltatásokra (pl.: elektromos áramforrások), a mentésekhez használt adathordozókra és a rendszer működéséhez szükséges minden egyéb elemre ki kell terjeszteni. Hozzáférési jogot csak az arra felhatalmazott személyek kaphatnak. Megfelelő eljárások keretében gondoskodni kell arról, hogy külsőszemélyek, vagyis akik nem tagjai az informatikai részleg üzemeltetési csoportjának, csak a fenti csoport valamely tagjának kíséretében léphessenek be a kulcsfontosságú számítógépes helyiségekbe (szerverszoba, kommunikációs kapcsolóberendezések helységeibe stb.). A látogatásokról naplót kell vezetni, amelyet rendszeres időközönként ellenőrizni kell. Az informatikai részleg vezetésének gondoskodnia kell arról, hogy megfelelő védelmi intézkedések és eljárások legyenek


- 79 -

érvényben a környezeti veszélyforrásokra (pl. tűz, por, elektromosság, túlzott hőmérséklet, illetve páratartalom stb.) vonatkozóan. A vezetésnek rendszeres időközönként fel kell mérnie a szünetmentes tápegységek és generátorok iránti igényeket a kritikus programok biztonságos működése érdekében. Kiszervezés esetén a szolgáltatónak is biztosítania kell a fenti feltételeket.

Phisingelés, kettős authentikáció? A 2007-es évet a magyarországi bankok és pénzintézetek joggal nevezhetik a phising (adathalászat) évének is. Az adathalászok több szervezet honlapját másolták le és helyezték el a világ számos szerverén, majd megpróbálták az ügyfeleket arra buzdítani, hogy ezen a helyen adják meg adataikat és egyedi azonosítóikat, persze csupán „adategyeztetés céljából”. A bankok és a hazai szervezetek a PSZÁF vezetésével és a média hathatós segítségével hívták fel a figyelmet a veszélyekre. Kidolgoztak több ajánlást a veszélyek elkerülése érdekében, így az internet banking (más társaságok esetében az interneten kersztül végzett tranzakciók végrehajtása) témakörében az alábbiak meglétének ellenőrzését, mint minimum feltételt tartjuk szükségesnek. � Bejelentkezés helyének vizsgálata

Gyakorlati tapasztalatok szerint jelentősen csökkenthető a honlap másolás veszélye akkor, ha az internet banking oldalra történőbelépés, nem közvetlenül a főoldalon (index.html), hanem egy másik oldalról érhető el. Ez irányú felmérések szerint az ügyfelek egy további oldalra történő linkelését (plus egy kattintás) még „szó nélkül” tolerálnak, így nem kell attól tartani, hogy ezen időveszteség miatt tömegével fognak elpártolni az érintett üzleti felhasználók.

� Kettős autentikáció avagy független csatorna meglétének vizsgálata Az internet bankingben rögzített megbízások validálására a PSZÁF, illetve a hazai pénzintézeti szektor egyértelműen a kettős autentikáció bevezetését javasolta. Számos társaság már 2007. év folyamán bevezette ezen szolgáltatást. Lényege az, hogy az autentikáció során megadott felhasználói azonosító és jelszó (PIN, password) mellet, a megbízások validálására egy független csatornán (pl. SMS, Token, One Time Password) érkező jelszó-t is meg kell adnunk. Így az autentikáció és a független csatornán érkező jelszó még abban az esetben is védi az ügyfelet, ha – valamilyen okból – a saját azonosítója (PIN-je, jelszava) illetéktelen kezekbe került.

� Limitek használata Bevált, és számos esetben használt szokás a tranzakciós limiteinek beállítása. A „no limit” használata itt egyik félnek sem kifizetődő, így az adott szervezet ügyfélszokásainak ellenőrző és monitorizó


- 80 -

kapacitásának, valamint kockázatvállalásának figyelembevételével kell ezen limiteket kialakítani, majd közölni az érintett ügyfelekkel.

� Riasztási és intézkedési folyamatok kialakítása. Phising támadás esetén a legfontosabb a gyors reakció! A támadásról azonnal informálni kell az alábbi szervezeteket: Hun-CERT, Rendőrség, Nemzetbiztonsági Hivatal felé küldött tájékoztatás mellet, az internetszolgáltatóval közösen (ha mód van rá) meg kell kezdeni a phising site-ok felkutatását. A folyamatos idősoros dokumentálás és az ügyfélpanaszok rögzítése rendkívüli fontossággal bír!

� Kommunikáció Újra előjön az oktatás és a biztonságtudatosság, mint állandóan aktualizálandó téma. Az ügyfeleket a lehető legszélesebb körben kell tájékoztatni a veszélyekről, illetve azok elkerülésének lehetőségeiről. Ezek közül emelünk most ki néhányat:

- Email-ben azonosítót és jelszót soha sem kérnek a Társaságok. - Figyeljünk az internet cím (domain) valódiságára. Akár egy

karakter is megtévesztő lehet. - Próbáljunk ki egy-két fő és almenüt, hogy bejönnek-e a hozzá

helyesen kapcsolódó adattartalommal. Általában csak a legfontosabb és az internet banking-hoz kapcsolódó oldalakat másolják le.

- Figyeljünk a nyelvhelyességre. A honlapok magyarítása sok esetben (szerencsére) nem tökéletes.

- Az ügyfelek otthoni munkaállomása mindig rendelkezzen frissített víruskereső – tűzfal és kémprogram eltávolító alkalmazásokkal.

Biztonsági paraméterek beállítása, (pl. Domain policy-k)? A munkaállomások és szerverek operációs rendszereibe történőbejelentkezések, valamint a belső hálózathoz való csatlakozás biztonsági beállításainak változtatását a legkörültekintőbben kell kezelni, és így vizsgálni is. Bármilyen kicsinek tűnő változtatás és paramétermódosítás, a megfelelőkockázatelemzés és tesztelés elhagyása mellet súlyos következményekkel is járhat, hiszen, gyengítheti a belső védelmi rendszer szilárdságát, új kockázati pontok és lehetőségek kialakulását idézi elő, előidézhet váratlan pl. autentikációval összefüggő hibákat. A biztonsági paraméterek változtatásakor vizsgálni kell, hogy : � a folyamat tervezését milyen szinten és milyen közreműködők

bevonásával oldották meg,


- 81 -

� a hatáselemzés vagy kockázatelemzés milyen feltételek mentén zajlott le és mi lett annak az eredménye,

� az átállítás folyamata valóban az eredeti tervek mentén és megfelelőteszteléseket követően történt-e,

� a bevezetés során, majd azt követően a változáshoz szorosan összefüggő hibák száma hogyan alakult.

Összefoglalás

Mire jó ez a kézikönyv?

Jelen kézikönyvben felsoroltuk a gyakorlati ellenőrzési tapasztalatok alapján, az informatikai kontrollok szempontjából legalapvetőbb és legfontosabb kérdéseket (gyakorlati problémakezelés). Megpróbáltunk ötleteket adni a kockázatok és kontroll hiányosságok kezelésére, vizsgálati pontokra. Javasoljuk, hogy időnként lapozzák fel újra-meg-újra a kézikönyvet és gondolkozzanak el, hogy mi az, amit ezek közül nem tesznek meg rendszeresen, illetve hogy a biztonságos működés szempontjából mivel lehetne még a saját működésüket javítani és biztonságosabbá tenni (minőségirányítás). Fontosnak tartjuk, hogy olvasóink azonosuljanak azzal a kontroll tudatos szemléletmóddal, amely az informatika ellenőrök sajátja, és amelyet például az ISACA tagjai képviselnek (kontroll tudatosság). Ha ezt a szemléletmódot sikerül a napi gyakorlatba átültetni, akkor e könyv szerzői már elérték céljukat. Ebben véleményünk szerint nagyban segít, ha olvasóink minél gyakrabban látogatják a http://www.isaca.hu/ és a http://www.isaca.org oldalakat, illetve nemcsak olvassák, hanem alkalmazzák is az ott megjelenő kiadványokban / kézikönyvekben leírtakat.

Mit érdemes feltétlenül megjegyezni?

Ha a kontroll tudatos szemléletmódot magunkévá tettük, akkor érdemes azt továbbadni munkatársainknak, beosztottjainknak, vezetőinknek (misszió). Ez a látásmód nem öncélú, hanem alapvetően az üzleti célok elérésének és a hatékony működésnek az alapfeltétele. Bármely tevékenységünk során azt érdemes megfontolni, hogy munkánk konkrét elvégzésének feltételei és eredményei mennyire vannak összhangban az arról alkotott elképzeléseinkkel, illetve a vállalat vezetés elképzelésével (lásd. a CobiT féle érettségi modellt – maturity model). Ha nagy eltérések vannak, akkor ott mindenképpen szükség van korrekcióra.


- 82 -

Ez a folyamat tulajdonképpen a minőségbiztosítás alapelve (PDCA folyamat, lásd az 1. számú mellékletet) és ezt vázolja a CobiT kézikönyvek érettségi modellje is. A legkisebb kockázat a jó kontroll környezetben valósul meg, amely – bármely tevékenység vonatkozásában, függetlenül a konkrét munkától – a szabályozás, dokumentálás és ellenőrzés elvégzésel biztosítható. Az informatikai kontrollok oldaláról nézve tehát a legfontosabb kontrollálandó folyamat: a stratégia készítés, a feladat és felelősség elhatárolás, a kockázat menedzselés, a szabályozás, a fejlesztés, a változáskezelés, a nyilvántartás, a jogosultság kezelés, a rendkívüli helyzet menedzselés, a naplózás és az ellenőrzés. A kontrollok működtetése nem egyszeri tevékenység, hanem folyamatos feladat, amely rendszeres odafigyelést és felülvizsgálatot igényel. A jelen kézikönyv nem terjed ki mindenre és gyorsan változó világunkban nem is terjedhet ki mindenre. Ha elfogadjuk azt a tényt, hogy a változó környezetből eredő eddig ismeretlen kockázatok bármikor megjelenhetnek és ezeket csak megfelelő intézkedésekkel lehet csökkenteni, akkor már jó úton járunk. Azt kell megértenünk és megértetnünk munkatársainkkal is, hogy munkánkban akkor lehetünk csak eredményesek, ha már tervezési és fejlesztési fázisban gondolunk a biztonsági funkciók és ellenőrzési lehetőségek beépítésére (utólag sokkal nehezebb és költségesebb is). Ha a kontroll tudatos szemléletmóddal rendszeresen felülvizsgáljuk tevékenységeinket és az új termékek, szolgáltatások esetén végiggondoljuk, hogy hogyan lehet ellenőrizhetővé, valamint alacsony kockázattal működővé tenni azt és meg is tesszük ezeket az intézkedéseket, akkor elmondhatjuk, hogy jó kontroll környezetet építettünk ki. Minden IT menedzselési módszertan és szabvány csak annyit ér, amennyit a gyakorlatban megvalósítunk belőle.


- 83 -

Irodalomjegyzék

1 COBIT (Control Objectives for Information and Related Technology) ver. 4.1. - ITGI 2005 (http://www.isaca.org/; http://www.isaca.hu/)

2 Board Briefing on IT Governance (Igazgatótanácsi tájékoztató az informatikai irányításról, 2. kiadás)

3 COBIT Online (http://www.isaca.org/cobitonline)

4 COBIT Control Practices (COBIT Kontroll gyakorlatok: Útmutató a sikeres informatikai irányítást szolgáló kontroll célkitűzések eléréséhez)

5 COBIT Quickstart (COBIT gyors bevezetés)

6 COBIT Security baseline (COBIT Alapvető Biztonság)

7 Alingning COBIT, ITIL and ISO 17799 for Business Benefit (A COBIT, az ITIL és az ISO 17799 összhangba hozása üzleti előnyök biztosítása érdekében)

8 COBIT Mapping: Overview of International IT Guidance (COBIT Leképezés: A nemzetközi informatikai útmutatók áttekintése, 2. kiadás)

9 IT Assurance Guide Using COBIT (Informatikai értékelési útmutató a COBIT felhasználásával)

10 IT Control Objectives for Sarbanes-Oxley (Informatikai kontroll célkitűzések a A Sarbanes -Oxley-hoz, 2. kiadás)

11 IT Governance Implementation Guide Using COBIT and Val IT (Informatikai irányítás megvalósítási útmutató: a COBIT és a Val IT használata, 2. kiadás)

12 COBIT Leképezés: Az ISO/IEC 17799:2000 leképezése a COBIT -ra, 2. kiadás COBIT Mapping: Mapping of ISO/IEC 177 99:2000 With COBIT, 2nd Edition

13 COBIT Mapping: Mapping of PMBOK With COBIT 4.0 (COBIT Leképezés: A PMBOK leképezése a COBIT 4.0 –ra)

14 COBIT Mapping: Mapping of SEI’s CMM for Software With COBIT 4.0

15 COBIT Mapping: Mapping of ITIL With COBIT 4.0 (COBIT Leképezés: Az ITIL leképezése a COBIT 4.0 –ra)

16 COBIT Mapping: Mapping of PRINCE2 With COBIT 4.0 (COBIT Leképezés: A PRINCE2 leképezése a COBIT 4.0 –ra)


- 84 -

17 IT control objectives for Basel2 – ITGI 2006

18 Information Security Governance (Információ biztonság irányítása: Útmutató az igazgatótanács és a felső vezetés számára, 2. kiadás)

19 The Val IT Framework (A Val IT keretrendszer - Vállalati érték az informatikai befektetések irányításában)

20 COSO: Internal Control - Integrated Framework, 1994

21 Office of Government Commerce: IT Infrastructure Library (ITIL)

22 International Organisation for Standardisation: ISO/IEC 27000

23 Software Engineering Institute (SEI): SEI Capability Maturity Model (CMM), 1993

24 SEI Capability Maturity Model Integration (CMMI), 2000

25 A Guide to the Project Management Body of Knowledge (PMBOK®) - Project Management Institute (PMI) 2004

26 Information Security Forum (ISF): The Standard of Good Practice for Infomation Security, 2003

27 IT Control Objectives for Sarbanes-Oxley: The Role of IT in the Design and Implementation of Internal Control Over Financial Reporting, 2nd Edition, IT Governance Institute, USA, 2006

28 CISA Review Manual, ISACA, 2006

29 Financial Audit Field Manual T9 Audit in an IT Environment, NAO 1996

30 Review of Information System Controls For NAO, 905 Version1 1999.

31 Federal Information System Controls Audit Manual, GAO/AIMD 1999.

32 Handbook of IT Auditing, PricewaterhouseCoopers L.L.P 2000.

33 Módszertan az IT rendszer kontrollok ellenőrzéséhez –ÁSZ 2007.

34 Az IT stratégia kialakításának és megvalósításának irányelvei ITB 2.sz ajánlás,1996. (ITB ajánlások http://www.itb.hu/ajanlasok/)

35 Az IT stratégia kialakításának és megvalósításának irányelvei ITB 3. sz. ajánlás, 1993

36 SSADM Struktúrált rendszerelemzési és tervezési módszer – ITB 4. sz. ajánlás 1993.

37 Bevezetés a PRINCE projektirányítási módszertanba – ITB 5. sz. ajánlás 1994.

38 Informatikai biztonsági módszertani kézikönyv ITB 8.sz ajánlás,


- 85 -

1994.

39 IT rendszerek biztonsági követelményei ITB 12.sz ajánlás, 1996

40 Iránymutató az IT biztonság területén (http://www.biztostu.hu/)

41 Az ENISA honlapja (http://www.enisa.europa.eu/rmra/rm_home.html)

42 OCTAVE method – Operationally Critical Threat, Asset, and Vulnerability Evaluationd (http://www.cert.org/octave/)

43 196/2007 Korm. rendelet a hitelezési kockázatokról

44 200/2007 Korm. rendelet a működési kockázatokról

45 2004/39/EK – a pénzügyi eszközök piacairól (MIFID)

46 2006/48/EK – a hitelintézeti tevékenység engedélyezéséről (BASEL2),

47 2006/49/EK – a befektetési vállalkozások és a hitelintézetek tőkemegfeleléséről (BASEL2),

48 2007/18/EK – a tőkemegfelelési szabályok módosításáról (BASEL2),

49 ISACA: IT control objectives for Basel2

50 1996. évi CXII. törvény (Hpt) a hitelintézetekről.

51 2001. évi CXX. törvény (Tpt) a tőkepiacról

52 1997. évi LXXXII. tv. (Mpt) a magánnyugdíjpénztárakról

53 1993. évi XCVI. (Öpt) az önkéntes pénztárakról

54 1992. évi LXIII. törvény - Adatvédelmi törvény

55 10/2001-es PSZÁF ajánlás a biztonsági feltételekről

56 1/2007-es PSZÁF módszertani útmutató az informatikáról az IT biztonság területén

57 Módszertan az információs rendszerek kontrolljainak ellenőrzéséhez – ÁSZ 2007.

58 ITKTB ajánlás (http://www.itktb.hu/engine.aspx?page=iba_oldal)

59 TCSEC (http://en.wikipedia.org/wiki/TCSEC)

60 ITSEC http://www.bsi.de/zertifiz/itkrit/itsec-en.pdf)

61 BS7799 (http://www.iso-17799.com, http://www.bs7799.hu/)

62 ITIL (BS 15000; http://www.itil.co.uk)


- 86 -

63 Common Criteria (MSZ ISO/IEC 15408, ITB 16. számú ajánlása)

64 MIBÉTS – Magyar IT Biztonsági Értékelési és Tanúsítási Séma (http://www.itktb.hu/engine.aspx?page=dokumentumtar&docstorefolder=11)

65 CERT (http://www.cert.hu/altalanos-biztonsagi-temak/)

66 Biztonság (http://www.biztonsagportal.hu/link-4.html)

67 ISO 9001-es minőségirányítás szabvány és minősítés (http://www.isotanusitas.hu/hu/szolgaltatasaink/iso-9001-tanusitas.html)

68 ISO 14000 (http://ts.nist.gov/Standards/Global/iso14.cfm)

69 ISO 13335 (http://www.iso.org/iso/en/CatalogueDetailPagesdfsdf)

70 ISO 12207 Szoftver életciklus folyamatok

71 ISO 9126 Szoftvertermék értékelése, minőségi jellemzők és használatuk

72 ISO 10006 Minőségmenedzsment és projektmenedzsment minőségbiztosítási irányelvei

74 ISO/IEC 12207:1995/Amd.1:2002 Szoftver életciklus-folyamatok

75 ISO/IEC TR 15504:2005 Szoftverfolyamat felmérése.

76 ISO/IEC 15288:2002 Szoftver életciklus-folyamatok

77 MSZ EN ISO 9000:2005 Minőségirányítási rendszerek.

78 MSZ EN ISO 17799:2006 Az információbiztonság irányítási gyakorlatának kézikönyve.

79 MSZ EN ISO 27001:2006 Az információbiztonság irányítási rendszerei.

80 ISO/IEC 2382-20:1990, Információtechnika. Rendszerfejlesztés

81 ISO 8402:1986 Minőség. Szakszótár

82 MSZ ISO/IEC 13335:2005 Informatika. Az informatikai biztonság menedzselésének irányelvei

83 MSZ ISO/IEC 15408:2003 Az informatikai biztonságértékelés közös szempontjai.

84 MSZE 15100:2005 Az informatikaszolgáltatás irányítása (ITIL).

85 Magyar Könyvvizsgálói kamara 401-es ajánlása – Könyvvizsgálat számítógépes információs rendszerek esetén. (http://www.mkvk.hu/pages/kezdolap/kezdolap.cgi?pg=kv&sp=3_1_1)


- 87 -

Mellékletek

1. sz. melléklet – A PDCA modell

A PDCA-modell az ISMS-folyamatokra alkalmazva (MSZ EN ISO 27001:2006)


- 88 -

2. sz. melléklet – A minőségirányítási rendszer modellje

Folyamatszemléletű megközelítésen alapuló minőségirányítási rendszer modellje

(MSZ EN ISO 9000:2005)


- 89 -

3. sz. melléklet – A kockázat menedzselés általános lépései

Részletes kockázatelemzést magában foglaló kockázatkezelés (MSZ ISO/IEC 13335-3:2005)


- 90 -

4. sz. melléklet – Az IT biztonság menedzselése

Az informatikai biztonság menedzselése (MSZ ISO/IEC 13335:2005)


- 91 -

5. sz. melléklet – Összeférhetetlenségi táblázat

Fel

hasz

náló

IT e

llenőr

Fejle

sztő

Szof

tver

kön

yvtá

ros

Felh

. tám

ogat

ó

Ren

dsze

r ad

min

.

Hál

ózat

i adm

in

Ada

tbáz

is a

dmin

.

Ope

ráto

r

IT b

izto

nság

i fel

elős

Felhasználó x x x x x x

IT ellenőr x x x x x x x

Fejlesztő x x x x x x x x x

SW könyvtáros x x x x x x x

Felh. támogató x x x x x x x x

Rendszer admin. x x x x x x x

Hálózati admin x x x x x x x x

Adatbázis admin. x x x x x x x x

Operátor x x x x x x x

IT biztonsági felelős x x x x x x x


- 92 -

6. sz. melléklet – Kontroll kérdések a CobiT alapján

TERVEZÉS, SZERVEZÉS

Stratégiával kapcsolatos kérdések: � A tervezésre milyen belső utasítások és milyen feltételek vonatkoznak a

stratégiai terv elkészítésére? � Milyen időtartamra (hosszútávú, középtávú, rövidtávú, éves) készülnek

tervek és milyen szabályok vonatkoznak a tervek aktualizálására valamint a megvalósíthatóságára vonatkozó preventív és detektív ellenőrzésekre?

� A véglegesített tervek, milyen szinten felelnek meg a tervezés elkészítésére vonatkozó szabályozásnak?

� Milyen szinten dokumentált az üzleti stratégia? � Milyen szinten dokumentált az informatikai stratégia? � Az informatikai stratégiai terv milyen szinten tartalmazza az üzleti

területek által megfogalmazott igényeket, követelményeket? � Az informatikai stratégiai terv milyen szinten tartalmazza az

- üzleti folyamat újraszervezés, - ügyvitelszervezés, - technológiai fejlesztés, - szervezeti változások, - munkaerő ellátás, - külső kapcsolatok, - szabályozási környezet elvárásait?

� Kik azok akik jóváhagyták az informatikai stratégia tervet? (Igazgatóság, Felügyelő Bizottság, Vezetői értekezlet, stb.)?

� Az informatikai stratégia, milyen szinten tartalmazza rövidtávú tervezést?

� Milyen rendszerességgel történik a rövidtávú tervezés felülvizsgálata? � Milyen rendszerességgel történik az egyes tervek aktualizálása? � Ki(k) – milyen gyakorisággal, valamint milyen formában ellenőrzik a

tervek megvalósíthatóságát?

Információs architektúrára vonatkozó kérdések: � Milyen szinten dokumentált az információs architektúra? � Az információs architektúra dokumentációja milyen mélységben

tartalmazza - az információs architektúra átfogó modelljét, - az intézményi adatmodelleket és a kapcsolódó információs

rendszereket,


- 93 -

- a hardverstruktúrát; - az alkalmazási rendszerek szerkezetét; - hálózati struktúrát; - adatszótárt és az adatstruktúrát és az adatok szintaktikai szabályait; - adatok biztonsági osztályokba sorolását; az adattulajdonosi

jogokat? � Az informatikai biztonsági szabályozás milyen szinten tartalmazza

- az aktuális információs architektúra kialakítását, - a biztonsági osztályok definiálását, - az adatok biztonsági osztályokba sorolásának szabályait, - a biztonsági osztályok hozzáférési szabályait, - az adattulajdonosi jogok kiosztásának szabályait?

� Kik, milyen gyakorisággal valamint milyen formában ellenőrzik az információs architektúra naprakészen tartását?

A technológiai fejlődési irány meghatározásával kapcsolatos kérdések: � Az informatikai stratégiai terv milyen szinten tartalmazza az

információ technológiai és biztonságtechnikai irányokat? � Ki(k) – milyen gyakorisággal, valamint milyen forrásból figyelik az

információ technológiai irányokat és szabályozási tendenciákat, biztonsági változásokat, trendeket?

� A technológiai fejlesztések milyen szinten vannak összhangban a szervezet által definiált technológiai irányokkal?

� A technológiai fejlesztési irányok milyen szinten tudják szolgálni, és pozitív irányban befolyásolni az üzleti stratégiát?

� Létezik, és ha igen akkor milyen formában és kinek részvételével valósúl meg a technológiai infrastruktúra tervezés?

� Kik és milyen formában határozták meg a technológiai normatívákat, szabványokat?

� Az információ technológiai infrastruktúra tervek milyen szonten tartalmazzák a

- rendszer architektúra tervet, - technológiai irányokat, - tartalékokat és a migrációs stratégiát?

� Létezik hardver-szoftver beszerzési terv és a beszerzésekhez milyen döntési folyamat párosúl?

� A beszerzési tervek milyen szinten tükrözik vissza az informatikai stratégiában és az infrastruktúra tervekben foglaltakat?


- 94 -

A szervezet és kapcsolatainak meghatározása � Az informatikai tervezést ki(k) és milyen formában ,működtetik ? � Az informatikai tervezéseket és döntéseket követően a felső milyen

szinten van tájékoztatva? � Létezik, és ha igen akkor milyen formában működik a felhasználói

területektől független belső informatikai szervezet, hatáskör? � Kik és milyen céllal határozták meg az informatikai szervezeten belül a

funkciókat, felelősségeket? � A funkciók és felelősséggi körök milyen szinten biztosítják a szükséges

jogosítványokat, erőforrásokat? � Léteznek és elfogadottak a funkciók elkülönítésére alkalmas munkaköri

leírások? � A munkaköri leírások, milyen szinten tartalmazzák a feladatok leírását, a

felelősségeket, a jogosítványokat és a szükséges készséget és szakértelmet? � Kik és milyen gyakorisággal aktualizálják a munkaköri leírásokat? Ezek

milyen körben lettek elfogadtattva? � Kik és milyen formában értékelik rendszeresen a munkaköri követelmények

teljesítését? � Megtörtént a fejlesztési és üzemeltetési szervezet, funkciók elkülönítése? � Megtörtént a biztonsági, adatvédelmi felelősségek elkülönítése? � Megtörtént az adattulajdonosi, adatfeldolgozói felelősségek elkülönítése? � Kik és milyen formában ellenőrzik az (IT) alkalmazottak képzettségét? � Milyen rendszerességgel történnek a feladatokhoz szorosan kapcsolódó

továbbképzések? � A hatályba levő szabályzatok milyen szinten kezelik és védik az

informatikai vagyon védelmét a külső konzulltánsakkal, partnerekkel szemben?

IT beruházások irányítása � Létezik IT beruházási terv? � Az IT beruházási terv milyen szinten van leképezve az IT hosszú és

rövid távú stratégiai terveknek? � Létezik IT működési költségterv? � A működési költségterv milyen szinten felel meg az IT hosszú és

rövidtávú stratégiai terveknek? � Milyen működő kontrollok biztosítják a tervek megvalósulását?

Automatikus és/vagy folyamatos ezek nyomon követése? � A terveket a felső vezetés milyen formában tárgyalja és fogadja el? � Létezik-e IT eszköz nyilvántartás a beruházások és költségek hatékony

tervezéséhez? � Működik engedélyezési vagy döntési eljárás a beruházások,

beszerzések hatékony végrehajtásához


- 95 -

� Kik és milyen formában támogatják-e a beruházási döntéseket és az IT projektek megvalósulását?

A vezetési célok és irányelvek érvényesítésével kapcsolatos kérdések: � Kik – mikor és milyen formában alakították ki és dokumentálták,

valamint hagyták jóvá a vezetés és az informatika felhasználásával kapcsolatos céljait, politikáit, irányelveit?

� Kik és milyen formában alakították ki a vezetés a politikák, irányelvek megismertetéséhez, megértéséhez, tudatosításához és elfogadtatásához szükséges eljárásokat és erőforrásokat? Ezek milyen formában működnek?

� A felső vezetés milyen gyakorisággal és milyen formában monitorozza politikák, irányelvek ismertségét, követését?

� A politikák, irányelvek milyen kontroll rendszert alakítottak ki az ügyspecifikus szabályzatok, eljárások és a folyamatosan változó környezet aktualizált formában tartására?

� Milyen szinten rögzített az informatika alkalmazásával kapcsolatos biztonsági politika?

� Milyen szinten rögzítettek az informatiakai szolgáltatásokkal kapcsolatos minőségbiztosítási kontrollok? Ezek milyen formában működnek?

� Milyen szinten rögzítettek az informatikai független ellenőrzéssel kapcsolatos elvárások?

� Léteznek a szükséges általános és ügyspecifikus belső szabályzatok, eljárások, szabványok?

Emberi erőforrás gazdálkodás � Léteznek IT humán erőforrás irányítási tervek? � Léteznek személyre szabott szakmai karrier tervek? � Kik és milyern adatok alapján, valaint milyen formában minősíti az IT

szakmai személyzetet? � Létezzik a szabványokra és speciális munkaköri felelősségre alapozott

szakmai értékelési rendszer és ezek alapján kik értékelik az IT szakmai személyzetet?

� Kik gondoskodnak a kulcsszemélyek helyettesítésére megfelelőtartalékról?

� Milyen formában léteznek megfelelő oktatási, továbbképzési tervek a szakmai és vezetési készség színvonalának emelésére?

� Milyen mértékű az (IT) alkalmazottak fluktuációjának? Ez elfogadható mértékű?

� Mekkora és ez elfogadható mértékű a betöltetlen munkahelyek száma és átlagos időtartama?


- 96 -

� A személyzet biztonsági átvilágításon alapuló felvétel, áthelyezés, pl.előléptetés esetén elfogadott és támogatott?

Külső jogszabályi követelmények teljesítése � A felső vezetés hogyan figyeli a külső szabályozásban bekövetkezett

változásokat és ebből adódó követelményeket? Ezeket milyen módon közvetíti az IT szervezet felé a rájuk vonatkozó eljárásokat, irányelveket?

� Kik és milyen gyakorisággalmonitorozzák és aktualizálják a belsőszabályzatokat, eljárásokat a külső szabályozók változása esetén?

� Milyen módon töürténnek meg az utólagos ellenőrzések a külsőszabályozó változásokból adódó korrekciók végrehajtására vonatkozóan?

� A belső ellenőrzés milyen módon vizsgálja külső szabályozásnak való megfelelést?

� Kik és milyen gyakorisággalfigyelik és elemzik-e a panasz ügyeket, a külső szabályozás betartása szempontjából?

Kockázatkezelés � A kockázatok kezelésére - menedzselésére létezuik kockázatkezelési

szabályozás, eljárás, metodika? � Milyen gyakorisággal dolgozzák fel és milyen IT alkalmazásba rögzítik

a bekövetkezett káreseményekből, rendkívüli helyzetekből nyert kockázati információkat?

� Milyen gyakorisággal vannak ötletbörzék, elemzések a kockázatok felismerésére és csökkentésére?

� Megtörténik az informatikai kockázatok szisztematikus felmérése? � Az informatikai kockázatok minimalizálása érdekében tudatosan kik és

milyen módon alakítják ki a szükséges kontrollokat?� Az informatikai kockázatok minimalizálása érdekében kialakított

kontrollok naprakész alkalmazása milyen módon valósul meg, ezek ellenőrzötte és dokumentáltak, folyamatos működésük kontrollált?

Projekt management � A projekt menedzsment, illetve az egységesen elfogadott

projektirányítási program milyen szinten van szabályozva? � A projektirányítási program és módszertan

- a projekt irányítás tartalmát és korlátjait, - a feladat és felelősség kiosztást, - és a kapcsolódó jogosítványokat, - az idő és erőforrás előirányzatokat és mérföldköveket, - ellenőrzési pontokat és a jóváhagyásokat,


- 97 -

- a felhasználói és informatikai szakember összetételt milyen módon tartalmazza?

� A projektirányítási program és módszertan a - projekt vezérterv az idő és költségráfordítások figyelésére - projekt minőségbiztosítási terv a kontrollok érvényesülésének

ellenőrzésére, - projekt kockázatkezelési - tesztelési terv - képzési terv vizsgálatára

milyen követelményeket fogalmaz meg? � Készül felülvizsgálati terv a projekt eredményének teljesítésének,

tervezett céloknak elérése vizsgálatának? � Biztosítottak a projektirányítási program és módszertan alkalmazásának

feltételei? (költség fedezet, humán erőforrás, stb.) � A projektirányítási program és módszer alkalmazásával lefolytatott

sikeres, befejezett programok és időarányosan növekszenek? � Teljes körűen, illetve a szabályozott körre milyen szinten alklamazzák

a projektirányítási programot és annak módszerét?

Minőségbiztosítás � Létezik minőségbiztosításra vonatkozóan szabályozás, előírás? � Létezik általános minőségbiztosítási terv, előírás a folytonos formálás

filozófiájának támogatására? � A minőségbiztosítási terv, előírás milyen szinten tartalmazza a(z)

- általános és speciális minőségbiztosítási tevékenységek típusait; - minőségbiztosítási tevékenység tárgyának és időzítésének

meghatározását, - minőségbiztosítási tevékenység alapjául szolgáló szabványok,

előírások és eljárások felsorolása hivatkozásait, - minőségbiztosítási tevékenység alapjául szolgáló szabványok és

eljárások betartására vonatkozó értékelési vizsgálati eljárásokat? � Létezik a minőségbiztosítási tervben megjelölt szabványoknak

megfelelő rendszerfejlesztési életciklus módszertant és eljárásokat a fejlesztendő, beszerzendő, megvalósítandó és karbantartandó rendszerekre?

� A rendszerfejlesztési életciklus módszertan a fejlesztési ciklusba épített ellenőrzési, döntési kritériumokat milyen mértékben tartalmazza?

� Megtörténik a mindenkori technikákra vonatkozóan, a rendszerfejlesztési életciklus módszertan és a kapcsolódó eljárások folyamatos aktualizálása?

� Kik és milyen formában egyeztetik. és milyen formában fogadják el a rendszerfejlesztési életciklus módszertant és a kapcsolódó eljárásokat, illetve a fejlesztési életciklusban résztvevő külső, szerződéses partnerekkel?


- 98 -

� Ki vannak alakítva a technológiai infrastruktúra beszerzési és karbantartási kereteit, eljárásait?

� Ki vannak alakítva a tesztelési szabványokat, standard eljárásokat (program, rendszer és pilot tesztelések)?

� Ki vannak alakítva a dokumentálási szabványokat és eljárásokat? � A minőségbiztosítási tervekben előírtak elvégzése, dokumentált

formában történik? � Megtörténik a célok elérésének vizsgálata, a fejlesztési életciklusba

épített ellenőrzési, döntési pontokon, illetve a fejlesztések módosításakor és befejezésekor?

BESZERZÉS, FEJLESZTÉS

Beszerzések tervezése és döntések � A beszerzés, fejlesztés az informatikai stratégiában definiáltak szerint

történik? � Az informatikai beszerzéseket, fejlesztéseket az üzleti követelmények

motiválják? � Folyamatosan történik a fejlesztési igények specifikálása, regisztrálása? � Milyen formában valósul meg a(z)

- alternatív megoldások számbavétele, - kockázati értékelése a felhasználói szoftverek, a technológiai

alternatívák, - a biztonsági problémák és a gazdaságosság, hatékonyság

tekintetében (pl. üzleti előnyök - beruházási és üzemeltetési költségek)?

� Megfelelő szionten kontrolláltak a beszerzés, fejlesztés a rendszerfejlesztési életciklus módszertan és kapcsolódó eljárások?

� Figyelembe veszik-e a beszerzésnél, fejlesztésnél az auditálhatósági, nyomkövetési, ellenőrzési szempontokat?

� Érvényesítik-e a külső partnerekkel kötött szerződésekben a - rendszerfejlesztési életciklus módszertanban és a kapcsolódó

eljárásokban előírt következő kontrollokat, - tesztelési követelmények (hardver és komponens tesztek,

rendszerterhelési, felhasználói, integrációs, migrációs tesztek, kísérleti üzem, stb);

- elfogadási kritériumok, - dokumentálási követelmények, - biztonsági tecchnológia és eljárások működése (mentések,

vírusvédelem, hozzáfélési politika, hálózat védelme, titkosítás, hitelesség, stb.)?


- 99 -

� Létezik beszerzési politika / eljárás? � Mi szabályozza a beszerzési eljárást és azokra vonatkozó kontrollokat? � Léteznek a beszerzési eljárásban előírt kontrollok?

Felhasználói szoftver beszerzése, fejlesztése, karbantartása � Milyen szinten tartalmazzák a rendszerfejlesztési, átalakítási tervek a

- felhasználói követelményeket, - adat-, file-, program és input/output specifikációkat, - interface-ek leírásokat, - feldolgozási követelményeket, - rendszer használati szabályokat,

� Milyen módon történik (manuális vagy automatikus, azaz gépi ellenőrzés) az applikációs kontrollok (adatbeviteli és folyamatba épített ellenőrzések, egyeztetések) működtetése?

� Milyen módon történik az - adatok sértetlenségének biztosítása - a mentések rendelkezésre állása, - a cseregép visszaállítása, - a hideg backup adatvisszatöltése - a meleg back-up- esetén?

� Milyen szinten tartalmazza a tesztelési terv az egyes tesztelési lépéseket, a tesztadatokat, a forgatókönyveket és az elfogadási kritériumokat?

Technológiai architektúra beszerzése, karbantartása� Hogyan aktualizálják a beszerzések, fejlesztések során hardver és

szoftver leltárt? � Ki és milyen módon gondoskodnak a hardver eszközök periodikus

karbantartásáról? � Kik és milyen szinten gondoskodnak a

- rendszerszoftver és paramétereinek beállításáról,- a felhasználói rendszerek biztonságos és optimális működésének

feltételeinek folyamatosan biztosításáról (elérési és üzemidők, sértetlenség, működési zavarok),

- a külső szakértői vizsgálat és a belső elemzés, illetve értékeléséről?

IT eljárások fejlesztése és karbantartása � Rendelkeznek-e a szolgáltatási szintek és technológiai eljárásokra

vonatkozó aktuális követelményrendszerrel? � Milyen eljárások biztosítják azt, hogy a rendszerfejlesztések,

átalakítások keretében mindig elkészüljenek a felhasználói kézikönyvek, a IT üzemeltetési dokumentációk és az oktatási anyagok?


- 100 -

Rendszerek installálása és átvétele � A külső szerződések keretében hogyan gondoskodnak a beszerzett,

fejlesztett rendszerek üzemeltetési támogatásáról, karbantartásáról, követéséről?

� Léteznek - teljesítményméretezési tesztek (hardver, hálózat, rendszer és

alkalmazási szoftver teljesítménymérése a várható forgalomra)? - migráció és konverzió, illetve változáskezelési tesztek (a

rendszerváltozással kapcsolatos eljárási, szabályozási, dokumentációs változások felülvizsgálata)

- műveleti tesztek, illetve párhuzamos futtatások, valamint felhasználói követelmények értékelése;

- minőségbiztosítási tesztek (a minőségbiztosítási eljárások, szabványok betartásának vizsgálata)

- biztonsági követelmények tesztelések (előírt biztonsági szinteknek megfelelő biztonsági kontrollok működése)

- éles környezetbe való bevezetés tesztelések, valamint annak próbaüzeme,

- végső elfogadások (a tesztek értékelése, vezetői döntés)?

Változáskezelés � Léteznek változáskezelési standard eljárások a(z)

- változtatási – módosítási - fejlesztési javaslatok - kérések nyilvántartására - kezelésére (elemzés, standardizálás, prioritások, döntés),

- valamint a megvalósítás követésére, majd adminisztrálására, - szoftver verzió kontrollra (programverziók archiválása, tárolása,

visszakeresése, dokumentálása),- rendszerváltozások teljes körű dokumentálására (adatleírások,

fejlesztői, felhasználói, üzemeltetési kézikönyvek és eljárások frissítése),

- szoftverek és dokumentációk hardver konfigurációval összehangolt szétosztására?

� Ki vannak alakítva a változáskezelés vezetői adminisztratív ellenőrzését biztosító kontroll eljárások?

� Kik és milyen módon alakították ki a rendszer-implementációkat követő ellenőrzéseket, illetve az elvárások teljesülésének értékelésére?


- 101 -

ÜZEMELTETÉS ÉS TÁMOGATÁS

A rendszertámogatási (support) típusok és szintek kialakítása � Működik a support szerződések megkötésére vonatkozó keretrendszer? � Meg vannak határozva a support szerződések szolgáltatási típusai és a

szolgáltatás egyes szintjei? � Meg lettek határozva és rögzítve lettek a(z)

- rendelkezésre állásra, - szolgáltatási kapacitásra, - szolgáltatások megbízhatóságára, - funkcionális (üzleti ügyviteli) követelmények biztosítására, - üzleti folytonosság biztosítására, - rendkívüli és incidens helyzetek kezelésére, - adatbiztonságra és adatvédelemre, - monitorozásra és teljesítménymérésre, - változáskezelésre (átadás-átvétel, tesztelés, dokumentációk

módosítása, stb.) vonatkozó elvárások? � A felső vezetés milyen módon ellenőrzi és milyen formában elemzi a

support szerződésben lévő követelmények teljesítését?ű� Milyen módon és kik ellenőrzik a teljesített szolgáltatások színvonalát? � Létezik szolgáltatásfejlesztési program, amely a szolgáltatások

minőségének javítására koncentrál?

Külső szolgáltatók (Outsource) menedzselése � Létezik szerződés minden külső alkalmazás mögött? � Meghatározták a szerződésekhez az adott szervezeti kapcsolattartó

felelősöket? � Kialakították-e az outsource, szerződéskötési rendjét, folyamatát? � Megfelelő mértékben definiált a szerződések kötelező, illetve ajánlott

tartalma (pl. Titoktartási nyilatkozat)?� A support szerződések tartalmazzák a szerződések a kockázat

minimalizálásához szükséges feltételeket? � Létezik partnerminősítés, kockázati értékelés, amelyet figyelembe

vesznek a kiválasztási eljárás során? � Monitorozzák a teljesítéseket? � A szolgáltatás folytonossága, a folyamatos működés biztosítása

(határidők vállalása, betartása, rendelkezésre állás a(z) - biztonság és adatvédelem, - feladat és felelősségelhatárolás folyamatos biztosítása és

dokumentálása, - szolgáltatások színvonala,


- 102 -

- kontrollált-e a szolgáltatók, outsourcing cégek működésének törvényi megfelelősége szempontjából?

� Figyelemmel kísérik a(z) - szolgáltatók pénzügyi helyzetének és életképességének alakulását, - információvagyon és az adatok védelmét a szerződéses

munkavégzésnél, - szolgáltatók tevékenységét más felhasználóknál felhasználói klub

által vagy más módon, - versenytársak tevékenységeit, illetve - milyen módon tudják elkerülni a szállítókkal, szolgáltatókkal

szembeni kiszolgáltatottságot?

Teljesítmény és kapacitás menedzselése � Léteznek eljárások, tervek, módszerek a teljesítménnyel kapcsolatos

elvárásoknak megfelelő kapacitások időben történő biztosítására, hatékony és optimális kihasználására?

� Ismert, illetve dokumentált-e folyamatosan a rendelkezésre álló technológiai és humán erőforrás kapacitás?

� Léteznek kapacitás szükséglet előrejelzések, tervek és forrásallokálási terv?

A szolgáltatások folytonosságának biztosítása � Előzetesen meghatározták a folyamatos működéshez szükséges

minimális szolgáltatási szinteket? � Meghatározták és szabályozták az üzleti folytonossági tervezés és az

informatikai katasztrófa tervezés stratégiáját, politikáját, módszerét, eljárásait?

� Tartalmazza az üzleti folytonosság tervezés a(z) - informatikai technológia folytonosságának biztosítási tervét

(informatikai katasztrófa, rendkívüli helyzetek kezelési terve) - üzeti folytonossági tervét, háttér eljárásait az egyes funkcionális

területek, üzletágak, szervezeti egységek, ügyintézők számára, - feladatok, felelősségek, szerepek definiálása a vezetés, az üzleti,

felhasználói területek és az információ technológiai szervezet részére a bizalmas információk, adatvédelem biztosítását,

- tesztelésekre vonatkozó üzleti folytonossági tervet és ennek részeként az információ technológiai háttér eljárásait,

- dokumentálását az üzleti folytonossági terv tesztelések eredményének,

- érintett személyzet oktatását az üzleti folytonossági tervről a tervben szereplő feladatok elsajátítását,


- 103 -

- tervek aktualizálását a terveket a folyamatos kockázatelemzés és az üzleti és technológiai változását?

� Biztosítottak a kritikus információ technológiai források az információ technológiai folytonosság biztosításához szükségesek

- back-up szerverek, központi számítógépek, - tartalék munkaállomások - back-up telekommunikációs hálózatok, - földrajzilag elkülönített háttér számítóközpont, - háttér feldolgozást biztosító eljárások, technológia, programok - helyreállítási tervek és eljárások, amelyek szükségesek a

katasztrófa, rendkívüli helyzetek utáni normál üzemelésre való visszaállításhoz?

Rendszerek (logikai) biztonsága � Létezik az üzleti követelményekkel összhangban lévő informatikai

biztonsági szabályozás, amely tartalmazza a(z) - kockázati felmérésen alapuló informatikai biztonsági tervezést? - informatikai biztonsági terv végrehajtását, folyamatos

aktualizálását a technológiai konfiguráció és a kockázati felmérések és a biztonsági követelmények alapján valamint a terv monitorozását?

- informatikai biztonsági terv végrehajtásához szükséges utasításokat, előírásokat, eljárásokat az informatikai személyzet és a felhasználók számára?

� Jelenleg működnek az azonosítási, hitelesítési és hozzáférési kontrollok az adatok on-line elérésénél a(z)

- illetéktelen hozzáférés megelőzésére (jogosultsági rendszerek hálózathoz, alkalmazási rendszerekhez, egyéb eszközökhöz, funkciókra)?

- hozzáférési jogok minimálisan szükséges szintre való korlátozására?

- hozzáférések hitelesítésére (jelszavak képzése, változtatása, egyéb eljárások)?

- külső felek hozzáférési jogainak szerződés szintjén történőmeghatározására?

� Jelenleg működnek olyan speciális biztonsági kontrollok a - felhasználói nyilvántartások kezelésénél a nyilvántartások

kezelésének korlátozására, - az adat és rendszertulajdonosok privilegizált eléréseire, - a nyilvántartásokra vonatkozó kezelési, elérési jogok vezetés általi

időszakos ellenőrzésére és a nyilvántartások felhasználók általi ellenőrzésre?


- 104 -

� Vezetnek nyílvántartást a biztonságot érintő eseményekről, valamint - működik-e tájékoztató és intézkedési rendszer a biztonságot érintő

eseményekről? - működik-e az adatok biztonsági osztályba sorolása,? - létezik központi jogosultság kezelés, adminisztrálás? - létezik olyan biztonsági felügyeleti funkciók, eljárások, amelyek

automatikusan naplózzák a hozzáférések kezelését és egyéb biztonsági tevékenységeket és jelentéseket készítenek a szabályostól eltérő eseményekről, tevékenységekről?

- működik-e a biztonsági események, szabálysértések, beavatkozások központi értékelése?

- kialakították-e a biztonságos adatátviteli utakat és kriptográfiai, digitális aláírási technikákat és eljárásokat a fokozottan védendőinformációk kezelésére?

- kialakították-e a szükséges eljárásokat a rosszindulatú szoftverek (vírusok, stb.) preventív, detektív és korrektív kezelésére?

- kialakították-e a nyilvános hálózatra való kapcsolódáshoz szükséges folyamatos védelmet (megfelelő tűzfal architektúra, folyamatos monitorozáson és kockázati értékelésen alapuló beállítás aktualizálás)?

Költségelemzés és allokáció � Kialakították azon költség-számítási eljárásokat, amelyek megfelelő

vezetői információkat nyújtanak az információs szolgáltatások költségeiről az egyes szolgáltatások szintjére lebontva, illetve amelyek alapján a felhasználók azonosítani és mérni tudják, illetve előre meg tudják becsülni a felszámításra kerülő szolgáltatási költségeket?

Felhasználók képzése � Létezzik oktatási tematika a felhasználók képzésére? � Az oktatásom lebonyolítása szervezetten és ellenőrzötten kerülnek

lebonyolításra? � Létezik oktatás az informatikai biztonsági ismeretekrőlet, és

kötelezettségről? � Létezik oktatás az alkalmazási programok kezelésére, használatára?

Információ technológiai felhasználók segítése � Létezik megfelelő támogatás, illetve gyors segítségnyújtási lehetőség

(help desk) a(z)- hardver, - szoftver,- hálózati eszközök meghibásodására,,


- 105 -

- felhasználói rendszer hibái és működési zavarai esetén, valamint - ügyfelek problémáinak megoldására?

� Milyen módon rögzítik - naplózzák – és milyen gyakorisággal értékelik ki a felhasználói kérdéseket és azok megoldásának folyamatát?

� Milyen gyakorisággal készítenek elemzéseket, értékeléseket a felhasználói kérdésekről, problémákról?

� Milyen hatékonysággal működik a vezetői ellenőrzés a help-desk funkció megfelelő működésére vonatkozóan?

Konfiguráció menedzsment � Létezik naprakész és ellenőrzött nyilvántartás a hardver és hálózati

konfigurációs elemekről, valamint a szoftverekről? � Kialakították a standard konfigurációkat az egyes felhasználói

funkciókhoz? � Léteznek ellenőrzési eljárások az illetéktelen szoftver használat

felderítésére? � Léteznek beépített automatikus biztosítékok az illetéktelen szoftverek

telepítésének megakadályozására (szoftvare compliance)? � Működőképesek a szoftverek master példányainak tárolási rendjét,

amely biztosítja a megfelelő verziókövetést és a fejlesztési, tesztelési és éles rendszerektől való elkülönítést?

Probléma és eseménykezelés, naplózás � Milyen hatékonysággal működik problémakezelő rendszer a rendkívüli

események, problémák, hibák nyilvántartására, elemzésére? � Léteznek jelentési kötelezettségek a rendkívüli események, problémák,

hibák előfordulásakor? � Milyen szinten dokumentálják-e az egyes problémák okát és a

megoldás módját? � A rendkívüli helyzetekben szükséges ideiglenes jogosultságok

megadása, megszűntetése, adminisztrálása, milyen szinten szabályozott?

� Kik és milyen módszerrel határozták meg a rendkívüli helyzetekben végrehajtandó műveletek prioritási rendjét?

Adatkezelés, adatvédelem � Hogyan támogatják automatikus, számítógépes eljárások az

adatelőkészítési, adatrögzítési hibák felderítését, javítását (négyszem elve, duplikált rögzítés, kontroll összegek egyeztetése, logikai összefüggés ellenőrzések, stb.)?

� Milyen hatékonysággal működik-e a feladat és felelősség illetve jogosultság elhatárolás a(z)


- 106 -

- forrásdokumentumok előkészítésére, - adatbevitel, adatrögzítésére, - kontroll bevitel, illetve validálására, - visszautasított, ill. hibás tételek újra bevitelének előkészítésére?

� Létezik egyeztetés, ellenőrzés a forrásdokumentumokkal a törzsadat változásoknál és a paraméterváltozásoknál?

� Milyen hatékonysággal működnek-e a feldolgozási folyamatba beépített egyeztető kontrollok (pl. főkönyvi feladás, alkalmazási rendszerek közötti adatátadások esetében)?

� Milyen formában gondoskodnak a kimenő adatok, bizalmas információk védelméről, sértetlenségéről, az illetéktelen hozzáférés, a téves kézbesítés megakadályozásáról a papíralapú adatok esetén, az elektronikus adattárolók esetén valamint az adatátviteli hálózaton továbbított adatoknál?

� Milyen formában gondoskodnak a bizalmas információk védelméről az adathordozó eszközök, gépek selejtezésénél?

� Meghatározták, majd kialakították az adatok igények szerinti visszakereséséhez szükséges adattárolási struktúrákat?

� Meghatározták és kialakították a különböző adattípusok (ügyféladatok, üzemeltetési, biztonsági információk és szoftverek) tárolási feltételeit és megőrzési idejét?

� Meghatározták, majd kialakították a külső adathordozók (szalagok, kazetták, CD-k, stb.) nyilvántartásának, kezelésének, címkézésének, fizikai mozgatásának, használatának, hozzáférésének rendjét és a kapcsolódó felelősségeket?

� Meghatározták, majd kialakították a rendkívüli események utáni helyreállítási eljárásoknak megfelelő mentési stratégiát és eljárásokat?

� Kik és milyen gyakorisággal ellenőrzik a mentések használhatóságát? � Meghatározták, majd kialakították a mentések biztonságos és fizikailag

elkülönített helyen történő tárolását? � Meghatározták, majd kialakították az adatok archiválásának üzleti és

jogi követelmények szerinti rendjét? � Kik és milyen gyakorisságal ellenőrzik az adatállományokban és külső

adathordozókon tárolt adatok sértetlenségét?

Fizikai környezet menedzselése � Milyen szinten és ki által korlátozott és kontrollált a bejárás

(differenciált belépést biztosító kártya, kulcsok kiosztása, tárolása, stb.) az informatikai eszközöket tartalmazó helyiségekbe és a különleges védelmet igénylő helyiségekbe (gépterem, adattárolási helységek)?

� Milyen szinten és ki által korlátozott és kontrollált a hozzáférés (hardver kulcsok, képernyő védők, szekrénykulcsok kiosztása,


- 107 -

hozzáférése) az informatikai eszközökhöz, berendezésekhez (számítógépek, hálózati eszközök, kapcsolószekrények, tároló szekrények, stb.)?

� Milyen szinten és kik által biztosítják a különös védelmet igénylőhelyiségek, tárolók elrejtését, korlátozott fizikai azonosíthatóságát?

� Meghatározták, majd kialakították a megfelelő védelmi intézkedéseket és eljárásokat a környezeti veszélyforrásokra (pl. tűz, por, elektromosság, túlzott hőmérséklet illetve páratartalom, stb.) vonatkozóan?

� Rendelkeznek a szükséges szünetmentes tápegységekkel és generátorokkal a kritikus programok biztonságos működése (áramkimaradások és áramingadozások kiküszöbölése) érdekében?

Üzemeltetés menedzselése � Léteznek aktuális üzemeltetési eljárások? � Milyen szinten dokumentált az üzemeltetési rend, a napi, heti, stb. és a

hozzá kapcsolódó munkafolyamatok? � Milyen szinten működnek az üzemeltetési kontrollok (létezik

üzemeltetési napló - üzemeltetési statisztika, dokumentált a szabványos üzemeltetési dokumentumokon, illetve formanyomtatványokon az üzemeltetési folyamatok végrehajtása)?

� Kik - milyen módon és milyen gyakorisággal a vezetők az üzemeltetési eljárások eredményességét és betartását?

� Megfelelő-e az üzemeltetők képzettsége, vannak-e feladat specifikus képzések?

� Kik és milyen módon figyelik a hibák, panaszok előfordulását, elhárítását? Készítenek naplót vagy jegyzőkönyveket kiértékeléseket erről?

MONITOROZÁS, ELLENŐRZÉS

Monitoringra vonatkozó kérdések:� Ki lettek alakítva az informatikai szolgáltatásokra vonatkozó

teljesítménymutatók, és működnek teljesítménymérési eljárások? � Kik és milyen gyakorisággal értékeli ki, illetve hoghyan méri az

informatikai szolgáltatások teljesítményét, illetve azt a kitűzött célokhoz viszonyítva a kialakított teljesítménymutatókkal és mérési eljárásokkal?

� Kik és milyen módon vizsgálják a vezetés a felhasználók elégedettségét az informatikai szolgáltatások vonatkozásában?


- 108 -

� Készít az informatikai vezetés, a felső vezetés számára beszámolókat a kitűzött célok, tervek megvalósításáról?

Vezetői ellenőrzés a beépített belső kontrollok vizsgálata� Milyen módon működik a vezetői ellenőrzés, a folyamatba épített belső

kontrollok vizsgálatakor � Kik és milyen módon tárják fel a folyamatba épített ellenőrzések

hiányosságait? � Milyen gyakorisággal készülnek jelentések, illetve milyen szinten

adminisztrálják a vezetői ellenőrzések eredményeit?

Független szakértői vizsgálatok � Léteznek biztonsági és egyéb szempontú megfelelőségi vizsgálatok és a

kontrollok az új információ technológiai szolgáltatások (belső és külső) bevezetéséhez illetve a szolgáltatások környezeti feltételeknek megfelelő változáskövetéséhez (pl. tűzfal és egyéb biztonsági rendszerek bevizsgálása)?

� Léteznek hatékonysági vizsgálatok a külső szolgáltatásokra vonatkozóan?

� Léteznek vizsgálatok az informatikai szolgáltatások törvényi és jogszabályi megfelelőségére?

� Léteznek vizsgálatok az informatikai szervezet és a külső szolgáltatók közötti szerződéses kapcsolatok betartására?

Belső ellenőrzés� Létezik belső ellenőrzési szabályzat, illetve működik független belső

ellenőrzés? � Létezik kockázat értékelési módszertan? � Az informatikai ellenőrzést végző belső ellenőr rendelkezik

informatikai szakértői képzettséggel (CISA)? � Az informatikai belső ellenőr az elmúlt 2 évben milyen informatikai

ellenőrzéssel kapcsolatos továbbképző tanfolyamon vett részt? � Létezik belső ellenőrzési terv és az tartalmazza az információ

technológia és informatikai biztonság ellenőrzéséhez szükséges vizsgálatokat?

� Milyen szinten dokumentált a belső ellenőr informatikai vizsgálatok lebonyolításához szükséges vizsgálati / ellenőrzési programja, audit scope és vizsgálati módszer?

� Milyen szabályrendszer alapján készülnek a vizsgálatokról írásos belsőellenőri jelentések?

� Léteznek írásos jelentések, válaszreakciók (vezetői comment) a belsőellenőri jelentésekben foglaltak érvényesítéséről?


- 109 -

� A belső ellenőrzés vizsgálja a rendkívüli eseményekre vonatkozó jelentések, jegyzőkönyvek és naplók elkészítését, a biztonsági és adatvédelmi kontrollok megfelelő működését és adminisztrálását (mentések, jogosultságok, üzemeltetési naplók) valamint az informatikai folyamatokba épített belső kontrollok érvényesülését?

� Milyen szinten vesz részt a belső ellenőrzés az informatikai szabályzatok értékelésében, elfogadásában?

� Milyen szinten vesz részt a belső ellenőrzés az informatikával kapcsolatos folyamatok menetében az egyes szakaszat lezáró döntésekben (az informatikai eszközök beszerzésénél, az informatikai fejlesztési tevékenységeknél, a fejlesztők, szolgáltatók kiválasztásánál)?

� A biztonsági osztály, illetve a belső ellenőrzés milyen szinten és rendszerességgel elemzi a számítógépes rendszerek által készített naplófájlokat, valamint a hibák, panaszok és egyéb rendkívüli eseményekről készült nyilvántartásokat, naplókat és statisztikákat?

Külső könyvvizsgálat� Az éves könyvvizsgálat során a külső auditor milyen mélységben

vizsgálja az informatikai kontrollrendszer működését? � Készül az éves könyvvizsgálat során a külső auditor informatikai

vizsgálatának eredményéről írásos jelentés? � A külső auditor jelentésében foglaltak érvényesítéséről készülnek e

vezetői előterjesztések?

Documents

INFORMATIKA ELLENŐRZÉSI KÉZIKÖNYV