Folt hátán folt

Fenyegetések és kockázatok – felértékelődött a „patch management” jelentősége.

Néhány évvel ezelőtt a javítások kezelését a rendszerek üzemeltetőinek periférikus tevékenységei között tartották számon. Már ahol számon tartották, hiszen sok helyütt a „Telepítsd és felejtsd el!” általános gyakorlata volt érvényben. Mindez pedig azt eredményezte, hogy a rendszereket sohasem – vagy csak nagyritkán – frissítették.

A fenyegetések számának növekedésével felértékelődött a sérülékenységek felismerésének és természetesen a kijavításának a jelentősége, emellett a törvényi szabályozás és a megfelelőségi kívánalmak is azt eredményezték, hogy a javítások kezelése jócskán feljebb került a biztonsági prioritások listáján.

Világos célok, nehéz megvalósítás

Nyilvánvaló, hogy kritikus kérdéskörről van szó. A javításkezelő program célja is kézenfekvő: olyan ellenőrzött környezetet kell kialakítani, amelynek a biztonságát a lehető legkisebb mértékben csökkentik az operációs rendszer és az alkalmazások sérülékenységei.

A gyakorlati megoldás azonban nem ilyen egyértelmű. Már a kis hálózatokban is elég bonyolult dolog a néhány eltérő platform és szoftver frissítéseinek a menedzselése, nagy szervezetekben pedig jóval összetettebbé teszi a feladatot az inhomogén környezet, a rendelkezésre állás biztosítása, a több telephely és a mobileszközös alkalmazottak sokasága.

Minden rendszer egyedi technológiai követelményeket támaszt, ezért a javításkezelést is a konkrét igényeknek megfelelően kell kivitelezni, ebből pedig egyenesen következik, hogy következetes alkalmazása gondos tervezést igényel.

Információforrások

A sikeres javításkezelés két alapvető információra támaszkodik: a sérülékenységek, valamint a javításuk céljából kiadott eszközök ismeretére. Tisztában kell lenni az adott IT-struktúra biztonsági viszonyaival, és követni kell a kapcsolódó szoftveres aktualizálási lehetőségeket (kötelességeket).

Bejön még a biztonsággal kapcsolatban sokszor hangoztatott felelősség kérdése is, azaz a szervezeten belül ki kell jelölni azokat a személyeket, akiknek az a dolguk, hogy az adott platform és alkalmazások ismeretében figyeljék és alkalmazzák a megjelenő javításokat (emellett az ő feladatuk az is, hogy az informatikai személyzet többi tagját és a felhasználókat figyelmeztessék azokra az ismert sérülékenységekre, amelyekhez nincs javítás).

További fontos szempont, hogy ismerni kell a szervezet saját rendszerét és a telepített alkalmazásokat, ez pedig a szoftverkészlet-kezelő rendszerekből származó részletes információk alapján lehetséges.

Az IT-rendszerekben használt elsődleges operációs rendszer, a főbb hálózati eszközök és alkalmazások fejlesztőivel vagy szállítóival kialakított viszony ugyancsak fontos a biztonsági és a javítási információk naprakészsége miatt. A kapcsolat megnyilvánulhat konzultációban, rendszeres telefonos vagy e-mailes kapcsolatban, illetve egyszerűen csak fel lehet (ajánlott) iratkozni a fejlesztő biztonsági bejelentéseit közlő hírlevélre.

Működnek olyan publikus – és nem fejlesztőspecifikus – szolgáltatások, amelyek kimerítő részletességű adatokat szolgáltatnak a sérülékenységek kijavítását célzó lehetőségekről.

Prioritások és ütemezés

Léteznek olyan ütemezési tervek és sémák, amelyek a tervszerű javításkezelő program kialakítását segítik a rendszer és az alkalmazások szintjén. Ez a javítási ciklus azonban alapvetően független a kritikus frissítések megjelenésétől, ezért nem célozza közvetlenül a biztonságot sem, hanem csak a rendszeresen kiadott szoftverfrissítések ütemezését.

A második lehetőség a biztonságot vagy funkcionalitást befolyásoló javításokhoz igazított ütemezés. Ezzel a módszerrel rangsorolhatók a szervezet szempontjából fontos frissítések, és a javítás menetrendje közvetlenül hozzáigazítható az adott sérülékenységek fontossági sorrendjéhez.

A sürgősség megállapításához több tényezőt is figyelembe lehet venni – például a fejlesztő által közölt súlyossági fokot, a sérülékenységeket támadási vektorként használó akna és/vagy rosszindulatú program meglétét. A prioritási sorrend technológiai szempontja lehet még, hogy a rendszer mennyire exponált helyén (DMZ, kliensgépek, belső fájlszerver) kell érvényesíteni a javítást.

Természetesen fontosak azok az üzleti szempontok is, amelyek a lehetséges üzletmenetben vagy anyagi értelemben vett károk mértéke alapján befolyásolhatják a javítási sorrendet.

Tesztelés

A javításokat tesztelni kell, ennek alaposságát és fontosságát pedig a rendszer és a kezelt adatok érzékenysége, valamint a rendszer komplexitása (például platformok és alkalmazások, illetve távoli munkahelyek száma) határozza meg. A tesztelés a javítás beszerzésével kezdődik, és a rendszerszintű alkalmazás után zárul le.

Ellenőrzés. Az első lépés a javítást kiadó forrás ellenőrzése.

Verifikálás. A második momentum magának a frissítésnek a verifikálása. Ebbe beletartozik az is, hogy meg kell bizonyosodni a javítóállomány épségéről (például ellenőrzőösszegek figyelésével).

Tesztkörnyezet. A javítás ezután a tesztkörnyezetbe kerül. Ideális esetben ez az „éles” rendszer tükörképe lenne, a próbakörnyezetnek azonban legalább a kritikus platformokat és alkalmazásokat mindenképpen tartalmaznia kell. Néhány szervezetnél a teljes rendszer kijelölt szegmenseit használják „pilotolásra”. Függetlenül attól, hogy milyen módszert használnak, a javításokat a lehető legtöbb variációban kell kipróbálni. Csak így lehet megbizonyosodni arról, hogy alkalmazásuk nem okoz nagyobb kárt, mint amekkora akkor következne be, ha nem érvényesítenénk őket.

Próbák. Ekkor következnek a próbák, amelyek mechanizmusa szervezetenként más és más lehet. Kimerülhetnek a működés gyors ellenőrzésében, az alkalmazások funkcionalitásának kipróbálásában, létezhetnek viszont egyszerű és bonyolult forgatókönyvek vagy alaposságra törekvő teszt-szkriptek is, amelyek egy sor szempont szerint automatikusan végzik el az ellenőrzéseket. A próbák alaposságát az adatok érzékenysége, a rendelkezésre állási szempontok, a tesztelésre fordítható erőforrások, üzleti szempontok és a megcélzott sérülékenység fontossága határozzák meg.

Produkciós környezet. A javítások ezután kerülnek be az éles produkciós környezetbe. Ez leggyakrabban nem egy lépésben történik meg, hanem meghatározott fázisokban. Először a rendszernek a kevésbé kritikus részein, majd a tapasztalatok alapján és határozott kritériumok szerint fokozatosan jutnak érvényre a teljes rendszerben.

A próbák akkor tekinthetők befejezettnek, ha az összes lehetséges ponton alkalmazták a javításokat, és arról is megbizonyosodtak, hogy a teljes telepítés után sem jelentkeznek problémák.

Frissítések telepítése

A javításkezelés minden mozzanata különös fontosságú lépés, de ha lehet ezt mondani, a javítások rendszerszintű alkalmazása az egyik legkritikusabb folyamat. Ez az a tevékenység, amely leginkább függ a megvalósításához használt eszközöktől.

Az első kérdés mindjárt az, hogy vásároljuk- e a telepítőeszközt, vagy inkább magunk készítsük el.

Történeti okokból számos szervezet készített olyan frissítőeszközöket, amelyek az operációs rendszerek lehetőségeinek és a különböző szkriptnyelvek kombinálásával elvégzik a frissítések érvényesítését a rendszeren.

A hálózatok növekedése, s ennek következtében bonyolultságuk fokozódása, az automatizálás iránti igény felmerülése és a technológia fejlődése miatt később megjelentek azok a kereskedelmi eszközök, amelyek segítik a javítások telepítésének folyamatát.

Az eszközök használhatnak szoftverágenseket, de vannak ágensmentes megoldások is (ez egyébként a csoportosításuk fő szempontja is).

A javításkezelő megoldások kiválasztásának legfontosabb aspektusai:

• támogatott operációs rendszerek;

• a támogatott eszközök száma;

• milyen humán erőforrások szükségesek a használatukhoz;

• milyen járulékos erőforrások meglétét igénylik.

A javítások, de különösen a biztonsági frissítések időzítése kritikus szempont, kontrollált alkalmazásuk és sikerességük kiszámíthatósága azonban legalább enynyire fontos. Ezek nélkül veszélybe kerülhet a rendszer, a tárolt adatok, nem beszélve a lehetséges üzleti károkról és a megfelelőségről.

Alapvető fontosságú, hogy a felhasználók, de még a rendszeradminisztrátorok sem frissíthetnek kényük-kedvük szerint!

Nemcsak a szervezeti házirendben kell rögzíteni, hanem megfelelő technológiai eszközökkel (jogosultságokkal) is szabályozni kell, hogy ki, mikor, milyen körülmények között érvényesíthet javításokat, különös tekintettel a változáskezelő rendszer integrációjának fontosságára.

Multifaktoriális nézőpont

A javításokkal kapcsolatban további fontos szempontok is vannak: az audit és a rendszer elemzésének eszközei, az átláthatósági és megfelelőségi aspektusok, valamint a különféle automatizálási megoldások. Lapunkban többször leírtuk, hogy az IT-biztonságban nem minden a technológia, és ez fokozottan érvényes a frissítés témakörére. A tervezés, a forgatókönyvek, a felelősségek és általában a humán tényezők legalább akkora szerepet töltenek be, mint az eszközök. Ezek működés alapú szemlélete együtt tud csak eleget tenni a szervezetek egyedi szükségleteinek.

Kelemen László