A modern villamosenergia-rendszer méltatlanul elhanyagolt részei az alállomások - mármint kiberbiztonsági szempontból, mert a hagyományos erőművek esetén az ICS/OT rendszerek biztonsága olyan, amilyen, a nukleáris erőművek kiberbiztonsága pedig egy teljesen más szinten mozog. Viszont az alállomások automatizálási rendszereit jellemzően még mindig villamosmérnökök tervezik és építik és csak elvétve vonják be ezekben a feladatokba a kiberbiztonsági szakembereket. Ennek oka főként a még mindig szilárdan álló tévhit, ami szerint az alállomásokon használt berendezések nem érintetettek az átlagos kiberbiztonsági sérülékenységek terén, pedig én is számos olyan esetet ismerek, amikor az ilyen alállomási eszközökben teljesen átlagos IT komponensekben talált sérülékenységeket kihasználva sikerült bejutni, majd adminisztrátori jogosultságot szerezni. Az Interneten pedig szabadon elérhetőek a legtöbb alállomási automatizálásban használt eszköz kézikönyvei, amiket elolvasva viszonylag könnyen meg lehet tanulni ezeknek a berendezéseknek a használatát és konfigurációját.
Ez tehát a helyzet jelenleg, de mit tehetünk (tehetnek az illetékesek) annak érdekében, hogy a mostani, nem éppen jó helyzeten javítani lehessen? Néhány alapvető intézkedéssel meglehetősen hatékonyan lehet csökkenteni a villamosenergia-rendszer alállomási folyamatirányító rendszereinek kockázatait:
Alállomási eszközleltár
Régóta axióma az IT biztonság területén az, hogy amiről nem tudunk, azt megvédeni sem tudjuk. Ugyanígy igaz ez az ICS/OT biztonság területén is és így az alállomási rendszerekre vonatkozóan is. Ráadásul az alállomások távkezelésének terjedésével a villamosmérnök kollégáknál ezek az eszközleltárok valamilyen (általában némileg kezdetleges formában, táblázatkezelőket használva) formában már rendelkezésre állnak. Ezek a táblázatos formák ugyan esetleges adattartalommal rendelkeznek és nehézkes lehet a használatuk, de a semminél mindenképp jobbak. Minden esetre egy olyan szervezetnek, ami alállomásokat üzemeltet és több ezer vagy tízezer Eurós berendezésekből építi fel ezeket az alállomásokat, nem gondolom, hogy pont egy normális eszköznyilvántartó szoftver licencén kéne spórolnia.
Védekezés-szempontú hálózat- és rendszerarchitektúra tervezés
A védekezés- (vagy védelem-) szempontú hálózat- és architektúra tervezés első és talán legfontosabb része a megfelelő hálózatszegmentálás. Ez azt jelenti, hogy a teljes folyamatirányítási rendszereket tartalmazó hálózat ne egyetlen nagy hálózat legyen, hanem legyenek szétválasztva a folyamatirányító rendszer, egyes logikailag különállóként kezelhető egységei (pl. SCADA/DCS rendszer szerverei egy hálózati szegmensben, az operátori és mérnöki munkállomások egy másik szegmens, az RTU-k, PLC-k és egyéb kontrollerek egy újabb hálózati zóna, stb). Ehhez fel lehet használni kiindulási alapnak a Purdue-modellt, bár egyre több (főleg OT irányból érkező) OT biztonsági szakértőtől (főleg amerikaiktól) lehet arról hallani/olvasni, hogy a Purdue egy referencia-architektúra modell és nem egy-az-egyben, tervrajzként kéne használni a folyamatirányító rendszerek hálózatszegmentációjának tervezése során.
Az architektúra tervezés másik lépése az egyes számítógépek és egyéb komponensek (RTU-k, PLC-k, stb.) biztonságának tervezése és megvalósítása, beleértve a hardening-et is.
ICS/OT hálózatmonitoring
Ahogy az IT biztonság terén, úgy az OT biztonság esetén is igaz, hogy a hatékony védekezéshez tudnunk kell, mi történik az adott rendszerekben és hálózatokban. Ennek az egyik leghatékonyabb módja a hálózati forgalom felügyelete (a folyamatiránytó rendszer hostjainak felügyelete mellett), amihez célszerű az IT/információbiztonsági területen már hosszú ideje használt SIEM megoldások mellett a kifejezetten OT hálózatmonitoring megoldásként fejlesztett rendszerek közül választani egyet. Ezek a rendszerek, szemben az IT biztonsági megoldásokkal szemben számos ICS/OT-specifikus protokollt is ismernek és képesek figyelni az ezen prokollok felhasználásával folytatott hálózati kommunikációkban látható anomáliák észlelésére.
Nagyon fontos hangsúlyozni, hogy az OT hálózatbiztonsági megoldások nem váltják ki az IT biztonsági megoldásokat, hanem kiegészítik azokat. Mivel az OT rendszerekben egyre kiegyensúlyozottabban keverednek az IT és OT komponensek, ezért látható és belátható, hogy mindkét terület megoldásaira szükség lehet ahhoz, hogy az elvárt szintű hálózatbiztonsági monitoringot az ICS/OT hálózatokban biztosítani lehessen.
Biztonságos távoli hozzáférés-menedzsment
A távoli hozzáférések terén az egyik utolsó terület volt a folyamatirányító rendszereké, ami "elesett a harcban", de ma már egyáltalán nem számít rendkívülinek, hogy az adott folyamatirányító rendszert vagy alállomási automatizálási eszközt távolról konfigurálják a szervezet belsős mérnökei vagy a gyártó támogató szakemberei. Az is mindennapossá vált, hogy egy ezek a szakemberek nemhogy nem az adott országban vannak, de még csak nem is ugyanazon a kontinensen dolgoznak, mint ahol az érintett rendszer működik. Figyelembe véve a mind nagyobb hiányt a képzett és tapasztalt munkaerőben, nem várható, hogy ebben bármikor a belátható jovőben pozitív irányú változások jönnének, így ezzel a helyzettel együtt kell élnünk és ezt kell megfelelően biztonságossá tenni. Ehhez szerintem két kulcs tényező, megoldás már a szervezetek rendelkezésére áll és többnyire már használják is ezeket (legalább is az IT területen meglehetősen elterjedtek).
2 vagy több (Multi-) Faktor Authentikáció: Sok éve hallgatjuk már az IT/információbiztonság világában, hogy a felhasználónév/jelszó-alapú authentikáció nem kellőképpen biztonságos, a különböző IT biztonsági megoldásokat gyártó cégeken túl már olyan szoftveróriások, mint pl. Microsoft is sok éve ajánlja ügyfeleinek a különböző 2 vagy többfaktoros authentikációs megoldásokat. Az elmúlt néhány évben már ezen is túllépve a jelszómentes authentikációt, mint biztonságos authentikációs megoldást népszerűsítik ahhoz, hogy a felhasználó egyáltalán távolról, az Internetet használva csatlakozzon VPN-kapcsolaton a szervezet belső hálózatához.
Privilégizált felhasználó menedzsment (Privileged User and Access Management) megoldások
A privilégizált felhasználó menedzsment megoldások szintén eredetileg az IT rendszerekben kezdték pályafutásukat, de az OT rendszerek egy része esetén ugyanolyan jól lehet használni őket, mint az IT rendszerek esetén. Még inkább igaz ez azóta, hogy egyre több alállomási automatizálási rendszerben jelenik meg a webes menedzsment/konfigurációs felület, amihez a legtöbb PUAM megoldás képes natív hozzáférést biztosítani. A privilégizált felhasználómenedzsment rendszerek számos biztonsági kontrollt tudnak biztosítani, többek között 2FA/MFA megoldásokkal is integrálhatóak, ezzel is tovább fokozva az OT rendszerek biztonságát.
Kockázatalapú sérülékenység-menedzsment
A sérülékenységek kezelése és ennek keretében a hibajavítások (patch-ek) telepítése nagyon régóta az OT rendszerek egyik leginkább neuralgikus pontja. Különösen igaz ez az alállomásokon használt berendezések esetén, hiszen ezekre patch-et telepíteni a legenyhébb megfogalmazás esetén sem "szokás", jobb esetben a rendszerek 10-15-20 éves életciklusa során talán egy, maximum két alkalommal cserélik a rajtuk futó firmware-t, de még ez sem 100%-ig biztos. A probléma ezzel az, hogy mindezt az elmaradó intézkedés és az adott sérülékenység okozta kockázatok értékelése és ismerete nélkül szokták eldönteni, ami ugyan lehetséges, de nem kifejezetten bölcs gyakorlat.
Ahogy az ICS/OT biztonság esetében oly sokszor, itt is a kompromisszumos megoldás lehet a célravezető, vagyis az egyes, alállomási berendezéseket érintő sérülékenységek esetén érdemes egy kockázatelemzés során értékelni, hogy az adott sérülékenység az érintett alállomási automatizálási berendezések esetén milyen kockázatnövekedést okoz és ennek a kockázatelemzésnek az eredménye alapján hozhatja meg az adott folyamat- vagy rendszergazda a döntést az egyes patch-ek telepítésének idejéről vagy kihagyásáról.
ICS/OT-specifikus incidens-kezelési tervek
Az incidenskezelés IT biztonsági rendszerek esetén sem egyszerű művelet, ami több, különböző szakterület képviselőinek hatékony együttműködését igényli. Ez (is) fokozottan igaz, amikor ICS/OT rendszerekkel kapcsolatos incidenst kell elhárítani, ebben az esetben a "szokásos" résztvevőkön (kiberbiztonsági elemzők, incidenskezelési vezető, a szervezet felsővezetői, HR és kommunikációs szakemberek/vezetők mellett elengedhetetlen az OT hálózat szakértőinek/üzemeltetőinek és a fizikai folyamatvezérlést elejétől a végéig alaposan ismerős mérnökök (jellemzően villamosmérnökök, gépészmérnökök, vegyészmérnökök, stb.) bevonása. Ráadásul az IT biztonsági incidenskezelésben hosszú évek alatt kidolgozott eljárások sem alkalmazhatóak egy az egyben egy ICS/OT biztonsági incidens során, ipari területen számos dolgot máshogy kell csinálni, mások a prioritások. Vegyünk például egy vírusfertőzött számítógépet az OT hálózaton (egy SCADA/DCS szervert vagy operátori/mérnöki munkaállomást). IT környezetben a malware-fertőzött számítógép leválasztása a hálózatról az egyik első és leginkább időkritikus tevékenység, hogy meg lehessen előzni a malware továbbterjedését a hálózaton. Ezzel szemben egy ICS/OT eszköz malware-fertőzése esetén az első kérdés, amit meg kell válaszolni, hogy a kártékony kód jelenlétének van-e hatása a fizikai folyamatvezérlésre. Itt nem csak egy Stuxnet-szerű működésre kell gondolni, de arra is, hogy vajon a malware jelenléte és működése okozhat-e üzembiztonsági vagy performancia-problémát a fertőzött host folyamatirányításban betöltött funkciójára nézve? Ha a vizsgálat eredménye az, hogy nincs ilyen érezhető hatás, akkor bizony még az előfordulhat, hogy a helyes döntés az, hogy a malware-fertőzött hostot a hálózaton hagyjuk és engedjük tovább működni addig, amíg egy karbantartás során a fizikai folyamatok vezérlésének megzavarása nélkül el lehet távolítani a kártékony kódot. Ez csak egy példa, de talán már ebből is látszik, hogy mennyire különböző célok és prioritások mentén mennyire más lehet egy ICS/OT rendszer/környezet esetében az incidensek kezelése - és akkor az alállomási automatizálási berendezésekkel kapcsolatos incidenskezelését még nem is érintettük...
