Fairuz Rafique, a Galactic Security munkatársa nemrég egy LinkedIn bejegyzésben írt arról, a grúziai Gudauri Ski Resort sífelvonóján még 2018 márciusban történt incidensről, amiben tizenketten sérültek meg. Bár a grúz illetékesek szerint a balesetet a sílift meghibásodása okozta, Fairuz szerint biztonsági kutatók ugyanazon a napon fedezték fel, hogy a sílift vezérlő rendszere elérhető volt az Internetről.

Az eset nyomán Joe Weiss ismét azt a (már 2015-ben is boncolt) témát járja körül, hogy az ICS rendszerek esetén van-e értelme különbséget tenni a szándékos (kibertámadás) és a nem szándékos (rendszerhiba, üzemeltetői hiba) ICS kiberbiztonsági incidensek között? Joe fontosabb észrevételei a téma kapcsán:

- Az NIST kiberbiztonsági szótára szerint "a kiberbiztonsági incidens olyan potenciális vagy ténylegesen bekövetkezett esemény, amely veszélyezteti az információs rendszer vagy az információs rendszer által feldolgozott, tárolt vagy továbbított információ bizalmas kezelését, integritását vagy elérhetőségét, vagy amely a biztonsági szabályok, eljárások megsértésének vagy közvetlen fenyegetésének minősül". Ebben a definícióban sehol nem szerepel a szándékos kitétel és ezen definíció alapján a fenti eset egyértelműen kiberbiztonsági incidensnek számít, hiszen a sílift rendelkezésre állása sérült (és akkor még nem is beszélünk a biztonsági - safety - tényező sérüléséről, hiszen emberek kerültek veszélybe és sérültek meg).

- Számos olyan esetről tudunk (az egyik még nevet is kapott, Stuxnet néven szoktuk emlegetni), amikor a szándékos és a véletlen ICS kiberbiztonsági incidenst csak az adott mérnök hozzáállása különböztette meg egymástól (az "A fenébe ezzel az egésszel!" és a "Hoppá..." pillanatok közötti különbség). Ráadásul egy jól felkészült támadó képes lehet a kibertámadása nyomán előálló üzemzavart egy ideig rendszerhibának álcázni - erre végképp tökéletes példa a Stuxnet.

- Az ICS rendszerekben, szemben az IT világával, a kiterjedt és alapos forensics vizsgálatoknak nincs meg a hagyománya és hiányzik a (kiberbiztonsági, főként forensics szempontból) megfelelően képzett OT mérnökök hada, akik képesek lennének az ICS rendszerek hosszabb ideig tartó leállása nélkül vizsgálni egy-egy incidens kiváltó okait. Az IT biztonsági incidensek esetén évek óta tudjuk, hogy az első támadás és a támadók felfedezése között akár 200-400 nap is eltelhet, ezért aztán, figyelembe véve az ICS kiberbiztonság igen korai érettségi állapotát, nem csoda, hogy az orosz hátterűnek tulajdonított, amerikai villamosenergia-rendszer elleni támadásokat 7 hónap utána fedezték fel, a 2015-ös ukrán áramszolgáltatók elleni támadás előtt a (szintén orosznak gyanított) támadók 9 hónapig rendelkeztek hozzáféréssel a kompromittált rendszerekhez - és akkor sem az adott cégek szakemberei fedezték fel a támadókat, hanem ők maguk mutatták meg magukat.

Joe záró gondolata, hogy alapvető fontosságú minden ICS biztonsági incidens alapos és minden részletre kiterjedő vizsgálatát elvégezni, még akkor is, ha "szinte biztos", hogy az adott üzemzavart nem kibertámadás okozta.

Már maga ez a cikk is érdekes gondolatokat vetett fel, de a SANS ICS Community-ben ennek nyomán elindult beszélgetés (csak regisztráció után olvasható!) még érdekesebb:

- Van, aki szerint igenis számít a különbség, mégpedig azért, ha meg akarjuk előzni egy incidens megismétlődését, akkor ismerni kell a kiváltó okát (root cause).

- Egy másik érv a biztosítási szektorból érkezik, akiket szintén nagyon érdekel egy adott incidens kiváltó oka.

Egy biztos, ezt a témát itthon eddig nem nagyon érintette senki. Szerintem itt lenne az ideje.