Sérülékenységkezelés: hogyan priorizáljon

Egy közepes méretű szervezet sérülékenység-szkennere jellemzően több ezer találatot ad, ebből több százat "kritikus" vagy "magas" besorolással. Ezt senki nem tudja lekezelni, és a leggyakoribb következmény az, hogy a lista senkit nem érdekel többé.

A megoldás nem több erőforrás, hanem jobb priorizálás. Ez a cikk arról szól, hogyan lehet a több ezerből kiválasztani azt a néhány tucatot, ami valóban számít.

Miért nem elég a CVSS

A CVSS-pontszám a sérülékenység elméleti súlyosságát méri, laboratóriumi körülmények között. Amit nem mond meg:

• kihasználják-e ténylegesen a valóságban,
• elérhető-e egyáltalán az adott rendszer a támadó számára,
• mit ér a rendszer üzletileg,
• van-e körülötte kompenzáló kontroll.

Emiatt fordul elő, hogy egy CVSS 9.8-as hiba egy izolált, internetről elérhetetlen tesztrendszeren kevésbé sürgős, mint egy CVSS 6.5-ös a publikus webalkalmazásban, amit aktívan támadnak.

A három adatforrás, ami rendet tesz

1. KEV: amit ténylegesen kihasználnak

A CISA Known Exploited Vulnerabilities katalógusa azokat a sérülékenységeket sorolja fel, amelyekre bizonyítottan létezik aktív kihasználás a vadonban. Ez néhány ezer tétel a több százezer CVE-ből.

Ha egy találat szerepel a KEV-ben, az azonnali prioritás, függetlenül a CVSS-pontjától. Ez az egyetlen szűrő, ami a legtöbb szervezet listáját azonnal kezelhető méretűre csökkenti.

2. EPSS: a kihasználás valószínűsége

Az Exploit Prediction Scoring System azt becsüli, mekkora eséllyel használják ki az adott sérülékenységet a következő 30 napban. Az érték 0 és 1 között mozog.

A gyakorlati tapasztalat: a CVE-k túlnyomó többségének EPSS-értéke 0,01 alatt van, vagyis gyakorlatilag soha nem használják ki őket. A magas CVSS és alacsony EPSS kombináció a leggyakoribb, és pontosan ez az, ami elárasztja a listát.

3. A saját kontextus

Ez az, amit külső adatbázis nem tud megadni:

• Elérhetőség: internetről elérhető, belső hálózatról, vagy izolált szegmensből?
• Üzleti kritikusság: mi történik, ha ez a rendszer kiesik vagy kompromittálódik?
• Adat: kezel-e személyes vagy üzleti szempontból érzékeny adatot?
• Kompenzáló kontroll: van-e előtte WAF, IPS, szegmentálás, ami a kihasználást megakadályozza?

A gyakorlati priorizálási sorrend

A P5 kategória fontos: nem minden sérülékenységet kell javítani. A dokumentált kockázatelfogadás legitim válasz, ha a döntést valaki meghozza és aláírja. Ami nem legitim, az a hallgatólagos figyelmen kívül hagyás.

OT-környezetben más a helyzet

Ipari környezetben a patch-elés gyakran nem opció. A gyártói támogatás lejárt, a frissítés érvénytelenítené a minősítést, vagy a leállási ablak évente egyszer van.

Ez nem jelenti azt, hogy nincs mit tenni. A sorrend más:

1. Ismerd meg, mid van. Passzív felderítés, firmware-verziók pontos rögzítése. Enélkül nincs sérülékenység-illesztés.

2. Szűrj elérhetőség szerint. Egy sérülékeny PLC egy jól szegmentált zónában, ahová csak a mérnöki munkaállomásról van út, lényegesen kisebb kockázat, mint ugyanaz laposan bekötve.

3. Alkalmazz kompenzáló kontrollt. A hálózati szintű virtuális patch (ipari IPS, ami az adott sérülékenységet célzó forgalmat blokkolja) gyakran az egyetlen reális válasz. Nem javítja a hibát, de megakadályozza a kihasználását.

4. Tervezz a leállási ablakra. A ténylegesen javítandó tételek listája álljon készen, amikor eljön az ablak, mert ott órák állnak rendelkezésre, nem napok.

5. Dokumentálj. A NIS2 ötödik intézkedése és az IEC 62443-2-3 is a folyamatot kéri számon, nem a nulla sérülékenységet. Egy működő, dokumentált kockázatelfogadás megfelelő válasz.

A működő folyamat elemei

Felderítés. Folyamatos, automatizált szkennelés a teljes vagyonleltáron. IT-ban aktív, OT-ban passzív.

Priorizálás. A fenti sorrend szerint, automatizáltan ha lehet. A cél, hogy a csapat elé kerülő lista tíz tételes legyen, ne kétezer.

Felelős. Minden tételnek legyen gazdája. A "az IT majd megcsinálja" nem felelős.

Határidő és követés. Prioritási szintenként rögzített határidő, és mérés arról, hogy tartják-e.

Ellenőrzés. A javítás után újraszkennelés. Meglepően gyakran derül ki, hogy a patch települt, de a szolgáltatás nem indult újra, tehát a régi verzió fut tovább.

Kivétel-kezelés. Írásos, határidős, felülvizsgált kockázatelfogadás azokra, amiket nem javítanak.

Mit mérjen

Három mutató elég:

• Átlagos javítási idő (MTTR) prioritási szintenként. Ez mutatja, működik-e a folyamat.
• KEV-listás nyitott tételek száma. Ennek nullához kell tartania.
• Lefedettség: a vagyonleltár hány százaléka van egyáltalán szkennelve.

A harmadik szokta a legnagyobb meglepetést okozni. Sok szervezetnél a szkennelés a szerverekre korlátozódik, miközben a munkaállomások, a hálózati eszközök és a peremberendezések kimaradnak. Márpedig a támadók pont ott jönnek be.

Ha szeretné felmérni, hol tart, az IT biztonsági szolgáltatásaink között a sérülékenységkezelési folyamat kialakítása is szerepel, OT-oldalon pedig az OT sebezhetőség-értékelés. A penetrációs tesztelésről és az IEC 62443 keretrendszerről külön cikkben írtunk.