Frissíteni vagy nem frissíteni, az itt a kérdés

Az IT-világ komolyan felbolydult, miután több nulladik napi MS Exchange sebezhetőséget fedeztek fel biztonsági szakértők. Az eset felhívta a figyelmet a frissítések fontosságára is , amit újból és újból meg kell ismételnünk.

Március közepén figyelmeztettük olvasóinkat arra, hogy négy kritikus fontosságú MS Exchange sebezhetőséghez adott ki frissítést a gyártó. Április közepén a Microsoft további kettő kritikus sebezhetőséget fedezett fel az Exchange Server 2013, 2016 és 2019 kiadásokban, melyek kihasználásával a támadók távolról átvehetik az ellenőrzést a szerverek felett. A hibákat az amerikai NSA jelentette a gyártónak, így a hacker közösségnek nem volt ideje kihasználni. Mármint a jelentés pillanatáig.

A kritikus jellegű biztonsági hibák esetében rendkívül fontos, hogy a vállalatok milyen gyorsan tudják a sérülékeny rendszereket frissíteni. A márciusban bejelentett MS Exchange hibák esetén még egy héttel a híradások után is több tízezer olyan rendszer volt elérhető az interneten, melyeket nem frissítettek. Ennek hatásait már most is lehet érezni, például az egyre gyakoribb zsarolóvírusos támadásokban.

A késlekedés oka

Hasonló problémákról bármely kritikus sérülékenység esetén beszámolhatnánk. A késlekedés oka több évtizede ugyanaz: a frissítés folyamata nem triviális, a patch-eket tesztelni kell, mielőtt a munkavégzésben használt számítógépekre felteszik azokat a rendszergazdák, vagy az adott frissítést a szakemberek különböző okok miatt nem tartják fontosnak. A helyzetet az sem segíti, hogy az elmúlt időben megnőtt a frissítések gyakorisága, bár a Microsoft védelmére legyen mondva, igyekeztek évi két jelentős frissítésre korlátozni ezt a tevékenységet. Így amikor a rendszergazdák épp végeztek az utolsó simításokkal, már érkezik az újabb frissítés. Ez önmagában is komoly kihívást jelent, de ne feledjük, a szervezetet nem egyetlen alkalmazás működteti.

És itt kezdődik a probléma. Az IT-vezetőség azt gondolja, hogy a rendszergazdák mellékesen a frissítéssel is tudnak foglalkozni – ami lássuk be, valóban mindennapi munkájuk részét képezi. Ha őszinték vagyunk, a gyakorlatban a rendszerek frissen tartása a huszonötödik a fontossági listában. És nem ez a legkreatívabb és legmotiválóbb munka a világon. A munkaerőhiánnyal küszködő IT-részlegek sokszor egyszerűen nem tudnak lépést tartani a frissítésekkel.

Nem csak a patchelés a fontos

Ezen a ponton lépjünk egyet hátra. A biztonság nemcsak frissítésekről és a sérülékenységek foltozásáról szól. Kritikus összetevői a vállalati IT-biztonsági stratégiának, de nem ez minden. A sérülékenységek foltozása mellett olyan biztonsági eszközök és megoldások léteznek, mint a többfaktoros azonosítás, a tűzfalak, IPS, titkosítás, egy jól megtervezett antivírus megoldás, melyet mesterséges intelligencia segít ki, vagy az alkalmazottak biztonsági oktatása. Egyetlen összetevő sem garantálhatja a vállalat biztonságát. Az IT-biztonság több faktor sikeres kombinációja.

Ennek megfelelően, egy sikeres támadás sem egyetlen összetevő gyengeségén, hanem több komponens hibáján múlik. Ha a támadó egy cselekedete vagy egy komponens kiesése a teljes vállalati IT-infrastruktúrát is magával rántja, ott tervezési problémák is vannak.

Mit tehetünk?

A frissítések lassú telepítésének egyik oka, a szervezeti tesztkörnyezetek hiánya. Sokat hangoztatott kifogás, hogy korábban a vállalatok már megégették magukat a kritikus alkalmazás frissítése után. Az eredmény, hogy a gyors frissítés helyett a hosszas teszteléssel foglalkoznak, így nem kockáztatják a mindennapi üzletmenet-folytonosságot. Ez a mindennapos dolog komoly valóságot fed fel: a szervezetek kevésbé félnek a biztonsági incidensektől, mint a frissítés üzletmenet folytonosságára gyakorolt hatásáról.

Ez viszont nem jó. A szervezeteknek tisztán meg kell határoznia, hogy mit frissítsen és hogyan, és főként mikor.

A CVSS (Common Vulnerability Scoring System – nyílt iparági szabvány az IT rendszereket érintő biztonsági rések súlyosságának felmérésére) rendszer jó kiindulópont.

Ennek alapján, minden kritikus biztonsági frissítés telepítését gyorsítani lehet. Nem javasoljuk a tesztelés elhagyását, de ajánljuk, hogy lehetőség szerint minél gyorsabban és hatékonyabban teszteljen a vállalat, hogy minél hamarabb, pár nap alatt telepíthető legyen a kritikus frissítés. Ez idő alatt ideiglenes megoldásokkal, kerülő utakkal, de kezeljük a biztonsági kockázatot.

Eszközök, technikák és folyamatok

Az is a valósághoz tartozik, hogy főleg a kisebb vállalatoknak nincs meg a szükséges eszközük a frissítések menedzselésére. Míg a fontosabb, például Windows frissítésekről a sajtóból is értesülhetnek, addig a kisebb eszközök frissítéséről lemaradhatunk. Megfelelő eszközök, például frissítéseket menedzselő megoldások beszerzésével ez orvosolható.

Ezek után egy terület még mindig komoly kockázatot jelent: az árnyék informatika. Ha az alkalmazottak használnak nem szabványos vállalati programokat, akkor jó ötlet szabványossá tenni azokat. Így az IT ellenőrzése alá vonhatja őket, és frissítésükkel is foglalkozhat.

A frissítés jövője

Az általunk előrelátható jövőben az embereknek továbbra is szükségük lesz programokra, és a milliárdnyi programsor között biztos lesz hibás is. A frissítés továbbra is szükséges rossz marad. Azonban a kritikus frissítések esetében megoldást jelenthet az automatikus patchelés. Hiszen nem azért fejleszti az emberiség a mesterséges intelligenciát, hogy rábízza az unalmas, repetitív feladatokat?

A cikkhez a lap alján tud hozzászólni, és mások hozzászólásait is ott olvashatja.

Ha tetszett a cikk:


Ne felejtsen el feliratkozni hírlevelünkre:

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük