KUKA Sim Pro sérülékenység

Federico Maggi, a Trend Micro munkatársa egy sérülékenységet talált a KUKA Sim Pro 3.1-es verziójában.

A gyártó a hibát a 3.1.2-es verzióban javította. 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-20-098-05

Sérülékenység Fuji Electric rendszerekben

A kimiya néven ismert biztonsági kutató a ZDI-vel együttműködve egy sérülékenységet fedezett fel a Fuji electric V-Server Lite minden, 4.0.9.0-nál korábbi verziójában.

A gyártó a hibát a 4.0.9.0 verzióban javította. A sérülékenységgel kapcsolatban bővebb információkat az ICS-CERT bejelentése tartalmaz: https://www.us-cert.gov/ics/advisories/icsa-20-098-04

HMS Networks rendszerek sérülékenysége

Ander Martínez, a Titanium Industrial Security munkatársa egy sérülékenységről osztott meg részleteket a spanyol INCIBE CERT-tel, ami az HMS Networks eWON termékcsaládjának alábbi tagjait érinti:

- eWON Flexy minden, 14.1s0-nál korábbi firmware-verziója;
- eWON Cosy 14.1s0-nál korábbi firmware-verziója.

A hibával kapcsolatban a gyártó a legújabb, 14.1s0 firmware-verzióra történő frissítését javasolja. A sérülékenységről bővebben az ICS-CERT weboldalán lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-20-098-03

Sérülékenység GE Digital rendszerekben

Sharon Brizinov, a Claroty munkatársa egy sérülékenységet jelentett a GE Digital-nak, ami a gyártó CIMPLICITY v10.0 és korábbi verzióit érinti.

A gyártó a hibát javító v11.0 verziót 2020. januárban adta ki. A sérülékenység részleteiről az ICS-CERT publikációjából lehet tájékozódni: https://www.us-cert.gov/ics/advisories/icsa-20-098-02

Advantech rendszerek sérülékenységei

rgod, a 9sg biztonsági csoport tagja 8 sérülékenységet azonosított az Advantech WebAccess/NMS 3.0.2-nél korábbi verzióiban.

A gyártó a hibákat a 3.0.2-es verzióban javította. A sérülékenység részleteit az ICS-CERT bejelentésében lehet megtalálni: https://www.us-cert.gov/ics/advisories/icsa-20-098-01

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.

Kevesen gondolnák, hogy a folyamatirányítás biztonsági kérdései olyan, az ICS rendszerekétől látszólag távoli világban is fel tudnak bukkanni, mint a tengerhajózásé. Pedig ha jól belegondolunk, nem kéne nagyon meglepőnek lennie, hogy a hatalmas teherszállító hajókat és turisták százait és ezreit a fedélzetükön szállító tengerjáró hajók csak úgy irányíthatóak egy maroknyi tengerésszel, hogy az irányításuk nagy mértékben automatizált. Ez viszont azt is jelenti, hogy a hajók automatizálási rendszerei minden valószínűség szerint kiberbiztonsági szempontból semmivel sincsenek jobb (vagy éppenséggel ami azt illeti, rosszabb) helyzetben, mint az átlagos ICS rendszerek. Persze nem jelenti azt, hogy a helyzet jó vagy megnyugtató lenne, éppen ellenkezőleg, erre nagyon jól rámutat, hogy az amerikai CISA (Cybersecurity and Infrastructure Security Agency) nemrég az amerikai parti őrség (US Coast Guard) ajánlásokat adott ki a hajózásban használt informatikai eszközök biztonságosabb használatával kapcsolatban.

Még 2019 tavaszán, a szingapúri Maritime Technology Conference nevű rendezvényen Itai Sela, a Szingapúri Kikötői Felügyelet vezetője előadásában azt részletezte, hogy a tengerhajózási cégek jelenleg is kibertámadások célpontjai és a szektor szereplőinek tisztában kell lenniük azzal, milyen fenyegetésekkel kell szembenézniük.

A konferencia kerekasztal beszélgetései és további előadásai során elhangzott, hogy bár a tengerhajózási cégek, leginkább pedig a tengeri árufuvarozással foglalkozó cégek tisztában vannak a kockázatokkal (ez szerintem már önmagában egy hatalmas eredmény - 7 éve foglalkozom az ICS kiberbiztonság kérdéseivel és én személy szerint még mindig azt tapasztalom, hogy nagyon sok szektorban nagyon sokan még mindig teljes értetlenséggel fogadják, hogy ezzel a témával foglalkozni kéne), azonban nagyon komoly kihívást jelent nekik, hogy pontosan mely pontokon és hogyan kéne hozzákezdeniük a kockázatok értékelésének és csökkentésének.

Szokás azt mondani, hogy a villamosenergia-rendszerek nélkül a civilizációnk rövid időn belül összeomlana, de legalábbis nagyon máshogy nézne ki, mint amit ma megszoktunk. Ezzel igen kevesen vitatkoznak. Azt már jóval kevesebben gondolják végig, hogy a tengeri áruszállítás felel az energiahordozók és legkülönbözőbb árucikkek célba juttatásáért, ezért egy, a tengerjáró hajók elleni nagyobb szabású kibertámadás-sorozat nem csak safety incidenseket okozna (természetesen azokra is számítani kellene és lehetne), hanem a világgazdaságra nézve is komoly veszélyeket jelenthetnek.

Sérülékenység a Becton, Dickinson and Company orvostechnikai rendszereiben

A Becton, Dickinson and Company (BD) egy sérülékenységet jelentett a DHS CISA-nak, ami az alábbi rendszereiket érinti:

- Pyxis MedStation ES System v1.6.1 verziója;
- Pyxis Anesthesia (PAS) ES System v1.6.1 verziója.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről további információkat az ICS-CERT publikációja tartalmaz: https://www.us-cert.gov/ics/advisories/icsma-20-091-01

Hirschmann Automation and Control rendszerek sérülékenysége

Sebastian Krause és Toralf Gimpel, a GAI NetConsult GmbH munkatársai egy sérülékenységet fedeztek fel a Hirschmann alábbi rendszereiben:

- Az alábbi, HiOS 07.0.02 és korábbi verziókat használó berendezések:
- SP, RSPE, RSPS, RSPL, MSP, EES, EES, EESX, GRS, OS, RED
- A HiSecOS 03.2.00 és korábbi verziókat használó EAGLE20/30 berendezések.

A gyártó a hibát a HiOS 07.0.03 és a HiSecOS 03.3.00 verziókban javította. A sérülékenységgel kapcsolatban részleteket az ICS-CERT bejelentésében lehet találni: https://www.us-cert.gov/ics/advisories/icsa-20-091-01

Sérülékenység Mitsubishi Electric MELSEC rendszerekben

Rongkuan Ma, Jie Meng és Peng Cheng egy sérülékenységet azonosítottak a Mitsubishi Electric MELSEC iQ-R, iQ-F, Q, L és F sorozatú programozható vezérlőinek minden verziójában.

A gyártó kockázatcsökkentő intézkedések bevezetését javasolja az érintett eszközeit használó ügyfeleinek. A sérülékenységről bővebben az ICS-CERT weboldalán lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-20-091-02

B&R Automation Studio sérülékenység

Yehuda Anikster és Amir Preminger, a Claroty munkatrásai három sérülékenységet találtak a B&R Automation Studio alábbi verzióiban:

- Automation Studio 4.0.x;
- Automation Studio 4.1.x;
- Automation Studio 4.2.x;
- Automation Studio 4.3.11SP-nél korábbi verziók;
- Automation Studio 4.4.9SP-nél korábbi verziók;
- Automation Studio 4.5.4SP-nél korábbi verziók;
- Automation Studio 4.6.3SP-nél korábbi verziók;
- Automation Studio 4.7.2-nél korábbi verziók;
- Automation Studio 4.8.1-nél korábbi verziók.

A gyártó a hibákkal kapcsolatban minél előbb a legfrissebb elérhető verzióra történő frissítést javasolja. A sérülékenységek részleteit az ICS-CERT publikációjában lehet megtalálni: https://www.us-cert.gov/ics/advisories/icsa-20-093-01

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.

A Kaspersky által nemrég publikált elemzés szerint egy, a Kaspersky által Milum-nak nevezett trójait használ egy ismeretlen APT-csoport Közel-keleti szervezetek, köztük ipari cégek elleni támadásokhoz.

A támadásokat és a trójait elemző szakértők szerint a malware-t nagyjából egy éve, 2019. márciusban készítették. Az elemzések szerint egyelőre nincs nyoma annak, hogy a Wildpressure-nek nevezett támadásoknak az információgyűjtésen kívül más célja is lenne.

Schneider Electric Modicon PLC-k sérülékenysége

Flavian Dola, az Airbus Security munkatársa egy sérülékenységet talált a Schneider Electric alábbi termékeiben:

- EcoStruxure Control Expert minden, 14.1 Hot Fix-nél korábbi verziója;
- Unity Pro minden verziója;
- Modicon M340 minden, V3.20-nál korábbi verziója;
- Modicon M580 minden, V3.10-nél korábbi verziója.

A gyártó a hibát javító hotfix-et elérhetővé tette a weboldalán. A sérülékenységről további információkat a Schneider Electric bejelentésében lehet találni.

Sérülékenységek VISAM rendszerekben

Gjoko Krstic, az Applied Risk munkatársa 5 sérülékenységet azonosított a VISAM Automation Base (VBASE) termékcsaládjának alábbi tagjaiban:

- VBASE Editor, Version 11.5.0.2
- VBASE Web-Remote Module

A gyártó egyelőre nem reagált a most felfedezett hibákra. A sérülékenységekkel kapcsolatban bővebben az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-20-084-01

Advantech WebAccess sérülékenység

Peter Cheng, az Elex CyberSecurity, Inc. munkatársa egy sérülékenységet jelentett a DHS CISA-nak, ami az Advantech WebAccess 8.4.2 és korábbi verzióit érinti.

A gyártó a hibát a 8.4.4-es 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-20-086-01

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.

Felmerülhet a kérdés, hogy hogyan kapcsolódhat össze az ICS rendszerek kiberbiztonsága a koronavírus járvánnyal a válasz pedig több részből áll össze.

Az első a tömegesen elrendelt otthoni-távoli munkavégzés/home office jelensége. Ahogy Magyarországon, úgy szerte Európában elég hirtelen döntöttek úgy állami és vállalati vezetők, hogy aki csak tudja, végezze otthonról, távolról a napi munkáját, ezzel is elősegítve, hogy minél kevesebb embernek kelljen az otthonából a munkahelyére majd vissza utaznia tömegközlekedéssel vagy más módokon, így csökkentve a lehetséges fertőzések számát. Ez a járvány terjedése szempontjából nyilván jó, de a legtöbb cég nem volt felkészülve arra, hogy a munkatársaik ilyen tömegben kezdjenek távolról dolgozni, ez számos szervezetnél (az államigazgatástól az üzleti szférán át a közüzemi szolgáltatókig) okozott igen komoly műszaki kihívásokat. A VPN kapcsolatokat termináló eszközök és a hálózatbiztonsági eszközök kapacitásproblémái valamint az elégtelen számú notebook is igen komoly átmeneti problémákat tudtak okozni, de a biztonságos VPN kapcsolatok sarokkövét jelentő többfaktoros authentikációt biztosító megoldások bővítése is kihívást jelentett nem egy szervezetnél, ahogyan a távoli munkavégzés feltételeit még ki nem alakító kollégák azonnali hozzáférési igényei is rohammunkára kényszerítették (és talán kényszerítik még mindig) az IT terület szakembereit. Mondhatnánk azt, hogy ez nem igazán baj, mert most legalább felzárkóznak a korszerű munkakörülmények témájában azok a szervezetek, akik ezt az elmúlt 10-15 évben bármilyen indokkal halogatták. Azonban a rohamtempóban végzett munka, a kollégák hozzáféréseinek mindenáron történő biztosítása gyanítom nem egy esetben okozta a normál IT biztonsági szabályok lazítását ("Csak működjön minél előbb, nem számít, hogyan oldjátok meg!"-jeligével), ami viszont rövidesen IT biztonsági incidensek formájában fizettethetik meg kapkodás árát. Az elmúlt napokban már elkezdtek érkezni az első hírek, amik támadási kísérletekről szólnak többek között a WHO (World Health Organization) munkatársai és rendszerei ellen. Ahogy azt már többször láttuk, az első ilyen, egy adott eseményhez vagy témához vagy módszerhez kapcsolódó támadások általában nem az ICS rendszereket üzemeltető és használó szervezetek ellen történnek, de a Stuxnet óta eltelt 10 évben az első támadások és az első, ICS rendszerek elleni támadások közötti idő nagymértékben csökkent, nem lenne meglepő tehát, ha a világméretű járvány vége előtt megjelenne egy valamilyen módon a koronavírushoz kapcsolódó kibertámadás, ami ipari szervezeteket vagy ICS rendszereket céloz.

A válasz második részét a blogon néhányszor már érintettem és a ICS sérülékenységek sorozatban is számos alkalommal hivatkoztam orvostechnikai folyamatvezérlő rendszerek sérülékenységeiről szóló bejelentéseket. Ma már a kórházakban használt egészségügyi berendezések egy jelentős része ugyanúgy számítógépek által vezérelt orvostechnikai eszköz, mint a termelésirányításban vagy a közműszektorban használt PLC-k és ezeknek az orvostechnikai eszközöknek a biztonsági helyzete semmivel sem jobb, mint az ipari környezetekben használt rendszereké, amikről már számtalanszor írtam. Bízzunk benne, hogy sem véletlenül, sem célzott módon nem történnek majd támadások azok ellen a TCP/IP-n kommunikáló orvostechnikai berendezések ellen, amelyek segítségével az orvosok éppen egy súlyos beteg életéért küzdenek.

A másik kérdés pedig az, hogy mit tehetnek az ICS rendszerek üzemeltetéséért és biztonságáért felelős szakemberek? A két héttel ezelőtt, magyarra fordítva már idézett mondás Robert M. Lee Dragos alapító/vezérigazgatótól nagyon tömörören foglalja össze a mostani teendőket: Fear less, do more! Maradjunk otthon amennyire csak tudunk, tegyük a dolgunkat tudásunk legjavát adva és védjük meg a ránk bizott rendszereket és hálózatokat, végső soron pedig azt a civilizációt, amit ismerünk és amiben élünk!

Moxa OnCell sérülékenységek

Sergey Temnikov, a Kaspersky Lab munkatársa két sérülékenységet jelentett a Moxa-nak, amik a OnCell Central Manager 2.4.1-nél régebbi verzióit érintik.

A gyártó a hibát a legújabb elérhető verzióban javította. A sérülékenység részleteiről a Moxa weboldalán lehet olvasni.

Sérülékenységek Delta Electronics rendszerekben

Natnael Samson és kimiya, a ZDI-vel együttműködve két sérülékenységről közöltek információkat a DHS CISA-val, amik a Delta Electronics CNCSoft ScreenEditor v1.00.96-os és korábbi verzióit érintik.

A gyártó a hibákat a CNCSoft v1.01.24-es verziójában javította. A sérülékenységekről további információkat az ICS-CERT publikációja tartalmaz: https://www.us-cert.gov/ics/advisories/icsa-20-077-01

Systech rendszerek sérülékenysége

Murat Aydemir, Biznet Bilisim A.S. kritikus infrastruktúrák behatolás-tesztelésére szakosodott munkatársa egy cross-site scripting sérülékenységet talált a Systech NDS-5000-es terminál szerverek 02D.30-as firmware-verziójában.

A gyártó a hibát a 02F firmware-verzióban javította. A sérülékenység részleteit az ICS-CERT bejelentésében lehet megtalálni: https://www.us-cert.gov/ics/advisories/icsa-20-079-01

Sérülékenység Insulet inzulin-menedzsment rendszerekben

A Thirdwayv Inc. egy sérülékenységről közölt információkat a DHS CISA-val, ami a Insulet inzulin-menedzsment rendszereinek alábbi sorozatait érinti:

- 19191-es és 40160-as termékazonosítóval rendelkező sorozatok;
- ZXP425 (10-Pack) és ZXR425 (10-Pack Canada) modellek.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységgel kapcsolatban bővebb információkat az ICS-CERT weboldalán lehet találni: https://www.us-cert.gov/ics/advisories/icsma-20-079-01

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.

A Stuxnet napvilágra kerülése óta eltelt közel egy évtizedben a különböző országok (jellemzően a hírszerző szolgálatok és/vagy a fegyveres erők) által támogatott APT-csoportok száma és képességei nagyságrendekkel növekedtek és ma már rutinszerűek a kritikus infrastruktúrák és azon belül is a villamosenergia-rendszert működtető szervezetek elleni kibertámadások. Bár az üzemzavarok és leállások minden iparágban, minden cég számára károsak (elég csak a Norsk Hydro elleni ransomware-támadás okozta károkra gondolni), a villamosenergia-rendszer elemei elleni támadásoknál nagyobb hatással egy sem járhat. Ráadásul ahogy az energiaszektor cégei egyre nagyobb számban használnak az ICS rendszerek mellett hagyományos IT és újabban IoT rendszereket is (főként a hatékonyság növelése és a kontinensnyi összekapcsolt villamosenergia-rendszerek és villamosenergia-piacok mindinkább időkritikus követelményeknek megfelelő üzemeltetése érdekében, úgy nő ezeknek a cégeknek és az ICS és IT rendszereiknek a kitettsége is.

Ezt a fajta kitettséget csökkenteni és egy, a villamosenergia-rendszer egyes részeinek zavartalan üzemeltetéséért felelős szervezetet hatékonyan megvédeni a kiberbiztonsági fenyegetésektől egyáltalán nem könnyű feladat. Egy-egy nagyobb méretű szervezet nap szinten is több tíz- vagy százezer fenyegetéssel kell, hogy megbírkózzanak, ami már önmagában is elég lehet arra, hogy folyamatosan túlterheljék a (különösen a mai magyar IT és IT biztonsági munkaerőpiaci helyzet mellett) nem túlzottan nagy létszámú IT biztonsági csoportokat. Ráadásul a villamosenergia-szektorban működő vállalatok IT biztonsági szakembereinek nem egy esetben a ma elképzelhető legkifinomultabb támadásokat kell felfedezniük és megbirkózniuk a támadók leleményességével.

Ez az a pont, ahol a fenyegetéselemzés segítségére lehet a mindig erőforrás szűkével küszködő szakembereknek, akik képesek lehetnek priorizálni a feladataikat és olyan tevékenységekre fordítani a véges idejüket és erőforrásaikat, amik a legnagyobb eséllyel segíthetnek megelőzni biztonsági incidenseket.

Néhány tevékenység, aminek bevezetésén minden érintett szervezetnek ajánlott elgondolkodnia:

- Sérülékenység-menedzsment: A villamosenergia-rendszer működésért felelős szervezetek egyenként is nagyon nagy és nagyon bonyolult rendszereket üzemeltetnek. Ahhoz, hogy ezt a feladatukat megfelelően tudják végezni, képesnek kell lenniük pontosan azonosítani és javítani a rendszerek legveszélyesebb sérülékenységeit. A fenyegetéselemzés képessé tudja tenni a szervezeteket arra, hogy az egyes sérülékenységek adott szervezetre gyakorolt kockázatnövelő hatása alapján priorizálja a hibajavítások telepítését.

- A biztonsági megoldások elhelyezésének kérdése: Bár Magyarországon még csak mostanában kezdi felismerni a szabályozó, hogy a közmű- és benne a villamosenergia-szektorra vonatkozóan is az eddigieknél jobb (és szigorúbb) szabályokat kell kidolgozni kiberbiztonsági témakörben is (hasonlóan ahhoz, ahogy a pénzügyi szektorra már legalább 15-20 éve megtörtént), az energiaszektor általános kiberbiztonsági helyzete sok szempontból nem vagy nem sokkal rosszabb, mint más szektoroké, de ez sem jelenti azt, hogy a villamosenergia-ipari cégek IT biztonsági eszközök végtelen tárházával rendelkeznének. A fenyegetéselemzés egy módszere lehet a cégek biztonsági programjai esetén az érettségi állapot értékelésének és alapját adhatják azoknak a döntéseknek, hogy a véges erőforrások telepítése esetén hol lehet a legnagyobb hatást elérni egy új eszköz vagy eljárás bevezetésével.

- Megelőző intézkedések: Az olyan, egy-egy közösség szempontjából elsődleges fontosságú közműszolgáltatás esetén, mint amilyen a villamosenergia-szolgáltatás, az incidensek megelőzését szolgáló intézkedések alapvető fontosságúak. Ezek az intézkedések általában a behatolás-teszteket (hálózatok, alkalmazások, weboldalak, hardverek és más eszközök tesztjeit) és más hasonló tevékenységeket jelentenek, amikkel azonban meglehetősen könnyű szem elől téveszteni az eredeti célt. Ennek a célnak a középpontban tartására is kiváló eszköz lehet a fenyegetéselemzés és segíthet azokra a rendszerekre és eszközökre fókuszálni az aktív védelmi intézkedéseket, amik a legnagyobb kockázatoknak vannak kitéve.

Sérülékenység Rockwell Automation Allen-Bradley berendezésekben

A Cisco Systems munkatársai egy sérülékenységet jelentettek a Rockwell Automation-nek, ami az Allen-Bradley Stratix 5950-es termékcsalád alábbi tagjait érinti:

- 1783-SAD4T0SBK9;
- 1783-SAD4T0SPK9;
- 1783-SAD2T2SBK9;
- 1783-SAD2T2SPK9.

A gyártó a hibával kapcsolatban az FRN v6.4.0 firmware telepítését és kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenység részleteit az ICS-CERT publikációjában lehet megtalálni: https://www.us-cert.gov/ics/advisories/icsa-20-072-03

ABB Asset Suite sérülékenység

Az ABB egy sérülékenységről közölt információkat a DHS CISA-val, ami az Asset Suite 9.6 és korábbi verzióit, kivéve a 9.4.2.6-os és 9.5.3.2-es verzióit érinti.

A gyártó a hibát a 9.6.1-es verzióban javította, a 9.4.2.6-os és 9.5.3.2-es verziók továbbra sem érintettek. 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-20-072-02

Sérülékenységek ABB eSOMS rendszerekben

Az ABB 13 sérülékenységet jelentett a DHS CISA-nak, amiket az eSOMS 6.02 és korábbi verzióiban találtak.

A gyártó a hibákat az eSOMS 6.0.3-as és 6.1-es verzióiban javította. A sérülékenységekkel kapcsolatban további információkat az ICS-CERT weboldalán lehet megtalálni: https://www.us-cert.gov/ics/advisories/icsa-20-072-01

Rockwell Automation termékek sérülékenységei

Ilya Karpov és Evgeny Druzhinin, a ScadaX Security független biztonsági csoport tagjai és Dmitry Sklyarov, a Positive Technologies munkatársa, valamint Rongkuan Ma, Xin Che és Peng Cheng, a 307 Lab munkatársai 4 sérülékenységet találtak az ABB alábbi termékeiben:

- MicroLogix 1400-as vezérlők
- B sorozatának v21.001 és korábbi verziói;
- A sorozatának minden verziója;
- MicroLogix 1100-as vezérők minden verziója;
- RSLogix 500-as szoftverek v12.001 és korábbi verziói.

A gyártó a MicroLogix 1400 B sorozatú eszközeihez és az RSLogix 500-hoz kiadta a hibákat javító újabb verziókat. A sérülékenységről további részleteket az ICS-CERT publikációja tartalmaz: https://www.us-cert.gov/ics/advisories/icsa-20-070-06

Sérülékenység Johnson Controls Metasys rendszerekben

Lukasz Rupala egy sérülékenységet fedezett fel a Johnson Controls Metasys termékcsalád alábbi verzióiban:

- Application and Data Server (ADS, ADS-Lite) 10.1 és korábbi verziói;
- Extended Application and Data Server (ADX) 10.1 és korábbi verziói;
- Open Data Server (ODS) 10.1 és korábbi verziói;
- Open Application Server (OAS) 10.1 és korábbi verziói;
- Network Automation Engine (csak a NAE55) 9.0.1, 9.0.2, 9.0.3, 9.0.5 és 9.0.6-os verziói;
- Network Integration Engine (NIE55/NIE59) 9.0.1, 9.0.2, 9.0.3, 9.0.5 és 9.0.6-os verziói;
- NAE85 and NIE85 10.1 és korábbi verziói;
- LonWorks Control Server (LCS) 10.1 és korábbi verziói;
- System Configuration Tool (SCT) 13.2 és korábbi verziói;
- Smoke Control Network Automation Engine (NAE55, UL 864 UUKL/ORD-C100-13 UUKLC 10. kiadás) 8.1-es verziója.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedésekre tesz javaslatot. A sérülékenységgel kapcsolatban bővebb információkat az ICS-CERT weboldalán lehet találni: https://www.us-cert.gov/ics/advisories/icsa-20-070-05

Kantech rendszerek sérülékenysége

Joachim Kerschbaumer egy sérülékenységet jelentett a Johnson Controls-nak, a Kantech anyavállalatának, ami a Kantech EntraPass alábbi változatait érinti:

- Corporate Edition v8.10-nél korábbi összes verziója;
- Global Edition v8.10-nél korábbi összes verziója.

A gyártó a hibát a v8.10-es verzióban javította, azoknak az ügyfeleinek pedig, akik valamilyen ok miatt nem tudnak frissíteni, kockázatcsökkentő intézkedéseket javasol. A sérülékenység részleteit az ICS-CERT bejelentésében lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-20-070-04

Schneider Electric IGSS sérülékenységek

A Schneider Electric publikációjában két sérülékenységről hozott nyilvánosságra információkat, amiket a ZDI jelenett nekik és amik az Interactive Graphical SCADA System (IGSS) nevű termékük 14-es és korábbi verziói közül azokat érinti, amelyekben használják az IGSSupdate szolgáltatást.

A gyártó a hibákat a 14.0.0.20009-es verzióban javította. A sérülékenységről további részleteket a Schneider Electric publikációjában lehet találni.

Sérülékenység Schneider Electric rendszerekben

A kínai IT biztonsági teszt központ (CNITSEC) egy sérülékenységet jelentett a Schneider Electricnek, ami az alábbi termékeiket érinti:

- A 140NOE771x1-es Quantum Ethernet Network modulok 7.0 és korábbi verziói;
- A 140CPU65xxxxx integrált Ethernet modullal rendelkező Quantum processzorok minden verziója;
- Az integrált Ethernet modullal rendelkező Premium processzorok minden verziója.

A gyártó a 140NOE771x1-es Quantum kontrollerekhez kiadta a hibát javító 7.1-es verziót. A további érintett típusok már elérték életciklusuk végét, így nem várható hozzájuk javítás. A sérülékenység részleteit a Schneider Electric weboldalán lehet elérni.

Schneider Electric ZigBee telepítőkészlet sérülékenység

Yongjun Liu, az nsfocus munkatársa egy sérülékenységet talált a Schneider Electric ZigBee telepítőkészletének 1.0.1-nél korábbi verzióiban.

A gyártó a hibát az 1.0.1-es verzióban javította. A sérülékenység részleteiről a Schneider Electric bejelentésében lehet olvasni.

Sérülékenységek Schneider Electric vezérlőkben

Niv Levy 3 sérülékenységet talált, amik a Schneider Electric Andover Continuum vezérlőinek minden verzióját érintik.

A gyártó a hibákhoz nem készít javítást, mivel az Andover Continuum termékcsalád támogatását már megszűntette, helyette az
EcoStruxure Building Operation termékre történő váltást javasolja. A sérülékenységekkel kapcsolatban további információkat a Schneider Electric publikációja tartalmaz.

Siemens Spectrum Power 5 sérülékenység

A Kudelski Security Pen-testing Team egy Cross-site Scripting sérülékenységet talált a Siemens Spectrum Power 5 SCADA rendszerének 5.50 HF02-nél korábbi verzióiban.

A hibával kapcsolatban a gyártó kockázatcsökkentő intézkedésre tett javaslatot. A sérülékenységről részleteket a Siemens ProductCERT és az ICS-CERT publikációiban lehet olvasni.

Sérülékenység Siemens rendszerekben

Peter Cheng, az Elex Cybersecurity munkatársa és a CNCERT/CC egy sérülékenységről közöltek információkat a Siemens-szel, ami a gyártó alábbi termékeit érinti:

- SIMATIC S7-300 CPU család (beleértve az ET200-as CPU-kat és a SIPLUS változatokat is) minden, 3.X.17-nél korábbi verziója;
- SINUMERIK 840D sl minden verziója.

A gyártó a hibát a SIMATIC S7-300 CPU család esetén a 3.X.17-es verzióban javította, a SINUMERIK 840D sl eszközök esetén nincs hír javításról. A sérülékenységgel kapcsolatban további részleteket a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet találni.

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

A Siemens 10 sérülékenységről közölt információkat a DHS CISA-val, amik a SiNVR 3 videómenedzsment megoldásuk alábbi elemeit érintik:

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

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

Sérülékenység Belden Hirschmann rendszerekben

Sebastian Krause és Toralf Gimpel, a GAI NetConsult GmbH munkatársai egy sérülékenységet találtak a Belden Hirschmann alábbi rendszereiben:

- HiOS RSP, RSPE, RSPS, RSPL, MSP, EES, EESX, GRS, OS, RED 07.0.02 és korábbi verziói;
- HiSecOS EAGLE20/30 03.2.00 és korábbi verziói.

A gyártó a hibát az érintett termékekhez kiadott újabb verzióban javította. A sérülékenység részleteit a Belden Hirschmann publikációja tartalmazza.

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.

Lassan már fel sem kapja a fejét az ember, ha ipari szervezetek elleni kibertámdásokról olvas. A héten két támadásról is jelentek meg hírek.

Az első incidensről az ENTSO-E (European Network of Transmission System Operators for Electricity, 35 ország 42 villamosipari átviteli rendszerirányítóját tömörítő szervezet) számolt be meglehetősen szűkszavú közleményében, amely szerint az ENTSO-E irodai hálózatának és rendszereinek semmilyen kapcsolata nincs a tagszervezet rendszerirányítók (Transmission System Operator, TSO) hálózataival.

A SecurityWeek cikkében három európai TSO (a norvég Statnett, a finn Fingrid és a svájci Swissgrid) közleményeit is idézi, amely szerint egyik TSO sem találta nyomát annak, hogy az ENTSO-E elleni támadás érintette volna a rendszereiket.

Az incidensről a Dragos blogján is megjelent egy bejegyzés, aminek első fele az ENTSO-E-t ért támadás kevés tudható részleteit ismerteti, a második felében pedig az USA Új-Mexikó államának New Mexico Public Regulation Commission (NMPRC) nevű szabályozó szerve elleni, valószínűsíthetően ransomware-támadásról ír. Egyelőre ebben az esetben is kevés információ áll rendelkezésre, nem lehet tudni sem arról, hogy milyen ransomware-ről lehet szó és az incidens kiterjedéséről sem. Az NMPRC szóvivője szerint semmilyen bizalmas információhoz nem fértek hozzá a támadók. Lévén az NMPRC számos közműcég, köztük erőművek és más ipari szervezetek hálózatairól tárol műszaki információkat, ezért értékes célpont lehet olyan támadók számára, akik támadásokat terveznek ezek ellen a szervezetek ellen.

A Dragos gyors elemzése szerint mindkét, a héten napvilágot látott incidens azt mutatja meg, hogy az ipari szervezetek elleni támadásokat végrehajtó csoportok egyre kifinomultabb módszereket alkalmaznak és egyre körültekintőbbek, így egyáltalán nem lehetetlen, hogy ezek a támadások csak a későbbi, közműcégek elleni támadások előkészítési fázisához tartozó információ-gyűjtő műveletek voltak.

A kérdés igazán az, hogy ilyen esetekben mit lehet, mit kell tenniük az illetékeseknek? Talán kicsit unalmas, hogy rendszeresen az USA-t hozom példának, de úgy gondolom, hogy az Atlanti-óceán túlpartján legalább tervekben és elképzelésekben több lépéssel előttünk járnak. A FERC (Federal Energy Regulatory Commission) által még 2018-ban kiadott 850-es rendelet (Order 850) alapján az USA villamosenergia-szektorának szereplői 2020. július 1-jétől kötelesek védeni minden, a kezelésükbe tartozó kritikus infrastruktúra-elemet a beszállítói láncon keresztül érkező támadástól is (erről az energycentral.com oldalon írnak). Végső soron (ismét csak) Robert M. Lee-t tudom idézni: "A támadások IT hálózatokat értek, szóval ne boruljunk ki, de az OT hálózatokban nem látjuk át megfelelő szinten, mi történik és agresszívebb proaktivitásra van szükség az ICS rendszereink védelme során. Más szóval, féljünk kevesebbet, tegyünk többet!"