Múlt héten kedden jelent meg a hír a CyberScoop weboldalán, hogy ransomware-támadás érte a tajvani állami energiavállalat, a CPC Corp. rendszereit. A CPC a tajvani olaj- és cseppfolyósított (LNG) gáz-szektor egyik nagoyn fontos szereplője.

A hírek szerint az incidens nem érintette a CPC ICS rendszereit.

Két nappal később, múlt héten csütörtökön jelent meg az első hír, ami szerint támadók bejutottak a Stadler (itthon is meglehetősen ismert - na nem az akasztói vállalkozó, hanem a svájci vasúti járműgyártó vállalat) rendszereibe és a közlemény szerint nagy mennyiségű adatot loptak el.

A jelenleg rendelkezésre álló információk alapján a támadók célja az adatlopás és zsarolás lehetett, egyelőre nincsenek olyan jelek, amik alapján feltételezhetnénk, hogy a Stadler termelésirányításban használt rendszerei vagy a különböző vonatokban és villamosokban használt vezérlőrendszereket érintette volna az incidens.

Az esetről mostanra több IT biztonsági portál is beszámolt.

Május 1-jén (a reakciókat figyelve némileg a szakmai közösséget is meglepő módon) a Fehéz Ház oldalán megjelent egy új elnöki rendelet, ami az USA villamosenergia-rendszerének biztonságával kapcsolatban tartalmaz rendelkezéseket.

Az elmúlt egy hétben még viszonylag kevés reakció jelent meg, de amikkel én találkoztam, azok pozitívként értékelik ezt az új fejleményt.

Az elnöki rendelet többek között megtiltja az USA villamosenergia-hálózatában a külföldi forrásból származó, nagyfeszültségű villamosenergia-berendezések (pl. transzformátorok, védelmek, RTU-k, stb., vagyis mindazoknak az ICS berendezéseknek, amiknek a biztonságáról beszélni szoktunk) beszerzését és üzemeltetését, amelyek esetében külföldi ország vagy állampolgár érdekeltséggel rendelkezik és ez az ügylet veszélyeztetné az USA nemzetbiztonsági érdekeit. Ha ezt a rendelkezést abból a szempontból nézzük, hogy az utóbbi években egyre nagyobb fenyegetést jelent a kritikus infrastruktúrák (köztük a villamosenergia-rendszert üzemeltető szervezetekre is, de nem csak rájuk nézve) a beszállítói láncok elleni kibertámadások, akkor még könnyebb megérteni, hogy miért fontos (és nagyon időszerű) ez az elnöki rendelet.

Várhatóan az elnöki rendelet nyomán megindul több régóta várt (és az ICS biztonsági közösség által régóta szorgalmazott) folyamat, mint például párbeszéd a szabályozók, az ellenőrzéseket végző hatóságok, a gyártók és az üzemeltetők között. Ugyancsak várható, hogy az elnöki rendelet változásokat fog eredményezni az USA villamosenergia-rendszerében működő cégek életét és működését szabályozó NERC CIP követelményrendszerben is.

A Fehér Ház weboldalán elérhető elnöki rendelet a következő hónapokban és években még számos fejleménynél lesz hivatkozási alap és én személy szerint úgy gondolom, hogy az USA ismét tett egy olyan lépést a helyes irányba, amit az európai országok előbb vagy utóbb valamilyen formában követni fognak. Csak remélni tudom, hogy a magyar jogalkotók és felügyeleti szervek minél előbb felismerik, hogy ez a helyes irány és a magyar környezet sajátosságait szem előtt tartva születik egy nagyon hasonló magyar jogszabály.

Kicsit több, mint egy hete hozta nyilvánosságra az izraeli kormány, hogy kibertámadás-sorozat érte az ország több viziközmű-vállalatát. Bár a hivatalos kommunikáció és az arra épülő első cikkek szerint a támadók nem fértek hozzá a folyamatirányító rendszerekhez, később új információk láttak napvilágot, ezek már arról szóltak, hogy a támadók alaposan ismerték a megtámadott cégek által használt PLC-ket és képesek voltak olyan változtatásokat végezni a PLC-ken, amik később érvényesnek bizonyultak, vagyis egészen pontos ismereteik voltak a kompromittált ICS eszközökkel kapcsolatban.

Az incidenssel kapcsolatban megjelent Radiflow blogposzt feltételezhető, hogy a támadókat valaki a helyszínen is segíthette, ami rögtön érthetőbbé teszi, hogyan juthattak a támadók ilyen mélyre a megtámadott viziközmű vállalat rendszereiben - még akkor is, ha az izraeli kormány első publikációjában arról is írnak, hogy a viziközmű cégeknek mielőbb gondoskodniuk kell az ICS rendszereik Internet-kapcsolatainak megszüntetéséről. Ez ugye nagyjából az első tanács bármilyen ICS kiberbiztonsági kérdés merül fel.

A Dragos által Parisite-nak nevezett csoport az elemzések szerint 2017 óta aktív és célpontjai közé egyaránt tartoznak Észak-amerikai, Közel-keleti, európai és ausztrál, különböző ipari területeken (légiközlekedés, olaj- és gázszektor, közműszektor) működő szervezetek.

A csoport eszköztárába elsősorban széles körben használt VPN-megoldások ismert sérülékenységei mellett különböző szabadon elérhető eszközökből (pl. Masscan, dsniff) áll.

A jelenleg rendelkezésre álló információk szerint a PARISITE csoport tevékenysége jelenleg nem célozza ICS rendszerek működésének megzavarását vagy ellehetetlenítését, sokkal inkább a Magnallium/APT33 neveken ismert csoport számára végez felderítési és hozzáférés-előkészítési feladatokat.

A Parisite-ról jelenleg egyedül a Dragos weboldalán lehet információkat találni.

Sérülékenység Inductive Automation rendszerekben

Sharon Brizinov és Mashav Sapir, a Claroty munkatársai egy sérülékenységet találtak az Inductive Automation Ignition 8 Gateway termékének 8.0.10-esnél korábbi verzióiban.

A gyártó a hibát a 8.0.10-es verzióban javította és kockázatcsökkentő intézkedések alkalmazását is javasolja. A sérülékenységről bővebb információk az ICS-CERT publikációjában találhatóak: https://www.us-cert.gov/ics/advisories/icsa-20-112-01

Sierra Wireless termékek sérülékenységei

Egy 2019-ben, Carl Hurd és Jared Rittle, a Cisco Talos laborjának munkatársai által felfedezett sérülékenységekről megjelent bejelentéshez adott ki frissítést az ICS-CERT. Az új információk alapján az érintett AirLink eszközök listája bővült az LS300, GX400, GX440 és ES440-es modellek összes, 4.4.9-esnél korábbi verziójával.

A bejelentés frissítése a hibát javító újabb verziókról is új információkat adott ki. A sérülékenységgel kapcsolatos új információk az ICS-CERT bejelentésében érhetőek el: https://www.us-cert.gov/ics/advisories/ICSA-19-122-03

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 Cisco Talos kutatói egy (általuk PoetRAT névre keresztelt), Python-alapú trójait terjesztő támadói csoportot azonosítottak. A PoetRAT a célba vett rendszerbe történő bejuttatása után egyebek mellett képes információkat kinyerni a kompromittált rendszerből, fájlokat tud le és feltölteni, módosításokat tud végezni a rendszerleíró adatbázisban és operációs rendszer parancsokat is ki tud adni.

A PoetRAT malware-t jellemzően Microsoft Word fájlokba rejtett dropperekkel terjesztik, ez év februárjában olyan, hamisított dokumentumokban is feltűnt, amik az indiai védelmi minisztérium egyik kutatás-fejlesztési cégének logóját viselték - ennek ellenére a Talos kutató nem találtak bizonyítékot arra, hogy a PoetRAT malware-rel indiai célpontok ellen is bevetették volna.

Ami az ICS rendszerek világát illeti, a Talos elemzői szerint a PoetRAT mögött álló támadók kifejezett érdeklődést tanúsítanak a villamosenergia-szektor egyes azeri (különösképpen a szélerőművi turbinák vezérlésben használt) ICS rendszerek iránt.

A PoetRAT-ról és a támadókról további részleteket a Talos elemzésében lehet olvasni.

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

A Schneider Electric bejelentése szerint Seok Min Lim és Johnny Pan, a Trustwave munkatársai egy sérülékenységet találtak az alábbi termékeikben:

- SoMachine Basic minden verziója;
- EcoStruxure Machine Expert – Basic minden verziója;
- Modicon M100 Logic Controller minden verziója;
- Modicon M200 Logic Controller minden verziója;
- Modicon M221 Logic Controller minden verziója.

A gyártó a hibát javító újabb szoftver és firmware-verziókat elérhetővé tette és további kockázatcsökkentő eljárásokra vonatkozó ajánlásokat is publikált. A sérülékenységgel kapcsolatban további információkat a Schneider Electric bejelentésében lehet találni.

Schneider Electric Modicon vezérlők, SoMachine és EcoStruxure rendszerek sérülékenységei

Rongkuan Ma, Shunkai Zhu és Peng Cheng, a Zhejiang-i Egyetemen működő 307Lab kutatói két sérülékenységet találtak a Schneider Electric alábbi termékeiben:

- EcoStruxure Machine Expert minden verziója;
- SoMachine, SoMachine Motion minden verziója;
- Modicon M218 Logic Controller minden verziója;
- Modicon M241 Logic Controller minden verziója;
- Modicon M251 Logic Controller minden verziója;
- Modicon M258 Logic Controller minden verziója.

A sérülékenységekkel kapcsolatos gyártói ajánlások és a sérülékenységek további részletei a Schneider Electric publikációjában olvashatóak.

Sérülékenység Schneider Electric Viejo termékekben

Yongjun Liu, az nsfocus munkatársa egy sérülékenységet talált a Schneider Electric Viejo termékcsaládjának alábbi tagjaiban:

- Vijeo Designer Basic V1.1 HotFix 15 és korábbi verziói;
- Vijeo Designer V6.9 SP9 és korábbi verziói.

A gyártó a hibát a Vijeo Designer Basic version V1.1 HotFix 16-ban már javította a Vijeo Designer esetén pedig a következő service pack-ben ígéri. A sérülékenységről bővebb információk a Schneider Electric weboldalán érhetőek el.

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

Egy meg nem nevezett biztonsági kutató 4 sérülékenységről közölt információkat a Schneider Electric-kel, amik az alábbi, régebbi kiadású Triconex rendszereket érintik:

Windows NT, Windows XP és Windows 7 operációs rendszereken futó TriStation 1131 v4.0.0-tól v4.9.0-ig tartó és v4.10.0 verziói;
Tricon v10.0, v10.1, v10.2.x és v10.3.x verziói;
Tricon Communications Module 4351, 4352, 4351A/B és 4352A/B modelljei.

A hibákat javító verziókat a gyártó publikációja szerint elérhetővé tették. A sérülékenységekről bővebb információkat a Schneider Electric bejelentésében lehet találni.

Rockwell Automation RSLinx Classic PLC-k sérülékenysége

Az Applied Risk munkatársai egy sérülékenységet találtak a Rockwell Automation RSLinx Classic PLC-k 4.11.00 és korábbi firmware-verzióiban.

A gyártó a hibát javító patch-et már elérhetővé tette ügyfelei számára. 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-100-01

Triangle MicroWorks SCADA Data Gateway sérülékenységek

Steven Seeley és Chris Anastasio, az Incite Team tagjai, valamint Tobias Scharnowski, Niklas Breitfeld és Ali Abbasi három sérülékenységet találtak a Triangle MicroWorks SCADA Data Gateway nevű termékén 2.41.0213-tól 4.0.122-ig terjedő verzióiban.

A gyártó a hibát a 4.0.123-as verzióban javította. A sérülékenység részleteit az ICS-CERT publikációjában lehet elolvasni: https://www.us-cert.gov/ics/advisories/icsa-20-105-03

Sérülékenység Triangle MicroWorks DNP3 Outstation forráskódjában

Steven Seeley és Chris Anastasio, az Incite Team tagjai egy sérülékenységet találtak a Triangle MicroWorks DNP3 Outstation .NET protokoll komponenseiben és ANSI C könyvtáraiban, ami az említett termékek 3.16.00-tól 3.25.01-ig terjedő verzióit érinti.

A gyártó a hibával kapcsolatban a 3.26-os verzióra történő frissítést javasolja. A sérülékenységgel kapcsolatban bővebb információk az ICS-CERT weboldalán találhatóak: https://www.us-cert.gov/ics/advisories/icsa-20-105-02

Eaton HMISoft sérülékenységek

Natnael Samson a ZDI-vel együttműködve két sérülékenységről hozott nyilvánosságra információkat, amik az Eaton HMISoft VU3 nevű termékének 3.00.23-as és korábbi verzióit érintik (a HMiVU verziók nem érintettek).

A hibákkal kapcsolatban csak kockázatcsökkentő intézkedésekre vonatkozó ajánlások érhetőek el. A sérülékenységekről részleteket az ICS-CERT publikációjában lehet találni: https://www.us-cert.gov/ics/advisories/icsa-20-105-01

Sérülékenység Siemens TIM3V-IE és 4R-IE termékcsaládokba tartozó eszközökben

A Siemens egy sérülékenységről publikált részleteket, amik a SIMATIC S7-300-as és S7-400-as eszközeik TIM kommunikációs moduljai közül az alábbiakban található meg:

- TIM 3V-IE (a SIPLUS NET változatok is) minden, v2.8-nál régebbi verziója;
- TIM 3V-IE Advanced (a SIPLUS NET változatok is) minden, v2.8-nál régebbi verziója;
- TIM 3V-IE DNP3 (a SIPLUS NET változatok is) minden, v3.3-nál régebbi verziója;
- TIM 4R-IE (a SIPLUS NET változatok is) minden, v2.8-nál régebbi verziója;
- TIM 4R-IE DNP3 (a SIPLUS NET változatok is) minden, v3.3-nál régebbi verziója.

A gyártó a hibát az érintett termékekhez kiadott legújabb frissítésekben javította. A sérülékenységgel kapcsolatban további részleteket a Siemens ProductCERT és az ICS-CERT bejelentései tartalmaznak.

Siemens rendszerek sérülékenysége

A Siemens ProductCERT egy sérülékenységről közölt információkat, ami az alábbi termékeiket érinti:

- KTK ATE530S minden verziója;
- SIDOOR ATD430W minden verziója;
- SIDOOR ATE530S COATED minden verziója;
- SIDOOR ATE531S minden verziója;
- SIMATIC ET200SP IM155-6 MF HF minden verziója;
- SIMATIC ET 200SP Open Controller CPU 1515SP PC (a SIPLUS változatok is) minden, 2.0-nál korábbi verziója;
- SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (a SIPLUS változatok is) minden, 2.0-nál korábbi verziója;
- SIMATIC ET200MP IM155-5 PN HF (a SIPLUS változatok is) 4.2 és későbbi verziói;
- SIMATIC ET200SP IM155-6 PN HA (a SIPLUS változatok is) minden verziója;
- SIMATIC ET200SP IM155-6 PN HF (a SIPLUS változatok is) 4.2 és későbbi verziói;
- SIMATIC ET200SP IM155-6 PN/2 HF (a SIPLUS változatok is) 4.2 és későbbi verziói;
- SIMATIC ET200SP IM155-6 PN/3 HF (a SIPLUS változatok is) 4.2 és későbbi verziói;
- SIMATIC MICRO-DRIVE PDC minden verziója;
- SIMATIC PN/PN Coupler (a SIPLUS NET változatok is) 4.2 és későbbi verziói;
- SIMATIC S7-1500 CPU család (beleértve az ET200 CPU-kat és a SIPLUS változatokat is) minden, 2.0-nál korábbi verziója;
- SIMATIC S7-1500 Software Controller minden, 2.0-nál korábbi verziója;
- SIMATIC S7-300 CPU család (beleértve az ET200 CPU-kat és a SIPLUS változatokat is) minden verziója;
- SIMATIC S7-400 PN/DP V7 és ez alatti CPU család (a SIPLUS változatok is) minden verziója;
- SIMATIC S7-410 CPU család (a SIPLUS változatok is) minden verziója;
- SIMATIC TDC CP51M1 minden verziója;
- SIMATIC TDC CPU555 minden verziója;
- SIMATIC WinAC RTX (F) 2010 minden verziója;
- SINAMICS S/G Control Unit w. PROFINET minden verziója.

A gyártó egyes érintett termékekhez már kiadta a hibát javító újabb verziókat. A sérülékenységről bővebben a Siemens ProductCERT és az ICS-CERT oldalain lehet olvasni.

Sérülékenység Siemens SCALANCE és SIMATIC rendszerekben

A Siemens ProductCERT publikációja szerint egy eddig ismeretlen sérülékenységet azonosítottak a Siemens VxWorks-alapú SCALANCE és SIMATIC termékcsaládjainak alábbi tagjaiban:

- SCALANCE X-200 switch család (a SIPLUS NET változatok is) minden verziója;
- SCALANCE X-200IRT switch family (a SIPLUS NET változatok is) minden verziója;
- SCALANCE X-300 switch family (beleértve az X408 és a SIPLUS NET változatokat) minden verziója.
- SIMATIC CP 443-1 (a SIPLUS NET változatok is) minden verziója;
- SIMATIC CP 443-1 Advanced (a SIPLUS NET változatok is) minden verziója;
- SIMATIC RF180C minden verziója;
- SIMATIC RF182C minden verziója.

A gyártó mostanáig sem javítást, sem kockázatcsökkentő intézkedésekre vonatkozó javaslatokat nem adott ki a hibával kapcsolatosan. A sérülékenység részleteit a Siemens ProductCERT és az ICS-CERT publikációiban lehet megtalálni

Siemens ipari rendszerek sérülékenységei

A Siemens két sérülékenységről osztott meg információkat, amelyek számos, ipari környezetekben szánt megoldását érintik:

- IE/PB-Link v3 minden verziója;
- RUGGEDCOM RM1224 minden, 6.1-nél korábbi verziója;
- RUGGEDCOM ROX II minden, 2.13.3-nál korábbi verziója;
- SCALANCE M-800 család minden, 6.1-nél korábbi verziója;
- SCALANCE S615 minden, 6.1-nél korábbi verziója;
- SCALANCE SC-600 minden, 2.0-nál korábbi verziója;
- SCALANCE W1700 IEEE 802.11ac minden, 2.0-nál korábbi verziója;
- SCALANCE W700 IEEE 802.11a/b/g/n minden, 6.4-nél korábbi verziója;
- SIMATIC CP 1242-7 minden, 3.2-nél korábbi verziója;
- SIMATIC CP 1243-1 (beleértve a SIPLUS NET változatokat is) minden, 3.2-nél korábbi verziója;
- SIMATIC CP 1243-7 LTE EU minden, 3.2-nél korábbi verziója;
- SIMATIC CP 2243-7 LTE US minden, 3.2-nél korábbi verziója;
- SIMATIC CP 1243-8 IRC minden, 3.2-nél korábbi verziója;
- SIMATIC CP 1542SP-1 minden, 2.1-nél korábbi verziója;
- SIMATIC CP 1542SP-1 IRC (beleértve a SIPLUS NET változatokat is) minden, 2.1-nél korábbi változata;
- SIMATIC CP 1543-1 (beleértve a SIPLUS NET változatokat is) minden, 2.2-nél korábbi változata;
- SIMATIC CP 1543SP-1 (beleértve a SIPLUS NET változatokat is) minden, 2.1-nél korábbi változata;
- SIMATIC RF185C minden verziója;
- SIMATIC RF186C minden verziója;
- SIMATIC RF186CI minden verziója;
- SIMATIC RF188C minden verziója;
- SIMATIC RF188CI minden verziója;
- SINEMA Remote Connect Server minden, 1.1 és 2.0.1 közötti verziója.

A gyártó a hibákat az érintett termékekhez kiadott legújabb verziókban javította. A sérülékenységekkel kapcsolatban további részleteket a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet olvasni.

Sérülékenységek Siemens Climatix rendszerekben

Ezequiel Fernandez, a Dreamlab Technologies munkatársa két sérülékenységet jelentett a Siemens ProductCERT-nek, amik az alábbi Siemens rendszereket érintik:

- Climatix POL908 (BACnet/IP module) minden verziója;
- Climatix POL909 (AWM module) minden verziója.

A gyártó a hibákkal kapcsolatban kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységekről részleteket a Siemens ProductCERT és az ICS-CERT bejelentései tartalmaznak.

Siemens SIMATIC S7 V5 PN CPU-k sérülékenysége

A Siemens ProductCERT bejelentése szerint egy sérülékenységet taáltak a SIMATIC S7-400-as CPU-k alábbi változataiban:

- SIMATIC S7-400 CPU 414-3 PN/DP (6ES7414-3EM05-0AB0) minden verziója;
- SIMATIC S7-400 CPU 416-3 PN/DP (6ES7416-3ER05-0AB0, beleértve a SIPLUS változatokat is) minden verziója;
- SIMATIC S7-400 CPU 416F-3 PN/DP (6ES7416-3FR05-0AB0) minden 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 bővebben a Siemens ProductCERT weboldalán lehet olvasni.

Sérülékenység SIMATIC S7-400 V6 PN CPU-kban

A Siemens ProductCERT az ICS-CERT-tel és a Kasperky Labs-nál dolgozó Artem Zinenko-val együttműködve egy sérülékenységről publikált információkat, ami az alábbi termékeit érinti:

- SIMATIC S7-400 CPU 412-2 PN (6ES7412-2EK06-0AB0, beleértve a SIPLUS változatokat is) minden, V6.0.3-nál korábbi változat;
- SIMATIC S7-400 CPU 414-3 PN/DP and CPU414F-3 PN/DP (6ES7414-3EM06-0AB0 és 6ES7414-3FM06-0AB0, beleértve a SIPLUS változatokat is) minden, V6.0.3-nál korábbi változat;
- SIMATIC S7-400 CPU 416-3 PN/DP és CPU 416F-3 PN (6ES7416-3ES06-0AB0 és 6ES7416-3FS06-0AB0, beleértve a SIPLUS változatokat is) minden, V6.0.3-nál korábbi változat.

A gyártó a hibát a legújabb verzióban javította. A sérülékenység részleteiről a Siemens ProductCERT bejelentéséből lehet tájékozódni.

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.

Az ICS kiberbiztonság egyik legrégebbi akadályát a különböző ICS rendszerek és berendezések végtelenül behatárolt performancia-tartalékai jelentik. Itt nem csak arra kell gondolni, hogy nem lehet mindazokat a klienseket telepíteni egy ICS rendszer elemeire, amiket a nagyvállalati IT rendszerek esetén már régen megszoktunk (végpontvédelmi megoldás, DLP, eszközgazdálkodási rendszerek és sok egyéb kliens) és amiknek a száma ma már akár tucatnyi is lehet egy-egy irodai, jellemzően Windows-alapú operációs rendszert futtató operációs rendszeren, de időnként olyan extrém esetek is megtörténnek, amikor egy adott ICS berendezésben felfedezett sérülékenységet nem azért nem javított a gyártó, mert nem akarta, hanem mert egyszerűen nem volt kapacitása az eszköznek (nem volt elég code space) a patch telepítéséhez! Hasonló helyzetet én személyesen is megéltem már, amikor egy gyártó az elavult és a fejlesztő által már nem támogatott webszerver problémájára azt a választ adta, hogy érti, mire gondolunk, de az eszközben használt processzor nem képes újabb generációs, akár valamilyen lightweight webszervert futtatni, a CPU cseréje pedig egy erősebb modellre csak CPU architektúra-váltással oldható meg, ami a berendezés teljes újratervezését és újraépítését is jelentené.

A másik oldalon viszont lassan már megszokottá válnak az ICS rendszerek és az ipari szervezetek elleni kibertámadásokról szóló hírek és mind gyakrabban merülnek fel azok a javaslatok, hogy az ICS rendszerek elmeire és az ICS célberendezésekre is kerüljenek telepítésre a nagyvállalati IT-ban már megszokottakhoz hasonló biztonsági megoldások.

Az Ipar 4.0 és az IIoT térnyerésével a fenti kihívások mind jobban fogják követelni a különböző ipari szervezetek döntéshozóinak figyelmét. Az én véleményem szerint a gyártóknak (közösen az ICS rendszerek és berendezések felhasználóival) minél gyorsabban fel kell ismerniük, hogy az új rendszerek és berendezések tervezésénél már a különböző biztonsági funkciókat (patch-elés, végpontvédelmi megoldások, stb.) és azok performancia-igényét is bele kell tervezniük az eszközök teljesítmény-igényeibe. Előbb vagy utóbb (én nagyon remélem, hogy minél előbb), az ICS rendszereket és eszközöket üzletkritikus folyamataikban használó vállalatok fel fogják ismerni, hogy a nagyvállalati IT rendszerek biztonságával kapcsolatban már másfél-két évtizede csiszolgatott szabályzataiknak és eljárásaiknak ki kell alakítani az OT-re vonatkozó párjait (figyelembe véve az OT rendszerek sajátosságait) és akkor nagyon gyorsan meg fog jelenni az igény olyan ICS rendszerekre és berendezésekre, amik képesek a jelenlegi üzembiztonsági követelményeknek megfelelni úgy, hogy közben már egyes biztonsági megoldások és funkciók is zavartalanul működnek rajtuk (nem tartom lehetetlennek, hogy akkor már kizárólag ilyen működés lesz elfogadható az új idők új követelményeit felismerő és elfogadó szervezetek számára).

Tavaly év végén írtam egy posztot arról a Tripwire cikkről, amiben 12 biztonsági szakértő vázolta, hogy milyennek látják az ICS biztonság jövőjét 5-10 éves időtávon. Ezekben a válaszokban az egyik várakozás az volt, hogy az ICS rendszerek egyre több ponton fognak kapcsolódni felhős alkalmazásokhoz, például az ipari folyamatirányítással kapcsolatos adatok felhős alkalmazásokkal történő feldolgozása során.

A poszthoz több hozzászólás is érkezett, egyrészt nem tagadva ezt a tendenciát, másrészt viszont erősen helytelenítve az ICS rendszereké és a felhős megoldások egyre szorosabb kapcsolatát.

Először is röviden érdemes átnézni, hogy mire is gondolunk, amikor felhőről beszélünk (ezt csak nagyon röviden, mert ez a téma nem igazán vág a blog profiljába).

Egyrészt vannak publikus, privát és hibrid felhők. Publikus felhőszolgáltató többek között a Microsoft, a Google vagy az Amazon, akik erőforrásokat bocsátanak az ügyfeleik rendelkezésére, privát felhőt pedig gyakorlatilag bármilyen megfelelő infrastruktúrával rendelkező vállalat építhet magának a saját belső hálózatát vagy akár az Internetet felhasználva ehhez - jellemzően ezt azért világszinten is jelentős multinacionális vállalatok szokták megtenni. A hibrid felhő a két előző megoldásnak valamilyen keveréke.

Másrészt ma már szinte bármivel kapcsolatban találhatunk "as-a-Service"-ként hivatkozott, felhős megoldást. A leginkább elterjedtebbek mindmáig az infrastruktúra, mint szolgáltatás (IaaS, Infrastructure-as-a-Service), a platform (Paas, Platform-as-a-Service) és a szoftver (SaaS, Software-as-a-Service), de gyakorlatilag tényleg bármi lehet felhős szolgáltatás, nemrég láttam már Recovery-as-a-Service vagy Identity-as-a-Service szolgáltatásokat is (a Wikipedián a poszt írásának pillanatában 56 különböző szolgáltatást sorolnak fel az Analytics-as-a-Service-től a Unified Communications-as-a-Service).

Én kb. 10 éve gondolom úgy, hogy az ipari szervezetek esetében sem ördögtől való gondolat a felhős alkalmazások használata, de előbb minden esetben alapos kockázatelemzést tartok fontosnak. Azokban az esetekben, amikor a felhőben tárolni szándékozott adatok esetében a bizalmasság nem szempont (vagy egyenesen nem értelmezhető, például jogszabályi kötelezettség miatt publikált adatok esetén), a felhő komolyabb kockázatok nélkül biztosíthat olyan rendelkezésre állást, amit az adott szervezet csak magasabb ráfordítások mellett tudna elérni.

Nyilván vannak olyan adatok, amiket nem vagy csak jelentősen komolyabb biztonsági kontrollok mellett lehet, szabad vagy érdemes a felhőben tárolni vagy feldolgozni, de már talán az előző példa is megmutatja, mennyire bonyolult lehet a kérdés.

Külön kell kezelni azokat az eseteket, amikor egy adott gyártó már nem igazán ad lehetőséget nem-felhős megoldás használatára. A legjobb példának a Microsoft Key Management Service (KMS) rendszerét ma már nem lehet felhő nélkül használni. Ha pedig belegondolunk, hogy a Microsoft Windows operációs rendszer-családja mennyire elterjedt bizonyos ICS gyártók termékeinél, rögtön láthatjuk, hogy vannak és lesznek olyan ICS rendszerek, ahol nem igazán lesz kérdés a jövőben, hogy az adott rendszernek lesz-e (akár csak közvetetten is) köze felhős megoldásokhoz.

Azoknak, akik egy ideje már olvassák a blogot, nem lehet túl meglepő, hogy én személy szerint nem vagyok híve annak, hogy az ICS rendszereket Internet-kapcsolattal lássuk el és ebből egyenesen következik, hogy az ICS rendszerek felhős kapcsolatait sem tartom kifejezetten jó ötletnek. Tekintettel azonban arra, hogy láthatóan nem lehet majd teljesen távol tartani a felhős megoldásokat az ICS rendszerek világától, mindenképp hasznosnak tartom beszélni a témáról, azon túl is, hogy miért nem tartjuk jó ötletnek a felhő és az ICS rendszerek kapcsolatát.

A hírek szerint ransomware-támadás érte a portugál központú, multinacionális energia-szolgáltató EDP csoport informatikai rendszereit. Az EDP csoport az egyik legnagyobb európai energia-szolgáltató cégcsoport, amely mind a gáz-, mind villamosenergia-szektorban jelen van és a világ negyedik legnagyobb szélenergia-termelő vállalata. Az EDP-nek 4 kontinensen, 19 országban vannak vállalatai, amik összesen több, mint 11.500 alkalmazottal 11 milliónál is több ügyfelet szolgálnak ki.

A támadók mintegy 10 millió Eurónak (vagy 11 millió amerikai dollárnak) megfelelő BitCoin-t követelnek és a legújabb ransomware-es trendeknek megfelelően azzal is fenyegetőznek, hogy az általuk letöltött, állításuk szerint 10 TB-nyi(!) adatot publikálják, ha az EDP nem fizet. A hírek egyelőre nem szólnak arról, hogy az EDP csoport adatain kívül a folyamatirányításban használt rendszereket vagy berendezéseket is érintette volna a támadás, azonban a RagnarLocker-t az EDP-re szabadító támadók által közzétett fájlok között található többek között egy edpradmin2.kdb nevű fájl is, ami a közkedvelt KeePass jelszókezelő alkalmazás által használt fájl lehet, ez pedig arra is utalhat, hogy a támadók akár az EDP rendszeradminisztrátorai által használt jelszavak egy részéhez is hozzáférhettek, aminek további súlyos következményei is lehetnek.