Röviden: A sebezhetőségkezelés a közép- és kisvállalkozásoknál egy karcsú, ismétlődő ciklus: a rendszerek ismerete, a közlemények célzott követése, kockázat szerinti értékelés, döntés, megvalósítás és igazolás. Nem a drága eszközök a döntők, hanem az egyértelmű felelősségek és egy olyan sorrend, amely figyelembe veszi az elérhetőséget, az adatokat és a támadási helyzetet. A PHP2Shell jó gyakorlópélda, mert benne minden lépés előfordul.
Száz közlemény, kevés munkatárs
Hétről hétre újabb biztonsági réseket hoznak nyilvánosságra operációs rendszerekben, programozási nyelvekben, alkalmazásokban és bővítményekben. Egy nagyvállalatnak erre van egy csapata. Egy középvállalkozásnak gyakran van egy IT-vezetője, egy-két rendszergazdája és több külső szolgáltatója. Senki sem tud minden közleményt elolvasni, és nem is kell.
Szűrőre van szükség: mely közlemények érintik a rendszereinket, ezek közül melyik sürgős, és ki foglalkozik vele? Ha ez a szűrő hiányzik, két dolog egyike történik. Vagy mindent figyelmen kívül hagynak, amíg meg nem történik valami, vagy minden közlemény felbolydulást okoz, és az igazán kritikus elvész a zajban.
A sebezhetőségkezelés ciklusa
A kkv-k számára használható folyamat hat lépésben írható le:
- Felmérni, mi fut. Leltár nélkül nincs összevetés. Mely weboldalakat, szervereket, PHP-verziókat és alkalmazásokat üzemeltet, és hol? Hogyan sikerül ez, azt a Tudni, mi fut: az összes weboldal és szerver leltára mutatja meg.
- Közleményeket követni. Néhány megbízható forrásra feliratkozni: a BSI (a német Szövetségi Információbiztonsági Hivatal) figyelmeztetései, a használt szoftverek gyártóinak közleményei, a Linux-disztribúció biztonsági oldalai, a PHP-nél a php.net nyitóoldala.
- Értékelni. Érint-e minket a közlemény? Ha igen, mennyire sürgős? Erről lejjebb bővebben.
- Dönteni. Kijavítani, átmenetileg védeni, a rendszert elszigetelni vagy a kockázatot tudatosan vállalni. Ki dönthet miről?
- Megvalósítani. Frissítést telepíteni, átmeneti intézkedést beállítani, szolgáltatót megbízni.
- Igazolni és nyomon követni. Valóban lezárult a rés? Mikor váltják le az átmeneti megoldást?
A ciklus ezután elölről kezdődik. Új rendszerek jönnek, a régiek kiesnek, és új közlemények jelennek meg.
A 2. lépéshez egy egyszerű szabály segít: inkább kevés forrást olvasson rendszeresen, mint sokat alkalmanként. Egy tipikus középvállalati webes környezetben többnyire elegendő a BSI-nál működő CERT-Bund (a német szövetségi kormányzat CERT-je) figyelmeztetése, a használt Linux-disztribúció biztonsági közleményei, a CMS- és webshopgyártók oldalai és a php.net nyitóoldala. Határozza meg, ki olvassa ezeket a forrásokat, és erre hozzon létre egy közös postafiókot vagy csatornát, amely nem egyetlen személyhez kötött.
Kiegészítésként érdemes kívülről is rápillantani. A nyilvánosan elérhető rendszerek rendszeres sebezhetőségi vizsgálata megmutatja, hogy látható-e elavult szoftver vagy szükségtelenül nyitott szolgáltatás. Nem helyettesíti a leltárt és a frissítéseket, de feltárja azokat a rendszereket, amelyek egyetlen listán sem szerepelnek.
Értékelés: mi kerül elsőként sorra
A CVSS-érték, a súlyosság szabványosított besorolása, jó kiindulópont. A saját házon belüli sorrendhez azonban nem elég. Három további kérdés dönt:
| Kérdés | Növeli a sürgősséget | Csökkenti a sürgősséget |
|---|---|---|
| Elérhető a rendszer az internetről? | nyilvános weboldal, webshop, portál | csak belső, VPN mögött |
| Szükséges bejelentkezés a rés kihasználásához? | nem, hitelesítés nélkül | igen, csak rendszergazdáknak |
| Milyen adatokat dolgoz fel a rendszer? | ügyféladatok, fizetések, hozzáférések | nyilvános tartalmak fiókok nélkül |
| Vannak jelentések támadásokról? | támadási kísérleteket jelentettek | nincs ismert kísérlet |
| Van átmeneti intézkedés? | nincs | van, igazolt hatással |
A PHP2Shell megmutatja, hogyan hat együtt mindez. Mindkét rés CVSS v4.0 értéke 9,2, bejelentkezés nélküli kódfuttatást tesznek lehetővé, és nyilvánosan elérhető webszervereket érintenek. A Cloudflare és a Patchstack a médiajelentések szerint támadási kísérletekről számolt be, a BSI pedig a helyzetet 3. riasztási szintűnek minősítette. A php.net átmeneti intézkedései kifejezetten nem nyújtanak teljes védelmet. Minden kérdés ugyanabba az irányba mutat: azonnal cselekedni. Hogy a BSI konkrétan mit javasolt, az A BSI ajánlásai a PHP2Shellről oldalon áll.
Dönteni és dokumentálni
Nem minden rés zárható le azonnal. Egy régi rendszer PHP 8.1-en fut, amelyhez már nincsenek hivatalos frissítések (lásd a PHP 8.1 és régebbi: mi érvényes most oldalt), egy szakalkalmazás pedig még nem bírja a frissítést. Ilyenkor döntésre van szükség, és az nem tartozhat egyedül a technikához.
Egy jó döntési feljegyzés tartalmazza az érintett rendszert, a rést, az értékelést, a választott lehetőséget, az átmeneti intézkedéseket, a felelős személyt és egy időpontot az újbóli felülvizsgálatra. Ha egy kockázatot tudatosan vállalnak, a vezetés dönt, nem a rendszergazda egyedül. A sebezhető függőségek kezeléséről szóló OWASP Cheat Sheet is azt ajánlja, hogy a kockázatvállalás kifejezetten vezetői szinten legyen rögzítve.
Vezessen egyetlen listát a nyitott sebezhetőségekről állapottal, felelőssel és határidővel. Egy táblázat is elég. Az a fontos, hogy rendszeresen átnézzék, például a vezetéssel tartott havi körben.
Mi köze ehhez a NIS2-nek és a szolgáltatóknak
A NIS2 hatálya alá tartozó vállalkozásoknál a sebezhetőségek kezelése a kockázatkezelési kötelezettségek része. A részleteket a NIS2 és a webszerverek biztonsága írja le. De törvényi kötelezettség nélkül is előny egy dokumentált folyamat, például az ügyfelekkel, a biztosítókkal és a saját vezetéssel szemben.
Sok lépés kiszervezhető, például a közlemények követése vagy a frissítések telepítése. A kockázatokról szóló döntésnek és az átfogó áttekintésnek azonban házon belül kell maradnia. Aki a ciklust teljesen átadja egy szolgáltatónak, vészhelyzetben már nem tudja, egyáltalán mely rendszerei vannak. Hogyan szervezhető meg a megvalósítás rutinként, azt a Patchmenedzsment folyamatként, nem tűzoltásként írja le.
Hogyan segít konkrétan a PHP SOS?
- Önnel együtt elkészítjük a weboldalak és szerverek leltárát, minden összevetés alapjaként.
- Követjük az Ön rendszereire vonatkozó közleményeket, és világos szavakkal értékelést adunk ajánlással.
- Döntési feljegyzéseket készítünk elő olyan esetekre, amikor a frissítés nem lehetséges azonnal.
- A biztonsági monitoringon keresztül folyamatosan ellenőrizzük, hogy a rendszerek feltűnővé válnak-e, amíg egy rés még nyitott.
Összegzés: A sebezhetőségkezelésnek a közép- és kisvállalkozásoknál nem kell nagynak lennie, de kötelezőnek igen. Aki ismeri a rendszereit, néhány jó forrást olvas és rögzíti a döntéseket, a következő kritikus közleménynél gyorsan és helyesen reagál.
Gyakori kérdések
Mi a sebezhetőségkezelés?
Egy ismétlődő folyamat, amelynek során a vállalkozás megtudja, értékeli, kijavítja vagy tudatosan vállalja a rendszereiben lévő biztonsági réseket, és az eredményt rögzíti. Nem egy eszközről szól, hanem felelősségekről és döntésekről.
Elég a CVSS-érték a sorrend meghatározásához?
Jó kiindulópont, de nem elég. Emellett az dönt, hogy az érintett rendszer elérhető-e az internetről, milyen adatokat dolgoz fel, és megfigyeltek-e már támadásokat. Egy belső tesztrendszeren lévő magas értékű rés várhatna, a webshopon lévő nem.
Kell ehhez egy kisvállalkozásnak saját eszköz?
Kezdetben nem. Elég a rendszerek gondozott listája, a feliratkozott biztonsági közlemények és egy táblázat a nyitott pontokkal. A sebezhetőségi szkennerek akkor érik meg, ha nő a rendszerek száma, vagy rendszeresen igazolni kell az ellenőrzéseket.
Szabad egy rést tudatosan nem kijavítani?
Igen, ha a kockázatot értékelték, a döntést az illetékes vezetés hozta meg, és írásban rögzítették, lehetőleg átmeneti intézkedésekkel és egy időponttal az újbóli felülvizsgálatra.