Szerző: Boros Balázs

Az IT security audit nem puszta megfelelőségi gyakorlat, hanem egy alapos, rendszerszintű állapotfelmérés és rendrakás az egész digitális környezetben: feltárja a rejtett kockázatokat, átláthatóbbá teszi a folyamatokat, és megmutatja, mennyire ellenálló a szervezet a valós támadási módszerekkel szemben. Célja a kockázat érdemi csökkentése és az üzleti célok (elérhetőség, bizalmasság, sértetlenség) támogatása. A hangsúly nem a hibák listázásán, hanem a gyakorlati, üzleti hatáson van.

Mi az IT security audit - és mi nem az?

Az audit független, bizonyítékalapú felmérés az emberek-folyamatok-technológia hármasán. Nem azonos a sebezhetőség-szkenneléssel vagy egy penetrációs teszttel: ezek csak adatgyűjtési módszerek. A teljes audit kiterjed a governance-re, a szabályzatokra és eljárásokra, a naplózásra és monitorozásra, a mentés-visszaállításra, az incidenskezelésre, a beszállítói kockázatokra és a helyreállítási képességre is. A technikai részeknél sokszor külön vizsgáljuk a hálózati réteget, ha ezt célzottan szeretnéd megerősíteni, a hálózati audit jó kiindulópont.

Mikor érdemes auditot indítani?

Auditot akkor érdemes indítani, amikor nagyobb változás történik, például felhőmigráció, új üzleti alkalmazás bevezetése vagy felvásárlás, mert ezek az átalakítások tipikusan új kitettségeket hoznak. Ugyanígy indokolt, ha a szervezetnek NIS2/ISO 27001 vagy iparági követelményeknek kell megfelelnie, ha ismétlődő incidensek vagy gyanús események jelennek meg, illetve ha a vezetőség kockázati riportot és költségtervet készít a következő időszakra. A jól időzített audit nem késleltet, hanem felgyorsítja a döntéshozatalt, mert világossá teszi, hol érdemes először beavatkozni.

Audit típusok és fókuszok

A megfelelőségi audit azt vizsgálja, mennyire illeszkednek a kontrollok a NIS2, az ISO/IEC 27001 vagy a CIS Controls elvárásaihoz, és mennyire koherensek a policyk és eljárások. A technikai audit a konfigurációkra, a hardeningre, a sebezhetőségekre és a hozzáférés-higiéniára koncentrál, itt illeszkedik természetesen a célzott hálózati audit is. A folyamat-audit az incidenskezelésre, a változáskezelésre, a mentés-visszaállításra és a harmadik felek bevonására fókuszál, míg a felhő-audit az identitás- és jogosultságkezelést, a nyilvános erőforrásokkal kapcsolatos kockázatokat, a titkosítást és a naplózást értékeli.

Ajánlott módszertan

A gyakorlatban a legjobb eredményt egy jól keretezett, hatlépéses folyamat adja. A kick-off és scope meghatározás során rögzítjük a célokat, a vizsgált rendszereket és adatosztályokat, az időzítést és a felelősöket.

Ezt követi az eszköz- és adatleltár, amelyben a CMDB/asset-adatokat üzleti kritikalitással és adatosztályozással egészítjük ki.

Az adatgyűjtés interjúkból, konfigurációs exportokból, naplókból, sérülékenység- és jogosultság-elemzésekből áll, majd a kockázatértékelés következik, ahol valószínűség és hatás alapján számítjuk a maradványkockázatot.

A javaslatok és roadmap szakaszban gyors nyereségeket, taktikai és stratégiai lépéseket különítünk el, végül egy tömör vezetői összefoglaló zárja a folyamatot, amely döntéstámogató, és KPI/KRI kiinduló értékeket is ad.

A megvalósítás és az üzemeltetés folytonosságát a IT security üzemeltetés szolgáltatásunkkal biztosítjuk, hogy a feltárt kockázatok tartósan csökkenjenek.

Gyakori megállapítások

A legtöbbször azt látjuk, hogy az adminisztrátori és távoli hozzáférések egy része még mindig MFA nélkül működik, miközben az operációs rendszerekhez, hálózati eszközökhöz és alkalmazásokhoz érkező frissítések bevezetése késik. Gyakori, hogy a mentések nem követik a 3-2-1 elvet, ritkán történik visszaállítási próba, és hiányzik az immutability, ezért a visszaállíthatóság kockázatos. A naplózás sok helyen hézagos: audit logok hiányoznak vagy túl rövid a megőrzés, a központi korreláció pedig nem teljes, ami megnehezíti a korai észlelést. Probléma továbbá a privilegizált jogosultságok túlzott szóródása és a segregation of duties hiánya, illetve a hálózati szegmensek közti oldalirányú mozgás túl nagy tere.

Felhőben tipikus a félrekonfigurálás: nyilvános erőforrások kerülnek véletlenül internetre, hiányzik a szervezetszintű titkosítás vagy túl széles szerepkörök maradnak meg. A végpontvédelem sem mindenhol egységes, EDR-lefedettségi rések keletkeznek, miközben az e-mail autentikáció (SPF/DKIM/DMARC) nincs kellően szigorítva, és nincs egységes URL-sandboxing. Végül a beszállítói láncban sokszor hiányoznak a biztonsági SLA-k és a hozzáférési korlátok, ami a harmadik feleken keresztüli kitettséget növeli.

Mérés: KPI/KRI és dashboard

Az érett biztonsági működés mérhető. Kulcsmetrikáknak számít a kritikus frissítések bevezetési ideje (patch MTTR), az EDR-lefedettség és a riasztásokra adott válasz sebessége, a mentések visszaállítási sikeraránya, az RPO/RTO célok teljesülése, a kiemelt fiókok MFA-aránya és a break-glass eljárások rendszere. Érdemes folyamatosan követni a harminc napon túl nyitva maradó kritikus sebezhetőségek számát és trendjét, valamint az e-mail autentikációs állapotot és a felhasználói phishing mutatókat. Ezeket a mutatókat a napi üzemeltetésben is fenntartjuk a IT security üzemeltetés szolgáltatásunkkal.

NIS2 és az audit kapcsolata

A NIS2 elvárások akkor válnak valódi védelemmé, ha konkrét operatív kontrollokká fordítjuk őket. Az audit ebben segít: eszköz- és kitettség-menedzsmentre, hozzáférés-kezelésre, incidenskezelésre, naplózásra és monitorozásra, üzletmenet-folytonosságra és beszállítói kockázatra bontja a követelményeket. A végén egy világos rés-elemzés, egy megvalósítási ütemterv és egy mérhető fejlődési pálya áll, amelyhez vezetői szintű riportolás kapcsolódik.

30/60/90 napos akcióterv

Az első harminc napban a gyors nyereségekre érdemes koncentrálni: minden adminisztrátori és távoli hozzáférésre kötelező MFA, az elavult protokollok letiltása, az EDR-lefedettségi rések bezárása és a magas megbízhatóságú riasztások felülvizsgálata. A mentési stratégia 3-2-1 elv szerinti rendezése, az immutability bevezetése és a rendszeres visszaállítási próba ugyancsak ide tartozik, miközben az SPF/DKIM/DMARC irányelvek fokozatos szigorítása csökkenti a levelezési kitettséget.

Hatvan nap környékén a folyamatok stabilizálása kerül előtérbe: ütemezett patching, dokumentált kivételkezelés a „különleges” rendszerekre, központi naplózás megfelelő megőrzéssel és kiemelt felhasználási esetekkel, valamint egy zárt sérülékenység-menedzsment ciklus, ahol a javítás igazolása is része a folyamatnak.

Kilencven napra érdemes tervezni az incidenskezelési terv élesítését tabletop gyakorlattal és értesítési mátrixszal, az IAM rendrakását (szerepkör-alapú hozzáférés, least privilege, privilegizált hozzáférések kezelése), a hálózati szegmentáció erősítését, például a távoli adminisztrációt dedikált jump hoston keresztül és a DR/BCP tesztet, amely validálja az RTO/RPO célokat és visszacsatolja a tanulságokat.

Hogyan készülj fel az auditra?

A felkészülés az átlátható scope-pal és prioritásokkal kezdődik: rangsorold az üzleti rendszereket és végezz adatosztályozást, biztosíts napló- és konfigurációs exportokat, adj ideiglenes és célzott lehetőleg read-only hozzáféréseket az auditoroknak, és készítsd elő a dokumentációt (szabályzatok, hálózati rajzok, mentési és incidenskezelési tervek). Érdemes RACI mátrixot készíteni, amelyben egyértelműek a felelősségek az IT, a biztonság, az üzlet, a jog és a kommunikáció között, és gondoskodni kell a titkosított megosztásról és az adatminimalizálásról is.

Összefoglalás

Egy jól lefuttatott audit nem piros-zöld minősítés, hanem priorizált beruházási terv és fejlődési pálya, amely az operatív működésbe beépülve tartósan csökkenti a kockázatot. Mi a felméréstől a napi üzemeltetésig végigkísérjük a megvalósítást a IT security üzemeltetés szolgáltatásunkkal, és ahol indokolt, a technológiai kontrollokat kiberbiztosítással is összekapcsoljuk, hogy a legrosszabb napon is kiszámítható maradjon a működés.