Ebben a posztban a ICS rendszerek biztonsági problémáinak általános áttekintését kezdem el. A tervek szerint ez egy több részes sorozat lesz - ebből is látható, hogy a ICS rendszerekkel bőven van probléma.
Protokollok biztonsági problémái
Ahogy a korábbi három posztban ismertetett, ICS rendszerekben használt protokolloknál lehet látni, ezek rendszerek gyakran évtizedekkel ezelőtt kidolgozott protokollokat használnak a mindennapi működésük során. Ezeknek a protokolloknak egy jelentős hányadát (elsősorban a ICS-specifikus protokollokat) jellemzően nem nyílt hálózatokon történő használatra tervezték, ezért ezek szinte soha nem tartalmaznak biztonsági funkciókat. Például a Modbus és a Modbus/TCP protokollok nem ismerik a felhasználónév/jelszó vagy bármilyen más authentikációs forma használatát a ICS szerver és a PLC/RTU közötti kommunikáció során, vagyis ha valaki kommunikálni tud egy Modbus szerverrel vagy klienssel és ismeri a megfelelő parancsokat, akkor irányítani is tudja az adott eszközt. Ez a legtöbb, hasonló korú ICS protokoll esetén sincs másként. Ez a probléma később még vissza fog térni néhányszor, nemzetközi ICS-biztonsági körökben a ICS rendszerek egyik fő ismérve, hogy nincs semmilyen authentikáció.
Jelszóproblémák
Ahogy a protokolloknál már érintettük, a ICS rendszerek egyik gyenge pontja az authentikáció (ami gyakran teljesen hiányzik a rendszerből), még akkor is, ha maga az authentikáció lehetőség adott. Nem ritka, hogy egyes (jellemzően távoli eszközökön, RTU-kon, PLC-ken) egy adott felhasználóhoz (akár root/adminisztrátor felhasználói fiókhoz is!) nincs jelszó beállítva, ha pedig van az adott fióknak jelszava, akkor az jellemzően könnyen kitalálható/törhető. Ha pedig ritka kivételként az üzemeltetők jó jelszót adtak meg, a legtöbb ICS rendszer esetén azt is pillanatok alatt meg lehet szerezni, hiszen ahogy a protokollokat tárgyaló korábbi részekből látni lehet, a ICS rendszerek elvétve használnak titkosított protokollokat, így az összes jelszó plain text formában utazik a hálózaton.
A ICS rendszerek életciklusa
Aki informatikai területen dolgozik (legyen akár üzemeltető, akár fejlesztő vagy bármilyen más terület szakértője), biztosan találkozott már az SDLC rövidítéssel, ami a szoftver-/rendszerfejlesztési életciklust jelöli. ICS rendszerek esetén az SDLC egy ciklusa sokkal nagyobb időtávot, gyakran évtizedeket ölel fel, szemben az általános informatikai gyakorlattal, ami napjainkra egyre gyorsuló ciklusokkal dolgozik (elég csak megnézni a népszerű böngészőprogramok vagy Linux-disztribúciók kiadási ütemét).
Egy ICS rendszer teljes életciklusa akár 20-30 év is lehet, ez azonban azt jelenti, hogy míg egy tervezési hibát egy átlagos szoftver vagy rendszer esetén a következő verzióban viszonylag gyorsan (akár napokon belül) lehet javítani. Ugyanez egy ICS rendszernél jobb esetben is hónapokat, rosszabb esetben akár éveket is igénybe vehet és eközben a rendszert napi szinten, gyakran 7/24-es üzemben kell használni olyan környezetben, ahol egy ismert hibát kihasználva a támadók jelentős anyagi károkat okozhatnak vagy akár emberéleteket veszélyeztethetnek.
Sajnálatos módon nagyon sokáig ez igaz volt a ICS rendszerek komponenseiben talált hibák javítására is. A Stuxnet előtt csak elvétve telepítették a ICS rendszerekre azokat az operációs rendszereket és adatbázisokat érintő hibajavításokat, amik minden más rendszer esetén az üzemeltetői rutin részeként kezelnek már több, mint egy évtizede. A Stuxnet okozta megrázkódtatás után egyes ICS rendzsereket fejlesztő cégek változtattak a korábbi hozzáállásukon és ma már készek (egy, más rendszerekéhez képes lassúnak és konzervatívnak tűnú) patch-menedzsment eljárást nyújtani a ICS üzemeltetőknek. Ennek ellenére mind a mai napig a ICS rendszerek rendszeres patch-elése nem elterjedt gyakorlat, volt olyan, ICS-rendszeren végzet penteszt, ahol 10 éves, javítatlan Solaris hibát találtak a biztonsági szakemberek.
