E-közigazgatási rendszerek vizsgálata-A biztonsági tesztelési módszertanok bemutatása-Krasznay Csaba
A biztonsági tesztelések módszertanával több, mérvadó ajánlás is foglalkozik. Ezek közül a legjelentősebbek az Open Source Security Testing Methodology Manual [1], mely az Institute for Security and Open Methodologies kiadványa, a NIST SP 800-115 Technical Guide to Information Security Testing and Assessment ajánlás [2], mely az amerikai kormányzat szabványa és az OWASP Testing Guide [3], amit az Open Web Application Security Project keretében fejlesztenek. A webes alkalmazások tesztelésének módszertanát ezek együttes használatával érdemes összeállítani.
A biztonsági tesztelési módszertanok csoportosítására jelenleg nincs egyezményes megállapodás, a tesztelt rendszerek ismeretétől kezdve, a hozzáférés mértékén át, a bevetett tesztelési eszközökig számos taxonómia létezik. Néhány fogalom azonban gyakran előfordul a szakirodalomban, melyek jól bemutatják a lehetséges módszereket [4].
- Biztonsági funkcionális tesztelés: az újonnan fejlesztett rendszer (alkalmazás) beépített védelmi kontrolljainak megfelelőségi ellenőrzése. Más néven white-box tesztelésnek is hívják, kód közeli megközelítésnek minősül. Pl. nézzük meg, hogy tényleg legalább 8 karaktert kell-e megadni jelszónak.
- Sérülékenység-vizsgálat: a rendszer (alkalmazás) védelmi kontrolljainál előforduló sebezhetőségek felderítése, tipikusan automatikus eszközökkel. Más néven black-box tesztelésként ismert, a modulszintű vizsgálatnak tekinthető. Pl. egyes bemeneteken olyan adatok megadása, melyekre a rendszer egyébként védett információkat ad át.
- Behatolás-tesztelés: az újonnan fejlesztett vagy már működő rendszer védelmi kontrolljainak kijátszása műszaki megoldásokkal, bármilyen kapcsolódó környezeti infrastruktúra felhasználásával. Két alfaja létezik, a Blue teaming, melynek során a tesztelő pontosan ismeri a tesztelt infrastruktúrát, és a Red teaming, melynél semmilyen ismerettel nem rendelkezik.
- Etikus hackelés: a működő rendszer védelmi kontrolljainak kijátszása bármilyen technikával, a rendszer előzetes ismerete nélkül. Ebbe beletartozik az emberi ráhatással (social engineering) történő támadás is.
A fenti technikákat a jogosultsági szint és a rendszer komplexitása szerint az 1. ábra mutatja be.
A fenti módszerek közül a sérülékenység-vizsgálat és a behatolás-tesztelés a legelterjedtebb, használatát több forrásban is kötelező előírásként találhatjuk meg. A tipikusan amerikai szabványok, jogszabályok az informatikai biztonság egyik alapkövének tekintik az ilyen típusú teszteléseket. Az alábbi felsorolás összefoglalja a legelterjedtebb követelményeket.
- Payment Card Industry Data Security Standard (PCI DSS): a nagy bankkártya cégek kártyaadatok biztonságos elektronikus kezelésére vonatkozó előírása az ellenőrzés egyik legfontosabb alapkövének tekinti a sérülékenység-vizsgálatokat. A tanúsításhoz szükséges kétszintű vizsgálat mellett már az érintett rendszerek fejlesztését követően, a megrendelő számára is előírt a biztonsági tesztelés elvégzése.
Az előírás 6.3.7 követelménye szerint a webes alkalmazásokat az OWASP útmutatói alapján kell fejleszteni és ezeket mintavételes módszerrel kell ellenőrizni (biztonsági funkcionális tesztelés), majd a 6.6 követelmény szerint manuális vagy automatikus módszerrel (sérülékenység-vizsgálat) legalább évente vagy minden változás után, egy erre specializálódott szervezettel (belső vagy külső) teszteltetni kell, és az esetleges hibák kijavítása után ezt a tesztet meg kell ismételni. [5] - Federal Information Security Management Act (FISMA): Az USA 2002-ben elfogadott e-kormányzati törvénye alapján a központi ügynökségek valamennyi informatikai rendszerét biztonságos körülmények között kell üzemeltetni. [6] Az alapvető követelményeket a NIST SP 800-53 szabvány [7] tartalmazza, mely a magyar Közigazgatás Informatikai Bizottság 28. [8] ajánláshoz hasonlóan három besorolási szintet határoz meg a rendszerekre. Az előírások között RA-5 jelzéssel szerepel a sérülékenység-vizsgálat. Ez az automatikus eszközökkel végrehajtott tesztelést preferálja, melynek eredményeit egységes formájú jelentésben kell bemutatni. A vizsgálatot a szervezet által meghatározott időközönként vagy a rendszert érintő új sebezhetőség megjelenésekor kell végrehajtani. Közepes biztonsági szinten az automatikus eszköz használatát integrálni kell a változáskezelési eljárások közé, kiemelt szinten pedig a sebezhetőség-vizsgálati folyamatot kell továbbfejleszteni. A külső értékelő által végzett, akár komplex vizsgálatok (behatolás-tesztelés) nem kötelező elem, de ajánlott teszteljárásként fel van tűntetve.
- Control Objectives for Information and related Technology (CObIT): Az elsősorban pénzintézeti szektorban használt IT irányítási ajánlás a DS5.5 Security Testing, Surveillance and Monitoring részben javasolja az informatikai rendszerek rendszeres biztonsági tesztelését, ám ennek módját nem jelzi. Az erre vonatkozó RACI táblázat viszont már nevén nevezi a sérülékenység-vizsgálatot, melynek végrehajtása a Megfelelőség, Audit, Kockázat és Biztonság szerepkör feladata. A biztonsággal kapcsolatos folyamat érettsége akkor tekinthető meghatározottnak, 3-as szintűnek, ha legalább ad hoc módon történnek ilyen vizsgálatok. [9]
- ISO/IEC 27002: A legismertebb információbiztonsági szabvány a 12.6. fejezetben foglalkozik a sérülékenység-vizsgálattal. Eszerint a szervezetnek bizonyos időközönként fel kell mérnie rendszerének technikai sebezhetőségeit, és megfelelő védelmi intézkedésekkel csökkenteni kell az ezekből eredő kockázatokat.
A szabvány nem ad útmutatást a vizsgálat pontos végrehajtására, akár a gyártóktól érkező vagy hiteles forrásokban megjelent információk rendszeres olvasása is kielégíti a követelményeket. A lényeg, hogy a szervezet rendelkezzen ilyen típusú folyamattal. [10] A KIB 28. ajánlás ezt a szellemiséget követi az RS-2 Hibajavítás követelményben, de a folyamat szerepét meglehetősen eljelentéktelenítve.
A biztonsággal foglalkozó szabványok és ajánlások túlnyomó többsége tehát foglalkozik a biztonsági tesztelésekkel, de ezt eltérő szigorúsággal teszi. Jelen tanulmány célja, hogy ezek alapján egységes közigazgatási módszertant dolgozzon ki.
