A héten két, az IT biztonsági szakma és a mainstream sajtó által egyaránt széles körben tárgyalt sérülékenységről publikáltak részleteket. Az x86-os architektúrájú CPU-k (jellemzően Intel és AMD) mellett az ARM processzorok is érintettek, ez pedig azt jelenti, hogy az IT eszközök bőven több, mint 90%-a érintett lehet. A legnagyobb operációs rendszer gyártók némelyike (Microsoft, RedHat, a Google az Android esetén, stb.) már kiadta vagy kiadni készül olyen frissítéseket, amikben javítják a hibákat, de ismerve az egyes szervezetek és felhasználók patch-elési szokásait, ezek a hibajavítások még jó esetben is hetekig, rosszabb esetben évekig nem lesznek telepítve - és ez is csak azokra a platformokra vonatkozik, ahol van/lesz elérhető frissítés (elég a különböző, nagy mobil eszköz gyártó vállalatok egyedi Andoid-verzióira gondolni, amikhez viszonylag gyorsan, kb. a következő modell megjelenésekor megszűnik a támogatás).
Mit is jelent ez a két sérülékenység az ICS rendszerek/eszközök üzemeltetői számára? Mivel a legtöbb ICS berendezés és rendszer az érintett CPU architektúrákra épül, ezért nagyjából biztosan állíthatjuk, hogy az ICS rendszerek döntő többsége érintett lehet. Tovább rontja a helyzetet, hogy az ICS rendszerek esetén még abban az esetben is lassan szoktak hibajavításokat telepíteni, ha a gyártó kiad hibajavításokat az adott eszközökhöz (és ahogy a héten korábban erről már írtam, az ICS világában az IT-nál sokkal gyakoribb a gyártói támogatással már nem rendelkező eszközök akár hosszú éveken át történő használata). Ráadásul napjainkban a SCADA és DCS rendszerek túlnyomó többsége már x86-os CPU-kra és Windows/Linux operációs rendszerekre épül, amikhez ugyan a hírek szerint legalábbis részben már elérhetőek a javítások, de a SCADA/DCS-gyártók jellemzően csak a saját, laborban végzett teszteléseik után szoktak engedélyt adni az ügyfeleiknek a patch-ek SCADA/DCS rendszerekre történő telepítésére, az üzemeltetők pedig ezt szinte minden esetben megvárják, mert nem akarják a rendszereik gyártói garanciáját kockázatatni egy, a gyártó által jóvá nem hagyott patch telepítésével. Sajnos az is nagyon elterjedt gyakorlat az ICS rendszerek világában, hogy a patch-eket még az esetlegesen már meglévő gyártói jóváhagyás esetén sem telepítik, úgy gondolva, hogy ezeket a rendszereket az ilyen sérülékenységeket kihasználó malware-ek és támadók úgy sem lesznek képesek elérni - arról pedig már számtalanszor írtam én is itt a blogon, hogy ezek a hiedelmek milyen károsak és hány esetben bizonyították sikeres támadások ennek az ellenkezőjét.
Ebben az esetben (illetve esetekben) tovább bonyolítja a helyzetet, hogy ez első hírek szerint a már elérhető patch-ek alkalmazása után az érintett rendszereknél jelentős (a hírek 5-30, időnként 50%-os) performancia-vesztés jelentkezett a hibajavítás előtti állapothoz képest, márpedig az ICS rendszerek döntő többsége jellemzően nem rendelkezik ekkora performancia-tartalékkal. Egyes SCADA és DCS rendszereknél láttam olyan méretezést, ahol a rendszer névleges teljesítménye legalább a rendszer tervezett csúcsteljesíményének a kétszerese, de egyrészt ezek a performancia-tartalékok azért vannak az adott rendszerekben, hogy a stabil működést garantálják minden esetben, másrészt számos olyan eszköz van (különösen a lvl1-lvl0 eszközök), ahol alig valamekkora performancia tartalék áll rendelkezésre. Ebbe a kicsi tartalékba az 5% talán még beleférhet egyes eszközöknél, de a 30-50% biztosan nem. Ismerve az ICS fejlesztők és üzemeltetők gondolkodását, ezeknél a rendszereknél és eszközöknél el fognak tekinteni a sérülékenységek patch-elésétől, ekkor pedig csak az ICS sérülékenységeknél gyakran ismételt kockázatcsökkentő intézkedések maradnak lehetőségként, hogy a sérülékeny rendszereket valahogyan megpróbálják a szakemberek megvédeni azoktól a támadási kísérletektől, amit az IT biztonsági szakma már most biztosra vesz a következő néhány hétben-hónapban.
Én minden esetre azt javaslom minden ICS rendszert üzemeltető kollégának, hogy vizsgálja meg a rendszereit és egyeztessen a gyártókkal, hogy az általa használt rendszerek/berendezések érintettek-e és elérhetőek-e már a javítások. Ha pedig van a gyártó által jóváhagyott javítás, kezdjen egyeztetéseket az érintett szakterületekkel a javítások telepítésének a lehetőségeiről.
