A mai posztban egy meglehetősen fontos, de méltatlanul keveset emlegetett témát igyekszem körüljárni, ez pedig az ICS rendszerekben végzett mentési eljárások és a mentések tesztelésének/visszatöltésének kérdése.
Úgy vélem a naprakész mentések fontosságát az elmúlt évek, nagy vihart és sajtóvisszhangot keltett zsarolóvírus-támadásai után nem kell és nem is lehet túlzottan hangsúlyozni, de arról már mindenképp érdemes lehet beszélni, hogy hogyan, milyen megoldással mentsük az ICS rendszereinket és azok melyik komponenseit érdemes menteni? Ezt a Purdue-modell alapján fogjuk áttekinteni.
Az L5/L4 szinteken működő komponensek (pl. különböző IT hálózatokban működő történeti adatbázisok) esetén nyugodtan használhatónak tartom az IT rendszerek mentésére használt megoldásokat, a lényeg itt is az, hogy az üzleti igényeknek és a kockázatviselési hajlandóságnak megfelelő (lehetőleg offline, esetleg geo-redundáns) mentésekkel rendelkezzen a szervezet.
Az ICS DMZ-ben (L3,5) üzemelő szerverek esetén már felmerülhet a kérdés, hogy az IT vagy az OT rendszerek mentését végző megoldás végezze-e ezt a tevékenységet, az én véleményem az, hogy a 62443-as szabványban megfogalmazott alapelveket követve soha ne egy kevésbé védett hálózatban futó szolgáltatástól függjön egy védettebb hálózatban működő szolgáltatásunk. Ezt figyelembe véve én úgy gondolom, hogy az ICS DMZ-ben működő szerverek mentését az L3-ra telepített mentőrendszer végezze.
Az L3-on működő rendszerek mentését az L3,5-nél már említett, az IT mentőrendszertől minden szempontból független mentési megoldás végezze, követve azt az ICS biztonsági alapelvet, hogy az IT és OT rendszerek lehetőleg soha ne osztozzanak egy szolgáltatáson (hiszen akkor az IT hálózatban sikeres támadás jó eséllyel kompromittálhat egy olyan szolgáltatást, amivel utána könnyebbé válik az ICS rendszer támadása is a Cyber Kill Chain 2. fázisa során).
Az L2-n működő rendszerek (jellemzően SCADA, DCS szerverek, egyes mérnöki munkaállomások, stb.) mentése szintén megoldható az előző bekezdésben írt, L3 szinten működő mentési megoldással és szintén az L2-re gondolnám elhelyezni azt a mentőszervert, amivel az L1-en működő mezőgépek (RTU-k, védelmek és egyéb PLC-k és hasonló berendezések) mentését lehet végezni.
(Itt most érdemes lehet röviden kitérni a mezőgépek konfigurációinak központi kezelésére is. Figyelembe véve, hogy ezek a berendezések mennyire fontosak a zavartalan folyamatirányítás szempontjából, én azt mondom, hogy ezeket a konfigurációkat nem csak érdemes, de gyakorlatilag kötelező lenne szigorú verziókontroll alatt, egy biztonsági szempontból kiemelten védett központi verziókezelő rendszerben tárolni és az így tárolt konfigurációkat menteni megfelelő gyakorisággal és megőrzési időkkel.)
Az IT üzemeltetésben jártas kollégák egy jelentős hányada szokta ezen a ponton ("Van mentésünk, mi baj lehet?") leporolni a kezeit és elégedetten kávézni vonulni, de válaszoljunk őszintén a kérdésre: ki nem látott még olyat, amikor beütött a krach és a komoly önbizalommal elővett mentésből nem sikerült visszaállítani a szervezet számára nélkülözhetetlen adatokat?
Szóval az elkészült mentéseket megfelelő gyakorisággal vissza is kéne tölteni (de hova?) és tesztelni is kellene, hogy amikor élesben szükség lesz rájuk (persze inkább ne legyen szükség rájuk, de ha mégis, akkor lehessünk biztosak abban, hogy bizony használhatóak is leszenek ezek a mentések), akkor egy sikeres rutintevékenység legyen a mentésből visszaállítás folyamata.
A problémás pont ebben az esetben az, hogy hol és hogyan történjen a visszaállítás és a tesztelés? A legtöbb ipari szervezetnek még a SCADA/DCS rendszereiből sincs olyan szintű tartaléka, amit egy ilyen adatvisszatöltésre (és utána tesztelésre) fel lehetne használni. Rendelkezésre állhat azonban 1-2 olyan szerver, amiket fel lehet használni különböző virtualizációs megoldások használatával egy mentés visszatöltésére és tesztelésére. Ez pedig már történhet egy olyan laborkörnyezetben, ahol nem kell attól tartani, hogy a visszatöltési és tesztelési tevékenységek zavart okoznának az éles folyamatvezérlési tevékenységben vagy (akár csak időszakosan) degradálná a tartalék rendszer rendelkezésre állási mutatóit. Végső esetben (ha még 1-2 ilyen szerver sem áll rendelkezére) pedig akár a SCADA/DCS tesztrendszer is felhasználható - hiszen végül is teszteket kell végezni...
Egy szinttel nagyobb problémát jelenthet a mezőgépekről készült mentések tesztelése, itt egy másik körülmény lehet a segítségünkre. A legtöbb ipari szervezet számára a mezőgépek olyannyira fontos berendezések, hogy nem megengedhető egy meghibásodás esetén napokra vagy hetekre kiesve hagyni a meghibásodott eszközt, így többnyire szokott lenni valamilyen, az üzembiztonságot biztosító tartalék. Az ilyen berendezésekből pedig (a megfelelő eljárási szabályok kidolgozása és szigorú betartása mellett) szerintem fel lehet egyet-egyet használni a visszatöltött konfigurációk laborban történő tesztelésére.
Annyi biztos, hogy a mentések és azok felhasználhatóságának biztosítása a folyamatvezérlő rendszerek esetében is kiemelt fontosságú tevékenység kell, hogy legyen. Bízzunk benne, hogy ezt a különböző kritikus infrastruktúrákat üzemeltető szakemberek is így gondolják és a mai poszt maximum unott hümmögést vált ki belőlük, mondván "Nem is értem, mi a pláne ebben a posztban, ezt pont így/ennél sokkal jobban csináljuk..."
