OT: „ Patch Management ” az „ Air-Gapped ” környezetekhez: A teljes offline javítás-folyamat

• Az OT-frissítéskezelés nem egyszerűen az IT-frissítéskezelés hosszabb időtávon történő végrehajtása. A biztonsági függőségek, a tanúsított gyártói konfigurációk, az eszközök hosszú élettartama, valamint a nem tervezett újraindítások iránti szinte nulla tolerancia a folyamat szinte minden lépését megváltoztatja.
• Air-gapped A hálózatok elveszítik az automatikus frissítések lefedettségét, de nem szűnik meg az irántuk fennálló igény. Azok a végpontok , amelyek nem tudnak kapcsolatot létesíteni a központi szerverrel, eltűnnek a felhőalapú vizsgálati és frissítési szolgáltatásokból, kivéve, ha egy offline adattár és a helyszíni felügyelet visszaállítja a láthatóságukat az elszigetelt zónán belül.
• A CVSS-súlyossági besorolás önmagában soha nem szabad, hogy meghatározza az OT-javítások prioritását. A döntéshozatal során a pontszám mellett figyelembe kell venni a kihasználási lehetőségek fejlettségi szintjét, a hálózati elérhetőséget, az eszközök kritikus fontosságát és az üzemeltetési biztonsági következményeket is, különben két hasonló besorolású sebezhetőség esetén is helytelen intézkedés születhet.
• A cserélhető adathordozók ellenőrzési pontot jelentenek, nem pedig kényelmi funkciót. Minden frissítési csomagot és az azt hordozó eszközt megbízhatatlannak kell tekinteni mindaddig, amíg a forrásellenőrzés, az aláírás- és hash-ellenőrzés, valamint a rosszindulatú programok vizsgálata nem ad zöld utat az átvitelhez.
• MetaDefender Az Endpoint™ egy végpont-ügynökön keresztül biztosítja a sebezhetőségek és a javítások kezelését, a cserélhető adathordozók védelmét, valamint a BadUSB elleni védelmet, központi felügyeleti lehetőséget biztosítva az My OPSWAT™ Central Management webhelyen keresztül; a szabályozás, a tesztelés és a beszállítók jóváhagyása azonban továbbra is a szervezet felelőssége marad.

Azok a végpontok, amelyek nem tudnak csatlakozni az internethez, kiesnek a felhőalapú sebezhetőségi vizsgálatból, a frissítési tárolókból és a házirend-szinkronizálásból, ami azt jelenti, hogy a megfelelőségi jelentésekből is eltűnnek, hacsak valami nem állítja vissza helyben a lefedettséget. A kézi, táblázatkezelő-alapú javítások egy ideig helyettesíthetik ezt, de nagy léptékben nem működnek: a nem hivatalos „ USB ” átadások nem kerülnek dokumentálásra, a telepítési eredmények nem kerülnek rögzítésre, és minden audit egy rekonstrukciós gyakorlatgá válik.

Az offline javítás-tárház, a helyszíni központosított felügyelet és az ellenőrzött átviteli útvonal újra létrehozza azt a lefedettséget, amelyet a felhőalapú automatizálás biztosít egy hálózatba kapcsolt környezetben, anélkül, hogy olyan élő kapcsolatot hoznának létre, amely maga is gyengítené az „air gap”-et.

• A beszerzés és az elsődleges érvényesítés a termelési környezeten kívül történik, egy olyan zónában, ahol internet-hozzáférés áll rendelkezésre a gyártói frissítések letöltéséhez, valamint az első lépésben végzett aláírás- és hash-ellenőrzések elvégzéséhez.
• Az offline javítás-tárhely a jóváhagyott operációs rendszer- és harmadik féltől származó alkalmazásfrissítéseket gyűjti össze, miközben a verziókezelést, a felváltások nyomon követését és a szinkronizálási naplókat az elszigetelt hálózaton belül tárolja.
• A helyszíni, központosított felügyelet felhasználási szabályokat oszt ki, telepítéseket ütemez, a végpontok állapotáról adatokat gyűjt és jelentéseket készít anélkül, hogy felhőszolgáltatásokra, külső identitásszolgáltatókra vagy „call-home” licencelésre lenne szüksége.
• A végső szabályalkalmazás és a bevezetés továbbra is a helyi operációs csapat irányítása alatt marad, így egy megfertőzött vagy késleltetett külső forrás soha nem tud közvetlenül változást átvinni a termelési környezetbe.

Az ismételhető offline javítási munkafolyamat hat szakaszra oszlik, amelyek mindegyike egy meghatározott döntést, eredményt és jóváhagyási nyilvántartást eredményez, így a folyamat végponttól végpontig nyomon követhető marad.

1. Leltározás és felderítés. Készítsen leltárt az eszközökről, amely tartalmazza a hardver- és szoftververziókat, a hálózati zónát, a biztonsági funkciókat és a támogatási állapotot, majd hasonlítsa össze azt a gyártói figyelmeztetésekkel és az offline sebezhetőségi vizsgálatok eredményeivel, hogy azonosítsa a szükséges frissítéseket.

2. A kockázatok fontossági sorrendbe állítása. Minden egyes javítócsomagot ne csupán a súlyossági pontszám alapján, hanem a kihasználhatóság, a kitettség, az eszköz kritikus fontossága és a biztonsági következmények szempontjából is értékeljen , és mielőtt a javítócsomag bekerülne a munkafolyamatba, ellenőrizze a firmware-rel, az operációs rendszerrel és a gyártói támogatással való kompatibilitását.

3. A csomag ellenőrzése és jóváhagyása. A hivatalos változtatás jóváhagyása előtt ellenőrizni kell a forrás hitelességét, a digitális aláírásokat és a kriptográfiai hash-értékeket, egy elszigetelt tesztkörnyezetben ellenőrizni kell a rosszindulatú programok jelenlétét, valamint reprezentatív teszteket kell futtatni.

4. Átvitel és előkészítés. A jóváhagyott csomagot ellenőrzött cserélhető adathordozón keresztül továbbítsa , az átvitel után ellenőrizze újra, majd a telepítési időszakot megelőzően helyi szinten készítse elő.

5. Fázisokban hajtsa végre a telepítést. A javítást egy engedélyezett karbantartási időintervallum alatt vezesse be , meghatározott végpontok kiválasztásával, ahol lehetséges, automatikus telepítési beállításokkal, újraindítási szabályokkal és leállítási feltételekkel.

6. Ellenőrzés, visszaállítás és jelentés. Ellenőrizze a telepítés állapotát, a szolgáltatás működési állapotát és a biztonsági funkciók viselkedését; amennyiben az átvételi kritériumok nem teljesülnek, indítson el egy előzetesen tesztelt visszaállítást, majd rögzítse az eredményt, a kivételeket és a bizonyítékokat az audit céljára.

Az a prioritási mátrix, amely a kiberbiztonsági események bekövetkezésének valószínűségét és azok operatív következményeit mérlegeli, következetes döntéshozatali keretet biztosít a csapatok számára, ahelyett, hogy minden súlyos megállapítást ugyanúgy kezelnének.

Ha egy javítást nem alkalmaznak, hanem elhalasztanak, a kivételnek kell lennie egy felelős személynek, egy műszaki indoklásnak, egy lejárati dátumnak, valamint kompenzáló ellenőrzési intézkedéseknek, amelyeket újra felül kell vizsgálni, ha a kihasználási tevékenységekben vagy a gyártói iránymutatásokban változás következik be. Az állandó, felülvizsgálat nélküli kivételek azok a hiányosságok, amelyeket az auditorok elsőként fedeznek fel.

A javítócsomagot és az azt hordozó cserélhető adathordozót egyaránt megbízhatatlannak kell tekinteni mindaddig, amíg a házirend nem ellenőrzi őket. Az „először ellenőrzés” elven alapuló lánc biztosítja a származást, az integritást és a tartalom biztonságát, mielőtt egy fájl hozzáférhetővé válna az OT-hálózaton belül.

• Forrásellenőrzés. A frissítéseket kizárólag a gyártói portálokról vagy hitelesített terjesztési csatornákról szerezze be , és rögzítse a forrást, a letöltés idejét, a csomag verzióját, valamint annak a személynek az adatait, aki a frissítést letöltötte.
• Aláírás és hash-érték ellenőrzése. Az átvitel előtt ellenőrizze a digitális aláírásokat, a tanúsítvány érvényességét és a gyártó által közzétett kriptográfiai hash-értékeket. Az érvényes aláírás alátámasztja a hitelességet; önmagában azonban nem bizonyítja, hogy a csomag egy adott OT-környezetben biztonságos.
• Kártevőprogram-ellenőrzés. A teljes csomagot – beleértve a beágyazott archívumokat, telepítőprogramokat, szkripteket és illesztőprogramokat is – ellenőrizzük egy elszigetelt tesztkörnyezetben, ahol a gyanús eredmények esetén előre meghatározott karanténba helyezési és elutasítási műveletek lépnek életbe.
• Cserélhető adathordozók és BadUSB-védelem. Az eszközök engedélyezésének és a hozzáférés előtti vizsgálatnak a kötelezővé tételével biztosítható , hogy a fertőzött meghajtók és a hamisított eszközök – beleértve a billentyűzetet utánozó BadUSB-támadásokat is – még mielőtt bármit is végrehajthatnának egy OT-végponton, blokkolásra kerüljenek.
• A felügyeleti lánc dokumentációja. Rögzítse az adathordozók azonosító adatait, a felügyelő személyét, a hash-értékeket, az ellenőrzési eredményeket, a jóváhagyásokat, az átadás időpontját és a célállomást, hogy egy ellenőrzés során minden átadás rekonstruálható legyen.

Egy validált javítás telepítése továbbra is üzemeltetési változást jelent, és a sikeres bevezetésnek ugyanolyan mértékben biztosítania kell a folyamatirányítást, a biztonságot és a helyreállíthatóságot, mint amennyire a sebezhetőséget megszünteti.

• Hozzon létre egy reprezentatív tesztkörnyezetet. Amennyiben lehetséges, utánozza a kritikus hardvereket, operációs rendszerverziókat, alkalmazásokat és kommunikációs csatornákat, és dokumentálja azokat a területeket, ahol a teszt- és az éles környezet elkerülhetetlenül eltér egymástól.
• A telepítés előtt ellenőrizze a kompatibilitást. Tekintse át a gyártók által kiadott útmutatásokat, az alkalmazások tanúsításait és az illesztőprogram-függőségeket, és kérjen külön jóváhagyást, ha egy javítás nem felel meg a gyártó által támogatott konfigurációnak.
• A bevezetést szakaszosan hajtsák végre. Kezdjenek olyan eszközökkel, amelyeknél a következmények kevésbé súlyosak, de reprezentatívak, értékeljék az eredményt, majd fokozatosan bővítsék ki a rendszert, ahelyett, hogy az egész környezetet egyszerre módosítanák, meghatározott szüneteltetési kritériumok és vészleállítási jogosultság mellett.
• A telepítés és az újraindítások ellenőrzése. Amennyiben lehetséges, válassza a zavarmentes telepítést, és a gyártói útmutatásoknak, a redundancia-tervnek, valamint az üzem jóváhagyásának megfelelően halassza el vagy hangolja össze az újraindításokat.
• Ellenőrizze a rendszer működőképességét, majd zárja le a ciklust. Ellenőrizze a szolgáltatás indítását, a vezérlő logikát, a riasztásokat és a biztonsági funkciókat a mérhető átvételi kritériumok alapján, és a telepítés megkezdése előtt készítse elő a tesztelt visszaállítási tervet, beleértve a konfigurációs biztonsági másolatokat és a helyreállítási adathordozókat.

A régi operációs rendszerverziókat és speciális mérnöki alkalmazásokat futtató, hosszú élettartamú végpontok gyakran kívül esnek a szokásos IT-frissítőeszközök hatókörén, ezért nem szabad őket teljesen kihagyni a programból, hanem külön megoldást kell számukra találni.

• A régebbi operációs rendszereket futtató végpontok esetében minden frissítés kiválasztása előtt pontos leltárra van szükség a kiadásról, az architektúráról és a gyártó által jóváhagyott alapkonfigurációról, és a folyamatba be kell építeni az offline csomagok támogatását, valamint a visszaállítási lehetőséget.
• Az olyan harmadik féltől származó alkalmazások, mint a böngészők, a futtatókörnyezetek és a távoli hozzáférést biztosító eszközök, gyakran nem tartoznak az operációs rendszer natív frissítési csatornái közé, ezért saját verziófelismerésre, függőségek kezelésére és offline telepítő támogatásra van szükségük.
• A frissíthetetlen rendszerek esetében is szükség van dokumentációra: meg kell indokolni, miért nem lehetséges vagy nem biztonságos a frissítés, ki a felelős tulajdonos, mi a felülvizsgálati időpont, valamint be kell mutatni a cserére vagy az áttérésre vonatkozó ütemtervet.
• Az olyan kompenzáló intézkedések, mint a hálózati szegmentálás, az alkalmazások engedélyezési listájának vezetése és a cserélhető adathordozókra vonatkozó korlátozások, csökkentik a frissítéssel nem javítható eszközök kockázatát, de nem szüntetik meg az alapvető sebezhetőséget, és a fenyegetési helyzet változásával rendszeres felülvizsgálatra szorulnak.

A központosított bizonyítékgyűjtésnek köszönhetően a megfelelőségi jelentések a javítási munkafolyamat rutinszerű kimenetévé válnak, és nem kell többé minden egyes audit alkalmával manuálisan rekonstruálni az adatokat.

• Megtartandó nyilvántartások: az eszközök köre, a sebezhetőségi állapot, a jóváhagyások, a fájl-hashértékek, az aláírási eredmények, az ellenőrzési megállapítások, az adathordozók használata, a telepítési eredmények, a kivételek és a visszaállítási események – mindegyik hozzárendelhető időbélyegekkel.
• Fedezeti mutatók: kövesse nyomon a készletfedezetet, a javítások telepítési arányát, a lejárt javítási feladatokat és a kivételeket, telephelyek és az eszközök kritikus szintje szerinti bontásban, hogy az összesített százalékos adatok ne fedjék el a súlyos következményekkel járó hiányosságokat.
• Kockázatcsökkentési mutatók: a javítás bevezetéséig eltelt időt és az érzékenységi időszakot össze kell vetni a visszaállítási aránnyal és a nem tervezett leállásokkal, így a gyorsabb javítás soha nem tekinthető sikernek, ha az instabilitást okoz.
• A keretrendszerhez való igazítás: az eszközleltár, a kockázatértékelés, a változáskezelés és a nyomonkövetési gyakorlatok összehangolása az IEC 62443 szabványban és a NIST SP 800-82 3. kiadásában – az operatív technológiák (OT) biztonságára vonatkozó jelenlegi útmutatóban – meghatározott vonatkozó célkitűzésekkel. A keretrendszerhez való igazítás támogatja az auditot; önmagában nem helyettesíti a tanúsítást, és nem garantálja a megfelelést.

Mielőtt bármely konkrét termék szóba kerülne, a gyártótól független követelményeknek kell irányítaniuk az értékelést: valódi offline működés, helyszíni központosított felügyelet, széles körű végpontok és alkalmazások lefedése, külső adathordozók védelme, valamint olyan központosított jelentéskészítés, amely felhőalapú megoldásoktól függetlenül auditálásra alkalmas bizonyítékokat szolgáltat.

• Offline működés: bevált, nem feltételezett. Kérjen bemutatót egy air-gapped környezetben, ahelyett, hogy egyszerűen feltételezné, hogy egy internetkapcsolattal rendelkező termék offline állapotban is ugyanúgy fog működni.
• Endpoint és az alkalmazások lefedettségét. Ellenőrizze a szervezetnél telepített Windows, macOS, Linux és régebbi rendszerek tényleges támogatását, beleértve az offline csomagformátumokat és a visszaállítási lehetőségek láthatóságát is.
• Külső adathordozók védelme. Győződjön meg arról, hogy a platform engedélyezi az eszközöket, ellenőrzi a fájlokat a hozzáférés előtt, és védelmet nyújt a BadUSB ellen, ahelyett, hogy az adatátviteli folyamatot egy különálló, a rendszerhez nem kapcsolódó eszközre bízná.
• Központosított jelentéskészítés és irányítás. Tesztelje a szerepkörökön alapuló hozzáférést, a telepítési állapotot, a kivételes esetekre vonatkozó munkafolyamatokat és az adatok exportálását olyan forgatókönyvek alapján, amelyek nem csupán a sikeres futtatásokat, hanem az elutasított adathordozókat és a sikertelen telepítéseket is magukban foglalják.

MetaDefender Az Endpoint™ az OPSWAT fejlett végpontvédelmi megoldása, amely védelmet nyújt a végpontok számára a külső adathordozókon terjedő fenyegetésekkel szemben, figyelemmel kíséri az eszközök szabályoknak való megfelelését, felismeri a sebezhetőségeket, valamint lehetővé teszi a javítások telepítését mind az internethez csatlakozó, mind az „ air-gapped ” környezetekben. Több mint 980 alkalmazás és operációs rendszer sebezhetőségeit ismeri fel, és több mint 580 harmadik féltől származó alkalmazáshoz, valamint operációs rendszer-frissítésekhez biztosít automatikus javításokat, olyan zavarmentes telepítési móddal, amely elkerüli a kezelői képernyők megszakítását a karbantartási időszak alatt.

A cserélhető adathordozók védelme a Metascan™ Multiscanning és a Deep CDR™ technológia MetaDefender segítségével működik. AEndpoint automatikusan felismeri az USB meghajtókat, és blokkolja azokhoz való hozzáférést mindaddig, amíg minden fájlt át nem vizsgáltak és tisztának nem nyilvánítottak; emellett védelmet nyújt a BadUSB, a „rubber ducky” és más, eszközhamisításon alapuló támadások ellen anélkül, hogy a fájlt először a végponton futtatni kellene.

A központosított áttekinthetőséget az My OPSWAT™ Central Management biztosítja, amely helyszíni telepítéssel vagy felhőalapú szolgáltatásként is elérhető. A rendszer internet-hozzáférés nélkül is elosztja a szabályzatokat, gyűjti a telepítési állapotokat és készít jelentéseket a különböző telephelyekről, így a biztonsági csapat egy helyről ugyanazt az offline munkafolyamatot futtathatja több, egymástól elszigetelt OT-telephelyen is.