Miért fontos a rendszeres penetrációs tesztelés

A penetrációs tesztelés körül két véglet uralkodik. Az egyik szerint felesleges pénzkidobás, mert „úgyis mindig találnak valamit". A másik szerint elég évente egyszer megcsináltatni, és onnantól a rendszer biztonságos. Mindkettő téves, és mindkettő ugyanabból ered: a teszt céljának félreértéséből.

Sérülékenységvizsgálat vagy penetrációs teszt?

Ezt a kettőt gyakran keverik, pedig alapvetően más a kimenetük.

A különbség lényege: a szkenner egy listát ad arról, mi lehet baj. A penetrációs teszt megmutatja, mi van baj, és mit ér el vele egy támadó.

Egy példa a gyakorlatból. Egy szkenner külön-külön „közepes" súlyosságúnak minősít három dolgot: egy elavult könyvtárat, egy túl bőkezű jogosultságot és egy belső szolgáltatás alapértelmezett hitelesítő adatait. Egyik sem indokolna sürgős beavatkozást. Egy tesztelő viszont ezt a hármat egymás után fűzve tartományi adminisztrátori jogosultságot szerez. A lánc értéke sokkal nagyobb, mint az elemek összege, és ezt csak ember látja meg.

Miért nem elég az évi egy alkalom

A leggyakoribb megközelítés az éves teszt, jellemzően valamilyen megfelelőségi követelmény miatt. Ez jobb a semminél, de két problémája van.

A környezet folyamatosan változik. Egy átlagos szervezet évente több tucat rendszert vezet be vagy módosít. A januári teszt eredménye augusztusra nagyrészt elavult.

A fenyegetési kép is változik. Az évi egy teszt nem méri, mennyi idő alatt reagálsz egy újonnan megjelenő, aktívan kihasznált sérülékenységre.

Egy működő ritmus inkább így néz ki:

• Folyamatos sérülékenységvizsgálat, automatizálva, a teljes vagyonleltáron.
• Évente teljes körű penetrációs teszt, külső és belső perspektívából.
• Eseti teszt jelentős változás után: új internetre kitett szolgáltatás, nagyobb architektúra-változás, felvásárlás utáni integráció.
• Célzott teszt a legkritikusabb üzleti folyamatra, évente egyszer, akár red team jelleggel.

Mit teszteljünk, és milyen perspektívából

A hatókör-meghatározás dönti el a teszt értékét. A tipikus perspektívák:

Külső (external). Amit az internet felől lát egy támadó. Ez a minimum: de önmagában hamis biztonságérzetet adhat, mert a legtöbb valós incidens phishinggel indul, ami megkerüli a perimétert.

Belső (internal). A kiindulópont egy kompromittált munkaállomás vagy egy vendéghálózati csatlakozás. Ez a legtöbb szervezetnél a legtanulságosabb: itt derül ki, hogy a belső hálózat lapos, a jelszavak újrahasználtak, és a laterális mozgásnak nincs akadálya.

Webalkalmazás. Hitelesített és nem hitelesített szerepekből, üzleti logikai hibákra is fókuszálva, ezeket egyetlen szkenner sem találja meg.

Social engineering. Phishing-szimuláció, esetleg fizikai behatolás. A leggyakoribb valós támadási vektort méri.

OT/ICS. Ipari környezetben külön megközelítés kell, erről alább.

OT-környezetben más a játék

Ipari hálózaton a szokásos penetrációs teszt módszertan veszélyes. Egy agresszív port-szkennelés megbéníthat egy PLC-t, egy kihasználási kísérlet leállíthatja a gyártást.

Az OT-tesztelés ezért jellemzően:

• passzív felderítéssel indul, forgalomtükrözésből,
• laborban vagy leállás alatt végzi az aktív részt, lehetőleg azonos típusú tartalék eszközön,
• a szegmentáció-ellenőrzésre fókuszál: valóban nem lehet átjutni az IT-ből az OT-ba? Működnek-e a zónahatárok?
• a kihasználás helyett gyakran elméleti támadási lánc felvázolásával zárul, ha a valós végrehajtás kockázata elfogadhatatlan.

Erről bővebben az OT behatolás-tesztelés oldalunkon írtunk.

Hogyan ismerhető fel a jó tesztjelentés

A jelentés az egyetlen dolog, ami a tesztből marad. Ezekre érdemes figyelni:

Van benne reprodukálható bizonyíték. Lépésről lépésre leírás, képernyőképek, kérések és válaszok. Ha nem tudod magad reprodukálni, nem tudod majd ellenőrizni a javítást sem.

Üzleti hatás szerint priorizál, nem CVSS szerint. A CVSS a sérülékenység elméleti súlyosságát méri, nem azt, hogy nálad mit jelent. Egy „közepes" hiba a fizetési folyamatban fontosabb, mint egy „magas" egy izolált tesztrendszeren.

Támadási láncokat mutat, nem csak elemeket. Lásd fentebb: az érték a láncban van.

Konkrét javítási javaslatot ad. Nem azt, hogy „erősítsd a hozzáférés-kezelést", hanem azt, hogy melyik konfigurációt hol kell megváltoztatni.

Van benne vezetői összefoglaló: érthetően, szakzsargon nélkül, hogy a döntéshozó is tudjon vele mit kezdeni.

Tartalmazza az újratesztelést. A javítás után egy ellenőrző kör nélkül nem tudod, hogy a hiba tényleg megszűnt-e.

A tesztelés megfelelőségi oldala

A rendszeres tesztelés nem csak jó gyakorlat, több helyen elvárás is. A NIS2 ötödik intézkedési területe (beszerzés, fejlesztés, karbantartás biztonsága) és hatodik területe (a biztonsági intézkedések hatékonyságának mérése) gyakorlatilag megköveteli a rendszeres, dokumentált tesztelést. Az ISO 27001 technikai megfelelőségi felülvizsgálati kontrollja szintén ide tartozik, a PCI DSS pedig kifejezetten előírja.

Fontos azonban a sorrend: ne azért tesztelj, hogy legyen papír. Azért tesztelj, hogy megtudd, mi működik, a papír ennek melléktermékeként úgyis meglesz.

Mit tegyél a jelentés után

A teszt értéke a javításban realizálódik. Egy használható folyamat:

1. Triázs, a találatok besorolása üzleti hatás szerint, felelősök kijelölése.
2. Azonnali intézkedés a kritikus elemekre, akár ideiglenes kompenzáló kontrollal.
3. Ütemezett javítás a többire, konkrét határidővel.
4. Gyökérok-elemzés, miért jött létre a hiba? Ha ugyanaz a hibatípus több helyen előfordul, folyamatprobléma van, nem konfigurációs.
5. Újrateszt a javítások ellenőrzésére.
6. Visszacsatolás a fejlesztési és üzemeltetési folyamatokba.

Az ötödik pont az, amit a legtöbben kihagynak, pedig ez különbözteti meg a javuló biztonsági programot attól, amelyik évről évre ugyanazokat a hibákat találja meg újra.

Ha aktuális a tesztelés, a penetrációs tesztelési szolgáltatásunk hatókör-egyeztetéssel indul, és újrateszttel zárul.