Az irodai gépeken a havi frissítés rutin: a javítás kimegy egy tesztcsoportnak, néhány nap múlva mindenkinek, és ha valami elromlik, a gép visszaállítható. Egy gyártósor operátori állomásán ugyanez a javítás megállíthatja a termelést, és ha a felügyeleti szoftver utána nem indul, a hibát éjjel kell elhárítani, miközben a sor áll.
Az üzemben ezért minden javításról külön döntés születik, és ebbe beleszól a rendszer gyártója, a tesztelés lehetősége és a következő leállás időpontja is.
Miért más a frissítés az üzemben
Az IT-rendszerekben a bizalmasság és az adatok sértetlensége áll az első helyen. Az OT-környezetben a folyamatos, biztonságos működés a legfontosabb, ezt a NIST SP 800-82 is így írja le. Egy javítás, amely a gépet újraindítja vagy egy szolgáltatás viselkedését megváltoztatja, közvetlenül a termelést érinti. Hőkezeléses vagy vegyipari folyamatnál a leállás után a berendezést újra fel kell fűteni és be kell állítani, és az első termékek gyakran selejtek.
A frissítendő elemek is sokfélék, és mindegyiknél más a kockázat:
- Windows alapú operátori állomások (HMI), mérnöki állomások, historian- és SCADA-szerverek operációs rendszere.
- A felügyeleti és mérnöki szoftverek, licenckezelők, kommunikációs meghajtók.
- A vezérlők (PLC, RTU), frekvenciaváltók, kommunikációs modulok firmware-e.
- Az ipari kapcsolók, routerek és tűzfalak firmware-e.
Az eszközök élettartama évtizedekben mérhető. Sok üzemben fut még olyan operációs rendszer, amelyre a gyártó már nem ad ki javítást, és olyan vezérlő, amelynek a gyártója a terméket rég kivezette. Ezeket a környezetükben kell megvédeni, erről a kockázatalapú döntésnél lesz szó.
Szabályozott iparágakban egy további szempont is bejön. A gyógyszergyártásban például a számítógépes rendszer validált állapotban üzemel, és minden olyan módosítás, amely ezt érinti, változáskezelési eljárást indít, dokumentált teszttel és jóváhagyással.
Gyártói jóváhagyás és kompatibilitás
Az ipari felügyeleti rendszerek gyártói jellemzően közzéteszik, mely operációsrendszer-javításokat próbálták ki a saját szoftverükkel. Ez a lista az operációs rendszer gyártójának havi kiadásai után napokkal vagy hetekkel frissül. Ha az üzemeltető jóváhagyás nélkül telepít, és a rendszer utána hibásan működik, a gyártó a támogatást arra hivatkozva utasíthatja el, hogy a környezet eltér a kipróbálttól.
Az IEC TR 62443-2-3 ezt az információcserét külön tárgyalja: a gyártó feladata közölni, hogy egy javítás kompatibilis-e, telepíthető-e és milyen feltételekkel, az üzemeltetőé pedig követni, melyik rendszeren melyik javítás van fent. Ha a beszállítói szerződés erről nem szól, érdemes a következő módosításnál beleírni, mennyi időn belül és milyen formában jön a jóváhagyás.
A verziók összefüggenek
A firmware-frissítés ritkán áll meg egy eszköznél. Egy újabb vezérlő-firmware gyakran a mérnöki szoftver újabb verzióját igényli, az pedig újabb operációs rendszert a mérnöki állomáson. Előfordul, hogy a régi projektfájlt az új szoftver átalakítja, és utána a régi verzióval már nem nyitható meg. Néhány eszköz pedig nem enged visszalépni korábbi firmware-re. Ezt a kiadási megjegyzésekből még a tervezéskor ki kell olvasni.
Biztonsági műszerezett rendszerek
A SIS szoftverének vagy firmware-ének módosítása funkcionális biztonsági kérdés is. Az IEC 61511 szerint ehhez változáskezelés kell, a módosítás hatásának elemzésével és a biztonsági funkciók újbóli ellenőrzésével. Itt a gyártó tanúsított verziói és a saját eljárásrend az irányadók, kiberbiztonsági szempontból sürgős javításnál is.
Honnan jön az információ
Az ipari gyártók biztonsági közleményekben adják ki, mely verziók érintettek, mi a javítás, és ha nincs, milyen ideiglenes intézkedés ajánlott. Az elsődleges forrás a gyártó saját biztonsági közleményoldala (PSIRT). Az amerikai CISA ICS Advisories oldala sok ilyen közleményt egy helyen is közzétesz, de nem mindet, és nem mindegyiket követi a későbbi módosításokkal. Hogy egy közlemény érinti-e az üzemet, az csak akkor derül ki, ha az eszközleltárban a firmware- és szoftververziók is szerepelnek.
Tesztkörnyezet és visszaállítási terv
A gyártói jóváhagyás azt jelenti, hogy a javítás a gyártó laborjában működött. Az üzemben ehhez képest más a konfiguráció, vannak egyedi kiegészítések, más gyártók szoftverei és védelmi ügynökök. A javítást ezért élesítés előtt egy olyan környezetben érdemes kipróbálni, amely az éles rendszerhez minél közelebb áll.
Az operátori állomások és szerverek esetében ez legtöbbször virtualizált másolat ugyanarról a lemezképről. A vezérlőknél egy tartalék eszköz kell ugyanabból a típusból, ugyanazzal a firmware-rel. A teljes folyamatot ritkán lehet laborban felépíteni, de a kommunikáció egy valódi vezérlővel már sokat elárul.
Mit érdemes tesztelni
- Elindul-e a felügyeleti szoftver, és érvényes-e a licence.
- Él-e a kommunikáció a vezérlőkkel, frissülnek-e az értékek a képernyőn.
- Megjelennek-e a riasztások, és nyugtázhatók-e.
- Írja-e a historian az adatokat, nincs-e hézag az idősorban.
- Nem nőtt-e érezhetően a processzorterhelés vagy a válaszidő.
- Működik-e a végpontvédelem, az engedélyezőlistás védelem nem blokkolja-e a javítás által hozott új fájlokat.
A visszaállítási terv
A terv a frissítés előtt készül, és arra a kérdésre felel, hogyan jut vissza a rendszer a korábbi, működő állapotba. Szerverről és állomásról teljes lemezkép kell, amelynek a visszaállítását már kipróbálták. A virtuális gép pillanatképe gyors visszalépést ad, de ugyanazon a tárolón van, mint a gép, ezért mentésnek nem tekinthető. A vezérlőből a frissítés előtt ki kell olvasni (upload) a futó programot és a konfigurációt, és össze kell vetni a tárolt projekttel, mert a kettő gyakran eltér. A régi firmware telepítőfájlját és a hálózati eszközök konfigurációját is el kell tenni.
A tervben az is szerepeljen, ki dönt a visszaállásról, és meddig vár. Ha előre rögzítik, hogy a kommunikáció helyreállására egy órát hagynak, utána visszaállnak, akkor éjjel nem kell ezen vitatkozni.
Karbantartási leállások ütemezése
A legtöbb üzemben vannak tervezett leállások: egy évente egyszer esedékes nagyobb karbantartás, és rövidebb, heti vagy havi ablakok. A javítások telepítése ezekhez igazodik, és ez a gyakorlatban azt jelenti, hogy egy javítás hónapokig várhat a sorára. A NIST SP 800-40 Rev. 4 a javítást megelőző karbantartásként kezeli. Az üzem szemével nézve ez ugyanolyan tervezett munka, mint a gépek kenése vagy egy kopó alkatrész cseréje.
Ahol a rendszer redundáns, ott leállás nélkül is lehet frissíteni. A redundáns szerverpárnál először a tartalék kap javítást, átveszi a működést, és csak ezután frissül a másik. Egyes redundáns vezérlőcsaládok, a gyártó által megadott feltételek mellett, támogatják az egyenkénti firmware-cserét üzem közben. Ehhez is kell terv, mert az átkapcsolás alatt a rendszer egy ideig redundancia nélkül fut.
Mi kerüljön a leállási tervbe
- A jóváhagyott és tesztelt javítások listája eszközönként, a telepítés sorrendjével.
- Az időigény, beleértve az újraindítást és az utána következő ellenőrzést.
- Kik vesznek részt: termelés, karbantartás, automatizálási mérnök, szükség esetén a rendszer gyártója és az IT.
- Az átvételi próba az operátorokkal: ugyanazok az ellenőrzések, mint a tesztkörnyezetben, most éles adatokkal.
- A visszaállási döntési pont és a hozzá tartozó felelős.
Ha a gyártó távolról végzi a munka egy részét, a hozzáférést a leállás idejére kell megnyitni, és utána lezárni. Erről a beszállítói távoli hozzáférésről szóló cikk szól részletesen.
A leállás után a leltárba bekerülnek az új verziók, és feljegyzik azt is, mi maradt ki és miért. Ami ebből a körből kimaradt, az a következő leállás első tételei közé kerül.
Kockázatalapú döntés: mi mehet a következő leállásra
Mivel a leállási idő kevés, a javításokat rangsorolni kell. Az IEC TR 62443-2-3 és a NIST SP 800-82 is azt mondja, hogy a telepítésről a kockázat alapján kell dönteni, és ahol a javítás nem telepíthető, ott más intézkedés kell helyette. A rangsorhoz ezeket a kérdéseket érdemes feltenni:
- Használja-e a rendszer az érintett funkciót? Egy vezérlő beépített webszerverének sebezhetősége kisebb gond, ha a webszerver ki van kapcsolva.
- Honnan érhető el a sebezhető szolgáltatás? Az IT-hálózatból vagy távoli hozzáférésen át elérhető eszköz előrébb kerül, mint egy zárt cellahálózat eleme.
- Kihasználják-e aktívan? A CISA KEV-katalógusa olyan sebezhetőségeket sorol fel, amelyek aktív kihasználására bizonyíték van, és amelyekhez egyértelmű elhárítási útmutatás tartozik.
- Mi történik, ha kihasználják? Egy biztonsági funkciót vagy a teljes sort érintő eszköz más súlyú, mint egy riportkészítő szerver.
- Jóváhagyta-e a gyártó, és mennyi leállási időt igényel?
Az általános priorizálásról, a CVSS-pontszám korlátairól és az EPSS szerepéről a sebezhetőségkezelésről szóló cikk ír. Az OT-ban ehhez jön hozzá a leállási ablak és a gyártói jóváhagyás.
| Helyzet | Döntés | Addig is |
|---|---|---|
| Aktívan kihasznált, kívülről elérhető, nagy hatású | Soron kívüli ablak, ha a gyártó jóváhagyta | Az elérés azonnali szűkítése a zónahatáron |
| Jelentős, de csak a zónán belülről érhető el | A következő tervezett leállás | Szigorúbb tűzfalszabály, a forgalom figyelése |
| Az érintett funkció ki van kapcsolva vagy nincs használatban | Rendes ciklus, alacsony prioritás | Ellenőrizni, hogy kikapcsolva is marad |
| Nincs javítás, vagy az eszköz már nem kap | Tartós kompenzáló intézkedés, cseretervezés | Szegmentálás, engedélyezőlista, virtuális patch |
Kompenzáló intézkedések
Ha egy javítás hónapokig nem kerülhet fel, a kockázatot a környezetén lehet csökkenteni. A szegmentálás és a zónák közötti szűkre szabott szabályok csökkentik, kik érik el a sebezhető szolgáltatást. Ennek a keretrendszeréről az IEC 62443 zóna- és csatornamodelljéről szóló cikk szól. A nem használt szolgáltatás kikapcsolható. A hálózati behatolásmegelőzés virtuális patch formájában a sebezhetőség kihasználására jellemző forgalmat szűri az eszköz előtt. Az engedélyezőlistás végpontvédelem azt akadályozza meg, hogy ismeretlen program fusson az állomáson.
A védelmi eszközök saját frissítései
A tűzfalak, a hálózati forgalmat figyelő érzékelők, a végpontvédelem és a naplógyűjtők maguk is szoftverek, amelyeket karban kell tartani. Kétféle frissítésük van, és a kettőt másként kell kezelni.
Szignatúrák és tartalomfrissítések
A behatolásmegelőzés szignatúrái, az ipari protokollok felismerése és a kártevőminták gyakran, akár naponta frissülnek, és általában újraindítás nélkül lépnek életbe. Csakhogy egy új szignatúra megváltoztathatja, mit lát gyanúsnak az eszköz. Ha az OT-hálózat határán a tűzfal blokkoló üzemmódban szűr, egy téves riasztás egy legitim vezérlőparancsot is eldobhat. Ezért az OT-ban az új szabályokat érdemes először figyelő üzemmódban futtatni, és csak a riasztások átnézése után élesíteni.
Ahol az OT-hálózat elzárt, a szignatúrák offline csomagban érkeznek, ellenőrzött adathordozón vagy egy köztes zónán át. Ha ennek nincs rendje, az elzárt hálózat védelmi eszközei hónapokkal régebbi mintákkal dolgoznak.
Firmware és szoftververziók
A védelmi eszközök firmware-frissítése jellemzően újraindítással jár. A forgalom útjában álló tűzfalnál ez megszakítja a kommunikációt a zónák között, ezért ugyanúgy leállási ablakot vagy redundáns párt igényel, mint bármely más OT-eszköz. A végpontvédelmi ügynök új verziója előtt érdemes ellenőrizni a felügyeleti szoftver gyártójának kompatibilitási listáját, mert az ügynök mélyen beépül az operációs rendszerbe.
A határvédelmi eszközök sebezhetőségei rendszeresen bekerülnek a CISA KEV-katalógusába, mert a támadók gyakran éppen rajtuk keresztül jutnak be, így az OT-hálózat bejáratánál álló, elavult firmware-ű tűzfal maga is támadási felület.
A szabálykészlet is avul
A frissítéshez tartozik a szabályok karbantartása is. Új eszköz kerül a hálózatra, egy kommunikációs kapcsolat megszűnik, egy ideiglenes beszállítói szabály bent marad. Ha a szabálykészletet nem nézik át rendszeresen, a tűzfal szabályai eltávolodnak attól, amire az üzemnek valóban szüksége van.
Kapcsolódó szolgáltatás: OT védelmi platform gondozása →
