Azok számára, akik IT irányból érkeztek az ICS/OT kiberbiztonság világába, egyáltalán nem újdonság, hogy az ipari rendszerek esetén a titkosított protokollok és kommunikáció használata egyáltalán nem olyan elterjedt, mint az IT rendszerek és hálózatok esetében (ahol ma már gyakorlatilag alig lehet titkosítatlan kommunikációt találni vagy ha mégis, akkor azokat, akik nem használnak titkosítást, minimum súlyosan felelőtlennek tartja a szakma jelentős része).
Az ICS/OT rendszerek esetében azonban gyorsan szembesülhet az ember azzal, hogy a titkosítás hiánya nem a felelőtlenség vagy a tudatlanság egyértelmű megnyilvánulása, sokkal inkább az eltérő szemléletből és eltérő prioritásokból következik. Valamikor régen én is írtam arról, hogy az IT világban megszokott Confidentiality-Integrity-Availability biztonsági "szentháromság" az ICS/OT világban egyrészt három helyett 5 szempontból áll és a bizalmasság még csak nincs is ebből az ötből a fontosabbak között. A legfontosabb biztonsági szempont egyértelműen a safety, a vezérelt folyamatokkal kapcsolatban kerülő emberek illetve a környezet biztonsága (hogy ne sérüljön vagy haljon meg senki és ne történjen környezetszennyezés) illetve a folyamat biztonsága (process safety, hogy a vezérelt folyamat az elvárások szerint működjön). A második a fontossági sorban már vitatható, bizonyos esetekben a folyamatirányítással kapcsolatos adatok megbízhatósága (reliability), más esetekben a rendelkezdésre állás következik. Harmadikként jön a "másik", majd még mindig a folyamatirányítási adatok sértetlensége és csak ötödik helyen beszélhetünk ezeknek az adatoknak a bizalmasságáról (kivéve azokat az eseteket, amikor pl. egy gyógyszergyár esetén az új készítmény receptúrája olyan szintű értéket képvisel a versenypiacon, hogy ennek az információnak a védelmén nem csak a vállalat jövedelmezősége, de adott esetben a fennmaradása is múlhat).
Fentiekből következik, hogy az ICS/OT rendszerek esetén más szempontrendszer szerint kell vizsgálni, hogy az egyes ICS komponensek közötti kommunikációk titkosításának milyen pozitív és negatív következményei lehetnek?
- Titkosított OT hálózati kommunikáció esetén nehezebben (vagy éppen sehogy sem) tudjuk azonosítani a működési problémákat;
- Tudván, hogy az ICS/OT rendszerek IT-tól jelentősen eltérő (hosszabb) életciklussal rendelkeznek, a különböző titkosítási algoritmusok az IT-ban megszokottnál sokkal gyakrabban okozhatnak sokkal komolyabb kompatibilitási problémákat - mindezt olyan környezetekben, ahol egy leállás akár percek alatt is súlyos milliókban (és nem feltétlenül magyar Forintban számolt milliókban!) mérhető veszteségeket generálhatnak;
- Még mindig az ICS/OT berendezések életciklusánál, illetve az IT rendszerekénél sokkal inkább az adott célra történő tervezésénél/építésénél maradva, egyáltalán nem kizárt, hogy egy adott ICS berendezésben nincsenek meg a titkosított protokollok használatához szükséges plusz teljesítmény tartalékai - hardveresen. Ilyenkor pedig nincs más mód, mint a teljes (egyébként funkcionális szempontból tökéletesen működő) berendezést cserélni - aminek viszont ismét súlyos dollár/Euró tíz- vagy százezrekben mérhető hatása lesz.
- A kommunikáció küldő oldalon történő betitkosítása, majd a fogadó oldalon a titkosítás visszafejtése időigényes. IT oldalon az a néhány tized- vagy századmásodperc, amibe ez a be-, majd kititkosítás kerül, nem igazán szokott számítani, de az ipari folyamatirányításban gyakran nem csak tized- vagy századmásodperceken múlhat egy igen súlyos következmény, de például a villamosenergia-iparban már nem csak milisecundumos, hanem microsecundumos válaszidő követelményekről is hallottam. Évekkel ezelőtt...
- A fentiek után az, hogy ha az ICS/OT rendszerekben az IT hálózatokhoz hasonlóan mindenhol titkosítanánk minden kommunikációt, elveszítenénk a még leginkább elfogadott, hálózati forgalom-figyelésen alapuló monitoring megoldás használhatóságát.
Mi is akkor a megoldás? Titkosítsuk vagy sem a kommunikációt ICS/OT rendszerekben?
A válasz szerintem, mint oly sokszor ebben a világban, nem fekete vagy fehér, hanem "attól függ".
Olvastam veterán folyamatirányítás mérnököktől olyan véleményt, hogy ha vezetéknélküli kommunikációt használunk ipari környezetben, használjunk titkosítást. Ha különböző biztonsági szintű hálózati zónák közötti kommunikációról van szó, használjunk titkosítást, de ha ugyanazon a biztonsági szinten lévő zónán belüli kommunikációról van szó, ne küzdjünk a titkosítással/titkosításért, főleg, mert gyakran akadályozhatja majd a különböző diagnosztikai vizsgálatokat.
Én emellett úgy gondolom, a válasz főleg attól függ, mennyire értékes az információ, amit át akarunk küldeni egyik ICS komponenstől a másiknak, mekkora a kockázata annak, ha egy illetéktelen harmadik fél (akár ártó szándékkal) megismerheti a kommunikáció tárgyát képező információt? Ha ezeknél az adatoknál a a bizalmassági követelmény nem értelmezhető vagy a kockázat az adatgazda szerint elhanyagolható vagy az elfogadható szint alatt marad, érdemesebb lehet nem küzdeni a titkosítással.
Viszont, ha az adatok bizalmassága bármilyen szempontból fontos a folyamatvezérlésért felelős szakembereknek vagy olyan adatokról van szó, amiket minden körülmények között védeni kell (pl. a folyamatirányító rendszerekbe történő bejelentkezéshez használt jelszavak vagy privát kulcsok védelme), akkor meg kell fontolni a titkosítás alkalmazását. Ilyenkor következhet egy olyan, minden fontos szempontra kiterjedő hatásvizsgálat, amibe legalább annyira fontos (ha nem fontosabb) bevonni a folyamatirányítási mérnök kollégákat, mint a biztonságért felelős szakembereket.
Jake Brodsky-tól olvastam egy nagyszerű gondolatot a témában: Az OT biztonság feladata, hogy fejlessze az OT rendszerek rendelkezésre állását [az én értelmezésemben az ellenálló-képességét], nem pedig az, hogy hátráltassa azt. Ha a biztonsági szakemberek [vagyis mi] ezt nem veszik figyelembe, csak ártani fognak, nem segíteni."
