Egy javítás kiadása és aközött, hogy az utolsó érintett gépre is felkerül, hetek telhetnek el. A támadók ezt az időszakot használják ki. A megjelent javításból gyakran visszafejthető, hol volt a hiba, a még nem frissített gépek pedig ugyanúgy sebezhetők maradnak, mint előtte.
A frissítéskezelés ezért nagyrészt szervezési feladat. Tudni kell, milyen gépek és szoftverek vannak, melyik javítás melyik csoporthoz mikor jut el, mi történik, ha egy frissítés hibát okoz, és honnan derül ki, hogy a folyamat tényleg végigment. Az alábbiak ezt a láncot követik a leltártól a jelentésig. Azt, hogy a sok sebezhetőség közül melyik a sürgős, a sebezhetőségek priorizálásáról szóló cikk tárgyalja, itt a javítás útjáról lesz szó.
Miért maradnak le a harmadik féltől származó alkalmazások
Az operációs rendszer frissítése a legtöbb helyen működik. A beépített frissítési szolgáltatás letölti a javításokat, és a központi felügyeleti eszközök is ezt tudják a legrégebben kezelni. A gépen futó többi program más eset. A böngészők, a PDF-olvasók, a tömörítők, a videokonferencia-kliensek, a futtatókörnyezetek és a szakmai alkalmazások saját kiadási ritmust követnek, és mindegyik máshogy frissül.
- Saját frissítő jogosultság nélkül. Egyes alkalmazások frissítője maga keresi az új verziót, de a telepítéshez helyi rendszergazdai jogot kér. Ez attól függ, hogy a program telepítésekor felkerült-e mellé rendszerjogon futó frissítőszolgáltatás vagy ütemezett feladat. Ha nem, és a felhasználónak nincs rendszergazdai joga, a frissítés csendben elmarad.
- Felhasználói telepítés. Egyes programok a felhasználó profiljába települnek, rendszergazdai jog nélkül. Ezek a központi szoftverlistában gyakran meg sem jelennek.
- Több verzió egymás mellett. Egy futtatókörnyezet régi verziója az új mellett is a gépen maradhat, ha egy régebbi alkalmazás arra hivatkozik. A sebezhető változat így a frissítés után is elérhető.
- Kézi letöltés. Ami nem került szoftverkatalógusba vagy csomagkezelőbe, annak frissítése azon múlik, észreveszi-e valaki az új verziót.
A támadó szemével éppen ezek az alkalmazások érdekesek, mert közvetlenül kezelnek kívülről érkező tartalmat: weboldalt, csatolmányt, letöltött fájlt. Az a folyamat, amely csak az operációs rendszerrel foglalkozik, a gép támadási felületének csak egy részét fedi le.
Eszköz- és szoftverleltár
A frissítési szabályok csak a leltárban szereplő gépekre hatnak. Ha a leltár hiányos, a jelentés rendben lévőnek mutatja a helyzetet, a kimaradt gépeken pedig nem változik semmi.
A leltár két részből áll. Az eszközleltár a hálózaton lévő gépeket sorolja fel, a szoftverleltár azt, ami rajtuk fut. Az eszközökhöz nem elég a felügyeleti eszköz saját listája, mert az csak azokat a gépeket látja, amelyeken az ügynöke fut. Érdemes összevetni más forrásokkal: a címtár számítógépfiókjaival, a DHCP-kiosztásokkal, a hálózati felderítés eredményével és a végpontvédelmi konzol listájával. Ami valamelyikben szerepel, a felügyeleti eszközben viszont nem, az jó eséllyel frissítés nélkül fut.
Mit érdemes eszközönként rögzíteni
- az operációs rendszer pontos verzióját és kiadását, mert a támogatás vége verziónként más,
- a telepített szoftvereket verziószámmal, a felhasználói profilba telepítetteket is,
- a gép szerepét (munkaállomás, szerver, kioszk, termelést kiszolgáló gép) és üzleti felelősét,
- a frissítési csoportot, ahová tartozik,
- az utolsó sikeres frissítés és az utolsó bejelentkezés idejét.
Külön jelölést kérnek a már nem támogatott verziók. Amelyik operációs rendszerre vagy alkalmazásra a gyártó nem ad ki több javítást, azt semmilyen frissítési szabály nem hozza rendbe. Róluk döntés kell: lecserélik, elkülönített hálózati szegmensbe kerülnek, vagy valaki írásban vállalja a kockázatot egy megadott időpontig.
Tesztcsoport, pilot és széles körű kiadás
A frissítési gyűrű azt jelenti, hogy a javítás nem egyszerre kerül minden gépre. Először egy kis csoport kapja meg, a következő csoport pedig csak akkor, ha az előzőnél nem jelentkezett hiba. Ha egy frissítés összeakad egy szakmai alkalmazással vagy egy illesztőprogrammal, a gond így néhány gépen jön elő, és a kiadás megállítható, mielőtt az egész szervezetet érintené.
Egy szokásos felosztás:
| Gyűrű | Kik tartoznak ide | Mit kell ellenőrizni |
|---|---|---|
| Teszt | az informatikusok gépei és néhány tesztszerver | települ-e a javítás, elindul-e a gép, működnek-e az alapalkalmazások |
| Pilot | minden fontosabb részlegből néhány felhasználó, a jellemző alkalmazásaikkal | a szakmai programok, a nyomtatók és a csatlakoztatott eszközök működése |
| Széles kiadás | a munkaállomások többsége | a sikeres telepítések aránya és a beérkező hibajelzések |
| Különleges gépek | szerverek, kioszkok, termelést kiszolgáló gépek | karbantartási ablak és visszaállítási terv |
A pilot csoport annyit ér, amennyit lefed a szervezetben használt alkalmazásokból. Ha a könyvelés vagy a tervezőiroda programja nincs benne, a hiba csak a széles kiadásnál derül ki. A pilot tagjainak tudniuk kell, hogy elsőként kapják a frissítést, és hová jelezzék, ha valami nem működik.
Késleltetés és határidő
A gyűrűk közötti várakozás a kiadástól eltelt napokban adható meg: a pilot néhány nappal a teszt után kapja a javítást, a széles kiadás újabb néhány nap múlva. Minden gyűrűnek határideje is legyen, ameddig a frissítésnek fel kell kerülnie. Utána a gép újraindítást kér, végül kikényszeríti. Határidő nélkül a gyűrű csak ajánlás, és a halogatott újraindítások miatt a gépek egy része hetekig a régi állapotban fut.
A visszalépés is a terv része. Mielőtt a frissítés a következő gyűrűre lép, tisztázni kell, hogyan szüneteltethető a kiadás, és hogyan távolítható el a javítás ott, ahol már gondot okozott.
Karbantartási ablakok és újraindítás a szervereken
A munkaállomás újraindítása egy embert zavar, a szerveré mindenkit, aki a rajta futó szolgáltatást használja. A szerverek ezért rögzített karbantartási ablakban frissülnek, a szolgáltatás gazdájával előre egyeztetett időpontban.
- Függőségi sorrend. Az alkalmazásszerver álljon le előbb és induljon el később, mint az adatbázis, amelyre épül. Ha a sorrend nincs leírva, egy éjszakai újraindítás után az alkalmazás hibával indul, és ez csak reggel derül ki.
- Fürtök és redundáns párok. Ahol a szolgáltatás több csomóponton fut, a csomópontok egymás után frissülnek, így a szolgáltatás közben is elérhető marad. Előtte érdemes ellenőrizni, hogy a megmaradó csomópont valóban átveszi-e a terhelést.
- Mentés és visszaállítási pont. A frissítés előtt legyen friss mentés, és legyen tisztázva, mennyi idő alatt állítható vissza a korábbi állapot. A virtuális gép pillanatképe rövid távú visszalépésre jó, a mentést nem helyettesíti.
- Ellenőrzés utána. Az újraindítás után nem elég, hogy a gép válaszol a hálózaton. Meg kell nézni, hogy a szolgáltatások elindultak-e, és működik-e az, amit a felhasználók használnak.
Gyakori hiba, hogy a frissítés felkerül, az újraindítás viszont elmarad. Sok javítás csak újraindítás után lép érvénybe, addig a gép a régi, sebezhető kódot futtatja, a felügyeleti eszköz pedig „telepítve, újraindításra vár” állapotot mutat, ezért a jelentés ezeket a gépeket külön számolja.
Az OT-környezet gépeinél más szabályok érvényesek. Ott egy leállás a termelést érinti, és a frissítést gyakran a berendezés gyártójának jóváhagyásához kell kötni, ezért ezek a gépek saját ütemezést kapnak.
Soron kívüli frissítés aktívan kihasznált sebezhetőségnél
A gyűrűs kiadás napokig vagy hetekig tart, és a rendes javításoknál ez így van rendjén. Ha viszont egy sebezhetőséget már aktívan kihasználnak, vagy a kihasználás módja a javítással együtt nyilvános lett, ennyi idő nincs. Erre a helyzetre előre leírt eljárás kell, különben a riadalom közben kell kitalálni.
A jelzés több helyről jöhet: a gyártó biztonsági közleményéből, a nemzeti CSIRT figyelmeztetéséből, vagy abból, hogy a sebezhetőség felkerül az amerikai CISA KEV-katalógusába. A katalógus minden tételhez javítási határidőt is megad, amely a CISA BOD 22-01 irányelve alapján az amerikai szövetségi polgári végrehajtó szervekre kötelező, másoknak pedig viszonyítási pontként használható.
Mi változik a soron kívüli kiadásnál
- A döntés. Előre ki kell jelölni, ki rendelheti el a soron kívüli kiadást, és milyen feltételek mellett, például ha a sebezhetőséget kihasználják, és az érintett rendszer elérhető az internetről.
- Rövidebb gyűrűk. A tesztgyűrű megmarad, mert egy hibás frissítés így is leállást okozhat, a várakozás viszont napokról órákra csökken. Elsőként a kitett rendszerek kapják meg a javítást: az internetről elérhető szerverek, a távoli hozzáférést adó rendszerek, a levelezés és a böngészők.
- Ideiglenes védelem. Ha a javítás még nem jelent meg, vagy nem telepíthető azonnal, a gyártó által közölt kerülő megoldás, egy szolgáltatás letiltása, a hozzáférés szűkítése vagy egy hálózati virtuális patch csökkenti a kockázatot a frissítésig.
- Utólagos vizsgálat. Ha a sebezhetőséget a javítás előtt kihasználták, a frissítés nem tünteti el azt, amit a támadó közben a gépen hagyott. A gyártói közlemények gyakran leírják, milyen nyomokat érdemes keresni.
- Visszatérés a rendes ütemhez. A gépek visszakerülnek a gyűrűkbe, az ideiglenes kivételeket pedig lezárják.
Mit mutasson a frissítettségi jelentés
A jelentésből az derüljön ki, hol tart a folyamat, és hol akadt el. Egyetlen százalék arról, hogy a gépek mekkora része „megfelelő”, keveset mond, mert elfedi, mely gépekből áll a hiányzó rész, és mióta hiányzik.
Amit érdemes látni
- A lefedettséget: a leltárban szereplő gépek közül melyik jelent a felügyeleti eszköznek, és melyik nem jelentkezett be egy ideje.
- Az állapotot gyűrűnként: telepítve, újraindításra vár, sikertelen, még nem kezdődött el.
- A legrégebbi hiányzó javítást gépenként. Egy gép, amelyről hónapok óta hiányzik egy frissítés, más teendőt jelent, mint ötven gép, amely a tegnapi kiadásra vár.
- A harmadik féltől származó alkalmazások verzióit, az operációs rendszertől elkülönítve.
- A kihasznált sebezhetőségek javításának állását a soron kívüli határidőhöz mérve.
- A nem támogatott verziókat és a nyitott kivételeket, lejárati dátummal.
A jelentésnek két olvasója van. Az üzemeltetőnek gépenkénti lista kell, amelyből teendő lesz. A vezetést a trend érdekli: fogy-e a régóta hiányzó javítások száma, és tartják-e a soron kívüli határidőket.
A szabályozás is a folyamatot kéri számon. A NIS2 irányelv 21. cikke a kockázatkezelési intézkedések között említi a sebezhetőségek kezelését, az ISO/IEC 27001:2022 A mellékletében pedig külön kontroll szól a műszaki sebezhetőségek kezeléséről. Mindkét esetben azt kell bemutatni, hogy a javítások rendszeresen eljutnak a gépekre, és a hiányokról tudnak.
Kapcsolódó szolgáltatás: Patch- és frissítéskezelés →
