ebben a cikkben, amelyet egy biztonsági felügyeleti megoldás szállítója írt, a fő érv (gyakran visszhangzott más kiadványokban és különféle kiállításokon) az volt, hogy az OT rendszerek javítása nehéz. A szerző azt állítja, hogy mivel nehéz, más módszerekhez kell fordulnunk a biztonság javítása érdekében. Az ő elmélete az, hogy bekapcsoljon egy olyan riasztási technológiát, mint az övé, és párosítsa a függőben lévő riasztásokat egy biztonsági incidensre reagáló csapattal. Más szavakkal, csak fogadja el a foltozást nehéz, adja fel, és öntsön több pénzt a tanulásra korábban (talán?) és erőteljesebben reagál.
ez a következtetés (a javítás nehéz, ezért ne zavarja) néhány okból hibás. Nem is említve, egy nagyon nagy tényezőt is átvilágít, amely jelentősen bonyolítja a figyelembe veendő válaszokat vagy kármentesítéseket.
az első ok, amiért ez veszélyes Tanács, egyszerűen nem hagyhatja figyelmen kívül a javítást. Meg kell tenned, amit tudsz, amikor tudsz, és amikor a javítás nem lehetséges, akkor a B, C és D tervre lépsz. A semmittevés azt jelenti, hogy minden olyan számítógépes esemény, amely a környezetébe kerül, maximális kárt okoz. Ez nagyon hasonlít az M& M védelemre 20 évvel ezelőtt. Ez az az elképzelés, hogy a biztonsági megoldásnak kívülről keménynek és ropogósnak kell lennie, de belül puha és rágós.
a második ok, amiért ez a Tanács hibás, az a feltételezés, hogy az OT biztonsági személyzetét (az incidensek kezelésére vagy javítására) könnyű megtalálni és telepíteni! Ez nem igaz – valójában a cikkben hivatkozott ICS biztonsági események egyike rámutat arra, hogy míg a javítás elérhető volt és készen áll a telepítésre, nem voltak rendelkezésre álló ICS szakértők a javítás telepítésének felügyeletére! Ha nem tudjuk felszabadítani biztonsági szakértőinket, hogy ismert, esemény előtti védelmet telepítsenek egy proaktív javításkezelő program részeként, miért gondoljuk, hogy megtaláljuk a költségvetést egy teljes incidensre reagáló csapat számára a tény után, amikor már túl késő?
végül, a hiányzó darab ebből az érvből az, hogy a kihívások OT/ICS patch management tovább súlyosbítja a mennyiség és összetettsége eszközök és architektúra egy OT hálózat. Egy új javítás vagy biztonsági rés megjelenésekor a legtöbb szervezet képes megérteni, hogy hány eszköz van a hatókörben és hol vannak, kihívást jelent. De ugyanolyan szintű betekintésre és eszközprofilokra lesz szükség minden incidensre reagáló csapat számára, hogy hatékony legyen. Még az a tanácsa is, hogy figyelmen kívül hagyja a javítás gyakorlatát, nem engedheti meg, hogy elkerülje a robusztus, kontextuális leltár felépítését (a javítás alapja!), mint az OT kiberbiztonsági programjának alapja.
Szóval, mit tegyünk? Először is meg kell próbálnunk javítani. Három dolog van, hogy egy érett ICS patch management program tartalmaznia kell, hogy sikeres legyen:
- valós idejű, kontextuális leltár
- a kármentesítés automatizálása (mind a patch fájlok, mind az ad-hoc védelem)
- kompenzáló vezérlők azonosítása és alkalmazása
valós idejű kontextuális leltár a patch-kezeléshez
a legtöbb OT környezet szkennelés-alapú javító eszközöket használ, mint például a WSUS/SCCM amelyek meglehetősen szabványosak, de nem túl éleslátóak ahhoz, hogy megmutassák nekünk, milyen eszközeink vannak, és hogyan vannak konfigurálva. Amire valóban szükség van, az a robusztus eszközprofilok, működési kontextusukkal együtt. Hogy értem ezt? Eszköz IP, modell, operációs rendszer stb. nagyon felületes felsorolás arról,hogy mi lehet a legújabb javítás. Értékesebb az a működési környezet, mint például az eszköz kritikussága a biztonságos műveletekhez, az eszköz helye, az eszköz tulajdonosa stb. a felmerülő kockázat megfelelő kontextusba helyezése érdekében, mivel nem minden OT eszköz egyenlő. Akkor miért nem védi meg először a kritikus rendszereket, vagy azonosítja a megfelelő tesztelési rendszereket (amelyek tükrözik a kritikus terepi rendszereket), és stratégiailag csökkenti a kockázatot?
és amíg ezeket az eszközprofilokat építjük, a lehető legtöbb információt kell tartalmaznunk az eszközökről az IP, a Mac cím és az OS verzió mellett. Olyan információk, mint a telepített szoftver, a felhasználók/fiók, a portok, a szolgáltatások, a rendszerleíró adatbázis beállításai, a legkisebb jogosultság-vezérlők, az AV, az engedélyezőlista és a biztonsági mentés állapota stb. Az ilyen típusú információforrások jelentősen növelik azon képességünket, hogy pontosan rangsoroljuk és stratégiázzuk cselekedeteinket, amikor új kockázat merül fel. Bizonyítékot akar? Vessen egy pillantást az alábbiakban kínált szokásos elemzési folyamatra. Hol kapja meg az adatokat a kérdések megválaszolásához a különböző szakaszokban? Törzsi tudás? Ösztön? Miért nem az adatok?
Automatikus javítás a szoftverjavításhoz
egy másik szoftverjavítási kihívás a javítások (vagy kompenzáló vezérlők) végpontokra történő telepítésének és előkészítésének feladata. Az OT patch menedzsment egyik leginkább időigényes feladata az előkészítő munka. Ez általában magában foglalja a célrendszerek azonosítását, a javítás telepítésének konfigurálását, a hibaelhárítást, amikor azok meghibásodnak, vagy az első szkennelést, a javítás megnyomását, valamint az újbóli szkennelést a siker meghatározása érdekében.
de mi van akkor, ha például a Bluekeephez hasonló kockázat következő megjelenésekor előre betöltheti fájljait a célrendszerekre, hogy felkészüljön a következő lépésekre? Ön és a kisebb, agilisabb OT biztonsági csapata stratégiailag megtervezheti, hogy mely ipari rendszerek frissítéseit telepítette az első, a második és a harmadik helyre, a robusztus eszközprofilok tetszőleges számú tényezője alapján, például az eszköz elhelyezkedése vagy kritikussága alapján.
ha egy lépéssel tovább lépünk, képzeljük el, hogy a javításkezelési technológia nem igényelt először vizsgálatot, hanem már leképezte a javítást a hatókörben lévő eszközökre, és amikor telepítette őket (akár távolról, alacsony kockázatú, akár személyesen magas kockázatú), ezek a feladatok igazolták sikerüket, és tükrözték ezt a haladást a globális irányítópulton?
az összes olyan magas kockázatú eszköz esetében, amelyet jelenleg nem tud vagy nem akar javítani, ehelyett létrehozhat egy portot, szolgáltatást vagy felhasználó/fiók változást ad-hoc kompenzációs vezérlőként. Tehát egy olyan biztonsági rés esetén, mint a BlueKeep, letilthatja a távoli asztalt vagy a vendégfiókot. Ez a megközelítés azonnal és jelentősen csökkenti a jelenlegi kockázatot, és több időt biztosít az esetleges javításra való felkészüléshez. Ez elvezet a ‘visszalépés’ műveletekhez, hogy mit tegyek, ha a javítás nem opció – kompenzáló vezérlők.
mik azok a kompenzáló vezérlők?
a kompenzáló vezérlők egyszerűen műveletek és biztonsági beállítások, amelyeket telepíthet és telepítenie kell a javítás helyett (vagy inkább). Ezek általában telepített proaktívan (ahol lehetséges), de lehet telepíteni egy esemény vagy ideiglenes védelmi intézkedések, mint például letiltása távoli asztal közben patch BlueKeep, amit bővíteni fel az esettanulmány végén ezt a blogot.
kompenzáló vezérlők azonosítása és alkalmazása az OT security alkalmazásban
a kompenzáló vezérlők számos formát ölthetnek az alkalmazás engedélyezőlistájából és a víruskereső naprakészen tartásából. De ebben az esetben az ICS végpontkezelésre szeretnék összpontosítani, mint az OT patch management kulcsfontosságú támogató összetevőjére.
a kompenzáló kontrollokat mind proaktívan, mind helyzetileg lehet és kell használni. Nem lenne meglepő, hogy bárki OT cyber security felfedezni alvó admin fiókok és felesleges vagy fel nem használt szoftver telepítve végpontok. Az sem titok, hogy a legjobb gyakorlat rendszer edzés elvek közel sem olyan univerzális, mint szeretnénk.
ahhoz, hogy valóban megvédjük OT rendszereinket, meg kell keményítenünk a nagyra becsült javainkat is. A valós idejű, robusztus eszközprofil lehetővé teszi az ipari szervezetek számára, hogy pontosan és hatékonyan megtisztítsák az alacsonyan lógó gyümölcsöket (azaz a alvó felhasználókat, a felesleges szoftvereket és a rendszerkeményedési paramétereket), hogy jelentősen csökkentsék a támadási felületet.
a szerencsétlen esemény, van egy feltörekvő fenyegetés (mint BlueKeep) hozzátéve ideiglenes kompenzáló ellenőrzések megvalósítható. Egy gyors esettanulmány a pontom kiemelésére:
- megjelent a BlueKeep biztonsági rése.
- a központi csapat azonnal letiltja a távoli asztal funkciót minden mezőeszközön és e-mailen a mezőcsoportnak rendszerenként konkrét kéréseket kell kérnie a távoli asztal szolgáltatás engedélyezéséhez a kockázati időszak alatt.
- a központi csapat előre betölti a patch fájlokat az összes hatókörű eszközre-nincs művelet, csak készülj fel.
- a központi csapat összeül, hogy eldöntse a legésszerűbb cselekvési tervet az eszköz kritikussága, elhelyezkedése, jelenléte vagy hiánya alapján kompenzáló ellenőrzések (azaz egy nagy hatású eszköz kritikus kockázata, amely nem sikerült az utolsó biztonsági mentésen, a lista tetejére kerül. Egy alacsony hatású eszköz, amelynek engedélyezőlistája érvényben van, és a közelmúltban jó teljes biztonsági mentés valószínűleg várhat).
- megkezdődik a javítások bevezetése, és a folyamat élőben frissül a globális jelentésekben.
- ahol szükséges, az OT technikusai a konzolnál felügyelik a javítás telepítését.
- ennek az igénynek az ütemezését és kommunikációját a központi csoport által használt adatok teljes mértékben megtervezik és prioritásként kezelik.
így kell kezelni az OT patch kezelését. És egyre több szervezet kezdi bevezetni ezt a típusú programot.
legyen proaktív a kompenzáló vezérlőkkel
az ICS patch kezelése nehéz, igen, de egyszerűen feladni a próbálkozást sem jó válasz. Egy kis előrelátással könnyű biztosítani a három legerősebb eszközt a könnyebb és hatékonyabb foltozáshoz és/vagy kompenzáláshoz. Az Insight megmutatja, hogy mi van, hogyan van konfigurálva, és mennyire fontos az Ön számára. A kontextus lehetővé teszi a priorizálást (az első kísérlet a javításra – a második lehetővé teszi, hogy megtudja, hogyan és hol kell alkalmazni a kompenzáló vezérlőket). A művelet lehetővé teszi a javítást, védelmet, eltérítést stb. Ha csak a megfigyelésre hagyatkozik, akkor beismeri, hogy tűzre számít, és több füstérzékelő vásárlása minimalizálhatja a károkat. Ön szerint melyik megközelítést részesítené előnyben a szervezete?