A MITRE által összeállított és karbantartott ATT&CK keretrendszer az elmúlt években kvázi szabvánnyá vált a kiberbiztonsági szektorban a támadók viselkedésének és tevékenységeinek osztályozásában, ennek a tudásbázisnak az ICS rendzserekre szabott változatát adták ki a hét első napjaiban.

A tudásbázis központi eleme egy mátrix, ami az ismert, ICS rendszerek elleni támadások során használt TTP-kből (Tools, Technics, Procedures) építkezik és tartalmaz egy kategorizálást is a különböző ICS eszközökre vonatkozóan.

Az ATT&CK for Industrial Control Systems szabadon elérhető a MITRE weboldalán.

Ahogy látom, az ICS biztonsági szakma meglehetősen lelkesen vette tudomásul az új ATT&CK verziót, számos IT és/vagy ICS biztonsági oldalon írtak róla és a Dragos január 14-én egy webinart is rendez, közösen a MITRE egyik munkatársával.

Azzal, hogy az elmúlt egy hétben megint a világ egyik legfontosabb témájává vált az amerikai-iráni viszony és feszültség, engem is megkerestek azzal a kérdéssel, hogy ennek lehet-e hatása a kritikus infrastruktúrák illetve más ICS rendszerek kiberbiztonságára. Ahogy a hírekben olvasható volt, többen számítottak arra, hogy Szulejmáni tábornok halálát az irániak nem (vagy nem csak) fizikai támadásokkal próbálják majd megbosszulni, hanem a kibertérben is támadásokat indítanak egyes amerikai kritikus infrastruktúra elemek ellen. Olyannyira komoly fenyegetésként kezelték/kezelik ezt a lehetőséget, hogy konkrétan tudok olyan európai közműszolgáltatóról, ahol ennek nyomán magasabb szintre emelték a készenlétet.

Mivel sok időm erre a posztra sajnos nincs, ezért csak két dologra térnék ki részletesebben:

1. Az iráni bosszúhadjárat gyakorlatilag már az Irakban található, amerikai haderő által is használt légibázisok elleni rakétatámadások előtt megindult, de amerikai kormányzati szervek (pl. a Federal Depository Library Program) weboldalai ellen indított deface-támadások valószínűleg inkább írhatóak az iráni hazafias hackerek számlájára, mint az iráni hátterű APT-csoportokéra (amikből szintén akad néhány, pl. a Magnallium/APT33).

Az ilyen támadások véleményem szerint, bár nyilván problémát jelentenek, egy ország szempontjából nem minősülnek komoly támadásnak, inkább arra jók, hogy a másik oldal (ebben az esetben Irán) fel tudjon mutatni valamilyen gyors és kockázatmentes választ, ami javítja a morált és minimálisan megfelel a tömegek feltüzelt bosszúvágyának).

2. A kritikus infrastruktúrák/ICS rendszerek elleni támadások szerintem nem valószínű, hogy (ha egyáltalán lesznek) az elkövetkező napokban fognak bekövetkezni. Egy ICS rendszer elleni támadás (az eddig tapasztalatok alapján) minden esetben hosszú hónapok előkészítő munkáját igénylik (emlékeztetőül, az ICS Cyber Kill Chain két fázisa külön-külön is több hetes, hónapos műveleteket jelenthetnek), ezért én két forgatókönyvet tudok elképzelni. Az első szerint az iráni APT-csoportok már hosszabb ideje hozzáféréseket szereztek egyes amerikai kritikus infrastruktúrák rendszereihez és ezeket felhasználva nagyon gyorsan képesek megszervezni és kivitelezni az ICS rendszerek (és/vagy az általuk vezérelt fizikai folyamatok) elleni támadásokat. A második forgatókönyv pedig az, hogy most kezdik el célzottan felderíteni az általuk fontosnak tartott és támadni kívánt rendszereket, ebben az esetben azonban hónapok vagy akár évek múlva számíthatunk komolyabb zavarokat okozó eseményekre. Én személy szerint inkább ez utóbbira számítok.

Ahogy Magyarországon, úgy az USA-ban is sok helyen cikkeztek a témáról a sajtóban, a SecurityWeek cikkében nyolc szakértő (a CyberX, a Dragos, a Nozomi Networks, a CrowdStrike, a Claroty, a Synopsys CyRC és a Lastline munkatársait) véleményét foglalja össze.

Sérülékenység Moxa berendezésekben

Dove Chiu, Philippe Lin, Charles Perine, Marco Balduzzi, Ryan Flores és Rainer Vosseler, a TrendMicro munkatársai egy Command Injection sérülékenységet fedeztek fel a Moxa MGate 5105-MB-EIP sorozatú eszközeinek 4.1-es és korábbi firmware-verzióiban.

A gyártó a hibát javító új firmware-verziót már elérhetővé tette. A sérülékenység részleteiről a Moxa weboldalán lehet olvasni.

A fenti sérülékenységek negatív hatásainak csökkentése érdekében az ICS-CERT az alábbi kockázatcsökkentő intézkedések bevezetését javasolja:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- Az ipari/egészségügyi rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari/egészségügyi rendszerek/hálózatok távoli eléréséhez biztonságos módszereket (pl. VPN) kell használni, de szem előtt kell tartani azt is, hogy az egyes VPN-megoldásoknak is lehetnek sérülékenységeik és ezeket is folyamatosan frissíteni kell a legújabb elérhető verzióra. Nem szabad elfelejteni továbbá azt sem, hogy a VPN csak annyira biztonságos megoldás, mint az eszköz, amit a VPN-en keresztül a védett hálózathoz csatlakoztatnak;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgáltatások hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználó kezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (valamilyen szinten tűzálló páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Az elmúlt időszakban többször is felmerült körülöttem a kérdés, hogy az IT és az ICS biztonság helyileg hova kéne, hogy tartozzon egy adott (ipari) szervezeten belül, ezért úgy határoztam, hogy egy posztban összefoglalom az ezzel a kérdéssel kapcsolatos gondolataimat, épp csak annyira, hogy elkezdődhessen egy diskurzus a témáról.

Kezdjük talán az IT biztonsági szakterülettel. Amennyire én látom, jellemzően két megközelítés létezik a szakmában azzal kapcsolatban, hogy az IT biztonsági szakemberek szervezetileg hova tartoznak. Az első szerint az IT vezető irányításával dolgoznak, ezek a szervezetek az IT biztonságot is főként az IT egy területeként fogják fel (mint az adatközponti üzemeltetést, alkalmazásfejlesztést vagy a felhasználók támogatását). Amennyire én ezt átlátom a saját tapasztalataim szerint, az ilyen szervezetekben az IT biztonság esetén a fő hangsúly a különböző biztonsági rendszerek (tűzfalak, spamszűrők, végpontvédelmi megoldások, stb.) üzemeltetésén van és az operatív feladatok jellemzően kisebb fontossággal léteznek. Ez (bár szerintem helytelen) nem annyira meglepő, hiszen az IT vezetők az esetek döntő többségében üzemeltetői és/vagy fejlesztői múlttal és tapasztalatokkal rendelkeznek, a biztonsági műveleti feladatok tőlük kicsit távolabb állnak. A másik megközelítés szerint az IT biztonsági szakterület a biztonsági vezetőhöz tartozik (együtt a fizikai, szervezeti/humán biztonsági és egyéb biztonsági témákkal). Az ilyen esetek talán még összetettebbek, mert az esetek döntő többségében a biztonsági vezetőnek fizikai biztonsági tapasztalatai vannak (jellemzően valamilyen rendvédelmi vagy katonai múlttal rendelkező emberek), viszont a logikai biztonság témáját általában kevésbé ismerik. Ilyen esetekben a műveleti feladatok erősebbek lehetnek, viszont az IT biztonsági rendszerek üzemeltetési kérdései nagyobb kihívásokat jelenthetnek és az IT üzemeltetőkkel történő együttműködés is komolyabb kihívásokat jelenthet.

Az ICS biztonság, mint szakterület a fentiekhez hasonlóan többnyire kétféle megvalósításban szokott létezni - legalábbis amennyire én ezt látom a szakmán belül. Az egyik szerint az ICS biztonságnak az IT biztonsághoz kell tartoznia (akik emellett érvelnek, többnyire az IT rendszerek és komponensek OT-n belüli térhódításával érvelnek), a másik szerint pedig az ICS biztonságnak az IT biztonsággal párhuzamosan kell léteznie, de az OT szakterületen belül, hiszen az ICS biztonság megfelelő minőségben történő megvalósításához és működtetéséhez elengedhetetlen az OT minél alaposabb ismerete.

Az én véleményem az, hogy ezek a megközelítések még mindig a régi, hierarchikus szervezeti felépítésekben gyökereznek, ami megakadályozza azt, hogy az ICS (és az IT) biztonság egy olyan szolgáltatása legyen az adott szervezetnek, ami átfogóan képes kezelni bármilyen irányból (legyen az fizikai, humán, IT vagy OT) irányból érkező fenyegetést. Kiemelten fontosnak tartom, hogy a különböző ipari szervezetek minél előbb számoljanak le a silós működési modellel a biztonság területén és kezdjenek megvalósítani egyfajta mátrix-szerű működést ebben a témában. Ehhez elsősorban megint a kommunikációra kell helyezni a hangsúlyt és komoly erőfeszítéseket kell tenni a többi szakterület kihívásainak és prioritásainak megismerésére.

Ki mit gondol erről a témáról?

A Chaos Computer Club évenként megrendezett konferenciájáról az elmúlt években többször is írtam már a blogon.

Az idén is megrendezett konferencián (sorrendben immár a 36-on, vagyis a 36c3-on) a Kaspersky Lab munkatársai tartottak előadást a nemrég publikált (én pedig itt írtam róla röviden), erőművi turbinavezérlésre használt Siemens SPPA-T3000 rendszerek sérülékenységéről.

Az előadás diái PDF-formátumban itt található.

Szerk: Időközben a SCADA Strangelove oldalán megjelent az előadás felvétele is néhány egyéb apróság (pl. dissector az SPPA-T3000 alkalmazás szerver kommunikációhoz) társaságában.

Még nyáron jelent meg a Tripwire egy cikke amiben 12, jellemzően a Tripwire-nél vagy más, ICS biztonsággal foglalkozó cégeknél dolgozó szakértőt kérdeztek arról, milyennek látják az ICS kiberbiztonság jövőjét 5-10 éves időtávon, milyen változásokat, kihívásokat valószínűsítenek. A legfontosabb fejlemények a megkérdezettek várakozásai szerint az alábbiak lesznek:

- A legnagyobb hatása a nem célzott, IT irányból érkező támadásoknak lesz, legyen az malware-alapú vagy a digitális transzformáció egyre nagyobb, ICS rendszerekre gyakorolt hatásának következménye;
- A már jelenleg is elavultnak számító (legacy) rendszerek cseréjével számos soros porton kommunikáló eszköz helyett Ethernet-alapú új rendszer kerül majd telepítésre a rekonstrukciók során, ami az eddigieknél is gyorsabban fogja növelni az OT IT-függőségét, ami tovább fogja növelni az IT-ban ismert kockázatokat az OT vonatkozásában is;
- A kritikus infrastruktúrák ellen végrehajtott, gyakran nemzetállami hátterű csoportok által indított (az egyik válaszadó a kiberháború kifejezést használja) támadások még elterjedtebbek lesznek;
- Az automatizálási eszközök gyártóira a korábbiaknál (és a jelenleginél) jóval nagyobb nyomás fog nehezedni, hogy a biztonság kérdését a tervezéstől az eszközök teljes életciklusa során kezeljék kiemelt szempontként;
- A folyamatvezérlés során keletkező adatok el fogják hagyni a folyamatirányítási rendszerek hálózatait és be fognak kerülni a felhő-alapú rendszerekbe (privát-, hibrid- és publikus felhőkbe egyaránt), majd ezek egy része (valamilyen feldolgozás, elemzés után) akár vissza is kerülhet a folyamatirányító rendszerekbe;
- A jelenleginél hatékonyabban kell a már ismert intézkedéseket (pl. hálózatszegmentálás, fenyegetés-elemzés) alkalmazni;
- Szükséges lesz valamilyen szabályozó szervezetre, ami rászorítja az érintett szervezeteket a megfelelő kiberbiztonsági kontrollok bevezetésére és azok érettségi szintjének vizsgálatára, mérésére - ez egyben azt is jelenti, hogy az ICS biztonság területén szükséges erősíteni a fentről vezérelt kiberbiztonsági terv megvalósítást, ami magában foglalja a költségkeretek és a beszállítók konszolidálását (ami az IT és az OT között napjainkban még mindig létező kommunikációs szakadékok miatt sokkal ritkábban van egyeztetve, mint az indokolt lenne);
- Az IIoT térhódítása az ICS rendszerek között, elsősorban a gyártásautomatizálási szektorban, egyre gyorsabb ütemben fog történni, ezért az ICS biztonsági szakembereknek naprakész tervekkel kell rendelkezniük az ilyen rendszerek és berendezések biztonságának megteremtéséhez és fenntartásához;
- Ahogy az IT egyre nagyobb szerepet kap az OT rendszerek és eszközök működésében, az időérzékeny hálózatok (Time Sensitive Network, TSN), amelyek az ICS rendszerek működésében gyakran kritikus fontosságúak (elég csak arra gondolni, hogy sok ICS eszköz esetén elengedhetetlen a néhány milisecundum válaszidők garantálása) üzemeltetése egyre inkább az IT hatáskörébe kerülhet, ahol viszont a szakembereknek (ritka kivételektől eltekintve) nincs meg sem a tudásuk, sem a tapasztalatuk ilyen hálózatok üzemeltetéséhez;
- A PKI rendszerek megjelenése az ipari rendszerekben és hálózatokban alapvető változásokat hozhat az ipari folyamatok és a folyamatok irányítása terén, főként, mert az OT területen dolgozó szakembereknek mostanáig nem kellett a PKI rendszerekkel kapcsolatos folyamatokat kidolgozniuk és megszokniuk (különösen, ami a lejáró tanúsítványok cseréje esetén lehet kritikus).

A fentiek miatt az érintett szervezeteknek újra kell gondolniuk a jelenlegi hozzáállásukat a hálózatbiztonság kérdéséhez, mert míg napjainkban szinte minden szervezet az IT felelősségének gondolja az IT biztonsági kockázatok és kérdések kezelését, az OT egyre nagyobb IT biztonsági kitettsége azt fogja követelni, hogy az IT és OT szakemberek egyre szorosabban működjenek együtt az érintett szervezetek üzletkritikus rendszerei (legyen az IT vagy OT rendszer) biztonságának megteremtésében és fenntartásában.

Sérülékenységek Schneider Electric Modicon termékekben

Mengmeng Young, Gideon Guo, Chansim Deng és Younes Dragoni összesen három sérülékenységet találtak a Schneider Electric Modicon termékcsaládjának alábbi tagjaiban:

- Modicon M580;
- Modicon M340;
- Modicon Quantum;
- Modicon Premium.

A gyártó a hibákat javító firmware-verziókat elérhetővé tette ügyfelei számára. A sérülékenységek részleteit a Schneider Electric weboldalán lehet elérni.

Schneider Electric EcoStruxure Control Expert sérülékenység

Rongkuan Ma, Xin Che és Peng Cheng, Zhejiang University munkatársai egy sérülékenységet fedeztek fel a Schneider Electric EcoStruxure Control Expert V 14.0 verziójában és a Unity Pro minden verziójában.

A gyártó a hibát a Control Expert V14.1-ben javította. A sérülékenységgel kapcsolatban további információkat a Schneider Electric publikációjában lehet olvasni.

Sérülékenység Schneider Electric Power SCADA termékekben

A Schneider Electric bejelentésében egy, az alábbi Power SCADA termékeit érintő sérülékenységről közölt részleteket:

- Power SCADA Operation 9.0;
- Power SCADA Expert 8.2;
- Power SCADA Expert 8.1;
- Power SCADA Expert 8.0;
- Power SCADA Expert 7.4;
- Power SCADA Expert 7.3.

A gyártó a hibát az érintett termékekhez kiadott v4.15.00 verzióban javította. A sérülékenységről bővebben a Schneider Electric bejelentésében lehet olvasni.

Schneider Electric EcoStruxure Geo SCADA Expert sérülékenység

A Schneider Electric publikációjában közölt információk szerint egy sérülékenységet találtak az EcoStruxure Geo SCADA Expert (ClearSCADA) nevű termékük minden, 2019. január 1-je előtt kiadott verziójában. Az érintett termékek közül jelenleg a következő verziók rendelkeznek támogatással:

- ClearSCADA 2017 R3;
- ClearSCADA 2017 R2;
- ClearSCADA 2017.

A gyártó a hibát az EcoStruxure Geo SCADA Expert 2019-es verziójában javította. A sérülékenységről bővebben a Schneider Electric weboldalán lehet olvasni.

Omron PLC sérülékenység

Egy n0b0dy néven hivatkozott biztonsági kutató egy sérülékenységet jelentett a DHS CISA-nak, ami az Omron alábbi termékeit érinti:

- CS sorozatú Omron PLC-k minden verziója;
- CJ sorozatú Omron PLC-k minden verziója;
- NJ sorozatú Omron PLC-k minden verziója.

A hibával kapcsolatban a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről bővebb információkat az ICS-CERT bejelentésében lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-346-03

Sérülékenységek Omron PLC-kben

Wang Zhibei és egy n0b0dy néven hivatkozott biztonsági kutató három sérülékenységről közölt részleteket a DHS CISA-val, amik az Omron alábbi PLC-it érintik:

- CJ sorozatú Omron PLC-k minden verziója;
- CS sorozatú Omron PLC-k minden verziója.

A hibák javításáról nincs információ, a gyártó kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységekről további részletek az ICS-CERT publikációjában érhetőek el: http://www.omron-cxone.com/security/2019-12-06_PLC_EN.pdf

Advantech DiagAnywhere Server sérülékenység

Egy Z0mb1E néven hivatkozott biztonsági kutató egy sérülékenységet jelentett a ZDI-nek, ami az Advantech DiagAnywhere Server 3.07.11-es és korábbi szervereit érinti.

A gyártó a hibát a 3.07.14-es verzióban javította. A sérülékenységről részleteket az ICS-CERT bejelentésében lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-346-01

GE rendszerek sérülékenysége

Murat Aydemir, a Biznet Bilisim A.S. munkatársa egy sérülékenységet jelentett a DHS CISA-nak, ami a GE S2020/S2020G típusú hálózati eszközeinek 61850-es változatának 07A03 és korábbi verzióit érinti.

A gyártó a hibát a 07A04 verzióban javította. A sérülékenység részleteit az ICS-CERT weboldalán lehet megtalálni: https://www.us-cert.gov/ics/advisories/icsa-19-351-01

Sérülékenység Reliable Controls eszközökben

Gjoko Krstic, az Applied Risk munkatársa egy sérülékenységet talált a Reliable Controls alábbi eszközeiben:

- MACH-ProWebSys: 2.15-nél korábbi verziók (8.26.4-nél korábbi firmware-verziók)
- MACH-ProWebCom: 2.15-nél korábbi verziók (8.26.4-nél korábbi firmware-verziók)

A gyártó a hibát a 2.15-ös szoftver/8.26.4-es firmware-verzióban javította. A sérülékenységgel kapcsolatban további információkat az ICS-CERT publikációjában lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-353-04

WECON PLC Editor sérülékenység

Francis Provencher (PRL) és Natnael Samson (Natti) a ZDI-vel együttműködve egy sérülékenységet azonosítottak a WECON PLC Editor 1.3.5_20190129-es verziójában.

A gyártó jelenleg is dolgozik a hiba javításán. A sérülékenységről bővebben az ICS-CERT bejelentésében lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-353-03

Sérülékenység Equinox Control Expert rendszerekben

Juan Pablo Lopez Yacubian egy sérülékenységet talált az Equinox Control Expert nevű HMI/SCADA menedzsment platformjának minden verziójában és jelentette azt a DHS CISA-nak.

A gyártó nem reagált a hibával kapcsolatos megkeresésekre. A sérülékenységgel kapcsolatos részletesebb információkat az ICS-CERT weboldalán lehet elérni: https://www.us-cert.gov/ics/advisories/icsa-19-353-02

Moxa ipari hálózati eszközök sérülékenységei

Yuval Ardon és Matan Dobrushin, az Otorio munkatársai egy sérülékenységet fedeztek fel a Moxa alábbi eszközeiben:

- EDS-G508E sorozat 6.0 és korábbi firmware-verziói;
- EDS-G512E Series: 6.0 és korábbi firmware-verziói;
- EDS-G516E Series: 6.0 és korábbi firmware-verziói.

A gyártó kiadta a hibát javító patch-et. A sérülékenység részleteiről az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-353-01

Sérülékenység Philips WAN routerekben

Daniel Yagudayev, a New York-i Presbiteriánus Kórház munkatársa egy sérülékenységet jelentett a Philips-nek, ami az alábbi WAN routereiket érinti:

- Veradius Unity (718132) vezeték nélküli funkciókkal rendelkező változatai (amiket 2016. és 2018. augusztus között szállítottak);
- Veradius Unity (718132) ViewForum funkcióval működő változatai (amiket 2016. és 2018. augusztus között szállítottak);
- Pulsera (718095) és Endura (718075) típusú eszközök vezeték nélküli funkciókkal rendelkező változatai (amiket 2017. június 26. és 2018. augusztus 7. között szállítottak);
- Pulsera (718095) és Endura (718075) típusú eszközök ViewForum funkcióval működő változatai (amiket 2017. június 26. és 2018. augusztus 7. között szállítottak).

A gyártó minden érintett ügyfelének azt javasolja, hogy vegyék fel velük a kapcsolatot a hiba megoldásáért. A sérülékenység részleteiről az ICS-CERT bejelentésében lehet olvasni: https://www.us-cert.gov/ics/advisories/icsma-19-353-01

Sérülékenységek WAGO berendezésekben

A Talos (a Cisco biztonsági laborja) saját blogján jelentette be, hogy számos sérülékenységet találtak a WAGO PFC200-as és PFC100-as automatizálási vezérlő berendezéseinek 03.00.39(12) verziójában és a hibák feltételezhetően kihasználhatóak a 03.01.07(13)-es firmware-verzió esetén is.

A hibák javításáról jelenleg nincs információ. A sérülékenységekkel kapcsolatos részletes információk a Talos weboldalán találhatóak: https://blog.talosintelligence.com/2019/12/vulnerability-spotlight-multiple.html

A fenti sérülékenységekkel kapcsolatban az ICS-CERT az alábbi kockázatcsökkentő intézkedések fontosságát hangsúlyozza:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- Az ipari/egészségügyi rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari/egészségügyi rendszerek/hálózatok távoli eléréséhez biztonságos módszereket (pl. VPN) kell használni, de szem előtt kell tartani azt is, hogy az egyes VPN-megoldásoknak is lehetnek sérülékenységeik és ezeket is folyamatosan frissíteni kell a legújabb elérhető verzióra. Nem szabad elfelejteni továbbá azt sem, hogy a VPN csak annyira biztonságos megoldás, mint az eszköz, amit a VPN-en keresztül a védett hálózathoz csatlakoztatnak;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgáltatások hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználó kezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (valamilyen szinten tűzálló páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Az Electrum/Sandworm/Quedagh csoport (az Electrum nevet a Dragos, a Sandworm nevet több más, APT csoportok támadásait elemző csoport használja, a Quedagh elnevezés kevésbé terjedt el, én az F-Secure-nál találkoztam vele) hátterével kapcsolatban nagyjából konszenzus van a különböző IT biztonsági cégek között, szinte mindenki azon a véleményen van, hogy ez a csoport az egyik legveszélyesebb orosz állami (egyes feltételezések szerint katonai titkosszolgálati) háttérrel rendelkező APT csoport.

Egyebek mellett ezt a csoportot gyanúsítják a 2015-ös (BlackEnergy) és a 2016-os (CrashOverride/Industroyer), ukrán villamosenergia-rendszer elleni kibertámadásokkal és ezt a csoportot tartják az ICS rendszerek elleni támadások területén az egyik legveszélyesebb támadónak is.

A Dragos elemzése szerint az Electrum/Sandworm/Quedagh csoportra nem jellemző az egyedi exploit-ok, 0. napi sérülékenységek használata, sokkal inkább elterjedt exploitokat, sérülékenységeket és technikákat használnak a célba vett szervezetek és rendszerek elleni támadásaik során.

A csoport az elemzések szerint jelenleg is aktív, de a korábbi, szinte kizárólagosan Ukrajna-fókuszú tevékenységük megváltozott, az ICS rendszerek iránti érdeklődésük azonban egyáltalán nem csökkent.

A csoporttal kapcsolatban több hosszabb-rövidebb elemzés is elérhető:

FireEye
Dragos
F-Secure

Reliable Controls License Manager sérülékenység

Gjoko Krstic, az Applied Risk munkatársa egy sérülékenységet talált a Reliable Controls RC-LicenseManager nevű termékének 3.5-ös verziójában.

A gyártó a hibát az RC Studio 3.6.3-as verziójában javította. A sérülékenységről további részleteket az ICS-CERT publikációjában lehet elérni: https://www.us-cert.gov/ics/advisories/icsa-19-337-01

Sérülékenységek Weidmüller ipari hálózati eszközökben

A CERT@VDE öt sérülékenységet azonosított a Weidmüller alábbi, ipari környezetekbe szánt hálózati eszközeiben:

- IE-SW-VL05M-5TX firmware v3.6.6 Build 16102415 és korábbi verziói;
- IE-SW-VL05MT-5TX firmware v3.6.6 Build 16102415 és korábbi verziói;
- IE-SW-VL05M-3TX-2SC firmware v3.6.6 Build 16102415 és korábbi verziói;
- IE-SW-VL05MT-3TX-2SC firmware v3.6.6 Build 16102415 és korábbi verziói;
- IE-SW-VL05M-3TX-2ST firmware v3.6.6 Build 16102415 és korábbi verziói;
- IE-SW-VL05MT-3TX-2ST firmware v3.6.6 Build 16102415 és korábbi verziói;
- IE-SW-VL08MT-8TX firmware v3.5.2 Build 16102415 és korábbi verziói;
- IE-SW-VL08MT-5TX-3SC firmware v3.5.2 Build 16102415 és korábbi verziói;
- IE-SW-VL08MT-5TX-1SC-2SCS firmware v3.5.2 Build 16102415 és korábbi verziói;
- IE-SW-VL08MT-6TX-2ST firmware v3.5.2 Build 16102415 és korábbi verziói;
- IE-SW-VL08MT-6TX-2SC firmware v3.5.2 Build 16102415 és korábbi verziói;
- IE-SW-VL08MT-6TX-2SCS firmware v3.5.2 Build 16102415 és korábbi verziói;
- IE-SW-PL08M-8TX firmware v3.3.8 Build 16102416 és korábbi verziói;
- IE-SW-PL08MT-8TX firmware v3.3.8 Build 16102416 és korábbi verziói;
- IE-SW-PL08M-6TX-2SC firmware v3.3.8 Build 16102416 és korábbi verziói;
- IE-SW-PL08MT-6TX-2SC firmware v3.3.8 Build 16102416 és korábbi verziói;
- IE-SW-PL08M-6TX-2ST firmware v3.3.8 Build 16102416 és korábbi verziói;
- IE-SW-PL08MT-6TX-2ST firmware v3.3.8 Build 16102416 és korábbi verziói;
- IE-SW-PL08M-6TX-2SCS firmware v3.3.8 Build 16102416 és korábbi verziói;
- IE-SW-PL08MT-6TX-2SCS firmware v3.3.8 Build 16102416 és korábbi verziói;
- IE-SW-PL10M-3GT-7TX firmware v3.3.16 Build 16102416 és korábbi verziói;
- IE-SW-PL10MT-3GT-7TX firmware v3.3.16 Build 16102416 és korábbi verziói;
- IE-SW-PL10M-1GT-2GS-7TX firmware v3.3.16 Build 16102416 és korábbi verziói;
- IE-SW-PL10MT-1GT-2GS-7TX firmware v3.3.16 Build 16102416 és korábbi verziói;
- IE-SW-PL16M-16TX firmware v3.4.2 Build 16102416 és korábbi verziói;
- IE-SW-PL16MT-16TX firmware v3.4.2 Build 16102416 és korábbi verziói;
- IE-SW-PL16M-14TX-2SC firmware v3.4.2 Build 16102416 és korábbi verziói;
- IE-SW-PL16MT-14TX-2SC firmware v3.4.2 Build 16102416 és korábbi verziói;
- IE-SW-PL16M-14TX-2ST firmware v3.4.2 Build 16102416 és korábbi verziói;
- IE-SW-PL16MT-14TX-2ST firmware v3.4.2 Build 16102416 és korábbi verziói;
- IE-SW-PL18M-2GC-16TX firmware v3.4.4 Build 16102416 és korábbi verziói;
- IE-SW-PL18MT-2GC-16TX firmware v3.4.4 Build 16102416 és korábbi verziói;
- IE-SW-PL18M-2GC14TX2SC firmware v3.4.4 Build 16102416 és korábbi verziói;
- IE-SW-PL18MT-2GC14TX2SC firmware v3.4.4 Build 16102416 és korábbi verziói;
- IE-SW-PL18M-2GC14TX2ST firmware v3.4.4 Build 16102416 és korábbi verziói;
- IE-SW-PL18MT-2GC14TX2ST firmware v3.4.4 Build 16102416 és korábbi verziói;
- IE-SW-PL18M-2GC14TX2SCS firmware v3.4.4 Build 16102416 és korábbi verziói;
- IE-SW-PL18MT-2GC14TX2SCS firmware v3.4.4 Build 16102416 és korábbi verziói;
- IE-SW-PL09M-5GC-4GT firmware v3.3.4 Build 16102416 és korábbi verziói;
- IE-SW-PL09MT-5GC-4GT firmware v3.3.4 Build 16102416 és korábbi verziói.

A gyártó elérhetővé tette a hibákat javító firmware verziókat. A sérülékenységekkel kapcsolatban bővebb információkat az ICS-CERT bejelentése tartalmaz: https://www.us-cert.gov/ics/advisories/icsa-19-339-02

Sentinel LDK sérülékenység

Ryan Wincey, a Blizzard Entertainment Red team munkatársa egy sérülékenységet jelentett a Thales-nek, ami a SafeNet Sentinel LDK License Manager 7.101-nél korábbi verzióit érinti (csak a Windows operációs rendszerre telepített változatokat).

A gyártó a hibát a Sentinel LDK License Manager 7.101-es és újabb verzióiban javította. A sérülékenység részleteiről az ICS-CERT weboldalán érhetőek el információk: https://www.us-cert.gov/ics/advisories/icsa-19-339-01

Sérülékenységek Siemens EN100 Ethernet modulokban

A Siemens ProductCERT publikációja szerint három sérülékenységet találtak az EN100 Ethernet modulok alábbi változataiban:

EN100 Ethernet module IEC 61850 protokollhoz - minden, 4.37-nél korábbi verzió érintett;
EN100 Ethernet module PROFINET IO protokollhoz - minden verzió érintett;
EN100 Ethernet module Modbus TCP protokollhoz - minden verzió érintett;
EN100 Ethernet module DNP3 protokollhoz - minden verzió érintett;
EN100 Ethernet module IEC104 protokollhoz - minden verzió érintett.

A gyártó jelenleg is dolgozik a hibák javításán és kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységekről bővebben a Siemens ProductCERT és az ICS-CERT publikációiban lehet olvasni.

Sérülékenységek a Siemens S7 CPU termékcsaládban

A Siemens bejelentése szerint Eli Biham, Sara Bitan, Aviad Carmel és Alon Dankner, a Haifa-i Műszaki Főiskola, Uriel Malin és Avishai Wool, a Tel-Aviv-i Egyetem Villamosmérnöki Karáról és Artem Zinenko, a Kaspersky munkatársa két sérülékenységről közöltek információkat a Siemens-szel, amik az S7 CPU termékcsalád alábbi tagjait érintik:

- SIMATIC ET200SP Open Controller CPU 1515SP PC minden verziója (a SIPLUS változatok is érintettek);
- SIMATIC ET200SP Open Controller CPU 1515SP PC2 minden verziója (a SIPLUS változatok is érintettek);
- SIMATIC S7 PLCSIM Advanced v3.0 és korábbi verziói;
- SIMATIC S7-1200 CPU család v4.4 és korábbi verziói;
- SIMATIC S7-1500 CPU család v2.8.1-es és korábbi verziói, beleértve az ET200-as CPU-kat és a SIPLUS változatokat is. A 1518-4 PN/DP 1518 MFP CPU-k (valamint ezek SIPLUS változatai) nem érintettek;
- SIMATIC S7-1500 szoftveres vezérlők minden változata.

A gyártó egyes érintett termékekhez már kiadta a hibákat javító új verziókat, a többi esetén pedig jelenleg is dolgozik a javításokon. A sérülékenységekről további információkat az ICS-CERT bejelentésében lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-344-06

Siemens XHQ termékek sérülékenységei

A Siemens ProductCERT által nyilvánosságra hozott információk szerint három sérülékenységet találtak az XHQ Operation Intelligence rendszerek v6.0.0.2-nél korábbi verzióiban.

A gyártó a hibákat a v6.0.0.2-es és későbbi verziókban javította. A sérülékenységek részleteit a Siemens ProductCERT és az ICS-CERT weboldalain lehet elérni.

Sérülékenységek Siemens RUGGEDCOM termékekben

A Siemens ProductCERT publikációja szerint két sérülékenységet azonosítottak a RUGGEDCOM termékcsalád alábbi tagjaiban:

- RMC8388 minden verziója;
- RSG2488 minden verziója;
- RSG920P minden verziója;
- RSG9xx R/C minden verziója;
- RSL910 minden verziója;
- RST2228 minden verziója.

A hibákkal kapcsolatban a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekről részletesebben a Siemens ProductCERT és az ICS-CERT publikációiban lehet olvasni.

Siemens SIMATIC termékek sérülékenysége

Eli Biham, Sara Bitan, Aviad Carmel és Alon Dankner, a Haifa-i Műszaki Főiskoláról illetve Uriel Malin és Avishai Wool a Tel-Aviv-i Egyetem Villamosmérnöki Karáról egy sérülékenységet találtak a Siemens SIMATIC termékcsaládjának alábbi tagjaiban:

- SIMATIC CP 1626 minden verziója;
- SIMATIC HMI Panel minden verziója (a SIPLUS változatok is);
- SIMATIC NET PC Software minden verziója
- SIMATIC STEP 7 (TIA Portal) minden, v16-nál korábbi verziói;
- SIMATIC WinCC (TIA Portal) minden, v16-nál korábbi verziói;
- SIMATIC WinCC OA v3.15 és korábbi verziói;
- SIMATIC WinCC OA v3.16 patch 12 és korbbi verziói;
- SIMATIC WinCC Runtime Advanced minden verziója;
- SIMATIC WinCC Runtime Professional minden verziója;
- TIM 1531 IRC minden verziója (a SIPLUS változatok is).

A hibát javító verziók egy részét a gyártó már publikálta, a többin jelenleg is dolgoznak. A sérülékenységgel kapcsolatos részletes információk a Siemens ProductCERT és az ICS-CERT weboldalain érhetőek el.

Siemens SiNVR 3 sérülékenységek

Raphaël Rigo, az Airbus Security Lab munkatársa 7 sérülékenységet fedezett fel a Siemens SiNVR videó menedzsment megoldásában:

- SiNVR 3 Central Control Server (CCS) minden verziója;
- SiNVR 3 Video Server minden verziója;

A gyártó a hibák jelentette kockázatok csökkentésére több intézekedés bevezetését javasolja, de a hibákat javító új verziókról jelenleg nincs hír. A sérülékenységekről részletesebben a Siemens ProductCERT és az ICS-CERT bejelentéseben lehet olvasni.

Sérülékenység Siemens SCALANCE eszközökben

A Siemens ProductCERT publikációja szerint egy sérülékenységet találtak, ami a SCALANCE termékek közül az alábbiakat érintik:

- SCALANCE W700 6.3-as és korábbi verziói;
- SCALANCE W1700 1.0 és korábbi verziói.

A gyártó a hibát javító frissítéseket már elérhetővé tette. A sérülékenységről bővebb információkat a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet elérni.

Sérülékenységek Siemens SPPA-T3000 rendszerekben

A Siemens ProductCERT bejelentése szerint ötvennél is több sérülékenységeket találtak az alábbi termékeikben:

- SPPA-T3000 Application Server minden verziója;
- SPPA-T3000 MS3000 Migration Server minden verziója;

A hibák egy részét a gyártó már javította a többivel kapcsolatban kockázatcsökkentő intézekedések alkalmazását javasolják. A sérülékenységek részleteit a Siemens ProductCERT oldalán lehet elérni: https://cert-portal.siemens.com/productcert/pdf/ssa-451445.pdf

Sérülékenységek Siemens SIMATIC CP és S7 CPU termékekben

A Siemens ProductCERT publikációja szerint az Inverse Path auditorai az Airbus ICT Industrial Security csoportjával együttműködve illetve Artem Zinenko, a Kaspersky Lab munkatársa két sérülékenységet találtak a Siemens alábbi termékeiben:

- SIMATIC CP 343-1 Advanced minden, V3.0.53-nál korábbi verziója (a SIPLUS NET változatok is);
- SIMATIC CP 443-1 Advanced minden, V3.2.17-nél korábbi verziója (a SIPLUS NET változatok is);
- SIMATIC S7-300 PN/DP CPU család minden verziója (a SIPLUS változatok is);
- SIMATIC S7-400 PN/DP CPU család minden verziója (a SIPLUS változatok is).

A gyártó a CP 343/443-as eszközökhöz kiadta a hibákat javító verziókat, a többi esetben kockázatcsökkentő intézekedések alkalmazására tettek javaslatot. A sérülékenységekről bővebben a Siemens ProductCERT weboldalán lehet olvansi: https://cert-portal.siemens.com/productcert/pdf/ssa-603476.pdf

Sérülékenység a Symantec Industrial Control System Protection végpontvédelmi rendszerében

A Symantec publikációja szerint egy sérülékenységet találtak az ipari rendszerekhez ajánlott végpontvédelmi megoldásának (Industrial Control System Protection) 6.1.1.123-nál korábbi verzióiban.

A gyártó a hibát a 6.1.1.123-as verzióban javította. A sérülékenységgel kapcsolatban részleteket a Symantec bejelentése tartalmaz: https://support.symantec.com/us/en/article.SYMSA1500.html

A sérülékenységek negatív hatásainak csökkentése érdekében az ICS-CERT az alábbi kockázatcsökkentő intézkedések bevezetését javasolja:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- Az ipari/egészségügyi rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari/egészségügyi rendszerek/hálózatok távoli eléréséhez biztonságos módszereket (pl. VPN) kell használni, de szem előtt kell tartani azt is, hogy az egyes VPN-megoldásoknak is lehetnek sérülékenységeik és ezeket is folyamatosan frissíteni kell a legújabb elérhető verzióra. Nem szabad elfelejteni továbbá azt sem, hogy a VPN csak annyira biztonságos megoldás, mint az eszköz, amit a VPN-en keresztül a védett hálózathoz csatlakoztatnak;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgáltatások hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználó kezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (valamilyen szinten tűzálló páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Laurence Pitt, a Juniper globális biztonsági stratégiáért felelős igazgatója egy egészen jó cikkben foglalta össze (az amerikai autógyártást példaként hozva), mi az az 5 intézkedés, amivel biztonságosabbá lehet tenni az IIoT rendszereket. A cikk főbb gondolatai (utánuk pedig az én hozzájuk fűzött kommentárjaim):

1. Gondolkodj előre! - Az IIoT egy nagyon nagymértékű technológiai váltás, célszerű jó előre és alaposan megtervezni, hogyan fog illeszkedni nem csak üzembiztonsági és folyamattervezési szempontból, hanem IT/ICS biztonsági szempontból is a meglévő rendszerekhez és folyamatokhoz.

Kiváló tanács, az ICS biztonság terén az elmúlt nagyjából egy évtizedben ugyanaz játszódik le, mint a vállalati IT rendszerek terén már többször: a technológiai újításokat (virtualizáció, IoT, stb.) a szervezetek, részben a marketing-gőzhenger hatására, hatalmas lelkesedéssel kezdték használni az új technológiákat, a biztonsági megfontolások teljes mellőzésével, majd 3-4-5 év (és időnként néhány nagyobb biztonsági incidens) után elkezdtek érdeklődni ezeknek a technológiáknak a szervezeti biztonsági szabályrendszerbe és kontroll-környezetbe illeszthetőségének a lehetőségeiről is - vagyis a biztonsági szakterületek, még ha korábban meg is fogalmazták a fenntartásaikat (ez sem mindig történt meg), azt jó darabig senki nem vette figyelembe, majd roham tempóban kell(ett) behozni a lemaradást. Nagyon hasznos lenne, ha az IIoT és az Ipar 4.0 kapcsán a biztonsági szempontok a tervezési fázistól szerves részét képeznék az új technológiák bevezetésének, ezzel is csökkentve a kockázatokat.

2. Tudd és értsd, hogy mid van és az mit csinál! - Tudni kell, milyen eszközök csatlakoznak a hálózathoz, ez elengedhetetlen egy egyenszilárd védelmi rendszer kialakításához. A legnagyobb, legfontosabb rendszertől a legkisebb eszközig mindennek tudni kell a helyét, érteni kell a szerepét és hogy pontosan mit is csinál, ez teszi majd lehetővé, hogy a lehető leggyorsabban fel lehessen ismerni a nem engedélyezett eszközök megjelenését a hálózatban, ez pedig javítja egy incidens esetén a felfedezés esélyeit, hogy minél előbb el tudjon indulni az incidenskezelési folyamat.

Szintén alapvető tanács, ami ráadásul az ICS rendszerek statikus természetéből adódóan nagyságrendekkel könnyebben megvalósítható (mégis sok helyen teljesen elhanyagolt) tevékenység, pedig enélkül hatékony IT/ICS biztonsági programot nem lehet működtetni, ha nincs egy pontos eszköz, szoftver és hálózati kapcsolat-leltár, akkor minden, ennél bonyolultabb biztonsági folyamat gyakorlatilag bizonytalan, ingatag alapra épül.

3. Tudd, hogy ki (vagy mi) rendelkezik hozzáférésekkel - Szigorú authentikációs és authorizációs folyamatot kell felépíteni és működtetni annak érdekében, hogy az ipari folyamatok vezérléséhez szükséges adatok integritását biztosítani lehessen és meg lehessen előzni az adatlopásokat. A felhasználónév-jelszó alapú authentikáció ma már ilyen helyeken nem elegendő, a több faktoros azonosítás különböző megoldásait (biometrikus, birtokáson alapuló) felhasználva kell megnehezíteni az illetéktelen hozzáféréseket. Ugyanígy fontos, hogy rendszeres jogosultság-felülvizsgálatokat végezzenek a szervezetek, hogy minél előbb fel lehessen fedezni a nem szükséges vagy nem engedélyezett hozzáférések létezését és meg lehessen szüntetni azokat.

A hozzáférés- és jogosultság-kezelés szintén egy nagyon fontos kérdés, ez az egyik olyan pont, ahol az IT/IT biztonság és az OT gyakran összeütközésbe kerül. Az IT vagy az IT biztonság (akik az esetek döntő többségében a jogosultság-kezelő rendszerekért felelnek) elsőre többnyire nem értik, hogy az OT rendszerek üzemeltetői miért tiltakoznak az igényelt és jóváhagyott jogosultságok ICS rendszerekben történő automatikus beállítása ellen, az OT mérnökök pedig nem értik, hogyan nem értik az IT/IT biztonsági területen dolgozó kollégáik, milyen súlyos következményei lehetnek egy hibásan beállított jogosultságnak. A megoldás (mint oly sokszor) ezúttal is a kompromisszum, célszerű az ICS rendszerek esetén a jogosultságok igénylését, engedélyezését és nyilvántartását a jogosultság-kezelő rendszerre bízni, a beállítást pedig az OT üzemeltetőkre, akik manuálisan elvégzik a szükséges beállításokat a saját üzemeltetési szabályaik alapján, majd a jogosultság-kezelő rendszerben visszaigazolják a beállítások elvégzését.

4. Kezdjük a határon! - Amióta az első ember védelmi megoldásokkal kezdett foglalkozni, tudjuk, hogy nem lehet mindent megvédeni, nem lehet mindenhol ugyanazt a szintű védelmet megvalósítani, nem képeznek kivételt ez alól az ICS és az IIoT eszközök és rendszerek sem. Ha a rendelkezésre álló erőforrásokat a leginkább hatékony módon akarjuk felhasználni, akkor az ICS rendszerek külső határainál célszerű elkezdeni a biztonsági szint emelését, ezzel máris nehezebbé téve a támadóknak, hogy hozzáférjenek a fontos rendszerekhez, eszközökhöz.

Egyértelmű, hogy egyikünk sem rendelkezik azokkal az erőforrásokkal, amiket szükségesnek tartana ahhoz, hogy kockázatvállalási kedvének megfelelő szintre tudja csökkenteni a rá bízott rendszerek fenyegetettségi szintjét (én sem vagyok kivétel), de nyilvánvaló módon legtöbbször még az indokoltnak látszó erőforrások sem állnak rendelkezésre. A legtöbbet azzal nyerhetünk, ha az ICS hálózatok határvédelmét és a legfontosabb eszközök host szintű védelmét megteremtjük (már amennyiben az adott eszköz esetén erre van lehetőség és performancia-tartalék és a rendszer válaszidejét sem befolyásolják a biztonsági eszközök/intézkedések negatívan). Ezt a pontot megvalósítani különösen nehéz lehet azért is, mert az IIoT megjelenése szinten egyetlen esetben sem jelenti azt, hogy egyben meg lehetne szabadulni a 10-15-20 éves berendezésektől és szoftverektől, vagyis szinte biztos, hogy egyszerre kell gondoskodni a minden biztonsági szempontból elavult és a legújabb, időként biztonsági szempontból még kiforratlan technológiák biztonságáról.

5. Kerüljük a gyakori hibákat! - A már elavult, de még velünk élő és a legújabb technológiák általában magukkal hozzák a saját menedzsment megoldásaikat is, azonban minél több ilyen megoldásunk van, annál nehezebb lesz átlátni, hogy mi is történik a rendszereinkben és felfedezni egy incidens jeleit. Többek között emiatt is lehet vonzó egy ernyő-menedzsment megoldás bevezetése, ezek azonban a legtöbb esetben azt igénylik, hogy kompromisszumokat kössünk az egyes rendszerek menedzsmentje során, ami aztán újabb kockázatokat hozhat be biztonsági szempontból.