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.

Az IBM X-Force szakértői egy új, a célbavett számítógépeken tárolt adatok törlésére specializált malware támadásainak nyomait fedezték fel a Közel-Keleten. A ZeroCleare névre keresztelt malware az X-Force szerint elsősorban a régió energia szektorában működő illetve más ipari szervezeteket támadja, arról azonban egyelőre nincs hír, hogy az incidensek érintettek volna ICS rendszereket.

Az X-Force kutatói a malware elemzése alapján arra a következtetésre jutottak, hogy a mostani kártevő sok szempontból hasonlít a korábbi években megismert Shamoon malware-re, emiatt pedig azt feltételezik, hogy a ZeroCleare támadások mögött is Irán állhat. Ezt az elméletet erősíti a ZeroCleare által a fájlok törlésére használt EldoS RawDisk is, amit már a Shamoon-támadásoknál is használtak a malware fejlesztői.

Egyelőre sokkal több információ nem érhető el, az X-Force cikke a ZeroCleare malware-ről eddig publikált részletekkel az IBM SecurityIntelligence weboldalán, a teljes elemzés pedig itt található.

ABB Relion 670 sorozatú eszközök sérülékenysége

Kirill Nesterov, a Kaspersky Lab munkatársa egy sérülékenységet talált az ABB Relion 670 sorozatú eszközök alábbi verzióiban:

- Relion 670 sorozat 1p1r26 és korábbi verziói;
- Relion 670 sorozat 1.2.3.17 és korábbi verziói;
- Relion 670 sorozat 2.0.0.10 és korábbi (RES670 2.0.0.4 és korábbi) verziói;
- Relion 670 sorozat 2.1.0.1 és korábbi verziói.

A gyártó a hibát az érintett eszközök legújabb verzióiban javította. A sérülékenységről további részleteket az ICS-CERT bejelentésében lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-330-01

Sérülékenység ABB Relion berendezésekben

lya Karpov, Evgeniy Druzhinin és Victor Nikitin, a ScadaX munkatársai egy sérülékenységet azonosítottak az ABB alábbi termékeiben:

- Relion 650 sorozat 1.3.0.5 és korábbi verziói;
- Relion 670 sorozat 1.2.3.18 és korábbi verziói;
- Relion 670 sorozat 2.0.0.11 és korábbi verziói;
- Relion 670 sorozat 2.1.0.1 és korábbi verziói.

A gyártó a hibát a legújabb verziókban javította. A sérülékenységgel kapcsolatban részletesebb információkat az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-330-02

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

A gyártó által nyilvánosságra hozott információk szerint 10 sérülékenységet találtak az AWK-3121 sorozatú, ipari környezetekbe szánt hálózati eszközök 1.14-es és korábbi firmware-verzióiban.

A gyártó az érintett eszközök támogatását már megszüntete, így a sérülékenységekkel kapcsolatban csak kockázatcsökkentő intézkedések alkalmazására nyílik mód. A sérülékenységekről további részleteket a Moxa weboldalán lehet találni.

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 APT33 névre keresztelt támadói csoport (őket nevezi a Dragos Magnallium-nak) a 2012-es Shamoon (más néven Disttrack) malware támadásai óta ismert. A támadók elsősorban olajipari és repülőgép-gyártásban érdekelt vállalatokat vett célba, többnyire a Perzsa- (Arab-) Öbölben, Dél-Koreában és az USA-ban. Korábban voltak olyan elemzők, akik úgy gondolták, a Magnallium/APT33 csoport jelentős fenyegetést képvisel a kritikus infrastruktúrák ellen, de az elmúlt néhány évben tapasztalt tevékenységeik elemzése alapján a Dragos munkatársai szerint a csoport inkább információszerzésre koncentrál és feltételezhetően nincsenek kifejezetten ICS rendszerek ellen fejlesztett képességeik.

A Magnallium/APT33 csoport jellemzően célzott adathalász támadásokkal probál kezdeti hozzáférést szerezni a célba vett szervezetek informatikai rendszereihez, ezen felül előszeretettel használják a különböző biztonsági cégek által Stonedrill, Tunedup, Shapeshift, Dropshot, Nanocore és Netwire névre keresztelt malware-eket is.

Bár a csoport az utóbbi időben a támadások kezdeti szakaszában folytatott információszerzést végezte és a célba vett vállalatok rendszereihez próbálnak tartósan hozzáféréseket szerezni, az elemzők szerint ezek lehetnek előkészítő lépések egy, az ICS rendszerek elleni későbbi támadáshoz is.

A Magnallium/APT33 csoportról a Dragos és a FireEye elemzéseiben lehet további részleteket találni.

Néhány héttel ezelőtt én is írtam arról, hogy iráni illetékesek szerint kibertámadás érte az iráni olajipar egyik legfontosabb létesítményét. Már abban a posztban is írtam arról, hogy indokolt egyre óvatosabban kezelni azokat a kijelentéseket, amik egy-egy ipari baleset vagy safety incidens után nagyon gyorsan kibertámadás neveznek meg vagy sejtetnek, mint kiváltó okot anélkül, hogy erre vonakozóan konkrét bizonyítékokat ismertetnének. Ezt erősítette meg Robert M. Lee október 20-án publikált posztja is (elérhető a Dragos weboldalán és Robert saját blogján is), amiben nem először ír arról, hogy bár az ipari szereplőket és ICS rendszereket támadó csoportok egyre agresszívebbek és egyre gyakrabban céljuk bizonyíthatóan a fizikai károkozás (elég csak a Trition/TriSIS malware-támadásra vagy a Industroyer/CrashOverride malware-ről nemrég publikált újabb elemzés következtetéseire gondolni), helytelennek tartja, hogy egy incidens után az első reakció az, hogy az illetékesek kibertámadásra hivatkoznak kiváltó okként. A konkrét esetről ma még csak annyit lehet tudni, hogy az olajfinomító egyik csatornájában, ahol a finomítás során keletkező hulladékanyagokat vezették el, tűz ütött ki.

Robert fontosnak tartja kiemelni, hogy a legtöbb ICS rendszereket üzemeltető szervezetnek (ide értve feltehetően az abadani olajfinomítót is) jelenleg nem állnak rendelkezésére azok a képességek és az a képzett és tapasztalt ICS biztonsági csapat, akikkel egy hasonló kategóriájú incidens esetén a fizikai következmények felszámolása során már egy alapos <<root-cause analysis>>-t tudjanak végrehajtani, amelynek során képesek alaposan átvizsgálni az érintett ICS rendszereket bármilyen, illegális vagy helytelen (hiszen nem szabad elfelejteni, a legtöbb ICS biztonsági incidens mind a mai napig nem ellenséges szándékú támadók, hanem jó szándékú és valamilyen legitim hozzáféréssel rendelkező ember tevékenységének a következménye) módosítás nyomait.

Ahhoz, hogy az ICS rendszerek és eszközök biztonsági szintjén javítani lehessen, korántsem elegendő a döntéshozók és a társadalom figyelmét ráirányítani a valóban létező problémára (arról nem is beszélve, hogy mennyire kontraproduktívnak tartom, hogy minden ICS rendszerrel kapcsolatos incidenst azonnal és gondolkodás nélkül kibertámadásra visszavezetni nagyjából annyira szolgálja az ipari szektorban működő szervezetek és a kritikus infrastruktúrák érdekeit, mint amennyire a mesebeli fiúnak érdemes volt rendszeresen farkast kiálltani), de mindenképp olyan intézkedéseket kell javasolni, amikkel jelentősen lehet javítani az ICS rendszerek biztonsági helyzetét. Néhány ilyen intézkedés lehet:

- Az ipari szektorban működő szervezetek kockázatainak felmérése és értékelése, a magasnak ítélt kockázatokra vonatkozóan kockázatcsökkentő intézkedések alkalmazása. Itt fontosnak tartom megemlíteni, hogy ma még az ipari szektorban sem sok helyen sikerült elmozdulni a fizikai eszközök és az adatok számszerűsített értékén alapuló kockázatelemzési megközelítéstől, pedig figyelembe véve, hogy az ICS rendszereket és berendezéseket használó szervezetek számára szinte kivétel nélkül az egyik legfontosabb érték az ICS rendszerekkel vezérelt folyamatok biztonságának (safety), megbízhatóságának és rendelkezésre állásának biztosítása, ezért úgy gondolom, hogy legalább is megfontolásra érdemes lehet egy másfajta, a fizikai folyamatokkal kapcsolatos elvárások irányából közelítő kockázatelemzési módszertan alkalmazása. Ezzel nyilván nem azt állítom, hogy az adatok nem fontosak, de mérlegelni kell, hogy egyes adatkörök fontossága hogyan viszonyul a felügyelt folyamatok különböző szempontok alapján értékelt fontosságához.

- ICS eszközleltár: A vállalati IT biztonság terén már igen régóta számos szabvány írja elő a napra kész eszközleltár vezetését. ICS környezetekben egy ilyen nyilvántartás kialakítása talán nehezebb lehet (hiszen fontos eszközök lehetnek távoli, akár személyzettel nem is rendelkező telephelyeken), azonban az ICS rendszerek már többször is említett statikussága ebben az esetben kifejezetten előnyt jelent.

- ICS rendszerek szeparálása publikus/külső hálózatoktól: Lassan már unalomig ismételt alapszabály, hogy ICS rendszerekhez ne engedjünk hozzáférést publikus hálózatokról (pl. Internet) vagy olyan külső hálózati zónákból, ami nem áll teljes mértékben az ellenőrzésünk alatt. Amennyiben nem lehet teljes mértékben elkülöníteni a külső hálózatokat az ICS rendszerektől (pl. mert külső szakértőknek is hozzáférést kell biztosítani a rendszer bizonyos részeihez, akkor használjuk a Purdue-modellt vagy annak valamelyik modernizált változatát.

- A rendszerek és kommunikációjuk átláthatóságának megteremtése: biztosítani kell azt, hogy az (ICS) kiberbiztonsággal foglalkozó szakemberek minél teljesebb képpel rendelkezzenek arról, mi is történik a hálózatokban és rendszerekben. Ennek leginkább hatékony módszere (a korábban már említett pontos és naprakész eszközleltáron túl) a folyamatos, 7/24-es hálózatbiztonsági monitoring tevékenység magas szintre fejlesztése.

Miközben ezt a posztot írtam, jöttek a hírek arról, hogy ransomware-támadás érte a Pemex nevű mexikói állami olajtársaságot. Bár a Pemex nem szolgált részletekkel (mindössze annyit közöltek, hogy az incidens nem érintette a termelésirányításért felelős rendszereiket), de egyes biztonsági kutatók nem megerősített hírei szerint az incidensért a DoppelPaymer ransomware a felelős. Egyes elemzések szerint a DoppelPaymer mögött ugyanaz a támadói csoport állhat, akik a Dridex és Locky ransomware-támadásokért is felelősek lehetnek.

Ahogy közeledünk az év végéhez, lassan megállapíthatjuk, hogy 2019 az ipari szervezetek (és az állami és önkormányzati szervek) elleni ransomware-támadások éve és nem sok jele van annak, hogy a helyzet 2020-ban javulna - valószínűleg inkább csak romlani fog. Azt hiszem éppen ideje mindenkinek feltenni magának a kérdést: fel vagyunk készülve hasonló incidensekre, mint amivel a Norsk Hydro-nak vagy a Johannesburg-i áramszolgáltatónak kellett megküzdenie?

Sérülékenység ABB rendszerekben

Rikard Bodforss, a Bodforss Consulting munkatársa (és a név alapján tulajdonosa) egy sérülékenységet fedezett fel az ABB alábbi rendszereiben:

- Power Generation Information Manager (PGIM) minden verziója;
- Plant Connect minden verziója.

A SecurityWeek cikke szerint a sérülékenységről a gyártó már 5 éve tudott, de nem javította azt és a jelek szerint már nem is fogja, mivel a Plant Connect gyártói támogatása már megszűnt és a PGIM életciklusa is a végéhez fog érni. A sérülékenység részleteiről az ICS-CERT publikációjában lehet bővebben olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-318-05

Omron CX-Supervisor sérülékenység

Michael DePlante a ZDI-vel együttműködve egy sérülékenységet talált az Omron CX-Supervisor 3.5 (12) és korábbi verzióiban.

A gyártó a hibát a 3.51 (9)-es verzióban javította. A sérülékenység részletei az ICS-CERT bejelentésében találhatóak: https://www.us-cert.gov/ics/advisories/icsa-19-318-04

Sérülékenység Siemens Desigo PX vezérlőkben

Gjoko “LiquidWorm” Krstic, a Zero Science Lab munkatársa egy sérülékenységet azonosított, ami az alábbi Siemens termékeket érinti:

- PXC00-E.D, PXC50-E.D, PXC100-E.D és PXC200-E.D Desigo PX vezérlők PXA40-W0, PXA40-W1 és PXA40-W2 web modullal működő példányai, amennyiben V6.00.320-nál korábbi firmware-verziót használnak;
- PXC00-U, PXC64-U és PXC128-U Desigo PX vezérlők, ha a PXA30-W0, PXA30-W1, PXA30-W2 web modult használják és a V6.00.320-nál korábbi firmware-verziót futtatják;
- PXC22.1-E.D, PXC36-E.D és PXC36.1-E.D modellek aktivált web szerver esetén, ha a a V6.00.320-nál korábbi firmware-verziót használják.

A gyártó a hibát a V6.00.320-as és újabb firmware-verziókban javította. A sérülékenységgel kapcsolatban további információkat a Siemens ProductCERT és az ICS-CERT publikációiban lehet olvasni.

Siemens S7-1200 CPU-k sérülékenysége

Ali Abbasi, a bochum-i Ruhr Egyetem munkatársa egy sérülékenységet talált a Siemens S7-1200-as eszközeiben, ami minden firmware-verziót érint.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységről bővebben a Siemens ProductCERT és az ICS-CERT weboldalain lehet olvasni.

Sérülékenység Siemens Nucleus rendszerekben

Az Armis Security munkatársai egy sérülékenységet jelentettek a Siemens-nek, ami az alábbi rendszereiket érinti:

- Nucleus NET minden verziója;
- Nucleus RTOS minden verziója;
- Nucleus ReadyStart ARM, MIPS és PPC processzorokhoz kiadott változatainak minden, v2017.02.2 “Nucleus 2017.02.02 Nucleus NET Patch” hibajavításnál korábbi verziója;
- Nucleus SafetyCert minden verziója;
- Nucleus Source Code minden verziója;
- VSTAR minden verziója.

A gyártó a Nucleus ReadyStart ARM, MIPS és PPC processzorokhoz adott ki javítást, a többi érintett termék esetében kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységgel kapcsolatban további részleteket a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet találni.

Philips Intellitech orvostechnikai eszközök sérülékenysége

A New York-i Presbiteriánus Kórház Medical Technology Solutions csoportja egy sérülékenységet fedezett fel a Philips alábbi rendszereiben:

- IntelliBridge EC40 Hub minden verziója;
- IntelliBridge EC80 Hub minden verziója.

A gyártó a hiba javítását 2020 harmadik negyedév végére ígéri. A sérülékenységről bővebben az ICS-CERT weboldalán lehet olvasni: https://www.us-cert.gov/ics/advisories/icsma-19-318-01

Sérülékenységek Flexera rendszerekben

Sergey Temnikov, a Kaspersky munkatársa 4 sérülékenységet talált a Flexera alábbi rendszereiben:

- FlexNet Publisher 2018 R3 és korábbi verziói.

A gyártó a hibákat a FlexNet Publisher 2018 R4 és újabb verzióiban javította. A sérülékenységekről további információkat az ICS-CERT publikációjában lehet elérni: https://www.us-cert.gov/ics/advisories/icsa-19-323-01

Sérülékenység Schneider Electric Andover Continuum vezérlőkben

Ken Pyle a DFDR Consulting munkatársa egy sérülékenységről közölt információkat a Schneider Electric-kel, ami az Andover Continuum termékcsalád alábbi vezérlőit érinti:

- 9680;
- 5740;
- 5720;
- bCX4040;
- bCX9640;
- 9900;
- 9940;
- 9924;
- 9702.

Az érintett termékek támogatását a gyártó már megszűntette, ezért a hibával kapcsolatban csak kockázatcsökkentő intézkedésekre vonatkozó javasolatokat adott ki. A sérülékenységről bővebb információkat a Schneider Electric weboldalán lehet találni.

Schneider Electric Modicon vezérlők sérülékenysége

A Schneider Electric bejelentése szerint egy sérülékenységet azonosítottak az alábbi termékeik minden verziójában:

- M340 BMX P34x CPU-k
- M340 kommunikációs modulok:
- BMX NOE 0100
- BMX NOE 0110
- BMX NOC 0401
- TSX P57x Premium CPU-k
- TSX ETY x103 Premium kommunikációs modulok:
- 140 CPU6x Quantum CPU-k
- Quantum kommunikációs modulok:
- 140 NOE 771x1
- 140 NOC 78x00
- 140 NOC 77101

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenység részleteit a Schneider Electric bejelentésében lehet megtalálni.

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.