ÚTMUTATÓ RENDSZER INTEGRÁTOROK SZÁMÁRA

ÚTMUTATÓ RENDSZER INTEGRÁTOROK SZÁMÁRA

Útmutató rendszer integrátorok számára

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_integratoroknak_080919_V3.docx

2


Metaadat-táblázat Megnevezés Cím (dc:Title) Kulcsszó (dc:Subject) Leírás (dc:Description)

Típus (dc:Type) Forrás (dc:Source) Kapcsolat (dc:Relation) Terület (dc:Coverage) Létrehozó (dc:Creator) Kiadó (dc:Publisher) Résztvevı (dc:Contributor) Jogok (dc:Rights) Dátum (dc:Date) Formátum (dc:Format) Azonosító (dc:Identifier) Nyelv (dc:Language) Verzió (dc:Version) Státusz (State) Fájlnév (FileName) Méret (Size) Ár (Price) Felhasználási jogok (UserRights)

Leírás Útmutató rendszer integrátorok számára IT biztonság; értékelés; útmutató 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 integrátorok 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. Szöveg, táblázat e-Közigazgatási Keretrendszer egyéb dokumentumai KOP-ok során megvalósuló projektek, központi IT fejlesztési projektek e-Közigazgatási Keretrendszer Kialakítása projekt Miniszterelnöki Hivatal Hunguard Kft e-Közigazgatási Keretrendszer 2008.09.19. .doc Magyar V3 Végleges EKK_ekozig_utmutato_rendszer_integratoroknak_080919_V3.doc

Korlátlan


3


A dokumentum neve A dokumentum készítıjének neve A dokumentum jóváhagyójának neve A dokumentum készítésének dátuma Verziószám Összes oldalszám A projekt azonosítója

Verzió V0.1 V1 V2 V3

Dátum 2008.05.21. 2008.07.20. 2008.07.30. 2008.09.19

Verziókövetési táblázat Útmutató rendszer integrátorok számára Hunguard Kft 2008.09.19. V3

39 E-közigazgatási keretrendszer kialakítása

Változáskezelés A változás leírása Elsı tartalomjegyzék Elsı változat Részteljesítésként átadott Végleges változat


4


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

Leírás 1. fejezet 2. fejezet

nincs 9. fejezet nincs nincs 5. fejezet V3 nincs


5


Tartalomjegyzék 1. 2.

Elıszó.............................................................................................................................................................. 7 Bevezetés ........................................................................................................................................................ 7 2.1. A dokumentum célja ............................................................................................................................ 7 2.2. A dokumentum felépítése .................................................................................................................... 8 3. Alkalmazási terület ......................................................................................................................................... 8 4. Rendelkezı hivatkozások................................................................................................................................ 9 5. Fogalom-meghatározások ............................................................................................................................... 9 6. Útmutatók a rendszer integrálás kritikus területeihez ..................................................................................... 9 6.1. Gyakorlati útmutató a biztonságos rendszer integrálásra..................................................................... 9 6.1.1. Operációs rendszerek helyes konfigurálása................................................................................... 10 6.1.2. Web szerverek védelme ................................................................................................................ 12 6.1.3. Webes alkalmazások védelme....................................................................................................... 13 6.1.4. Adatbázisok védelme .................................................................................................................... 14 6.2. Útmutató a rendszer biztonsági teszteléséhez .................................................................................... 15 6.2.1. Eltérı feladatok és felelısségek a tesztelésben ............................................................................. 16 6.2.2. Különbözı tesztelési típusok......................................................................................................... 18 6.2.3. Tesztelési lehetıségek a szoftver különbözı életciklus fázisaiban ............................................... 30 6.3. Biztonsági hibajavítás, javítócsomagok kezelése............................................................................... 34 6.3.1. A javítócsomagok alkalmazásának szerepe................................................................................... 34 6.3.2. Mérföldkövek a javítócsomagok alkalmazásában......................................................................... 35 7. Mellékletek ................................................................................................................................................... 38 8. Bibliográfia ................................................................................................................................................... 38 9. Rövidítésgyőjtemény .................................................................................................................................... 39 10. Fogalomtár.............................................................................................................................................. 40 11. Ábrák ...................................................................................................................................................... 40 12. Képek...................................................................................................................................................... 40 13. Táblázatok .............................................................................................................................................. 40 14. Verziószám ............................................................................................................................................. 40


6


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ó komponensekre (termékekre, illetve összetett termékekre) korábban elvégzett értékelési és tanúsítási munkák eredményeit. A rendszerek integrátorainak figyelembe kell venniük a biztonsági követelményeket, a rendszerben felhasznált értékelt, tanúsított termékek tanúsítására vonatkozó érvényességi feltételeket, de a rendszerértékelés elıkészítéséhez is meghatározott feladatokat kell teljesíteniük. 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 (jelen dokumentum), ― Útmutató rendszer értékelık számára [4].

2. Bevezetés 2.1.

A dokumentum célja

Jelen dokumentum a rendszer szintő értékelési módszertanban [3] meghatározott integrátori feladatok végrehajtásához nyújt gyakorlati útmutatót. Feltételezi [3] 6.1 alfejezetének (Elıkészítı feladatok informatikai rendszerek biztonsági értékeléséhez) ismeretét. A dokumentum célja a [3] által meghatározott rendszer integrátori 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.


7


2.2.

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. 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 rendelkezı 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 a biztonságos rendszer integrálásra ad gyakorlati útmutatást. Felhasználható a rendszer architektúra megtervezéséhez, a rendszer integrálásához, valamint számos értékelési bizonyíték elkészítéséhez. Egy tipikus rendszer alábbi biztonság-kritikus területeit tekinti át: ― az operációs rendszerek alapértelmezéső telepítésének (alapkonfigurációk) veszélyei, ― a web szerverek védelmére meghozandó általános biztonsági intézkedések, ― a webes alkalmazások védelmét szolgáló biztonsági ajánlások, ― az adatbázisok védelmét szolgáló javaslatok. A 6.2 alfejezet a rendszer biztonsági teszteléséhez nyújt útmutatást. Elıbb áttekinti a termék fejlesztık, rendszer integrátorok és biztonságot értékelık eltérı feladatait és felelısségeit a tesztelés területén (6.2.1). Ezt követıen áttekinti a különbözı tesztelési típusokat, (rámutatva a funkcionális és biztonsági tesztelés közötti különbségekre is (6.2.2), valamint a szoftverfejlesztés különbözı életciklus fázisaiban végzendı teszteléseket (6.2.3). A 6.3 alfejezet a biztonság szempontjából kritikus javítócsomagok kezelését tárgyalja. Jelen dokumentumnak nincsenek mellékletei. A 8. - 14. 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


8


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, 2008.06.08) [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, 2008.06.08) [3]: Rendszerekre vonatkozó értékelési módszertan (az „e-Közigazgatási Keretrendszer Kialakítása” projekt keretében kidolgozott dokumentum, V2, 2008.08.01) [4]: Útmutató rendszer értékelık számára (az „e-Közigazgatási Keretrendszer Kialakítása” projekt keretében kidolgozott dokumentum, V2, 2008.08.20) 1. táblázat - A rendelkezı hivatkozások elérhetısége Cím Termékekre vonatkozó értékelési módszertan Összetett termékekre vonatkozó értékelési módszertan Rendszerekre vonatkozó értékelési módszertan Útmutató rendszer értékelık számára

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

Magyar elérhetıség e-Közigazgatási Keretrendszer e-Közigazgatási Keretrendszer e-Közigazgatási Keretrendszer 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 ugyanakkor feltételezi a [3]-ban meghatározott fogalmak ismeretét.

6. Útmutatók a rendszer integrálás kritikus területeihez 6.1.

Gyakorlati útmutató a biztonságos rendszer integrálásra

Az alábbi útmutatót érdemes már a rendszer architektúrájának megtervezésekor, majd a rendszer összeépítése (integrálása) során figyelembe venni. Ebben a megközelítésben az alábbi értékelési bizonyítékok elkészítéséhez nyújt segítséget: ― biztonsági architektúra leírás (ASDV_ARC, lásd [3] 6.1.5.2), ― rendszer interfész specifikáció (ASDV_SIS, lásd [3] 6.1.5.3),


9


― rendszer biztonsági terv (lásd ASDV_SDS, lásd [3] 6.1.5.4). Az alábbiakban megfogalmazott javaslatok ugyanakkor elsısorban a már integrált rendszer biztonságos konfigurálását segítik. Ebben a megközelítésben az alábbi értékelési bizonyítékok elkészítéséhez nyújt segítséget: ― Elıkészítési útmutató (ASGD_PRE, lásd [3] 6.1.6.1), ― Konfigurálási útmutató (ASGD_CON, lásd [3] 6.1.6.2). A következı logikai sorrendet követjük: ― az operációs rendszerek alapértelmezéső telepítésének (alapkonfigurációk) veszélyeinek a kivédése ellenırzı listák alkalmazásával (6.1.1), ― a web szerverek védelmére meghozandó általános biztonsági intézkedések (6.1.2), ― a webes alkalmazások védelmét szolgáló biztonsági ajánlások (6.1.3), ― az adatbázisok védelmét szolgáló javaslatok (6.1.4). 6.1.1. Operációs rendszerek helyes konfigurálása A telepített operációs rendszerek és szolgáltatásaik biztonságának növelésére ajánlások, biztonsági ellenırzı listák (security checklist) léteznek, melynek használata feltétlenül javasolt. Ezek lényege az alábbi két ellentétes szempont figyelembe vétele: ― az operációs rendszerek alapértelmezéső telepítése a biztonság szempontjából hiányos, ezért kiegészítésre, megerısítésre szorul, ― az operációs rendszerek alapértelmezéső telepítése számos olyan tulajdonságot és szolgáltatást biztosít, mely a biztonságra kifejezetten veszélyes, ezért ezek (hacsak a funkcionalitás oldaláról külön nem indokolható feltétlen szükségességük) eltávolítandók, korlátozandók, kikapcsolandók. 6.1.1.1. Windows rendszerek Windows rendszerek esetén az alábbi mértékadó dokumentum tartalmaz hasznos ötleteket: http://www.sans.org/score/checklists/Win2K_XP_Checklist.pdf A biztonsági ellenırzı lista fıbb javaslatai az alábbiak: ― Jelszóhasználat megerısítése (password length, password age, …), ― Kizárás megerısítése (lockout threshold, lockout duration,…), ― Naplózás megerısítése, ― Felhasználói jogosultságok megerısítése, ― Utolsó bejelentkezett felhasználó elrejtése a bejelentkezési ablakban, ― Fájlrendszer ellenırzése (NTFS), ― Rendszerkönyvtár megerısítse (System), ― Jelszófájl megerısítése (SAM), ― Antivírus szoftver beállítása, ― Naplóállományok védelmének beállítása, ― Registry megerısítése.


10


Javaslat_1: Tanulmányozzuk és fogadjuk el a fenti ellenırzı lista javaslatait. Kiegészítı javaslat a Null Session kizárására A Windows rendszerek Achilles sarkának emlegetett Common Internet File System / Server Message Block (CIFS/SMB) protokoll tartalmazza annak lehetıségét, hogy egy rendszerhez hitelesítés nélkül is csatlakozhatunk. Csatlakozás után felhasználókról, megosztásokról, registry kulcsokról kaphatunk információkat. A Microsoft tett ugyan már lépéseket, hogy kizárja ezt a Null Session szolgáltatást az egyes alaptelepítésekbıl, de ez a szolgáltatás szervereken (Windows Server 2003 és 2008) alapértelmezésben még mindig elérhetı. Javaslat_2: Állítsuk le az SMB szolgáltatást, ha nincs rá feltétlen szükség. Javaslat_3: Amennyiben az SMB szolgáltatásra feltétlenül szükség van: ― Biztosítsuk, hogy minden adminisztrátori jelszó különösen erıs legyen, és felhasználók ne kaphassanak adminisztrátori jogosultságot. (A számítógép által létrehozott rejtett felügyeleti megosztások - mint az ADMIN$ és a C$ - törlése nem megoldás, mert a Kiszolgáló szolgáltatás leállítása és újraindítása, vagy a számítógép újraindítása után a rendszer ismét létrehozza azokat.) ― Töröljük a felhasználók által létrehozott rejtett megosztásokat. (Ezeket újraindítás után a számítógép nem hozza ismét létre. A Microsoft Windows XP Home Edition nem hoz létre rejtett felügyeleti megosztásokat. Lásd még errıl részletesebben: http://support.microsoft.com/kb/314984) Kiegészítı javaslatok a megosztások kezelésére A megosztások (Shares) gyakran súlyos incidensekhez vezetnek, amennyiben a felhasználóknak megengedett megosztásokat létrehozni vagy létezı megosztásokba fájlokat másolni. Ha szabályozatlanul történik a megosztások kezelése, akkor számítani lehet rá, hogy érzékeny adatokat is meg fognak osztani, véletlenül is bemásolnak védendı információkat, mert az átlag felhasználók nincsenek tisztában a megosztások veszélyeivel. A megosztások ezenkívül nagyban elısegítik a kártékony programkódok, férgek, vírusok terjedését, mert számos károkozó terjed úgy, hogy csalogató névvel bemásolja magát az elérhetı megosztásokba, amelyet a gyanútlan felhasználó elindít, megnyit. Javaslat_4: a felhasználók számára tiltsák meg a megosztások létrehozását, vagy létezı megosztások fájlokba másolását. A közös projektekben dolgozó munkatársaknak hozzanak létre projektkönyvtárakat, s ezek jogosultságának megfelelı beállításával érjék el, hogy azt csak az arra jogosultak láthatják/írhatják. Alaptelepítésben a Windows rendszerek megosztják az összes partíciójukat (c$, d$,…), távoli adminisztrációs célokkal. Ezeket távolról fel lehet csatolni rendszergazdai jogosultsággal, vagyis local admin illetve domain admin joggal. Sikeres felcsatolás után távolról a partíció teljes tartalma hozzáférhetı, írható, olvasható. Helyi adminisztrátor jelszót gyakran nem is kell sokáig kutatni, mert a felhasználók (gyakran nem is tudatosan) adminisztrátori joggal használják a gépüket. Domain admin jogosultságot pedig a már ismertetett null session szolgáltatáson keresztül elérhetı kiinduló információk alapján lehet megpróbálni kitalálni.


11


6.1.1.2. Linux rendszerek Linux rendszerek esetén például a Sans féle „Linux Security Checklist” írás tartalmaz hasznos javaslatokat a biztonság növelésére. http://www.sans.org/score/checklists/linuxchecklist.pdf A biztonsági ellenırzı lista fıbb javaslatai az alábbiak: ― Boot és mentılemez készítése, ― Biztonsági javítócsomagok (system patches) rendszeres alkalmazása, ― Felesleges szolgáltatások letiltása, ― Kulcsfontosságú fájlok hozzáférésvédelme, ― Alap jelszópolitika, ― Root hozzáférés korlátozása, ― Szerver szoftverek árulkodó fejléceinek (banner) megváltoztatása, ― SSH kiszolgáló megerısítése, ― Csomagszőrı tőzfal beállítása, ― Inetd felesleges szolgáltatások kikapcsolása, ― Tcpwrapper alkalmazása, ― Naplózás beállítása, ― Biztonsági mentések beállítása, ― Kritikus fájlokon az integritás ellenırzése, ― Web szerver (Apache) megerısítése, ― Web szerver biztonsági mudul (mod_security) alkalmazása, ― Xwindow rendszer megerısítése, ― Biztonsági kernel bıvítések (pl.:LIDS, Selinux) alkalmazása, ― Email szolgáltatás megerısítése, ― Fájlmegosztások (Samba) megerısítése, ― Rejtjelezések beállítása (SSL), ― Antivírus szoftver alkalmazása. Javaslat_5: Tanulmányozzuk és fogadjuk el a fenti ellenırzı lista javaslatait. 6.1.2. Web szerverek védelme Az alábbi lista segíti a rendszeradminisztrátorokat, hogy a rendszerükben található web szerverek biztonságát növeljék. Általános biztonsági ajánlások: ― Bizonyosodjunk meg, hogy az összes web szerver szoftver és betöltött moduljai (Microsoft IIS, Apache, OpenSSL, PHP, mod_perl) naprakész, legfrissebb szoftvercsomagokat tartalmaznak, amelyek biztosítják, hogy a már ismert és publikált biztonsági hiányosságokat nem lehet kihasználni a szerver ellen. ― Ha a web szerver nem szolgál ki dinamikus tartalmakat (PHP, ASP, PERL), akkor gondoskodjunk róla, hogy a web szerver ne töltse be ezen lapok kiszolgálására képes modulokat (mod_php, mod_perl, stb.). Ezen dinamikus tartalmak moduljai a web szerverek leggyakrabban támadott pontjai. ― A legtöbb puffer túlcsordulásos támadás kivitelezésekor a támadó kód kikapcsolódik egy távoli szerverre, hogy onnan parancsot töltsön le. Az ilyen támadások


12


detektálására hasznos lehet, ha szőrjük / figyeljük a web szerverrıl kimenı kapcsolati kezdeményezéseket, mert ezek támadásra utalhatnak. ― Kapcsoljuk ki az autoindex funkciókat, amelyek megvédik a felderítésektıl a szerver azon könyvtárait, amelyekben nincs kezdıpont (index.html, index.php, stb.). ― Kapcsoljuk ki a szerveroldali alkalmazások hibakiírását, vagy naplózzuk ıket fájlba, mert a kliensnek kiküldött hibajelentések érzékeny adatokat tartalmazhatnak a rendszerrıl. Javaslat_6: Tanulmányozzuk és fogadjuk el a fenti általános biztonsági ajánlásokat. Microsoft specifikus biztonsági ajánlások: ― Ellenırizzük az IIS szerverünk konfigurációját a Microsoft honlapján található eszközökkel: URLScan és IIS Lockdown. ― Távolítsuk el a fölösleges ISAPI kiterjesztéseket. ― Ne futtassuk az Outlook Web Access szolgáltatást könnyen kitalálható elérési úton (/owa, /exchange, /mail). Védjük ezt a fontos szolgáltatást SSL protokollal a lehallgatástól. ― Minimalizáljuk a futtatható adminisztrációs tartalmakat, amelyek számos sérülékenységet tartalmaztak /tartalmazhatnak. Ilyenek: /msadc, /scripts, /_vti_bin ― Ha nem használjuk, kapcsoljuk ki a WebDAV szolgáltatást, ami megakadályozza a veszélyes PUT, DELETE, SEARCH kérések teljesítését. Javaslat_7: Tanulmányozzuk és fogadjuk el a fenti Microsoft specifikus biztonsági ajánlásokat. 6.1.3. Webes alkalmazások védelme Fontosabb biztonsági ajánlások webes alkalmazások esetén: ― Bizonyosodjunk meg, hogy a webes szolgáltatásban részt vevı szoftverek biztonsági frissítései folyamatosan települnek a rendszerre, nem tartalmaznak már ismert biztonsági réseket. ― A webes alkalmazás minden esetben ellenırizze a klienstıl érkezı adatokat, szőrje ki a veszélyes karaktereket (’ ; -- |). ― Javasolt a web szerver biztonsági modulok használata, például mod_security vagy Microsoft URLscan. ― Gondoljuk jól át a session használatot, használjuk a rendszer beépített session management-jét, állítsunk be a session azonosítókra lejárati idıt. ― Ha nem használunk szerver oldali nyelvet, ne legyen betöltve annak modulja. ― A háttéradatbázis használatakor a webes alkalmazás korlátozott jogosultsággal használja az adatbázist, ne tudjon más adattáblákhoz hozzáférni, rendszerszintő utasításokat végrehajtani (SA). Javaslat_8: Tanulmányozzuk és fogadjuk el a fenti biztonsági ajánlásokat. További hasznos információk és segédanyagok találhatók e témában az alábbi két dokumentumban: ― A Security Checklist for Web Application Design http://www.sans.org/reading_room/whitepapers/securecode/1389.php


13


― A Guide to Building Secure Web Applications and Web Services http://www.owasp.org/index.php/OWASP_Guide_Project 6.1.4. Adatbázisok védelme Az adatbázisok az informatikai rendszerek, ezen belül a webes szolgáltatások elengedhetetlen részét alkotják. Mivel a háttérben kiszolgáló funkciót ellátó adatbázisszervereken értékes információk találhatók, ezért az adatbázisszerverek a támadások gyakori célpontjai. A legtöbb hazai szervezet (köztük a közigazgatási szervek is) informatikai rendszerei SQL szervereket tartalmaznak. A legismertebb és leggyakrabban alkalmazott SQL szerverek az alábbiak: ― Microsoft SQL Server (MsSQL), ― Oracle, ― MySQL. 6.1.4.1. Általános biztonsági ajánlások SQL szerverek esetén SQL szerverek esetén általános biztonsági ajánlások az alábbiak: ― Bizonyosodjunk meg arról, hogy a telepített SQL szerverek alapértelmezett felhasználóinak (MsSQL esetén „sa” és „probe”, Oracle esetén „sys”, „system”, „scott”, „dbsnmp”, MySQL esetén „root”) megfelelıen erıs jelszó van beállítva. ― Szőrjük és ellenırizzük a kívülrıl megvalósítható adatbázishoz kapcsolódási lehetıségeket a beépített jogosultság kezelésével, illetve tőzfal alkalmazásával. Ezzel megakadályozható, hogy „bárki” belépési próbálkozásokat végezzen az SQL szerveren. Amennyiben a webes alkalmazás egy hoszton fut az SQL kiszolgálóval (ez nagyon gyakran így van), akkor nincs is szükség, hogy az SQL szerver távolról kapcsolatokat fogadjon el, tiltsuk ezt le. ― Az elıre telepített rendszerszintő tárolt eljárások hozzáférését korlátozzuk. ― Kísérjük figyelemmel az SQL szerverünket érintı biztonsági bejelentéseket, a javításokat azonnal telepítsük a rendszerre. Javaslat_9: Tanulmányozzuk és valósítsuk meg a fenti biztonsági ajánlásokat. Az SQL szerverek biztonságával kapcsolatos hasznos publikációkat és eszközöket találunk a következı oldalakon: ― www.sqlsecurity.com ― http://www.cgisecurity.com 6.1.4.2. Biztonsági ajánlás MsSQL szerverek esetén MsSQL szerverek esetén speciális biztonsági ajánlás a következı: Javaslat_10: Mivel az MsSQL szerver adminisztrátori jogosultságú felhasználója (sa) alaptelepítésben jelszó nélkül tud bejelentkezni egészen az SQL Server 2003 verzióig,


14


ezért lehetıleg ezt követı verziókat használjunk (melyek már nem engedik meg a jelszó nélküli bejelentkezést), vagy állítsunk be megfelelı erıs jelszót az "sa" felhasználónak. 6.1.4.3. Biztonsági ajánlások Oracle szerverek esetén Oracle szerverek esetén a TNS protokollon keresztül lehet csatlakozni a szerveren hallgató TNS listener szolgáltatáshoz. Ehhez a szolgáltatáshoz alaptelepítés esetén hitelesítés nélkül is lehet csatlakozni, sıt parancsok is futtathatók, akár az adatbázisrendszeren kívüli környezetben is. Javaslat_11: Tiltsuk meg az adatbázishoz való távoli hozzáférést. Javaslat_12: Amennyiben az adatbázishoz való távoli hozzáférés feltétlenül szükséges: ― Erısítsük meg a TNS listener alapértelmezett beállításait: állítsunk be jelszót a TNS listener számára, kapcsoljuk be a naplózását. ― Tőzfalszabályok alkalmazásával szőrjük az adatbázishoz kapcsolódásokat. A fentiekrıl részletesebben lásd az alábbi dokumentumot: ― Oracle Database Listener Security Guide: http://www.databasesecurity.com/oracle/Integrigy_OracleDB_Listener_Security.pdf 6.1.4.4. Speciális biztonsági ajánlások MySQL szerverek esetén MySQL szerverek esetén speciális biztonsági ajánlások a következık: Javaslat_13: A MySQL alaptelepítésekor létrejön egy saját „root” felhasználó, amelynek a jelszava üres. Ezt feltétlenül cseréljük le megfelelıen erıs jelszóra. Javaslat_14: További veszélyforrás lehet, ha a webes alkalmazások root felhasználóval kapcsolódnak az adatbázishoz, mert ennek jelszava gyakran visszakereshetı a konfigurációs állományokból. Ezért soha ne használjuk a webes alkalmazásunkban a MySQL root felhasználót az adatbázis mőveletek végrehajtására, hanem hozzunk létre egy új MsSQL felhasználót a webes alkalmazás számára. Az új felhasználó jogosultságát korlátozzuk az alkalmazás által használt adattáblák elérésére.

6.2.

Útmutató a rendszer biztonsági teszteléséhez

Ez az alfejezet az alábbi értékelési bizonyítékok elkészítéséhez nyújt segítséget: ― Tesztelési dokumentáció (ASTE_FUN, lásd [3] 6.1.8.1), ― Tesztlefedettség elemzés (ASTE_COV, lásd [3] 6.1.8.2), ― Tesztmélység elemzés (ASTE_DPT, lásd [3] 6.1.8.3), ― Regressziós tesztelés dokumentációja (ASTE_MOD, lásd [3] 6.1.8.5),


15


6.2.1. Eltérı feladatok és felelısségek a tesztelésben A teszteléssel kapcsolatban a szoftver termékek fejlesztıinek, a termékbıl rendszert összeépítı rendszer integrátoroknak, illetve a rendszer biztonságát értékelıknek eltérı feladataik és felelısségük van. 6.2.1.1. A szoftver termék fejlesztıjének feladata és felelıssége A szoftver termékek fejlesztıinek a szoftverminıség legtöbb jellemzıjére figyelemmel kell lenniük munkájuk során, köztük az MSZ ISO/IEC 9126 szabvány által megadott alábbiakra: ― Funkcionalitás (Azon tulajdonságok összessége, amelyek valamilyen kifejezett vagy elvárt igényt kielégítı funkciókra és ezek tulajdonságaira vonatkoznak. Segédjellemzıi: alkalmasság, pontosság, együttmőködés, alkalmazhatóság, biztonság.), ― Megbízhatóság (Azon tulajdonságok összessége, amelyek a szoftver azon képességére vannak hatással, hogy - adott feltételek között és adott idıszakon belül teljesítményszintjét fenntartsa. Segédjellemzıi: kiforrottság, hibatőrés, helyreállíthatóság.), ― Használhatóság (Azon tulajdonságok összessége, amelyek a használathoz szükséges ráfordításra, és az ilyen használat egyedi felmérésére vannak hatással, a felhasználók közvetlenül vagy közvetetten meghatározható körében. Segédjellemzıi: érthetıség, megtanulhatóság, üzemeltethetıség.), ― Hatékonyság (Azon tulajdonságok összessége, amelyek a szoftver teljesítményszintje és az ehhez felhasznált erıforrások mennyisége között fennálló kapcsolatra vannak hatással. Segédjellemzıi: idıigény, erıforrásigény.), ― Karbantarthatóság (Azon tulajdonságok összessége, amelyek konkrét változtatások pl. helyesbítés, továbbfejlesztés, külsı változásokhoz való illesztés - elvégzéséhez szükséges ráfordításokra vannak hatással. Segédjellemzıi: elemezhetıség, változtathatóság, stabilitás, tesztelhetıség.), ― Hordozhatóság (Azon tulajdonságok összessége, amelyek a szoftver azon képességére vannak hatással, hogy a szoftver egyik környezetbıl a másikba lehessen átvinni. Segédjellemzıi: adaptálhatóság, telepíthetıség, mőszaki megfelelıség, kiválthatóság.) A szoftver termékek (modul és termék szintő) tesztelésénél valamennyi fenti szempont figyelembe veendı, és ez elsısorban a termék fejlesztı feladata és felelıssége. 6.2.1.2. A rendszer integrátor feladata és felelıssége A termékbıl rendszert összeépítı rendszer integrátoroknak nincs lehetıségük a fenti jellemzık és segédjellemzık utólagos megvalósítására, megerısítésére, de még teljes körő vizsgálatára, tesztelésére sem. Az ı feladatuk és felelısségük kettıs: ― kihasználni a fejlesztık által megvalósított jellemzıket a rendszer integrálásánál (pl. telepíthetıség, változtathatóság, üzemeltethetıség), ― 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 (pl. együttmőködés, biztonság).


16


A rendszer integrátoroknak a (komponens, alrendszer és rendszer szintő) teszteléseknél döntıen az interoperabilitás és 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. Jelen útmutató a biztonsági tesztelésre irányul. Ugyanakkor nem szabad elfelejteni, hogy számos „hagyományos” szoftver hibának biztonsági kihatása is lehet. A hibás mőködés szinte kivétel nélkül elıre nem látott mőködés, s így ez lehetıséget biztosít a támadónak egy potenciális hiba kihasználására. Számos jól ismert sebezhetıség (mint pl. a puffer túlcsordulás, a formátum sztring hiba, a kettıs felszabadítás) rendszer összeomláshoz vezethet (feltéve, hogy véletlenül kerültek végrehajtásra és nem egy támadó direkt támadási kísérlete idézte elı ezeket). A rendszer összeomlás bizalmas adatokat is elérhetıvé tehet a diagnosztikai és adat kilistázások formájában. Még ha a szoftver nem is omlik össze egy hiba miatt, a belsı állapota megsérülhet, ami késıbb nem várt viselkedést eredményezhet. Maguk a hibakezelık is gyakran célpontjai a rosszindulatú támadóknak. A fenti okok miatt a hagyományos program hibákat is figyelembe kell venni a biztonsági tesztelés során. A rendszer integrátoroknak a (komponens, alrendszer és rendszer szintő) teszteléseknél tehát az interoperabilitás és a biztonság szempontjain túl a megbízhatóság szoftverminıség jellemzıre is kiemelt figyelmet kell fordítaniuk. 6.2.1.3. A rendszer értékelı feladata és felelıssége Egy informatikai rendszer értékelıjének feladata alapvetıen a rendszer biztonságára irányul. A biztonságra irányuló vizsgálata során az alábbiakra támaszkodhat: ― a rendszert alkotó szoftver termékek fejlesztıi által végzett tervezı/megvalósító/ ellenırzı munka, ez utóbbin belül a termék modul és termék szintő tesztelése (a szoftverminıségi valamennyi jellemzıje szerint), ― a rendszert alkotó szoftver termékek független értékelését elvégzı értékelık és tanúsítók eredményei (melyek döntıen az interoperabilitásra és a biztonságra irányultak), ― a rendszer integrátor által készített értékelési bizonyítékok, melyek elsısorban a biztonságra irányulnak, s tartalmazzák a komponens (termék), alrendszer és rendszer szintő biztonsági tesztelés eredményeit is. Ahogy a rendszer integrátoroknak nincs lehetıségük a termékek általános minıségi jellemzıinek teljes körő vizsgálatára, tesztelésére, úgy a rendszer értékelıknek sincs lehetıségük egy bonyolult rendszer termék komponenseinek teljes körő biztonsági vizsgálatára és tesztelésére. Egy rendszer biztonsága jelentıs mértékben azon múlik, hogy a komponensek fejlesztıi milyen megbízható munkát végeztek, illetve, hogy a biztonság szempontjából fontos (a biztonságot érvényre juttató és támogató) termékekre végeztek-e független értékeléseket.


17


A rendszer szintő biztonsághoz azonban kevés az alkotó termékek biztonsága, akár magas garanciaszinten értékelt és tanúsított termékek integrálását is el lehet rontani, helytelen koncepcióval, tervezéssel és konfigurálással, illetve hibás üzemeltetési paraméterek alkalmazásával. A rendszer integrátor által elvégzendı és dokumentálandó biztonsági tesztelés egy fontos eleme a rendszer biztonság megvalósításának. 6.2.2. Különbözı tesztelési típusok Jelentıs különbség van a szoftverek funkcionális, biztonsági és behatolás tesztelése között. A funkcionális tesztelés célja a szoftver megfelelıségének ellenırzése az általános szoftverminıségi követelményeknek. Ez alapvetıen a szoftver fejlesztı feladata és felelıssége. A biztonsági tesztelés célja a szoftver megfelelıségének ellenırzése a biztonsági követelményeknek. Termékek esetén ez alapvetıen a fejlesztı, míg rendszerek esetén a rendszer integrátor feladata és felelıssége. A (termék vagy rendszer) értékelıje ezt a tesztelést ellenırzi, egy mintavételezéssel kiválasztott részét megismétli, illetve független teszteléssel kiegészíti. A behatolás tesztelés célja potenciális biztonsági sebezhetıségek felfedése (a termékben vagy rendszerben). Ez 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. Az alábbiakban részletesen jellemezzük a funkcionális és biztonsági tesztelést. A behatolás tesztelés témáját [4] részletezi. Mivel a funkcionális tesztelés tartalmazza a biztonsági tesztelést is, s ez utóbbi útmutatónk elsıdleges irányultsága, ezért a funkcionális tesztelésnél is elsısorban biztonsággal kapcsolatos példákat tárgyalunk. 6.2.2.1. A funkcionális tesztelés A funkcionális tesztelés célja a szoftver megfelelıségének ellenırzése az általános szoftverminıségi követelményeknek. Ezen belül általában a legnagyobb hangsúly a funkcionális követelményeknek való megfelelésre esik („a szoftver úgy viselkedik-e, ahogy kell”). A funkcionális tesztelés bevett gyakorlata, hogy minden egyes (funkcionális) követelménynek megfelel egy szoftver elem, amely ezt a követelményt hivatott megvalósítani. Ebbıl következıen egy adott követelménynek való megfelelıséget ellenırzı tesztelı számára egyértelmő, hogy melyik szoftver (kód) elemet kell tesztelnie. Így általában hármas megfeleltetésbe hozhatók a követelmények, a kód elemek és a funkcionális tesztek. A negatív követelmények azonban kihívást jelentenek a funkcionális tesztelés fenti gyakorlata számára. A negatív követelmények olyan dolgokat határoznak meg, amit a szoftvernek nem szabad megtennie, ellentétben azokkal, amelyek azt mondják, hogy mit kell tenni. Negatív


18


követelményre két példa az alábbi: „a szoftver ne legyen érzékeny az SQL beszúrásos támadásra”, „a szoftver védjen a jelszó feltörési támadás ellen”. A negatív követelmények megfeleltetése egy adott kód elemre, illetve egy funkcionális tesztre problematikus lehet. Nyilvánvaló, hogy a példákban említett követelmények nem csak egy helyen kerülnek megvalósításra. Számos esetben a negatív követelmény által megjelenített kockázat csökkenthetı pozitív követelmény (másképpen fogalmazva ellenintézkedés) segítségével. Az SQL beszúrásos támadás kockázata például egy input ellenırzési fehérlista alkalmazásával csökkenthetı, amely nem tartalmazza az ilyen támadás kivitelezéséhez szükséges karaktereket. A jelszó feltörési támadás kockázata pedig például csökkenthetı úgy, hogy elıírjuk a felhasználói fiók letiltását adott számú sikertelen próbálkozás után. Az ilyen pozitív követelmények (ellenintézkedések) már a hagyományos megközelítéssel is tesztelhetık, és ez nem csak a helyes implementációt ellenırzi, hanem a kivédendı kockázat csökkentését is megerısíti. A funkcionális tesztelés kimutathatja egy hiba létezését, de alkalmatlan a hibák hiányának igazolására. E mögött az a gyakorlati probléma áll, hogy a tesztelı csak korlátozott számú tesztesetet próbálhat ki, és lehetséges, hogy ezekben jól mőködik a szoftver, de más esetekben mégsem. Ezért az ellenintézkedések tesztelése nem elég az érintett kockázat kivédésének a garantálására. A funkcionális tesztelésnek számos technikája van, az alábbiakban vázlatosan áttekintjük a legismertebbeket, [Risk-Based and Functional Security Testing] alapján. 6.2.2.1.1.

Követelmény alapú tesztelés

Egy adott követelményrendszerbıl a tesztek származtatása úgy történik, hogy minden követelményhez tartozik egy teszt készlet. A tesztesetek visszavezetésre kerülnek a követelményekre, hogy biztosítva legyen, hogy minden követelmény lefedésre került. Ez a technika a biztonsági tesztelés egyik alap technikája is. A biztonsági követelmények lefedését egy külön értékelési bizonyítékban [3] el is várja a rendszer integrátortól (lásd [3] ASTE_COV, 6.1.8.2). 6.2.2.1.2.

Tapasztalat alapú tesztelés

A tesztek származtatása a tesztelı szakértelmén, megérzésein és korábbi tapasztalatain alapul. Ez a teszt fajta csak akkor hatékony, ha képzett és tapasztalt tesztelı hajtja végre, különösen olyan speciális tesztesetek mellett, amelyek nem férnek bele más formális tesztekbe. Ez a fajta tesztelés elınyös lehet, ha a tesztelı közvetett bizonyítékokat fedezett fel egy sebezhetıséggel kapcsolatban, és utána kíván ennek járni. Az értékelık független biztonsági tesztelése során is gyakran alkalmazzák, az értékelı megérzéseinek kivizsgálására.


19


6.2.2.1.3.

Specifikáció alapú tesztelés

Adott egy specifikáció (ami lehet akár egy külsı interfész vagy egy API specifikációja), a tesztesetek pedig ebbıl akár automatikusan is származtathatóak (fıleg egy formális nyelven megírt specifikáció esetén). A biztonsági tesztelés során hasznos lehet olyan esetek tesztelése is, amelyek nem szerepelnek a specifikációban. 6.2.2.1.4.

A bemeneti tartomány ekvivalencia osztályokra bontása

A bemeneti tartományt részhalmazok összességére (ekvivalencia osztályokra) bontjuk, és az egy osztályba kerülı elemeket azonosnak tekintjük. Minden osztályra reprezentatív teszteket választunk (néha csak egyet-egyet). Az ekvivalencia osztályokra bontás a kimenetekre, az útvonal és a program struktúrára is végrehajtható. Ez a fajta tesztelés fıleg a kezelhetetlenül sok bemenet véges számra csökkentésére alkalmas. Biztonsági tesztelés esetén különösen arra kell ügyelni, hogy az ekvivalencia osztályok biztonsági szempontból hasonló teszteseteket fogjanak át. 6.2.2.1.5.

Határérték elemzés

A teszteseteket a változók bemeneti tartomány határaihoz közeli értékeibıl válasszuk, abból a megfontolásból, hogy sokszor a bemeneti értékek szélsı értékei közelében lép fel hiba. A biztonsági tesztelésben egy klasszikus példa a határérték elemzésre, amikor egy hosszú bemeneti sztringgel próbálunk potenciális puffer túlcsordulást elıidézni. Ez a tesztelés fajta arra a tapasztalatra épít, hogy a fejlesztık általában a nem biztonságos viselkedést nem látják elıre a határértékek közelében, mivel elsısorban az átlagos értékekre fókuszálnak. 6.2.2.1.6.

Hibatőrés tesztelés

A határérték elemzés egy speciális esete, amikor a teszteseteket a tartományon kívülrıl választják, ezzel tesztelve a szoftver robusztusságát a nem várt és hibás bemenetekkel kapcsolatosan. Ez hasznos a hibakezelés kipróbálására is. Biztonsági szempontból ez a tesztelés fajta azért fontos, mert az így elıidézett hibák nem biztonságos állapotot eredményezhetnek, akár érzékeny információk felfedésével is járhatnak (például a debug üzenetekben és a memória tartalom listázásában). 6.2.2.1.7.

Döntési tábla alapú tesztelés

A döntési táblázatok logikai kapcsolatokat teremtenek a feltételek (pl. bemenetek) és a tevékenységek (pl. kimenetek) között. Tesztesetek származtathatók az összes lehetséges feltétel és tevékenység kombináció szisztematikus számba vételével.


20


A biztonsági tesztelık gyakran olyan feltételekre koncentrálnak, amelyeket nem fednek le a követelmények vagy a specifikációk. 6.2.2.1.8.

Állapot alapú tesztelés

Modellezzük úgy a programot, mint egy véges állapotterő absztrakt gépet, és különbözı technikákkal válasszunk úgy teszteket, hogy azok lefedjék az állapotokat és az átmeneteket. Ez elsısorban tranzakció feldolgozó, reaktív és valós idejő rendszerek esetében lehet megfelelı. Biztonsági tesztelés esetén gyakran hasznos lehet olyan tranzakciókat kierıszakolni, amelyek nem szerepelnek a magasabb szintő terv dokumentumokban, mivel a sebezhetıségek gyakran akkor keletkeznek, amikor a szoftver egy nem várt állapotba lép. 6.2.2.1.9.

Vezérlési folyamat tesztelés

A vezérlési folyamat alapú tesztelés célja, hogy egy programban lefedjen minden utasítást, osztályt vagy blokkot (vagy ezek egy meghatározott kombinációját). Egyszerősítsük a programot egy irányított gráffá, és elemezzük a gráfot. Egy példa erre a döntés/feltétel lefedés. Ez a fajta tesztelés általában csak nagyon egyszerő programok esetén kivitelezhetı. 6.2.2.1.10.

Adatáramlás alapú tesztelés

Címkézzük fel a program vezérlési folyamat gráfját azzal az információval, hogy hogyan vannak a változók definiálva és használva. Használjuk az alábbi definíció/használat párokat (gyakran ezt d/h tesztelésnek is hívják): ha V egy változó és d egy olyan csúcs, ahol a V definiálva van, valamint a h egy másik csúcs, ahol ugyanaz a V használva van, ezen kívül létezik út a d-bıl a h-ba. A cél gyenge vagy potenciálisan helytelen program struktúra (d/h pár) keresése. Az adatáramlás tesztelést gyakran használják alrendszerek közötti interfész tesztelésére. 6.2.2.1.11.

Használat alapú és használati eset alapú tesztelés

Készítsünk teszteket a termék valóságos használata során mőködési profilok létrehozásával, vagy használati esetek létrehozásával. Esetenként lehetıség van arra, hogy következtetéseket vonjunk le a késıbbi megbízhatóságról a teszt eredményekbıl (feltéve, hogy van egy statisztikailag helyes mőködési profilunk). Ezt úgy tehetjük meg, ha a bemenetekhez valószínőségi eloszlást rendelünk hozzá a tényleges mőködés elıfordulási gyakorisága alapján.


21


6.2.2.1.12.

Kód alapú tesztelés

A vezérlési struktúra, az adatáramlás struktúra, a döntési vezérlés és a modularitás figyelembe vételével lefedjük a kódot. Lefedettség elemzés segítségével felmérjük a teszt teljességét és megfelelıségét. Ez a technika magába foglalja a vezérlési folyamat tesztelést és az adatáramlás tesztelést is. 6.2.2.1.13.

Hiba alapú tesztelés

Szándékosan hibákat követünk el a teszt során, hogy ezzel teszteljük a program robusztusságát és megbízhatóságát. Itt a kihívást az jelenti, hogy milyen hibákat ejtsünk, és hogy figyeljük meg a hatását. E módszer sikeres használatához megfelelı tapasztalat szükséges. 6.2.2.1.14.

Protokoll megfelelıségi tesztelés

Használjuk a program kommunikációs protokollját a program tesztelésének közvetlen alapjaként. Ez akkor hasznos, ha a programnak értelmeznie kell valamilyen protokollt. Kombinálva a „határérték elemzés” és a „bemeneti tartomány ekvivalencia osztályokra bontása” teszteléssel, ez a módszer igen hasznos web alapú és más internet alapú kódok esetében. A protokoll alapú elemzés különösen fontos webes alkalmazások biztonsági tesztelése során, mivel a távoli támadók számára ezen alkalmazások elérése a legkönnyebben a web protokollokon keresztül lehetséges. 6.2.2.1.15.

Terheléses és stressz tesztelés

Ennek a tesztelés fajtának a speciális célja annak ellenırzése, hogy egy alrendszer megfelel-e bizonyos teljesítmény követelményeknek (pl. kapacitás és válaszidı). Terheléses és stressz tesztek során a rendszert a maximális tervezett terhelésnek vagy még annál is magasabbnak tesszük ki. Biztonsági szempontból a stresszes helyzetek olyan sebezhetıségekre világíthatnak rá, amelyeket másképp nehéz észrevenni. Sebezhetıségeket olyan mechanizmusok is okozhatnak, amelyeket a szoftver az extrém helyzetek kezelésére használ. Az ilyen mechanizmusok megvalósításakor a fejlesztık gyakran csak az ideális esetekre fókuszálnak, nem törıdve a biztonsággal. 6.2.2.2. A biztonsági tesztelés A biztonsági tesztelés célja a szoftver megfelelıségének ellenırzése a biztonsági követelményeknek. Termékek esetén ez alapvetıen a fejlesztı, míg rendszerek esetén a rendszer integrátor feladata és felelıssége. A (termék vagy rendszer) értékelıje ezt a tesztelést ellenırzi, egy mintavételezéssel kiválasztott részét megismétli, illetve független teszteléssel kiegészíti.


22


Fontos megállapítás, hogy nem a biztonsági tesztelés során (akár annak elsı lépésében) kell kockázat elemzést végezni, s ebbıl levezetni a tesztelendı követelményeket. A követelményeket már korábban, más feladatokban (kockázat elemzés, biztonsági elıirányzat készítés) meg kellett határozni. A biztonsági teszteléshez az alábbi feladatokat kell elvégezni: ― teszt stratégia kidolgozása, amely meghatározza a tesztelési célok eléréséhez szükséges tesztelési tevékenységeket, ― részletes teszt terv kidolgozása, amely összeszervezi az elkövetkezı teszt folyamatokat, ― a teszt környezet kiépítése a teszt végrehajtására, ― a tesztesetek végrehajtása és az eredmények rögzítése, ― a tesztelés eredményeinek elemzése. 6.2.2.2.1.

Teszt stratégia kidolgozása

A teszt stratégia célja, hogy világossá váljanak a fı tevékenységek, a meghozott kulcsfontosságú döntések, és a tesztelés során várható kihívások. Ide tartoznak az alábbiak meghatározása: ― a tesztelés hatóköre, ― a tesztelési technikák, ― a lefedettség mérési módszere (mérıszámok, metrikák), ― tesz környezet, ― a tesztelést végzık elvárt szakértelme. A teszt stratégia lényegében menedzsment tevékenység. A teszt menedzser (vagy hasonló pozíció) felelıs a teszt stratégia kidolgozásáért és menedzseléséért. A rendszer integrátori és tesztelı csapat tagjai segíthetik a menedzsert a teszt stratégia kidolgozásában. A teszt stratégia elkészítése során figyelembe kell venni, hogy az idı és költségvetési korlátok miatt nem végezhetı el a rendszer valamennyi elemének a tesztelése, ezért egyensúlyba kell hozni a teszt hatékonyságát a teszt eredményességével a rendszer kockázatai alapján. A hatékonyság szintje nyilvánvalóan függ a szoftver használati módjától és a hiba következményétıl. A tervezett tesztelés ezért szelektív, és ez a szelektálás a rendszer kockázatelemzésén alapul. A kockázatok prioritása (vagy sorrendje) alapján kell a tesztelés fókuszát megválasztani, egyszerően azért, mert a nagy mértékben sebezhetı területeket alaposabban kell tesztelni. A teszt stratégia összefoglalja a döntéseket, prioritásokat, tevékenységeket és a tesztelés fókuszát, amelyek mind a szoftver hibák lehetséges következményein alapulnak. 6.2.2.2.2.

Teszt terv készítése

A teszt terv testesíti meg a teszt stratégiát.


23


A teszt terv kidolgozásának az a célja, hogy megszervezze a következı tesztelési tevékenységeket. Ide tartoznak a teszteléssel lefedendı területek meghatározása, a teszt technikák megvalósítása, tesztesetek és tesztadatok kiválasztása, a teszt eredmények érvényesítése, teszt ciklusok, valamint a belépési és kilépési feltételek a lefedettségi mérték alapján. A teszt terv egy másik célja a tesztelési folyamat elérhetı legjobb automatizálása, mely nem csak megkönnyíti a tesztelést, hanem megismételhetıségét is biztosítja. A teszt tervnek magába kell foglalnia mindannak a magas szintő meghatározását, hogy mely szoftver elem kerül tesztelésre, és milyen módszerek alkalmazásával, továbbá tartalmaznia kell a tesztek általános leírását is, beleértve az elıfeltételeket, a beállításokat, azok végrehajtását, és hogy mit keressünk a teszt eredményekben. A magas szintő áttekintés hasznos a vezetés részére, tervezési és jelentési céllal, míg a részletesebb leírás célja a tesztfolyamat gördülékeny haladását biztosítani. A teszt terv számos elınyt biztosít: ― Írásban rögzíti az elvégzendı feladatokat. ― Lehetıséget biztosít a projekt vezetıjének a tervezett tesztek jóváhagyására. /Aki ezzel kinyilvánítja egyetértését a terv elemeivel, s ez a teszteléssel kapcsolatos erıfeszítések támogatását is jelenti./ ― Elısegíti az elırehaladás mérését. /A tesztelı ennek alapján meghatározhatja, hogy a tervezettnek megfelelıen halad-e./ ― Lehetıvé teszi a tesztelési prioritások áttekintését. A teszt terv egyik látszólagos hátránya, hogy merevségével és elıre meghatározottságával korlátozhatják a tesztelıt és meggátolhatják abban, hogy ad hoc módon utána járjon olyan megfigyeléseinek és gyanúinak, melyek nem várt felfedezéseket hozhatnak. Ez különösen igaz lehet a biztonsági tesztelések során, amikor a negatív követelmények kimondottan elvárják a tesztelések során tapasztalt ellentmondások további vizsgálatát. A fenti hátrány valóban csak látszólagos, amennyiben a tesztelık eltérhetnek a teszt tervben vázolt egyes tervektıl, ha ezeket a változtatásokat megfelelıen dokumentálják és indokolják. A teszt tervezés iteratív tevékenység. Maga a teszt folyamat is generál olyan információt, amely felhasználható további tesztek tervezésére. A teszt terv elkészítése során figyelembe kell venni a rendszer különbözı komponensei közötti függıségeket, a szükségessé váló tesztismétlések minimalizálása érdekében. Ideális esetben úgy lehet meghatározni a komponensek tesztelési sorrendjét, hogy minden modul a tıle függı modul elıtt kerül tesztelésre. A gyakorlatban ez nem mindig ilyen egyszerő, de a tervezéskor mégis ésszerő figyelembe venni ezeket a függıségeket. A teszt tervnek ki kell dolgoznia a végrehajtandó teszteseteket. A tesztesetek tipikusan információt tartalmaznak a teszt elı- és utófeltételeirıl, a tesztek felépítésére és lebontására vonatkozó adatokról, és arról, hogy hogyan kell a teszt eredményeket kiértékelni. A teszteset meghatározza a teszt feltételt is, amely a vizsgált eset aktuális állapota, például a tesztelı olyan teszt feltételt készít, amely a szoftver válaszát vizsgálja. Egy tipikus biztonsági teszt terv a következı elemeket tartalmazza:


24


a) Cél b) A vizsgált szoftver áttekintése ba) Szoftver és komponensek bb) Teszt határok bc) Teszt korlátozások c) A kockázat elemzés eredményeinek (a meghatározott biztonsági követelmények) összegzése d) Teszt stratégia da) Feltételezések db) Teszt megközelítés dc) Nem tesztelendı elemek e) Teszt követelmények ea) Telepítési/konfigurálási teszt követelmények eb) Felhasználói dokumentációra vonatkozó követelmények ec) Személyi követelmények ed) Berendezés és hardver követelmények f) Teszt környezet g) Teszteset specifikációk ga) Egyedi teszt azonosító gb) Követelmény megfeleltetés (melyik követelményre irányul a teszteset) gc) Input specifikációk gd) Output specifikációk (várt eredmények) ge) Környezeti elvárások gf) Függıségek a tesztesetek között h) Teszt automatizálás és teszttermék ha) Teszttermék architektúra hb) Tesz eszközök hc) Teszttermék i) Teszt végrehajtás ia) Teszt belépési feltételek ib) Teszt eljárások (speciális követelmények, eljárás lépések) ic) Teszt ütemezés id) Teszt kilépési feltételek j) Teszt menedzselés terv (a terv folyamatos változtatására, kezelésére) k) Fogalom-meghatározások és rövidítések. Ugyanakkor a teszt tervezés egy folyamat. Gyakran létezik egy fı teszt terv, amely az egész rendszer tesztelési folyamatát körvonalazza, s ezt különbözı teszt fázisok, részletesebb teszt tervek egészítik ki, melyek nem feltétlenül a teljes rendszerre, esetenként csak egyes komponensekre vagy alrendszerekre vonatkoznak. Egy fı teszt terv körvonalazhatja például az alábbiakat: A modul (függvények, metódusok, osztályok) teszteket a fejlesztık, a komponens (könyvtárak, futtatható állományok) teszteket a teszt mérnökök végzik el. Ezután következnek az alrendszer szintő integrációs tesztek speciális teszt környezetben, majd a rendszer szintő tesztek szimulált valós környezetben. Végül speciális eszközök felhasználásával egy stressz tesztelés zárja a biztonsági tesztelést. Minden teszt fázisnak lehet saját részletes teszt terve.


25


6.2.2.2.3.

Teszt környezet kiépítése

A teszt környezet kiépítése és kezelése fontos a hatékony és eredményes teszteléshez. Egyszerő alkalmazói programok esetén a teszt környezet egyetlen számítógépbıl állhat, egy informatikai rendszer esetében a teszt környezet sokkal bonyolultabb lehet. A biztonsági tesztelés során gyakran szükségessé válik a környezet feletti kontroll, hogy a tesztelı részletesen megfigyelhesse, manipulálhassa a szoftver és a környezete kapcsolatát. A teszt környezetet izolálására is szükség lehet, különösen akkor, ha a teszt technikák romboló eredménnyel zárulhatnak, és így érvénytelenné tehetnek más, éppen párhuzamosan futó teszt eredményeket is. A teszt környezet kiépítését jóval a tesztelés megkezdése elıtt, még a teszt tervezése alatt meg kell kezdeni. Ennek során fel kell tölteni az adatbázisokat is, konverziós program vagy fájl feltöltési szolgáltatás segítségével. A teszt környezet összeállítását követıen a teszt környezet kialakításában és a tesztelésben résztvevı erıknek közösen részteszteket ajánlott végezniük, hogy meggyızıdhessenek a környezet helyes kiépítésérıl. A teszt környezet kiépítésébe tartozik a támogató szakértık (adatbázis adminisztrátorok, hálózati szakértık, stb.) kijelölése is. 6.2.2.2.4.

A tesztelés végrehajtása, az eredmények rögzítése

A tesztelés végrehajtása a biztonsági teszt tervben kidolgozott tesztesetek kézi vagy automatikus megvalósítását jelenti. Bár valószínőleg kézi tesztelésre is szükség lesz, egy rendszer tesztelés hatékony végrehajtása elképzelhetetlen a tesztelés bizonyos fokú automatizálása nélkül. A teszt automatizálás lehetıséget biztosít a tesztek végrehajtásának és menedzselésének automatizált támogatására, különösen a korábbi tesztek megismétlésére. A rendszerre kidolgozott valamennyi tesztet egy teszt készletbe kell győjteni. Ha a rendszer változik, akkor a változásnak megfelelı teszteket újra végre kell hajtani. A teszt készletek végrehajtását teszt meghajtók, vagy készlet meghajtók támogathatják. A teszt meghajtók alapvetıen az egyes tesztek beállításában, végrehajtásában, értékelésében és lebontásában segítenek. A tesztek végrehajtása mellett a teszt automatizáláshoz további automatizált mechanizmusok szükségesek a teszt inputok generálásához és a teszt eredmények értékeléséhez. A teszt adatok generálása és a teszt eredmények értékelésének módszere nagyban függ a tesztelés alatt álló szoftvertıl és az adott teszt céljától. 6.2.2.2.5.

A tesztelés eredményeinek elemzése

A tesztelés mennyiségét és minıségét valahogy mérni kell. Erre nincs általánosan elfogadott szabvány, de számos publikáció tett javaslatot ezen mérıszámok felállítására, s maga az értékelési módszertan is elvár ezek közül néhányat (melyet az alábbiakban részletezünk). A


26


mérıszámokat általában arra használják, hogy meghatározzák, mikor fejezhetik be sikeresen a tesztelést. A figyelembe veendı kritériumok, illetve javasolt mérıszámok a következık: ― Követelmény lefedettség mérték: a tesztelt követelmények aránya az összes követelményekhez viszonyítva. A tesztelés egyik célja annak bemutatása, hogy a szoftver a követelményeknek megfelelıen mőködik. Így tehát minden szoftver követelményt le kell tesztelni, legalább egy tesztesettel. Ha vissza tudjuk vezetni a teszteseteket a funkcionális követelményekre, akkor meg lehet határozni a tesztelt követelmények arányát az összes követelmény függvényében. ― Kód lefedettség mérték: A tesztelés során ki kell próbálni a szoftver minél több lehetséges „részét”, mivel a ki nem próbált részek potenciális hibákat tartalmazhatnak. A kód teljes körő kipróbálása azt jelenti, hogy a szoftver valamennyi végrehajtási útját bejárjuk. Mivel még kis programok esetében is a bejárható utak száma csillagászati mérető lehet, ezért a gyakorlatban ez nem kivitelezhetı. A legtöbb, amit tehetünk, hogy minél több utasítást, ágat és feltételt vizsgálunk meg. Így lehetıségünk nyílik teszt lefedettséget definiálni, azaz utasítás lefedettséget, elágazás lefedettséget, stb. A lefedettség mérésére különbözı lefedettség mérı eszközök állnak rendelkezésre. ― Teszteset mérték: Ez a mérték megmutatja a létrehozott tesztesetek számát, a végrehajtott esetek számát, illetve, hogy ezek közül mennyi volt sikeres és mennyi sikertelen. Ez a mérték különösen akkor hasznos, ha idı szerint kerül ábrázolásra. Egy projekten belül ez a mérték jól mutatja a tesztelési folyamat pillanatnyi állapotát, hol áll most a projekt, és milyen irányba halad. ― Hiba mérték: Ez a mérték is nagyon hasznos, ha idı szerint kerül ábrázolásra. Sokkal informatívabb, ha tesztelés kezdetétıl a jelentés napjáig együttesen megtalált hibák száma kerül ábrázolásra. A görbe íve fontos információt tartalmaz. Ha a görbe íve élesen emelkedik, akkor rövid idı alatt sok hiba kerül felismerésre, és a jelenlegi tesztelési erıkifejtést kell tartani, vagy még erısíteni. Ha azonban kezd kiegyenesedni, akkor azt jelenti, hogy kevesebb hiba kerül felismerésre. ― Biztonsági hiba mérték: A biztonsági tesztelés által megtalált hibák száma. (Azon biztonsági tesztesetek száma, melyeknél az elvárt és a tényleges eredmény nem egyezett, s ezt utólag sem lehetett ésszerően megindokolni.) Az értékelési módszertan [3] nem vár el konkrét kód lefedettség, teszteset és hiba mértéket. A másik két mértékre viszont speciális elvárások vannak. A biztonsági hiba mértékre az értékelési módszertan 0-t vár: azaz addig kell ismételni a biztonsági tesztelést, míg nem marad megindokolhatatlan eltérés a biztonsági tesztek elvárt és tényleges eredményei között. A követelmény lefedettség mértékre az értékelési módszertannak két különbözı megközelítésben is elvárásai vannak. Az értékelési módszertan mindhárom garanciacsomag esetén megköveteli a rendszer integrátortól, hogy biztosítson egy teszt lefedettség elemzést (ASTE_COV.1). Ennek a teszt lefedettség elemzésnek be kell mutatnia a tesztdokumentációban azonosított tesztek és a rendszer biztonsági funkcionalitás közötti megfeleltetést, de csak ahogyan azt a rendszer interfész specifikáció a felhasználók számára látható külsı interfészeken keresztül leírja.


27


Vagyis a rendszer interfész specifikációban lévı minden (biztonságot is érintı) funkcióra legalább egy tesztet végre kell hajtani, de nincs megkövetelve, hogy az egyes funkciókat kimerítıen teszteljék. Az értékelési módszertan mindhárom garanciacsomag esetén megköveteli a rendszer integrátortól, hogy biztosítson egy teszt mélység elemzést (ASTE_DPT). Ennek a tesztmélység elemzésnek be kell mutatnia, hogy a tesztdokumentációban azonosított tesztek elegendıek annak bemutatására, hogy a rendszer biztonsági funkcionalitása a rendszer különbözı szintő leírásaival is összhangban mőködik. Az elvárt összhang SAP-A garanciacsomag esetén csak a biztonsági architektúrára (ASTE_DPT.1), SAP-F esetén az alrendszerekre is (ASTE_DPT.2), SAP-K esetén pedig a komponensekre is (ASTE_DPT.3) vonatkozik. Ez a következıket jelenti a gyakorlatban: ― SAP-A esetén tesztelni kell a rendszer felhasználók számára kívülrıl nem látható olyan külsı interfészeket is, melyeken keresztül a rendszer más külsı rendszerekkel tart kapcsolatot (szolgáltatás kérést küld vagy fogad). ― SAP-F esetén tesztelni kell az alrendszerek közötti belsı interfészeket is. ― SAP-K esetén tesztelni kell a komponensek közötti belsı interfészeket is. 6.2.2.3. A funkcionális és a biztonsági tesztelés összehasonlítása A funkcionális tesztelés célja annak ellenırzése, hogy a szoftver megfelel-e a szoftverrel szemben támasztott általános követelményeknek. A biztonsági tesztelés célja, hogy ellenırizzük a rendszer megfelelését a biztonsági követelményeknek. Szoftverfejlesztıi szempontból a biztonsági tesztelés során feltárt biztonsági sebezhetıségek ugyanúgy tekinthetık, mint a standard szoftver tesztelési eljárással felfedezett „hagyományos” szoftver hibák. Ugyanakkor a biztonsági hibák sok szempontból különbözhetnek a hagyományos hibáktól: ― A felhasználók általában nem keresnek kimondottan szoftver hibákat. Ugyanakkor rosszindulatú hacker-ek kimondottan sebezhetıségeket keresnek. Ha sikerrel járnak, akkor más felhasználóknak okozhatnak gondot, akiket ez rosszul érinthet. Még inkább tetézi a gondot az, hogy a rosszindulatú hacker-ek leírják a támadási módszereket és terjesztik is azokat. ― A fejlesztık könnyen megtanulhatják, hogy kerüljék el a rossz programozási gyakorlatot, amely hibás kódot eredményezhet. Ezzel ellentétben a nem biztonságos programozási gyakorlat listája hosszú, és évrıl évre egyre csak nı, így nehéz a fejlesztıknek napra késznek maradniuk a legújabb biztonsági sebezhetıségek tekintetében. Mivel a legtöbb fejlesztı jelenleg nem képzett a biztonságos programozás területén, azért a biztonsági elemzıkre hárul a biztonságos programozási gyakorlat betartásának ellenırzése. ― A biztonsági tesztelés alapvetıen különbözik a hagyományos teszteléstıl, mert arra koncentrál, hogy az alkalmazásnak mit nem szabad csinálnia, és nem arra, hogy mit kell csinálnia (pozitív és negatív követelmények). Bár a biztonsági tesztelés néha valamely pozitív követelménynek való megfelelıséget ellenıriz (pl. le kell tiltani egy felhasználói fiókot adott számú sikertelen próbálkozás után), a negatív követelmények


28


játszanak túlnyomó többségben szerepet. Egy példa a negatív tesztelésre, „fel nem jogosított felhasználók nem férhetnek hozzá az adatokhoz”. A hangsúly eltolódás a pozitív követelményekrıl a negatívok felé hatással a van a tesztelés végrehajtási módjára is. A pozitív követelmények ellenırzésének tipikus módja, hogy megteremtjük a feltételeket, amelyben a követelmények teljesülését várjuk, és ellenırizzük, hogy a szoftver valóban teljesíti azokat. Ugyanakkor a negatív követelmények azt követelhetik meg, hogy sohase teljesüljön valami. Ha ebben az esetben szeretnénk alkalmazni a szokásos tesztelési módszert, akkor minden lehetséges feltételrendszert ki kellene próbálnunk, ami kivitelezhetetlen. ― Számos biztonsági követelmény, mint pl. „a támadónak sosem szabad átvennie a vezérlést az alkalmazás felett”, tesztelhetetlen a hagyományos szoftverfejlesztési körülmények között. Bevett gyakorlat, hogy ilyen esetekben a tesztelı az ilyen követelmények finomítását kéri, vagy egyszerően figyelmen kívül hagyja. Ugyanakkor a legtöbb biztonsági követelményt nem lehet finomítani vagy figyelmen kívül hagyni, még ha azok nem is tesztelhetıek. Nem lehet például teljes körően felsorolni, hogy milyen módon szerezheti meg a vezérlést a támadó a szoftver rendszer felett (amely egy lépés lenne a tesztelhetıbbé tétel felé), és nyilvánvalóan nem is lehet figyelmen kívül hagyni a követelményt. A fentiek szemléltetik, hogy a biztonságos szoftver fejlesztés ténylegesen nehezebb, mint a hagyományos program fejlesztés, ezért a biztonság tesztelése is nagyobb szerepet kap. A biztonságos szoftverfejlesztés erısebb szoftver tesztelési technikákat és megközelítést igényel: ― A számos szoftverfejlesztési fázis közül a tesztelés az egyetlen olyan dinamikus elemzés, amelyen a szoftver átesik. Dinamikus elemzésnek nevezzük azt, amikor a szoftver futtatásra kerül. Bizonyos problémákat könnyebb detektálni dinamikusan, mint statikusan, különösen azokat, amelyekben pointerek, széles tartományú adatok, vagy folyamat irányítás van. ― A tesztelés segíthet annak ellenırzésében, hogy a fejlesztı nem hagyott-e benne véletlenül valamely nem biztonságos programozási technikát. A statikus elemzés is hasznos lehet ebbıl a célból, de valódi sebezhetıségek megkülönböztetése a nem kihasználható hibáktól gyakran könnyebb, ha a dinamikus és statikus elemzést kombinálva használjuk. ― A sebezhetıséget általában komolyabban veszik, ha van hozzá ismert, a hibát kihasználó kód, de ezen kódok kifejlesztése a behatolás teszt témakörébe tartozik. ― A tesztelés segíthet harmadik fél által gyártott komponensekben beazonosítani és csökkenteni a kockázatokat, amikor a forráskód, és architektúra diagram nem áll rendelkezésre. ― A tesztelés lehetıséget biztosít a szoftver biztonságának mérésére, és riasztást lehet kiváltani, ha biztonsági szempontból a szoftver súlyosan hibás. ― A különbözı szoftver tervezési dokumentációk a szoftvert az absztrakció más és más szintjén tekintik át. Az architektúra diagram a szoftvert a rendszer architektúrájának megfelelı absztrakciós szinten tekinti, és a forráskód is a szoftver egy absztrakt nézete. Egy C kód például nem mutatja, hogy az strcpy() függvény puffer túlcsordulást okozhat, azt tudni kell elıre, hogy az strcpy() veszélyes lehet. Sem egy személy, sem egy csoport nem láthatja át a szoftvert valamennyi absztrakciós szinten,


29


de a tesztelés segíthet megtalálni (legalább néhány) hibát, amely nem derül ki a tervezési dokumentumokból. Természetesen a biztonságos programozás sokkal több, mint csupán a biztonsági tesztelés. Ugyanakkor a biztonsági tesztelésnek fontos szerepe van a biztonságos programozás megvalósításában. 6.2.3. Tesztelési lehetıségek a szoftver különbözı életciklus fázisaiban Egy szoftver teljes életciklusát érintik a teszteléshez tartozó tevékenységek. Az életciklus minden fázisának más és más jellemzı tesztelési feladata van. Bár a rendszer integrátoroknak nincs minden életciklus fázisában szerepe, mégis hasznos lehet a teljes szoftver életciklus rövid áttekintése a tesztelhetıség szempontjából. A szoftver életciklusának alábbi három fı fázisát vizsgáljuk: ― tervezési fázis (ebben nincs a rendszer integrátornak feladata), ― megvalósítási (kódolási) fázis, ― üzemeltetési fázis. A megvalósítási fázison belül különbözı szintő teszteléseket különböztetünk meg: ― modulok tesztelése, ahol egyedi osztályok, metódusok, függvények, vagy más, viszonylag kis modulok kerülnek tesztelésre (ezen a szinten elsısorban a fejlesztık hajtják végre a tesztelést, ez tehát nem a rendszer integrátor feladata), ― könyvtárak és futtatható állományok tesztelése (ezen a szinten elsısorban teszt mérnökök hajtják végre a tesztelést, ez tehát nem a rendszer integrátor feladata), ― integrációs tesztelés, ahol a cél annak a tesztelése, hogy a különbözı szoftver elemek az elvártak szerint mőködnek-e együtt (ez a szint a rendszer integrátor feladata is), ― rendszer tesztelés, ahol az egész rendszer kerül tesztelésre (ez a szint elsıdlegesen a rendszer integrátor feladata). 6.2.3.1. Tervezési fázis Ez a fázis a követelmények összeállítására és ezek ellenırzésére vonatkozó elıkészítı tevékenységeket tartalmaz, döntıen teszt tervek készítését, bár még nincs mit tesztelni. A teszt tervezése ebben a fázisban szorosan kapcsolódik a kockázat elemzéshez: ― a kockázat elemzés során feltárt kockázatok kipróbálását végzı tesztek tervezése, ― a feltárt kockázatokat csökkentı ellenintézkedéseket ellenırzı tesztek tervezése. Egy web szerver fejlesztésére vonatkozó szemléltetı példa a fentiekre: ― A kockázat elemzés során azonosításra került a beszúrásos támadás, melynek során a támadó speciális karaktereket szúr be az URL-ekbe. Különbözı tesztek tervezhetık ennek felismerésére. ― Ellenintézkedésként az URL elıfeldolgozását megvalósító modul kerül kifejlesztésre, amely azt ellenırzi, hogy az URL csak egy bizonyos legitim karakterkészletbıl tartalmaz-e karaktereket.


30


― A beszúrásos támadás elleni védelem tesztelését csak ezen a modulon kell végrehajtani. Ehhez a fázishoz a rendszer integrátor nem kapcsolódik. 6.2.3.2. Megvalósítási fázis - modul tesztelés A tesztelendı „modul” fogalmába értjük ez egyedi függvényeket, metódusokat, osztályokat és programcsonkokat. A modulok nem futtathatók önállóan, azért teszt meghajtók szükségesek hozzá. Tesztelésük más szempontból is alapvetıen különbözik a késıbbi teszt tevékenységektıl. A modul tesztelés során a hangsúly a pozitív követelményeken van. A pozitív követelmények azt írják le, hogy mit kell tennie a szoftvernek, nem pedig az, hogy mit nem szabad. A tesztelt modul feladata egy vagy több követelmény implementálása, és a cél annak az ellenırzése, hogy valóban megvalósítja-e ezeket a követelményeket. Már a modul tesztek tervezésekor kiemelt figyelmet kell fordítani a biztonság szempontjára. A támadó speciális megközelítés módját nem szabad figyelmen kívül hagyni. Ha például egy modul adatot olvas egy fájlból, akkor már modul szinten ajánlott ellenırizni az adat érvényességét, abból a meggondolásból, hogy egy támadó megváltoztathatta azt. Ha a modul valamilyen feltételezéssel él egy felhasználótól kapott inputtal kapcsolatban – még ha az input valahol máshol már ellenırzésre került is - helyénvaló a modul szintjén is ellenırizni ezt a feltételezést, mivel a feltételezést legjobban a modul készítıje érti, másrészt a támadó a másik ellenırzést kikerülheti. A modul szintő helyes tervezés és tesztelés megalapozza a magasabb szintek biztonságát, egyúttal egyszerősíti a késıbbi karbantartást is (például a feltételezések megváltozása esetén). A mélységi védelem alapelve szerint a modul szintjére irányuló (helyi) fenyegetettségeket akkor is figyelembe kell venni, amikor a rendszerben nincsenek rosszindulatú felhasználók, sıt olyan gépeken is, ahol nincsenek is valódi felhasználók. Számos támadás két fázisban valósul meg, az elsı fázisban a támadó csak kezdeti hozzáférést szerez a géphez, a második fázisban pedig átveszi a gép felett a vezérlést. (Egy web szerver feltörése esetében például a támadó elıször csak a web szerver jogosultságait szerzi meg, de ezután már helyi támadási módszereket is használhat, mint például a helyi erıforrások támadása, és ezáltal privilegizált programok futtatása.) 6.2.3.3. Megvalósítási fázis - könyvtárak és futtatható állományok tesztelése Ezen a szinten általában már nem a fejlesztık, hanem a teszt mérnökök hajtják végre a tesztelést. A teszt környezet is bonyolultabb, tartalmazhat adatbázisokat, egyedi tesztesetekhez készült komplex teszt meghajtókat. A biztonsági tesztelés során szükség lehet speciális technológiákra, amelyek speciálisan összeállított hálózati forgalmat generálnak, hibákat és stressz helyzeteket szimulálnak vagy rendellenes program viselkedést vizsgálnak.


31


Ezen a szinten hasznos lehet a kód lefedettség elemzés végrehajtása is. Ez speciális eszköz segítségével elkülöníteni azokat a program részeket, amelyek nem kerültek végrehajtásra a funkcionális teszt során. A lefedettség elemzés különösen fontos a biztonsági tesztelés során. A hibakezelı rutinokat tipikusan nehéz lefedni teszteléssel, pedig ezek gyakran tartalmaznak sebezhetıséget. A jó kódolási gyakorlat csökkenti a hibakezelık által okozott kockázatot, de akkor is ajánlott olyan teszteseteket vizsgálni, amelyek hiba feltételeket szimulálva a hiba kezelıket vizsgálják dinamikus környezetben. A könyvtárak is különleges figyelmet igényelnek. A könyvtárban található komponensek idınként olyan körülmények között kerülhetnek újrafelhasználásra, amelyek nem nyilvánvalók az aktuális rendszertervben. Azért mert egy könyvtári függvény a jelenlegi tervek szerint egy másik komponens védelme alatt áll, nem biztos, hogy ez a jövıben is így marad. A könyvtárak olyan felhasználásra is kerülhetnek késıbb, melyekre tervezésükkor még nem gondoltak. A könyvtárban lévı sebezhetıség hatása annál nagyobb lesz, minél több rendszerben kerül felhasználásra. Ez különösen fontossá teszi a könyvtárak korai tesztelését és bevizsgálását. Az egyik közismert példa sebezhetı könyvtári függvényre a standard C könyvtár strcpy() függvénye, amely gyaníthatóan puffer túlcsordulást okoz. Éveken keresztül a strcpy() és ehhez hasonló függvényhívások voltak a telepített rendszerekben a sebezhetıségek fı okozói. Mire az strcpy() sebezhetıségét felfedezték, a függvényt olyan széles körben használták, hogy a standard C könyvtárból való eltávolítása már nem volt megvalósítható. Az strcyp() története jól példázza azt, hogy milyen fontos a sebezhetıségek lehetı legkorábbi felismerése, és hogy mennyibe kerülhet a késıi felismerés. 6.2.3.4. Megvalósítási fázis - integrációs tesztelés Az integrációs teszt az alrendszer szint vizsgálatára koncentrál, ahol több futtatható komponens együttmőködése valósul meg. A rendszer integrátor integrációs tesztelése azoknak a biztonsági és hagyományos hibáknak a feltárására irányul, amely a komponensek közötti együttmőködésben mutatkozik meg. Az integrációs hibák gyakran abból adódnak, hogy egy komponens olyan feltételezésekkel él a másik komponenssel kapcsolatban, amely nem teljesül. Integrációs hiba lép fel például akkor, ha a hívott és a hívó fél is azt feltételezi, hogy a másik függvény felelıs a határok ellenırzéséért, és ezért egyik sem végzi azt el. Egy másik ilyen tipikus integrációs hiba, amikor rossz típusú adatot adunk meg egy könyvtári függvény hívásánál. (Például a C nyelvben nem feltétlenül jelez a fordítóprogram figyelmeztetést, ha egész értéket adunk át, ahol elıjel nélküli egészet vár, de ilyen esetben negatív számok nagy pozitív számokká válnak. Ha ez a szám egy puffer méretét jelöli, akkor ez sebezhetıséghez vezethet. Persze ez a hiba megelızhetı, ha az érték ellenırzésre kerül a hívott függvényben.) Az integrációs hibák leggyakoribb okai az ellenırizetlen input értékek, mivel minden komponens feltételezheti, hogy az inputok máshol kerülnek ellenırzésre. A biztonsági tesztelés során különösen fontos meghatározni, hogy mely adatokat képes, és melyeket nem képes megváltoztatni egy támadói.


32


Az integrációs hiba másik fı forrása a hibakezelés, a benne lévı szokatlan vezérlés és adatfolyam miatt. A rendszer integrátornak mindkét hiba lehetıséggel számolnia kell az integrációs tesztelés során. 6.2.3.5. Megvalósítási fázis - rendszer tesztelés A rendszer tesztelés egyrészt a rendszer szintő integrációs (hibamentes együttmőködést vizsgáló) és funkcionális (a funkcionális követelményeknek való megfelelést vizsgáló) teszteléseket jelenti. Ennek végrehajtása elsıdlegesen a rendszer integrátor feladata A szigorú teljesítmény követelményeket (pl. kapacitás és válaszidı) felvállaló informatikai rendszerekben a terheléses és stressz tesztek szintén a rendszer szintjén kerülhetnek végrehajtásra. A támadás tárgya általában a teljes rendszer, még akkor is, ha a támadónak elıször csak egyes komponensekhez sikerül hozzáférést szereznie. Az elsı hozzáférést gyakran kívülrıl sikerül megszereznie, fıleg a hálózati szolgáltatásokat nyújtó rendszerekben. Egy adott védelmi tartományba sikeresen bejutó támadó ezután általában megtámadja a másik tartományt is, az operációs rendszer egy rétegét már uraló támadó az operációs rendszer más rétegeit is támadja, stb. A fenti támadási kísérletekkel szemben alkalmazni kell a mélységi védelem elvét (tehát minden komponensnek biztonságosnak kell lennie), ugyanakkor a rendszer egészére is szigorú biztonsági intézkedéseket kell megvalósítani. Ez utóbbit a rendszer szintő biztonsági tesztelés (mely elsısorban a rendszer integrátor feladata) és a rendszer szintő behatolás tesztelés (mely elsısorban a rendszer értékelı feladata) ellenırzi. A rendszer szintő integrációs, funkcionális és biztonsági tesztelésnek az ad különös jelentıséget, hogy ez a szint felel meg elıször az üzemeltetés valódi környezetének, hiszen a korábbi tesztelések mind mesterséges környezetben történtek. A rendszer szinten megtalált integrációs és funkcionális hiba biztosan a rendszer helyes mőködésének hiányát mutatja. A rendszer szinten megtalált sebezhetıség biztosan létezı sebezhetıséget jelent. 6.2.3.6. Üzemeltetési fázis Egy informatikai szoftver rendszer életciklus üzemeltetési fázisa akkor kezdıdik, amikor a szoftver alkalmazása éles környezetében megkezdıdik. Gyakran ilyenkor a szoftver kikerül a rendszer integrátor hatókörébıl. Hagyományosan a bétatesztelés a korai üzemeltetési fázishoz kapcsolódik, ugyanakkor biztonsági szempontból lehetıséget biztosít az értékelık behatolási tesztelésére, a szoftver sebezhetıségeinek keresésére. Ugyanakkor a szoftver rendszer az üzemeltetési fázisban is sebezhetıvé válhat. Ennek oka lehet konfigurációs hiba, vagy elıre nem látott tényezı a mőködési környezetben. Sebezhetıségek egyedi komponensek frissítésével is bekerülhetnek a rendszerbe. Azon


33


feltételezések, amelyek igazak voltak fejlesztés alatt, már nem teljesülnek az új verzió telepítése esetén. Ez úgy is elıfordulhat, hogy csak a rendszer egyes elemei kerülnek frissítésre, míg mások nem, így a szoftver verziók egy olyan keveredése alakul ki, melyet egzakt módon nem lehetett elıre látni a fejlesztés/integrálás folyamán. A rendszer kockázati profilja is változhat, például amikor új sebezhetıséget találnak a létezı szoftver verziókban, vagy a rendszerben használt rejtjelezési technikák elavulnak. A fenti problémák miatt van szükség a mőködı rendszer felülvizsgálati értékeléseire, melyet [3] részletesen tárgyal. 6.2.3.7. Összefoglalás A tesztelés fent vázolt hierarchikus felépítése /modul (függvények, metódusok, osztályok, programcsonkok – komponens (könyvtárak, futtatható állományok) – alrendszer - rendszer szintő tesztelés/ annak a felismerésnek a következménye, hogy a szoftver hibákat a rendszer integrálás minél korai szakaszában fedezik fel, annál egyszerőbb, gyorsabb és olcsóbb a kijavításuk. Hasonlítsunk össze az alábbi két esetet: ― A hibát a fejlesztı találja meg a saját maga által végrehajtott modul teszt során. A hiba diagnosztizálása és kijavítása egyaránt viszonylag kis erıfeszítést igényel. ― Ugyanez a hiba csak akkor kerül felfedezésre, amikor a termék egy rendszerbe integrálva már beüzemelésre került a fogyasztónál. A hiba diagnosztizálásához és kijavításához sok személy és több folyamat szükséges, így a költség jelentısen nı. A különbségek magukért beszélnek.

6.3.

Biztonsági hibajavítás, javítócsomagok kezelése

Ez az alfejezet az alábbi értékelési bizonyíték elkészítéséhez nyújt segítséget: ― CM dokumentáció, melynek a rendszer alap konfiguráció komponenseire nyomon kell követnie a javítócsomagokkal való frissítéseket (ASCM_SBC, lásd [3] 6.1.7.1), 6.3.1. A javítócsomagok alkalmazásának szerepe Egy informatikai rendszer biztonsági szabályzata meghatározza a vagyontárgyak kezelését, védelmét, elosztását szabályozó szabályokat. Egy informatikai rendszer biztonsági funkcionalitása a rendszer biztonsági szabályzatának helyes érvényre juttatását biztosítja. Egy informatikai rendszer biztonsági architektúrája garantálja, hogy a biztonsági funkcionalitást ne lehessen megkerülni, és hogy a rendszer képes legyen megvédeni magát a nem-megbízható aktív egyedek hamisításaitól. Amennyiben hibát tárnak fel a biztonság architektúrájában, még a jól mőködı biztonsági funkcionalitás is megkerülhetı, vagy a rendszer nem képes megvédeni magát a hamisításoktól. Amennyiben hibát tárnak fel a biztonsági funkcionalitást megalapozó hardver,


34


szoftver és förmver komponensekben, a rendszer által kezelt vagyontárgyak védelmére vonatkozó biztonsági célok sérülhetnek, köztük a rendszer által kezelt információ bizalmassága, sértetlensége és rendelkezésre állása. A biztonság architektúra és a biztonsági funkcionalitás hibáit biztonsági réseknek nevezik. A biztonsági rések elkerülése, észlelése és javítása elsıdleges fontosságú egy rendszer biztonságában. A rendszer biztonsági értékelések egyik fı célja annak valószínősítése, hogy nincsenek biztonsági rések az értékelt rendszer konfigurációjában. A szoftverek területén ritkán fordul elı, hogy egy szoftvert ne kelljen javítani, módosítani vagy bıvíteni. Egy rendszer szerkezetét, konfigurációját és szolgáltatásait is folyamatos változásra kényszerítı kihívások érik. A fentiek következtében minden rendszerben (még a sikeres biztonsági értékelésen átesettekben is) folyamatosan gondoskodni kell a potenciálisan bekerülı biztonsági rések észlelésérıl, valamint a feltárt biztonsági rések javításáról. A biztonsági rések elleni védekezés egyik leghatékonyabb és legolcsóbb formája a javítócsomagok alkalmazása, amennyiben a frissítési folyamat hatékonyan van kiépítve. Az alábbiak errıl szólnak. 6.3.2. Mérföldkövek a javítócsomagok alkalmazásában A frissítések kezelésének tervezésekor meg kell határozni az átgondolandó, végrehajtandó lépéseket. Ezek közül a legfontosabb mérföldkövek az alábbiak: ― a prioritások meghatározása, ― a szerepkörök és felelısségek meghatározása, ― a javítócsomag kezelési eljárások dokumentálása, ― a javítócsomag kezelést végzı szoftver kiválasztása, ― a frissítés megvalósítása /tesztrendszerek alkalmazása/ . 6.3.2.1. A prioritások meghatározása Nagy rendszerek esetén elıre meg kell határozni azokat a biztonság-kritikus területeket, amelyek a hibajavítások szempontjából is elsıbbséget élveznek. Ez nem azt jelenti, hogy csak ezekre kell koncentrálni a frissítések során, de ha nyilvánosságra kerül egy olyan biztonsági rés, amely a rendszerünk nagy részét érinti, akkor a javítások telepítését a kiválasztott kritikus rendszerelemeken kell elkezdeni. A frissítések telepítése ne csak a kívülrıl elérhetı szolgáltatásokra terjedjen ki, mert a támadások belülrıl, belsı rendszerek ellen is irányulhatnak (akár közvetve, egy sikeres külsı támadás utáni második lépésben). A prioritások meghatározása függ a rendszer által nyújtott szolgáltatások típusától, de általánosságban elmondható, hogy elsı helyen a névszerverek, domain controllerek és


35


levelezı szerverek állnak, majd ıket követik az alkalmazás szerverek, web szerverek és az adatbázis szerverek. 6.3.2.2. A szerepkörök és felelısségek meghatározása Miután meghatároztuk a biztonsági hibajavítás hatókörét, ezen belül pedig a prioritásokat, ki kell jelölni a frissítési (javítócsomag kezelési) eljárásban résztvevık körét, s meg kell határozni az egyes szereplık feladatait. A 2. táblázat tartalmazza a definiálható szerepköröket és feladatokat (természetesen kisebb rendszerek esetén egy személy számos szerepkört betölthet, az alábbi részletezés inkább a feladatokat különíti el). 2. táblázat – A definiálható szerepkörök és feladatok Szerep Patching Coordinator Patching Administrator System Support

Application Support Quality Assurance System Monitor Patching Auditor Business Approval

Feladat Szervezi a frissítések kiértékelésével foglalkozó megbeszéléseket. Kapcsolatot tart az IT részleg és a vezetés között. Beszerzi és telepíti a frissítéseket. Csoportosítja a frissítendı rendszereket funkció és elhelyezkedés szerint. A tevékenységérıl jegyzıkönyvet készít. A rendszerek üzembe állításáért felel a frissítések telepítése után, ami gyakran a rendszer újraindítását is megköveteli. A rendszereken futó alkalmazások folyamatos üzemelését felügyeli a frissítési eljárás során. A rendszeren futó alkalmazások funkcionalitását ellenırzi (teszteli) a frissítések után. Az automatikus online frissítı rendszereket ellenırzi a frissítés és újraindulás során. A frissítések meglétét ellenırzi a rendszeren, a talált hiányosságokról jegyzıkönyvet készít. Hozzáféréseket biztosít a frissítések telepítése során.

Munkakör Information Security Architect Domain or System Administrator Configuration Management Engineer Application Engineer Quality Assurance Engineer Network Operations Engineer Information Security Analyst Change Management Board

6.3.2.3. A javítócsomag kezelési eljárások dokumentálása A frissítési eljárások dokumentálása a fenti szerepek csoportosítását, a szervezetben ténylegesen meglévı munkakörökhöz rendelését, valamint a feladatok sorrendbe rendezett leírását jelenti. A folyamatos üzem fenntartásához elengedhetetlen a jó dokumentáltság, s hogy minden érintett ismerje feladatát, és annak ellátásához megfelelı tudással és gyakorlattal is rendelkezzen. 6.3.2.4. A frissítés kezelı szoftver kiválasztása A frissítési eljárások alkalmazása (a legfrissebb javítócsomagok telepítése) végsı soron a rendszeradminisztrátorok felelıssége, az alkalmazott technika pedig függ a rendszer méretétıl és az IT erıforrásoktól.


36


A frissítés történhet kézi vagy automatikus úton. A kézi frissítésnél választható, hogy mi kerüljön telepítésre, továbbá átlátható és nyomon követhetı marad az eljárás a rendszergazda számára. Az automatikus frissítés esetén a javítások letöltése és telepítése a háttérben, rendszeres idıközönként zajlik. Itt azonban nagyon fontos, hogy amennyiben az idızített frissítés nem futott le megfelelıen, a letöltés közben hálózati hiba lépett fel, vagy a már letöltött frissítés telepítése nem sikerült, akkor ezt valamilyen jól észrevehetı módon jelezze az automatizmus a rendszert üzemeltetık számára. Amennyiben a hálózat mérete, vagy a rendelkezésre álló IT erıforrás nem teszi lehetıvé az egyenkénti frissítések telepítését, akkor frissítés kezelı szoftvert kell bevezetni. Windows rendszerek esetén elérhetı a Microsoft Software Update Services (SUS) szolgáltatás, amelynek segítségével nagyvállalati környezetben is a prioritásoknak megfelelıen gyorsan és könnyen telepíthetık a biztonsági frissítések. A rendszer ügyféloldali és kiszolgálói funkciókkal rendelkezik. Az ügyféloldali funkciók az alábbiak: ― jóváhagyott frissítések garantált telepítése, ― ütemezett telepítési lehetıségek, ― beépített biztonság (digitális aláírások meglétének ellenırzése), ― letöltés a háttérben. A kiszolgáló oldali funkciók az alábbiak: ― biztosítja a fontos frissítések és szervizcsomagok telepítését Windows XP, Windows Server 2003 rendszerekre, ― beépített biztonság: digitális aláírás meglétének ellenırzése, rendszergazdai beavatkozás lehetısége, ― a tartalom szelektív engedélyezése: a frissítések szelektálhatók, ― távfelügyelet HTTP, HTTPS protokollal, ― a frissítési állapot naplózása, statisztikák készítése. A Linux disztribúciók esetén is elérhetık az automatikus csomagfrissítési megoldások. A legtöbb linux disztribúció rendelkezik szöveges (grafikus) felülető csomagfrissítési megoldással. Redhat esetén a YUM (Yellowdog Update Manager), Debian és Ubuntu esetén az APT (Advanced Package Tool), SuSe esetén a Yast Online Update. Ezek elınye, hogy automatikusan kezelik a csomagfüggıségeket, amelyek általában nagyon megbonyolíthatják a rendszer frissítési mechanizmusát. Egy nagyobb informatikai rendszer legtöbbször vegyesen tartalmaz Windows és Unix kiszolgálókat, sıt megjelentek a Linux alapú felhasználói alkalmazások is. Ezek együttes, központosított frissítés kezelésére ajánlott Patch Management szoftvert alkalmazni. A 3. táblázat megadja a piacon található termékeket. 3. táblázat – A piacon található termékek Szoftver Altiris Patch Management GFI LANguard Network Security Scanner

Forgalmazó honlapja www.altiris.com www.gfi.com


37


Szoftver Patch Authority Plus PatchAdvisor PolicyMaker Software Update WinINSTALL PatchLink Update ANSA SecureCentral PatchQuest PatchWorks Cenergy Patch Manager

Forgalmazó honlapja www.scriptlogic.com www.patchadvisor.com www.desktopstandard.com www.attachmate.com www.patchlink.com www.autonomic-software.com www.adventnet.com www.rippletech.com www.tallysystems.com

Egy Patch Management szoftver kiválasztásakor fontos szempontok az alábbiak: a) A szoftver kiszolgálókra, vagy munkaállomásokra alkalmazható? Ha mindkettıre akkor pontosan melyik operációs rendszerekre használható? b) Hogyan kezeli le a sikertelen frissítési eseteket? c) Hogyan térképezi fel a hálózatban található gépeken az operációs rendszereket és a telepített szoftvereket? d) Integrálható-e más konfiguráció kezelı alkalmazásokba? e) Képes-e riportot készíteni a tevékenységérıl (sikeres, sikertelen)? f) Kezel-e prioritásokat az elérhetı frissítések között? 6.3.2.5. A frissítés megvalósítása /tesztrendszerek alkalmazása/ A frissítési végrehajtásának helyes megvalósítása különösen fontos. Az alábbi hibák gyakran elıfordulnak, ezekre tehát különösen figyelni kell: a) A frissítés tesztelés nélkül kerül telepítésre. Néhány alkalmazás kompatibilitási hiba miatt a frissítés után rosszul mőködik. b) Nem gondoskodnak visszaállítási lehetıségrıl, rossz frissítés telepítése után nem lehet mőködı pontra visszaállítani a rendszert. c) Sok kliensre egyszerre telepítenek nagy mennyiségő frissítést, ezáltal a saját hálózatuk ellen hajtanak végre DoS támadást. d) Az újraindítás kihagyása az azt megkövetelı frissítések telepítése után. Ez elavult rendszert eredményez. e) Nincs dokumentálva a frissítés kezelés menete. A folyamatos üzem fenntartásához elengedhetetlen a jó dokumentáltság.

7. Mellékletek -

8. Bibliográfia [A Guide to Building Secure Web Applications and Web Services] http://www.owasp.org/index.php/OWASP_Guide_Project [A Security Checklist for Web Application Design]


38


http://www.sans.org/reading_room/whitepapers/securecode/1389.php http://support.microsoft.com/kb/314984 [Linux Security Checklist] /Lori Homsher, Tim Evans/ http://www.sans.org/score/checklists/linuxchecklist.pdf Oracle Database Listener Security Guide: http://www.databasesecurity.com/oracle/Integrigy_OracleDB_Listener_Security.pdf DSS Auditing Documentation for Windows 2000/XP http://www.sans.org/score/checklists/Win2K_XP_Checklist.pdf [Patch Patch management] /Brad Ruppert/ https://www2.sans.org/reading_room/whitepapers/iso17799/2064.php [Risk-Based and Functional Security Testing] /C. C. Michael, Will Radosevich, Cigital/

9. Rövidítésgyőjtemény A 4. táblázat a dokumentumban használt rövidítéseket tartalmazza. 4. táblázat – A dokumentumban használt rövidítések Rövidítés API ASCM_SBC ASDV_ARC ASDV_SIS ASDV_SDS ASGD_CON ASGD_PRE ASTE_COV ASTE_DPT ASTE_FUN ASP CIFS CM EKK HTTP HTTPS IIS ISAPI IT KOP NTFS SMB SQL SSH SSL

Angol Application Programming Interface ASCM: System Base-Configuration ASDV: Security Architecture ASDV: System Interface specification ASDV: STOE Design ASGD: Configuration guidance ASGD: Preparative guidance ASTE: Coverage ASTE: Depth ASTE: Functional tests Active Server Pages Common Internet File system Configuration Management --Hypertext Transfer Protocol Secure http Internet Information Service Internet Server Application Programming Interface Information Technology --Windows NT File System Server Message Block Structured Query Language Secure Shell Secure Sockets Layer

Magyar Alkalmazás programozói interfész Rendszer alapkonfiguráció garanciacsalád Biztonsági architektúra garanciacsalád Rendszer interfész specifikáció garanciacsalád STOE terv garanciacsalád Konfigurálási útmutató garanciacsalád Elıkészítı útmutató garanciacsalád Lefedettség garanciacsalád Mélység garanciacsalád Funkcionális tesztek garanciacsalád Aktív szerver oldalak Közös Internet fájl rendszer Konfiguráció kezelés e-Közigazgatási Keretrendszer Hipertext továbbító protokoll Biztonságos HTTP Internet információs szolgáltatás Internet szerver alkalmazás programozói interfész Információs technológia, informatika közigazgatási operatív program Windows NT fájl rendszer Szerver üzenet blokk (protokoll) Strukturált lekérdezı nyelv Biztonságos csatorna Biztonságos kapcsolati réteg


39


Rövidítés STOE TNS URL

Angol System Target of Evaluation Transparent Network Substrate Uniform Resource Locator

Magyar Rendszer értékelés tárgya Transzparens hálózati alap Egységes erıforrás helymeghatározás

10. Fogalomtár -

11. Ábrák -

12. Képek -

13. Táblázatok 1. táblázat - A rendelkezı hivatkozások elérhetısége 2. táblázat – A definiálható szerepkörök és feladatok 3. táblázat – A piacon található termékek 4. táblázat – A dokumentumban használt rövidítések

14. Verziószám V3


40

ÚTMUTATÓ RENDSZER INTEGRÁTOROK SZÁMÁRA

Recommend Documents