ÚTMUTATÓ RENDSZER ÉRTÉKELİKNEK

Átírás

1 ÚTMUTATÓ RENDSZER ÉRTÉKELİKNEK

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

3 Metaadat-táblázat Megnevezés Leírás Cím (dc:title) Útmutató rendszer értékelıknek Kulcsszó (dc:subject) IT biztonság; értékelés; útmutató Leírás (dc:description) Az elkészült e-közigazgatási alkalmazásokat, valamint az ezt biztosító informatikai rendszereket használatbavételük elıtt meg kell vizsgálni, hogy megfelelnek-e a rájuk vonatkozó biztonsági követelményeknek. A követelménytár tartalmazza a szolgáltató (informatikai) rendszerek megfelelıség vizsgálatára alkalmazható biztonság értékelési módszertant. A módszertan egyaránt meghatározza az értékelési bizonyítékok létrehozásához kapcsolódó rendszer tulajdonosi és rendszer integrátori feladatokat, illetve a biztonságot értékelık feladatait. Ez a dokumentum a rendszer értékelık számára biztosít kiegészítı útmutatást az értékelési módszertan néhány kiemelten fontos részterületéhez. Típus (dc:type) Szöveg, táblázat, ábra Forrás (dc:source) Kapcsolat (dc:relation) e-közigazgatási Keretrendszer egyéb dokumentumai Terület (dc:coverage) KOP-ok során megvalósuló projektek, központi IT fejlesztési projektek Létrehozó (dc:creator) e-közigazgatási Keretrendszer Kialakítása projekt Kiadó (dc:publisher) Miniszterelnöki Hivatal Résztvevı (dc:contributor) Hunguard Kft. Jogok (dc:rights) e-közigazgatási Keretrendszer Dátum (dc:date) Formátum (dc:format).doc Azonosító (dc:identifier) Nyelv (dc:language) Magyar Verzió (dc:version) V3 Státusz (State) Végleges Fájlnév (FileName) EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.doc Méret (Size) Ár (Price) Felhasználási jogok (UserRights) Korlátlan EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx 3

4 Verziókövetési táblázat A dokumentum neve Útmutató rendszer értékelıknek A dokumentum készítıjének neve Hunguard Kft A dokumentum jóváhagyójának neve A dokumentum készítésének dátuma Verziószám V3 Összes oldalszám 64 A projekt azonosítója E-közigazgatási keretrendszer kialakítása Változáskezelés Verzió Dátum A változás leírása V Elsı tartalomjegyzék V Elsı változat V Résteljesítésként átadott V Végleges változat EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx 4

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

6 Tartalomjegyzék 1. Elıszó Bevezetés A dokumentum célja A dokumentum felépítése Alkalmazási terület Rendelkezı hivatkozások Fogalom-meghatározások Útmutatók a rendszer értékelés kritikus területeihez Útmutató a behatolás teszteléshez Bevezetés Elméleti alapok Egy behatolás tesztelési modell A behatolás tesztelés gyakorlati megközelítése A legjobban használható értékelési eszközök Példák behatolás tesztelés forgatókönyvre Útmutató a rendszer sebezhetıségi vizsgálatához Útmutató a független sebezhetıség vizsgálat elvégzéséhez Sebezhetıségi adatbázisok Az ingyenesen használható eszközök elérési lehetıségei Útmutató az értékelési altevékenységek sorrendjére Lineáris megközelítés A sebezhetıség vizsgálatra koncentráló megközelítés A két megközelítés összehasonlítása és javasolt alkalmazásuk Mellékletek Bibliográfia Rövidítésgyőjtemény Fogalomtár Ábrák Képek Táblázatok Verziószám EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx 6

7 1. Elıszó Jelen dokumentum az e-közigazgatási Keretrendszer részét képezi. Az elkészült e-közigazgatási alkalmazásokat használatbavételük elıtt meg kell vizsgálni, hogy megfelelnek-e a rájuk vonatkozó biztonsági követelményeknek. A megfelelıség vizsgálatra alkalmazható biztonság értékelési módszertan a követelménytár alábbi dokumentumaiban található: Termékekre vonatkozó értékelési módszertan [1], Összetett termékekre vonatkozó értékelési módszertan [2], Rendszerekre vonatkozó értékelési módszertan [3]. A rendszer szintő értékelési módszertan felhasználja a rendszert alkotó összetevıkre (termékekre, illetve összetett termékekre) korábban elvégzett értékelési és tanúsítási munkák eredményeit. A rendszer szintő értékelési módszertan meghatározza az értékelési bizonyítékok létrehozásához kapcsolódó rendszer integrátori feladatokat, valamint a biztonságot értékelık feladatait. A rendszer szintő értékelési módszertanban meghatározott integrátori és értékelıi feladatok végrehajtásához két gyakorlati útmutató kapcsolódik: Útmutató rendszer integrátorok számára [4], Útmutató rendszer értékelık számára (jelen dokumentum), 2. Bevezetés 2.1. A dokumentum célja Jelen dokumentum a rendszer szintő értékelési módszertanban [3] meghatározott rendszer értékelıi feladatok végrehajtásához nyújt gyakorlati útmutatót. Feltételezi [3] tartalmának teljes ismeretét. A dokumentum célja a [3] által meghatározott rendszer értékelıi feladatok elvégzéséhez használható ismeretek nyújtása, s ezzel [3] gyakorlati szemlélető kiegészítése néhány fontos területen A dokumentum felépítése Az 1. fejezet elhelyezi a dokumentumot az e-közigazgatási Keretrendszeren belül, tájékoztatást adva a célközönségrıl és a kapcsolódó dokumentumokról. EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx 7

8 A 2. fejezet bevezetı információkat tartalmaz, megadva a dokumentum célját és felépítését. A 3. fejezet meghatározza az alkalmazás lehetséges területeit. A 4. és 5. fejezet a hivatkozásokat, illetve a fogalom-meghatározásokat tartalmazza. A 6. fejezet tartalmazza a dokumentum lényegi részét, 3 alfejezetben. A 6.1 alfejezet az egyik kritikus értékelıi altevékenységhez, a behatolás teszteléshez ad elméleti és gyakorlati útmutatást. Egy bevezetı rész (6.1.1) után áttekinti az elméleti alapokat (6.1.2), majd egy általánosan használható modellt ismertet a behatolás tesztelésre (6.1.3), mely hat különbözı szempontból osztályozza a lehetséges megközelítési és kivitelezési módokat. A behatolás tesztelés gyakorlati megközelítése alfejezet (6.1.4) a külsı támadó megközelítését is jellemzı alábbi sorrendet követi: elıkészületek (általános hálózati vizsgálatok), az operációs rendszerek alapkonfigurációira irányuló vizsgálatok, web szerverek vizsgálata, webes alkalmazások vizsgálata, adatbázisok vizsgálata. Az értékelık behatolás tesztelı munkájukhoz számos automatizált mőködést biztosító szoftvert használhatnak fel áttekinti a kipróbáltan legjobban használhatókat. A 6.2 alfejezet egy másik kritikus értékelıi tevékenységgel, a sebezhetıség vizsgálatával foglalkozik (melynek egyik altevékenysége a behatolás tesztelés). Elsı lépésben áttekinti az ilyen típusú vizsgálatokat (6.2.1). Ezt követıen a leginkább használható sebezhetıségi adatbázisokat (6.2.2), majd az ingyenesen használható szoftver eszközök elérési lehetıségeit adja meg (6.2.3). A 6.3 alfejezet a rendszer értékelési módszertan által meghatározott értékelıi feladatok végrehajtási sorrendjére ad javaslatot. Két lényegesen eltérı sorrendet ismertet, a lineáris (6.3.1) és a sebezhetıség vizsgálatra koncentráló (6.3.2) megközelítést, melyeket összehasonlítva javaslatot tesz a különbözı értékelési típusokban történı alkalmazásukra (6.3.3). Jelen dokumentumnak nincsenek mellékletei. A fejezetek kiegészítı információkat tartalmaznak (8. Bibliográfia, 9. Rövidítésgyőjtemény, 10. Fogalomtár, 11. Ábrák, 12. Képek, 13. Táblázatok, 14. Verziószám). 3. Alkalmazási terület A [3] által meghatározott rendszer értékelési módszertan, s így az ezt gyakorlati útmutatóval kiegészítı jelen anyag is elsıdlegesen a közigazgatási operatív programok keretében megvalósított szolgáltató rendszerek biztonsági értékelésére vonatkozik. Ezáltal a közigazgatási operatív programok végrehajtásával elkészülı szolgáltató rendszerekre irányuló megfelelıségi vizsgálatok eljárásrendjének részét képezi. Ugyanakkor az informatikai rendszerek biztonsági értékelési módszertana az elektronikus közigazgatáson kívül, a közszféra más területein, valamint a magánszférában is EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx 8

9 alkalmazhatók, minden olyan esetben, amikor rendszerek megfelelıség vizsgálatára, ezen belül biztonsági értékelésére van szükség. 4. Rendelkezı hivatkozások A jelen dokumentumban megfogalmazott irányelvek és követelmények az alábbi mértékadó dokumentumokon alapulnak: [1]: Termékekre vonatkozó értékelési módszertan (az e-közigazgatási Keretrendszer Kialakítása projekt keretében kidolgozott dokumentum, V2, ) [2]: Összetett termékekre vonatkozó értékelési módszertan (az e-közigazgatási Keretrendszer Kialakítása projekt keretében kidolgozott dokumentum, V2, ) [3]: Rendszerekre vonatkozó értékelési módszertan (az e-közigazgatási Keretrendszer Kialakítása projekt keretében kidolgozott dokumentum, V2, ) [4]: Útmutató rendszer integrátorok számára (az e-közigazgatási Keretrendszer Kialakítása projekt keretében kidolgozott dokumentum, V2, ) Az 1. táblázat a rendelkezı hivatkozások elérhetıségét adja meg. 1. táblázat - A rendelkezı hivatkozások elérhetısége Cím Külföldi elérhetıség Magyar elérhetıség Termékekre vonatkozó értékelési módszertan e-közigazgatási Keretrendszer Összetett termékekre vonatkozó értékelési módszertan e-közigazgatási Keretrendszer Rendszerekre vonatkozó értékelési módszertan e-közigazgatási Keretrendszer Útmutató rendszer integrátorok számára e-közigazgatási Keretrendszer 5. Fogalom-meghatározások Jelen dokumentum a [3]-ban meghatározott fogalmakon kívül egyéb külön meghatározandó fogalmakat nem használ. Jelen dokumentum feltételezi [3] tartalmának teljes ismeretét. 6. Útmutatók a rendszer értékelés kritikus területeihez A rendszerértékelés hasonlóan a termék- és összetett termék értékeléséhez a rendszer biztonsági elıirányzatból kiindulva vizsgálja a követelmények teljesülését, az egyes értékelt termékek- és rendszerek egymásra hatását. Az alábbiakban a legkritikusabb értékelési területek értékeléséhez nyújtunk segítı útmutatókat. EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx 9

10 6.1. Útmutató a behatolás teszteléshez Bevezetés Egy rendszer tesztelésében a szoftver fejlesztıknek, a rendszer integrátoroknak és a rendszer értékelınek eltérı feladatai és felelısségei vannak (lásd részletesebben ezt a kérdést [4]: 6.2.1). Egy szoftver termék fejlesztıjének csak a saját termékét kell tesztelnie, de ennek során a szoftverminıség legtöbb jellemzıjére figyelemmel kell lennie, köztük az alábbiakra: funkcionalitás, megbízhatóság, használhatóság, hatékonyság, karbantarthatóság, hordozhatóság. A termékekbıl rendszert összeépítı rendszer integrátor feladata és felelıssége kettıs: kihasználni a fejlesztık által megvalósított jellemzıket a rendszer integrálásánál, egyúttal biztosítani azt, hogy a különbözı fejlesztık által megvalósított jellemzık ne vesszenek el, ne sérüljenek a rendszer integrálás során. A rendszer integrátoroknak a (komponens, alrendszer és rendszer szintő) teszteléseknél az együttmőködı képességre (interoperabilitás) és különösen a biztonság szempontjaira kell koncentrálniuk, mivel ezek azok a tulajdonságok (segédjellemzık), amelyek különbözı termékekbıl integrált rendszerekben könnyen sérülhetnek. Egy rendszer értékelınek nincs lehetısége a komponens termékek teljes körő vizsgálatára és tesztelésére. Támaszkodnia kell a termék fejlesztık által végzett munkára, szerencsés esetben a termék biztonságát tanúsító független harmadik fél vizsgálati eredményeire, valamit a rendszer integrátor által végzett biztonsági tesztelés eredményeire. A rendszer tesztelés területén az értékelınek két speciális feladata van: Ellenırizni és független teszteléssel kiegészíteni az integrátor biztonsági tesztelését (az ASTE garanciaosztály keretében), behatolás tesztelést végezni a rendszerre (az ASVA garanciaosztály keretében). A behatolás tesztelés célja potenciális biztonsági sebezhetıségek felfedése. Alapvetıen az értékelı feladata és felelıssége, minthogy különleges (támadói) szemléletet, valamint speciális szaktudást és eszközöket igényel. A biztonsági tesztelést [4] részletezi. Az alábbiak a behatolás tesztelésre összpontosítanak Elméleti alapok A behatolás tesztelés helye az értékelési módszertanban A termékek, összetett termékek és rendszerek biztonsági értékelésére vonatkozó módszertanokban [1] - [3] fontos szerepet kap az értékelés tárgyára irányuló behatolás tesztelés. A továbbiak a rendszer értékelésre koncentrálnak, de a leírtak többsége termék és összetett termék értékelésre is érvényes. EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx 10

11 A behatolási tesztelés nem garantálja, hogy nem lehet sikeresen támadni a rendszert, de jelentısen csökkenti ennek a valószínőségét. A behatolási tesztelés nem helyettesíti a szokásos IT biztonsági tesztelést, és nem váltja ki az értékelés egyéb elemzéseit, vizsgálatait sem. Ugyanakkor a behatolás tesztelés a betetızése minden értékelıi elemzésnek és vizsgálatnak. Ez ad lehetıséget az STOE feltörésére. Persze a megközelítési módnak módszeresnek és ésszerőnek kell lennie. Számos körülményt figyelembe kell venni, közte a rendszer értékeinek esetleges sérülését is A behatolás tesztelés jellemzése A nyilvános hálózatokkal összekötött informatikai rendszerek biztonságát fenyegethetik olyan illetéktelen és a legtöbb esetben névtelen próbálkozók, akik a rendszerekhez akarnak férni. Ez a helyzet olyan módszerek igénybevételét teszi szükségessé, amely a támadók szemszögébıl vizsgálja a rendszereket, biztosítva hogy a tesztelés feltételei olyan valóságosak legyenek, amennyire csak lehetséges. Mőszaki-technológiai oldalról a behatolás tesztelés egy ellenırzött próbálkozás egy informatikai rendszer vagy hálózat védelmének áttörésére, megtalálva annak sebezhetıségeit. A tesztelı azonos vagy hasonló technikákat használ, mint amit egy valódi támadás esetén alkalmaznak. Az így feltárt sebezhetıségek ellen fel lehet készülni még azelıtt, hogy egy külsı próbálkozó használná ki ıket. A behatolás tesztelés nem vizsgálja a biztonsági funkciók érvényességét, legalábbis nem közvetlenül. Ez éles ellentétben áll a biztonsági teszteléssel. Bár a kockázatok sorrendiségét használja a behatolás tesztelés fókuszának meghatározásában, az elsıdleges cél az, hogy betörjünk a célrendszerbe. A behatolás tesztelés nem vizsgálja az alkalmazáson belüli adatáramlást forráskód szinten. Még ha forráskód bevonására is sor kerül a behatolás tesztelés keretében, ennek kifejezett célja a rendszerbe való betörés elısegítése. Ilyen esetekben a forráskód egy olyan lehetséges input, amely segíti a behatolás tesztelıt abban, hogy hova fókuszálja az erıit, de a behatolás tesztelés önmagában nem forráskód elemzés. A behatolás tesztelés 3 legfontosabb jellemzıje az alábbi: sebezhetıség vizsgálaton alapul (sebezhetıségek keresése az STOE-ban vagy annak üzemeltetési környezetében, majd ezek kihatásainak a vizsgálata), tesztek kialakításával és futtatásával jár, a sebezhetıségek kihasználhatóságának meghatározására irányul. Behatolás tesztelést különbözı célokból lehet végezni, illetve végeztetni: a) a technikai rendszerek biztonságának fejlesztése érdekében, b) a sebezhetıségek azonosítására, c) az IT biztonság külsı fél általi megerısítése (igazolása) céljából, d) a szervezeti és személyzeti infrastruktúra biztonságának javítása érdekében. Az IT behatolási teszt eredménye több kell legyen, mint a létezı sebezhetıségek felsorolása, ideális esetben megoldásokat is kell javasolni ezek kivédésére. EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx 11

12 A technikai rendszerek biztonságának fejlesztése érdekében végzett behatolási tesztek csak a technikai rendszerekre korlátozódnak (mint például a tőzfalak, routerek, web szerverek), a szervezeti és személyzeti infrastruktúra ilyenkor nem kerül közvetlen tesztelés alá. Példa erre egy olyan behatolási teszt, amelynek célja kifejezetten azt vizsgálni, hogy hozzáférhetnek-e jogosulatlan külsı felek egy szervezet LAN-jához az interneten keresztül. A lehetséges teszt eredmények lehetnek megtalált, szükségtelenül nyitva maradt portok a tőzfalon, sebezhetı verziójú internetes alkalmazások vagy operációs rendszerek. A sebezhetıségek azonosítása önmagában is fontos lehet. Például ha két szervezet összevonása esetén a két LAN-t is egyesíteni kell, szükség lehet annak tesztelésére, hogy az új LAN-ba nem lehet-e kívülrıl betörni. Ha ezt sikerül megtenni a behatolási tesztben, még az összevonás elıtt biztonságossá kell tenni a kapcsolatot, addig nem szabad egyesíteni a két hálózatot. Az IT biztonság külsı fél általi megerısítése céljából végeztetett behatolási teszt lehet önálló feladat és lehet egy általánosabb értékelési/igazolási eljárás egyik lépése is. Fontos megjegyezni, hogy a behatolási teszt csak egy adott idıpillanatban fennálló helyzetet tükröz, és ezért egy külsı fél által megerısített, igazolt biztonság szintrıl nem lehet a jövıre is érvényes következtetéseket levonni. A szervezeti és személyi infrastruktúra biztonságának javítása érdekében végzett behatolási tesztelés általában két területre összpontosít. Egyrészt a problémák észlelését és továbbítási eljárásait ellenırzi (incidens kezelés), a behatolási tesztelések hatókörének és/vagy agresszivitásának fokozatos növelésével. Másrészt az olyan social engineering technikák segítségével, mint például jelszavak kicsalása telefonon, fel lehet mérni a biztonsági tudatosság általános szintjét, a biztonság szabályzatok és a felhasználói nyilatkozatok hatásosságát. Egy informatikai rendszer értékelésén belül végrehajtott behatolás tesztelés célja az azonosított lehetséges sebezhetıségek kiaknázhatóságának megerısítése vagy megcáfolása (egy külsı fél által), vagyis a c) pontban meghatározott cél. Melléktermékként alkalmas az a) és b) célok elérésére is. A d) pontban meghatározottak azonban nem képezik részét egy mőszaki szempontú biztonsági értékelésnek, azok a szervezetet vizsgáló biztonsági auditok hatókörébe tartoznak. A behatolás tesztelésre is érvényes az értékelés egészére vonatkozó általános elvárás a megismételhetıségre. A behatolás tesztelés során biztosítani kell, hogy minden megállapítás feljegyezésre kerüljön, s ilyen módon a tesztek pontosan megismételhetık legyenek, eredményüktıl függetlenül. Az értékelésbıl származó összes korábbi elképzelését ebben a fázisban az értékelı teszt forgatókönyvekbe (szkriptek) építi be. Ez magában foglalja az STOE-ra vonatkozó nyilvánosan ismert sebezhetıségeket is. Azt is dokumentálni kell, hogy bizonyos sebezhetıségeket miért nem tesztelt az értékelı (pl. mert nem bizonyultak hozzáilleszthetınek az alkalmazáshoz, vagy mert kellı erıfeszítés után nem sikerült nyilvánosságra hozott teszt szkriptet szerezni futtatásra. EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx 12

13 A behatolás tesztelés forrása alapvetıen a sebezhetıség vizsgálat, azon belül is az alábbiak: a tervek vizsgálata, a biztonsági tesztelés eredményeinek elemzése, a mőködési környezet kiértékelése. Közvetett módon azonban az értékelés összes fázisa hozzájárul a behatolás tesztelési tevékenységhez. Az értékelés során összegyőjtött elképzelések összeállítása elızze meg a behatolás tesztelést. Vannak olyan értékelık, akik teszt jegyzéket vezetnek az értékelés során felmerült ötleteik rögzítésére. A behatolás tesztelés elıtt a korábban összegyőjtött ötletek áttekintésével meghatározható, hogy mely ötletek a megalapozottak. Ezekbıl teszt scriptek készíthetık. Fontos, hogy minden elképzelés leírásra kerüljön az értékelés során, még akkor is, ha azokat végül elvetjük A behatolás tesztelés típusai A behatolás tesztelés 3 fı típusa az alábbi: Pozitív. (Azt bizonyítja, hogy a funkcionalitás mőködik. Ezeket a teszteket a biztonsági tesztelés feltehetıen lefedi, de végrehajthatók itt is kiegészítı tesztek.) Negatív. (Azt próbálja bizonyítani, hogy a funkcionalitás nem mőködik. Ezeket a teszteket is végre lehet hajtani a biztonsági tesztelés során. Magában foglalhatja a korlátoknak vagy a megengedett tartományon kívül esésnek a tesztelését, vagy bármely olyan szempontét, amelyet az értékelı ki tud gondolni az STOE-re vonatkozó ismeretei alapján.) Összetett tesztelés. (A funkcionalitás több vonatkozását egyszerre teszteli, illetve több funkciót egyszerre vizsgál. Egy példa erre annak ellenırzése, hogy lehetséges-e bejelentkezni egy rendszerbe, mielıtt a naplózási funkció mőködésbe lépne. Másik példa erre annak megfigyelése, hogy ha megváltoztatjuk a szerepkörünket, az új szerepkörünkben rendelkezünk-e további privilégiumokkal.) Egyéb tesztek is vannak, amelyek formálisan nem illenek a fenti kategóriák egyikébe sem. Példák erre a <CNTRL>Z, <CNTRL,ALT,DELETE>, stb. Ezek a teszteket ki lehet alakítani negatív vagy összetett tesztként, minthogy megpróbálják aláaknázni az STOE funkcionalitását, de konkrétan meghatározott funkció célbavétele nélkül A behatolás tesztelés tervezése A tervezés a hatékony behatolás tesztelés legfontosabb szempontja. Ha nem tervezzük el, hogy milyen teszteket fogunk végrehajtani, nem lehetünk biztosak abban, hogy mindent leteszteltünk, vagy hogy mikor vagyunk készen. Egy másik fontos tényezı a sorrend, ahogyan a teszteket futtatjuk, minthogy ez hozzásegíthet a maximális eredmény eléréséhez a rendelkezésre álló idıtartam alatt. EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx 13

14 Vannak értékelık, akik szeretnek formális szkripteket kialakítani, mielıtt elkezdenék a formális tesztelést, hogy be tudjanak fejezni minden szkriptet a tesztelési látogatás során. Ez különösen hasznos akkor, ha a helyszínen tesztelünk; ez tudomásunkra juttatja, hogy meddig jutottunk el a teszteléssel, így lehetséges a befejezés idejének a tervezése, és lehetıséget nyújt arra, hogy idıt takarítsunk meg a tesztek továbbfolytatásához. Az értékelı szervezet saját helyszínén folyó tesztelés esetén (ha megvalósítható) az STOE folyamatosan rendelkezésre áll, és a tesztelést végre lehet hajtani bármikor, amikor ötletek felmerülnek. Ez azt jelenti, hogy az ötletek kipróbálhatók és finomíthatók, mielıtt formálisan lefuttatnánk. Az otthoni tesztelés elınye, hogy az értékelık több idıt fordíthatnak a tesztelésre, mint amikor a tesztelés az integrálás/üzemeltetés helyszínén történik. Hátránya, hogy néha nehéz biztosítani, hogy a tesztelés formális konfiguráció ellenırzés mellett legyen végrehajtva. Az STOE konfigurációja módosulhat a tesztelés részeként, ekkor a behatolás tesztek nem az STOE éles verziójára hajtódnak végre. A behatolás tesztelésre elvárt, hogy a tesztelés felülvizsgált és engedélyezett scriptek szerint legyen végrehajtva, és az STOE konfigurációja ismert és feljegyzett legyen minden behatolás tesztelési munkaszakasz esetében Kiegészítı tesztelés A behatolás tesztelés alapos tervezése esetén is szükség lehet kiegészítı tesztelésre. A tervszerő behatolás tesztelés során - ahogyan elırehaladunk - több ötletünk is támadhat, például amikor váratlan eredményt kapunk, amely további vizsgálatokat igényel. Az ilyen teszteket is formálisan fel kell jegyezni, majd felül kell vizsgálni, de már csak az (adhoc) teszt lefutása után. Tudnunk kell, hogy mikor hagyjuk abba a behatolás tesztelést: amikor már csak annyi rendelkezésre álló idınk maradt, hogy leállítsuk a tesztelést és megírjuk a jelentést. Feljegyzéseket kell készítenünk, hogy biztosak lehessünk abban, hogy minden tesztelés megtörtént, és az esetlegesen feltárt problémák késıbb újra elıállíthatók legyenek Viselkedés a rendszer integrátoraival és üzemeltetıivel Amennyiben a behatolás tesztelésre a rendszer integrálásának vagy üzemeltetésének helyszínén kerül sor, különösen fontos figyelembe venni az alábbiakat. A behatolás tesztelés meglehetısen bonyolult szituációk kialakításával járhat, több biztonsági funkciót és paramétert is érinthet. Ezek együttesen nem biztonságos állapotba juttathatják az STOE-t. Nem szabad megfeledkezni arról, hogy a fejlesztık és az rendszer integrátorok jelentıs idıt fordítottak a komponensek és az STOE elıállítására, és az értékelı dolga munkájuk megerısítése vagy kijavítása. Arra például biztosan nincs szükségük, hogy derüljünk azon, ha a STOE összeomlik. Egy értékelınek nem csak a határozat hozatal során szükséges az objektivitásra törekednie, hanem kulturált viselkedés várható el tıle kiélezett EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx 14

15 problémás helyzetekben, valamit az észrevételezési jelentések és egyéb jegyzıkönyvek megfogalmazásánál is. A megfelelı emberi kapcsolatok kialakítása a rendszer integrátorral nemcsak viselkedés kultúra és az objektivitás megırzésének kérdése. Az értékelınek azt is szem elıtt kell tartania, hogy egy helyszínen végrehajtott behatolás tesztelés során szüksége lehet a rendszer integrátor együttmőködésére, gyakorlati segítségére is. Másfelıl az értékelı a behatolás tesztelése és az eredmények jelentésbe foglalása során jogosan kívánhat meg bizonyos szintő visszavonultságot, elmélyülési lehetıséget. Különös figyelmet igényel az az eset, amikor a behatolás tesztelése egy éles szolgáltató rendszerben kerül sor. Ilyenkor a napközben végzett tesztelést a pozitív tesztelésre szükséges korlátozni, tekintetbe véve, hogy a rendszer tulajdonosnak szerzıdése lehet az ügyfelekkel a szolgáltatás szintjére vonatkozóan, tehát a normál üzemidı alatt nem maradhatnak szolgáltatás nélkül. A behatolás tesztelés végrehajtását követıen az STOE-t vissza kell állítani eredeti állapotába Egy tipikus behatolás tesztelési terv tartalma Egy tipikus behatolás tesztelési terv tartalma az alábbiakat: Teszt sorszám: hogy a teszt egyértelmően azonosítható legyen, Tárgy/téma: a teszt céljának összegzése (mit próbálunk tesztelni), A teszt eredete: honnan származik a teszt (dokumentált biztonsági funkciók, ismert sebezhetıségek), Kezdés/befejezés: mikor kezdıdött, és mikor fejezıdött be a teszt A teszt végrehajtója: aki futtatta a tesztet, A tesztelés ellenıre, jegyzıkönyvezıje: a teszt helyes végrehajtását ellenırzi személy, aki a jegyzıkönyvet alá is írja. Lépések: ezek lépésrıl lépésre részletezik, hogy mit kell megtenni a teszt végrehajtásához. A teszt lépések megkívánhatnak bizonyos alapfokú technikai ismereteket, de elegendıen részletesnek kell lenniük ahhoz, hogy biztosítva legyen, hogy ezeket végre lehessen hajtani, meg lehessen ismételni és az eredményeket újra elı lehessen állítani. Várt eredmények: a lépésekben megadott tevékenységektıl várható eredmények. Tényleges eredmények: azok a tényleges eredmények, amelyek a lépésekben megadott tevékenységek következtében keletkeztek. Végeredmény: a teszt kimenetele, megfelelt, nem felelt meg, nem meggyızı, megismétlendı. /Nem megfelelt végeredmény esetén meg lehet határozni egy másik futtatandó tesztet./ A behatolás tesztelés jellemzése, általános forgatókönyve A behatolás tesztelés különbözı formái alkalmazhatók: Távoli (vagy külsı) behatolás tesztelés során az értékelı az Interneten keresztül végzi vizsgálatát. A hálózat külsı kapcsolati pontjait vizsgálva keres behatolási pontot, EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx 15

16 biztonsági réseket, elsısorban a tőzfalakon és a DMZ-ben elhelyezett szervereken vagy routeren. Helyi (vagy belsı) behatolás tesztelés során az értékelı a helyi hálózat egy hosztján végzi vizsgálatát. Ennek során belsı támadást szimulál annak felderítése érdekében, hogy megkerülhetıek-e a hálózati hozzáférések korlátozásai, kivitelezhetı-e egy hamis megszemélyesítéses támadás. Fizikai hozzáférésen alapuló behatolás tesztelés során az értékelı vizsgálata arra terjed ki, hogy fizikai hozzáféréssel milyen adatokhoz lehet jutni, pl. telepíthetık-e kártékony programok CD, DVD, USB adathordozó behelyezésével. Egy más megközelítésben a behatolás tesztelés típusa attól függ, hogy a vizsgálatot végzı személy milyen információkkal rendelkezik a vizsgált rendszerrıl: Fekete dobozos behatolás tesztelésnél a vizsgálatot végzı személy semmilyen elızetes információval nem rendelkezik a rendszer infrastruktúrájáról és alkalmazásokról. Fehér dobozos behatolás tesztelésnél a vizsgálatot végzı személy minden információ birtokában van úgy, mint a rendszer adminisztrátora. Szürke dobozos behatolás tesztelésnél a vizsgálatot végzı személy egy szinten van a rendszer felhasználóival, célja a jogosultságok kijátszása. Egy rendszer behatolás tesztelésének lépései függnek a vizsgálat típusától (fekete, fehér, szürke). Természetesen a legkevesebb kiinduló információval rendelkezı vizsgálat tartalmazza a legtöbb lépést, mivel a vizsgálónak össze kell győjteni a kiinduló információkat a szimulált támadáshoz. Az alábbiak a fehér dobozos megközelítést követik, hiszen mindkét másik megközelítés ennek részét képezi. A szakirodalom egy része a következı fázisokat különíti el egy behatolás tesztelés során: a) Elıkészületek (E) aa) passzív és aktív felderítés ab) pásztázás (szkennelés) b) Kiaknázás (K) ba) hozzáférés bb) a hozzáférés megtartása c) Lezárás (L) ca) a nyomok elfedése Minthogy az értékelı által végzett behatolás tesztelés célja a rendszer sebezhetıségének vagy ezek hiányának kimutatása, az értékelık által alkalmazott forgatókönyvek a fenti lépések közül nem részletezik a hozzáférés megtartását és a nyomok elfedését. (Egy értékelı számára a sikeres hozzáférés már negatív végeredmény, s a nyomok eltüntetésére sem kell energiát fordítania.) A szőkebben a behatolás tesztelés folyamatára koncentráló megközelítés szerint a következı lépéseket kell követni: Információk kutatása a célrendszerrıl: Az internetrıl elérhetı számítógépekhez kell tartozzon egy hivatalos IP cím. Szabadon elérhetı adatbázisokban találni információkat arról, hogy milyen IP címek blokkolódnak a szervezetnél. EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx 16

17 A célrendszer által nyújtott szolgáltatások vizsgálata (szkennelés): A tesztelt számítógépeken port-szkennelést lehet végezni, a nyitott portok utalnak a hozzájuk tartozó alkalmazásokra. Rendszerek és alkalmazások azonosítása: A fingerprinting technika segítségével megszerezhetıek az operációs rendszerek és alkalmazások nevei és verziói. Sebezhetıségek kutatása: A győjtött információk segítségével hatékonyan lehet információt győjteni az operációs rendszerek és alkalmazások sebezhetıségeirıl. Sebezhetıségek kihasználása: A talált sebezhetıségek segítségével jogosulatlan hozzáférést lehet szerezni a rendszerhez vagy további támadást lehet elıkészíteni Egy behatolás tesztelési modell A BSI egy tanulmánya [A Penetration Testing Model - Study] az értékelık számára is jól használható modellt állít fel a behatolás tesztelésre. Az 1. ábra által bemutatott osztályozás ebbıl a tanulmányból való. Szempont: Behatolás teszt 1. Információs bázis Fekete doboz Fehér doboz 2. Agresszivitás Passzív / szkennelés Óvatos Kiszámított Agresszív 3. Hatókör Teljes Korlátozott Fókuszált 4. Megközelítés Rejtett / óvatos Nyílt / elhíresztelt 5. Technika Hálózatalapú Egyéb kommunikációk Fizikai hozzáférés Social engineering 6. Kiindulási pont Külsı Belsı Forrás - BSI: A Penetration Testing Model (Study) 1. ábra - A behatolás tesztelés lehetséges osztályai Az 1. ábra bal oldalán a behatolási tesztek hat különbözı szempontja található, a jobb oldal pedig egy fa diagramon ábrázolja a tulajdonságok különbözı értékeit. Bár a különbözı szempontok amennyire csak lehet függetlenek egymástól, mégsem minden lehetséges kombináció vezet értelmes behatolási teszthez. Például egy agresszív teszt EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx 17

18 általában nagyon gyorsan azonosítható, ezért általában nem ideális rejtett megközelítéssel együtt használni. Egy nyílt behatolási teszt sem megfelelı, ha például ennek során bizalmas információt kell megszerezni olyan alkalmazottaktól, akiket figyelmeztettek, hogy social engineering technikákat alkalmazhatnak rajtuk. A rendszer értékelı által végzett behatolási tesztelésre pedig egyéb korlátok is vonatkoznak, melyet az alábbiakban részletezünk szempont: Információs bázis Információs bázis: Milyen kezdeti ismeretekkel bír a teszt végrehajtója a célhálózatról? Megkülönböztetünk fekete doboz tesztelést, ahol semmi belsı tudással nem rendelkezik a tesztelı, és fehér doboz tesztelést, ahol belsı információk is rendelkezésre állnak: A fekete doboz teszt valósághően szimulál egy internetes támadó által elkövetett támadást. A támadónak nyilvánosan hozzáférhetı adatbázisokban kutatnia kell a szükséges információk után, vagy kívülállóként vizsgálódnia kell. A fehér doboz teszt olyan támadást szimulál, amit egy (régebbi) alkalmazott vagy egy olyan külsıs követ el, aki részletes ismeretekkel rendelkezik bizonyos területekrıl. Ennek a tudásnak a mértéke a korlátozottól (ilyennel rendelkezhet egy alkalmazott, aki csak rövid ideig dolgozott a cégnél) egészen a rendszert mélyen ismerıig terjedhet (ilyen lehet egy külsı IT szolgáltató, aki a biztonsági rendszereket telepítette). Az értékelı elvileg mindkét típusú behatolási tesztelést végezheti. Ugyanakkor az értékelı számára általában minden fehér dobozos teszteléshez szükséges információ rendelkezésére áll, így a fekete dobozos megközelítést legfeljebb demonstrációs megfontolásokból, vagy egy feltárt sebezhetıséghez szükséges támadási képesség meghatározására használja. Kivételt képez az alap garanciacsomag, melynél az értékelı csak automatikus eszközökkel végrehajtott sebezhetıség elemzést végez. Ez esetben fekete dobozos behatolási tesztelést kell csak végrehajtania szempont: Agresszivitás Agresszivitás: Milyen agresszív lehet a tesztelı a tesztelés alatt? Az agresszivitás négy szintjét határozza meg a tanulmány: A legalacsonyabb szinten passzív - a tesztelési célokat csak passzívan lehet vizsgálni, vagyis a talált sebezhetıségeket nem szabad kihasználni. A második szinten óvatos az azonosított sebezhetıségeket csak akkor lehet kihasználni, ha a tesztelt rendszernek nem lehet baja. Például ilyen az ismert alap jelszavak kipróbálása vagy a hozzáférés kipróbálása könyvtárakhoz a web szerveren. A következı fokozatban - kiszámított a tesztelı olyan sebezhetıségeket is kipróbálhat, amelyek a rendszer zavarához vezethetnek. Ilyen lehet például a jelszavak automatikus kipróbálása, vagy az ismert buffer túlcsordulásos hibák kihasználása a EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx 18

19 pontosan azonosított rendszereken. Mielıtt a tesztelı ezeket megtenné, a tesztelınek figyelembe kell vennie milyen eséllyel lesz sikeres a támadás, és milyen súlyosak lehetnek a következmények. A legmagasabb szinten - agresszív a tesztelı kipróbálja az összes lehetséges sebezhetıséget, pl. buffer overflow hibákat használ ki olyan rendszereken is, amelyek nincsen teljesen azonosítva, vagy a biztonsági rendszereket szándékos túlterheléssel deaktiválja (Denial of Service (DoS) támadások) A tesztelınek tisztában kell lennie azzal, hogy tesztelt rendszer mellett, a szomszédos rendszerekben vagy hálózati komponensekben is hibák történhetnek a tesztelés hatására. Az értékelınek elsısorban passzív és óvatos behatolási tesztelést kell alkalmaznia. Kivételes esetben alkalmazhatja a kiszámított variánst is, de csak teszt környezetben és a megfelelı helyreállítás lehetıségének ellenırzése után. Semmilyen körülmények között nem alkalmazhat agresszív behatolási tesztelést szempont: Hatókör Hatókör: Melyik rendszereket kell tesztelni? A hatókör szempontjából az alábbi osztályok vannak: Fókuszált a behatolási teszt, ha csak egy meghatározott biztonsági tartományt, alrendszert vagy szolgáltatást kell tesztelni. Egy ilyen teszt természetesen csak a tesztelt rendszerekrıl szolgáltat információkat; nem ad általános információt az IT biztonságról. Korlátozott behatolási teszt esetén csak korlátozott számú alrendszert vagy szolgáltatást kell vizsgálni. Például minden rendszert a DMZ-ben, vagy a funkcionális egység részét képezı rendszereket. A teljes behatolási teszt az egész vizsgált rendszert érinti. Meg kell jegyezni, hogy még a teljes tesztben is bizonyos alrendszerek - például külsıleg hosztolt alrendszerek - esetén elıfordulhat, hogy nem lehetséges a tesztelés. Kezdeti értékelés esetén ajánlott egy teljes behatolási tesztelést elvégezni, biztosítva hogy nem maradt olyan biztonsági kibúvó, ami nem lett letesztelve. A behatolási teszthez szükséges idı közvetlenül függ a vizsgált rendszer hatókörétıl. A különbözı valós konfigurációkkal is egyedileg kell foglalkozni. Egy tervezett felülvizsgálati értékelés esetén érdemes a korlátozott behatolási tesztelést választani, biztosítva azt is, hogy a rendszeres idıközönként (pl. évente) megismételt felülvizsgálatok elıbb utóbb a teljes rendszert is lefedjék. Rendkívüli felülvizsgálati értékelés esetén a fókuszált behatolási tesztelés a javasolt, értelemszerően a rendszer módosított vagy bıvített részeire összpontosítva a vizsgálatot szempont: Megközelítés Megközelítés: Mennyire legyen "látható" a csapat a tesztelés közben? EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx 19

20 Ha az elsıdleges biztonsági rendszerek mellett másodlagos rendszereket mint pl. IDS, szervezeti vagy személyi struktúra (pl. problématovábbítási eljárások) is tesztelni kell, a tesztelési megközelítést ehhez kell igazítani. Rejtett az a behatolási tesztelés, amely csak olyan módszereket alkalmaz, amelyek nem utalnak támadásra. Ha a rejtett megközelítés nem hoz eredményt, nyílt módszerek alkalmazásával fehér dobozos tesztet kell végezni, mint például port-szkennelés egy közvetlen kapcsolaton keresztül. Az értékelı elvileg mindkét típusú behatolási tesztelést végezheti. A másodlagos rendszereken és a létezı problématovábbítási eljárásokon végzett behatolási teszteknek - legalábbis kezdetben rejtettnek kell lenniük. A nyílt módszerek alkalmazásánál a megrendelı alkalmazottai is részt vehetnek a tesztelésen. Ez különösen ajánlott a kritikusabb rendszerek esetén, mert ebben az esetben a tesztelık gyorsabban tudnak reagálni a felmerülı váratlan problémákra szempont: Technika Technika: Milyen technikák használhatóak a tesztelésre? Egy hagyományos behatolási teszt esetén a rendszerek csak a hálózaton keresztül támadhatók. Ezek mellett használhatók fizikai támadások különbözı típusai és social engineering technikák is. A hálózat-alapú behatolási teszt a normál eljárás, és a tipikus hacker támadást szimulálja. A legtöbb IT hálózat jelenleg TCP/IP protokollt használ, ezért ezeket a teszteket IP alapú behatolási teszteknek is hívják. A TCP/IP hálózatokon kívül vannak más kommunikációs hálózatok, amelyeket támadásokban használhatnak. Ezek lehetnek a telefon és fax hálózatok, vezeték nélküli hálózatok a mobil kommunikációra, pl. az IEEE (b)-n alapuló hálózatok és a bluetooth technológia. Fizikai támadás. Manapság a biztonsági rendszerek (pl. tőzfalak, stb.) széles körben elterjedtek, és egy ilyen rendszer kialakítása általában olyan magas szintő biztonságot nyújt, hogy nagyon nehéz, ha nem lehetetlen egy ilyen rendszert eredményesen támadni. Gyakran könnyebb és gyorsabb megszerezni a kívánt vagy szükséges adatokat egy jelszóval nem védett munkaállomásból, ha sikerül bejutni az épületbe és/vagy a szerver szobába fizikai támadás útján.. Az ember gyakran a leggyengébb láncszem a biztonsági láncban, ezért a social engineering technikák, amelyek az emberek nem megfelelı biztonsági tudását és alacsony biztonság tudatosságát használják ki, gyakran sikeresek. Ezeket a teszteket egy általános biztonsági szabályzat bevezetése után érdemes elvégezni, így fel lehet mérni a megvalósítás és elfogadottság mértékét. A hamis feltételezések a biztonsági szabályzat vélt hatásosságáról gyakran vezetnek olyan biztonsági kockázatokhoz, amelyeket a helyzet helyes felmérése esetén, idejében mérsékelni lehetett volna. A rendszer mőszaki biztonságát értékelı az elsı két típusú behatolási tesztelést végezheti. EKK_ekozig_utmutato_rendszer_ertekeloknek_080919_V3.docx 20