Tegnap este egy érdekes cikket olvastam a hwsw.hu-n arról, hogy miért esett ki tavaly decemberben a Delta Airlines adatközpontja és mi okozta a kiesést. A részletek a cikkben olvashatóak, dióhéjban az történt, hogy az áramkimaradás idejére üzembe helyezett tartalék generátorok védelmi reléiben használt PLC-k feszültségingadozást észleltek az áramszolgáltató vonalán bekövetkezett betáp-kiesés után, amit a PLC belső logikája úgy értelmezett, hogy az adatközpont villamosenergia-rendszerében valahol rövidzárlat van, ezért a generátorokat védve nem engedte csatlakoztatni őket az adatközponti hálózatra. Emiatt a generátorok fogyasztók nélkül, "üresben" működtek, a szerverek pedig a szünetmentes áramforrások lemerülése után leálltak.
A cikk szerint hasonló történt már az Amazon egyik adatközpontjában is, abban az esetben a PLC gyártója még az Amazon kifejezett kérésére sem volt hajlandó olyan, módosított firmware-t szállítani a védelmi relék PLC-ihez, amiben felülbírálható lett volna a generátort védő logika. Emiatt - írja a hwsw.hu - az Amazon adatközpontjaiban ma már azok a villamosmérnökök írják a PLC-k firmware-jeit, akik az adatközponti villamosenergia-ellátásért felelősek. Itt meg is érkeztünk a ma poszt elején feltett kérdéshez: ICS biztonsági szempontból jó-e, ha az OT munkatársai írják a saját maguk üzemeltette eszközökön futó szoftvereket?
Az ICS kiberbiztonság területén dolgozók hosszú ideje próbálják terjeszteni azt a nézetet, hogy a biztonságos programozásnak az ipari rendszerek világába is utat kell találni. Ennek megértése és alkalmazása az ICS gyártók részéről még a IT szoftverfejlesztők meggyőzésénél is fontosabb feladat kéne, hogy legyen, hiszen egy IT-ban használt szoftver életciklusa jellemzően 1-2-3 év lehet és ez az idő egyre csökken, ráadásul a feltárt hibákat rövid idő alatt lehet javítani. Ezzel szemben az ICS rendszereknél egy már élesbe állított rendszert 10-15-20 évig fognak használni és jóval ritkábbak a hibajavítások telepítésének lehetőségei is.
Természetesen ezzel nem azt mondom, hogy ez egy elhibázott út, hiszen ha egy szervezet a beszállítóitól nem kapja meg azt a funkcionalitást egy rendszerben, amire szüksége van és van lehetősége egyedileg fejleszteni, akkor nem igen van más lehetősége. Azonban ha ezt választják, mindenképp nagyon alapos kockázatelemzéseket kell folytatniuk a saját fejlesztésű szoftverek teljes életciklusa során és ha ilyen alapvető fontosságú szoftverelemeket fejlesztenek házon belül, hangsúlyt kell fektetniük a szoftverfejlesztés biztonsági szempontú minőségbiztosítására is, különben elképzelhető, hogy egy funkcionalitásában már-már tökéletes, de a támadók számára könnyen kompromittálható rendszert építenek, ami immár a szoftveres sérülékenységei miatt nem lesz képes az elvárásoknak megfelelően működni.
