Dale Peterson gondolatai és a kérdés magyar vetülete

Még tavaly év végén Dale Peterson írt egy rövidebb blogbejegyzést arról, hogy hogyan érdemes ICS (OT) biztonsági programot és csapatot építeni. Posztjában Dale, évtizedes ICS biztonsági tapasztalat alapján amellett teszi le voksát, hogy elsősorban az IT illetve az IT biztonság területéről érkező szakemberekre célszerű építeni, mert az ICS biztonsági programok és csapatok elsődleges prioritása, hogy csökkentsék egy sikeres támadás bekövetkezési valószínűségét és ezt leggyorsabban olyan IT biztonsági szakértőkkel lehet elérni, akiknek az OT megtanítja az ICS rendszerek és berendezések üzemeltetésének alapvető szempontjait és sajátosságait.

Dale második érve az, hogy egy általános IT biztonsági szakembert egy tapasztalt OT mérnökkel párba állítva és az alapvető OT prioritásokat megértetve nagyon gyorsan hatékony résztvevője lehet az ICS rendszerek és berendezések biztonságosabbá tételét célzó erőfeszítéseknek.

Fontos érv továbbá Dale posztjában, hogy egyre több folyamatvezérlési folyamat és eszköz használ egyre nagyobb mértékben IT megoldásokat, így számára egyre inkább tűnik úgy, hogy az IT-OT szembenállás már a múlté és az IT győzött, csak ezt sokan még nem ismerték fel. Az ipari folyamatvezérlést használó vállalatok felsővezetői egyre tisztábban látják, hogy az ICS biztonsággal kapcsolatban a kockázatelemzés az egyik leghatékonyabb eszköz és ezt a kockázatelemzést az informatikai illetve az információbiztonsági menedzserektől várják, ugyanúgy, mint bármelyik IT rendszer esetén.

Számomra az ilyen gondolatok olvasása mindig nagyon érdekes és többször próbáltam már párbeszédet kezdeményezni ebben a témában a hazai szakma képviselői között itt, a blogon. Most, hogy a tavalyi év végén elindult a SeConSys együttműködés (és amennyire tudom, a januári első workshopon még a blog egyik-másik posztja is előkerült), talán eljön végre az ideje, hogy egy ilyen beszélgetés is elinduljon. Minden esetre a kérdés adott: ki mit gondol, hogyan lehet egy ipari szervezet ICS biztonságát a leginkább hatékonyan fejleszteni?

PEPPERL+FUCHS WirelessHART átjárók sérülékenysége

Az ICS-CERT bejelentése szerint a PEPPERL+FUCHS egy sérülékenységet javított a WirelessHART protokollhoz ajánlott átjáróinak minden verziójában.

A gyártó a hibát az érintett eszközök WHA-GW-*-ETH 03.00.08-as és WHA-GW-*-ETH.EIP 02.00.01-es firmware-verzióiban javította. A sérülékenységről további információk az ICS-CERT bejelentésében találhatóak: https://ics-cert.us-cert.gov/advisories/ICSA-19-073-03

Sérülékenység Gemalto Sentinel UltraPro rendszerekben

A Venustech-hez tartozó ADLab munkatársai egy sérülékenységet azonosítottak a Sentinel UltraPro 1.3.0, 1.3.1 és 1.3.2-es verzióiban.

A gyártó a hibát a Sentinel UtraPro v1.3.3-as verzióban javította. A sérülékenységről bővebben az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-073-02

LCDS LAquis SCADA sérülékenység

Mat Powell a ZDI-vel együttműködve egy memóriakezelési hibát talált az LCDS LAquis SCADA SCADA 4.1.0.4150-es verziójában.

A gyártó a hibát a termék 4.3.1.71-es verziójában javította. A sérülékenységről részleteket az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-073-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.

Ma reggel érkeztek az első hírek arról, hogy a Norsk Hydro nevű, norvég központú alumíniumgyártó vállalat rendszereit támadás érte. Az első hírekből még nem lehetett tudni a támadás jellegét, azt viszont igen, hogy az ügyviteli rendszerek mellett a termelésirányításért felelős rendszerek egy részét is érintette az incidens, az első cikkek manuális vezérlésre történő átállásról szóltak.

Mostanra több részlet is nyilvánosságra került, ezek szerint a LockerGoga nevű zsarolóvírus okozta az incidenst, aminek következtében a Norsk Hydro leállította több alumínium-megmunkáló gyártósorát és izolálták a gyárak termelésirányítási rendszereit a vállalat ügyviteli hálózataitól.

Az esetről további részleteket a Reuters és a DarkReading oldalain lehet olvasni.

Szerk: Ahogy azt sejteni lehetett a szaksajtó igen komoly érdeklődéssel követi az eseményeket, cikkek a témában:

The Register

HelpNet Security

SecurityWeek

SecurityWeek2

SecurityAffairs

Recorded Future

SecurityWeek3

Bleeping Computer

Kaspersky

HelpNet Security2

Lassan már nekem is kezd gyanúsan soknak tűnni, hogy az utóbbi időben a TrendMicro munkatársai milyen sok, ICS biztonsággal kapcsolatos publikációt jelentetnek meg (eddig a nagy biztonsági gyártók közül a Kaspersky volt az éltanuló, de ugye őket az utóbbi időben a nyugati világban IT biztonsági illetve politikai döntéshozói nem igazán kedvelik).

A nemrég talált tanulmányukban a TrendMicro munkatársai a rádiótávirányítással működtetett ipari daruk (főként építkezéseken és összeszerelő üzemekben használt változatok) biztonságát vizsgálták. Megállapításaik szerint ezeknek a berendezéseknek a biztonsága jelenleg a távirányítható garázsajtók biztonsági szintjét sem érik el. Ráadásul, ahogy a TrendMicro egyik munkatársa a tanulmány megjelenése nyomán érdeklődő szaksajtó kérdésére elmondta, van olyan gyártó, akit egy ügyfele kifejezetten azzal a kéréssel keresett meg, hogy tegyék a daruk vezérlését teljesen automatizálttá és egyáltalán ne kelljen fizikai gombokat megnyomni a távirányításhoz, ehelyett számítógépek a teljes folyamatot, emberi beavatkozás nélkül tudják vezérelni. Bár ez a kérés egyértelműen illeszkedik az IIoT és az Ipar 4.0 tendenciákba, elég ijesztő belegondolni, hogy milyen következményei lehetnek, ha egy illetéktelen személy vagy csoport nem kellő körültekintéssel végez változtatásokat a távirányított berendezéseket vezérlő számítógépen - vagy éppen egy, a WannaCry-hoz vagy a NotPetya-hoz hasonló ransomware- vagy wiper-malware zavarja meg a távírányításért felelős számítógépet.

További problémaként jelzi a tanulmány, hogy a rádiótávirányításhoz használt készülékek és a daruk rádiófrekvenciás társítási folyamatába, az egyetlen ellenőrzési funkció arra szolgál, hogy el lehessen kerülni a protokoll-szintű interferenciákat és több eszköz tudjon párhuzamosan dolgozni az emberek életének és testi épségének veszélyeztetése nélkül.

Ahogy azt számos más ICS eszköznél már-már megszokottként említhetünk, az ipari daruk esetében is viszonylag könnyű lehet egy támadónak rögzíteni és később visszajátszani egy eredetileg legitim parancsot (replay-attack), illegális utasításokat kiadni (command injection), szolgáltatás-megtagadást (Denial-of-Service) előidézni vagy akár ártó szándékkal a berendezések teljes programját megváltoztatni.

A TrendMicro tanulmányát itt lehet megtalálni, a témáról Bruce Schneier is írt a blogján, ahol több érdekes hozzászólást is lehet olvasni.

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

A Rockwell Automation a Tenable-vel együttműködve egy kritikus besorolású puffer-túlcsordulás sérülékenységet találtak az RSLinx Classic PLC-k 4.10.00 és korábbi verzióiban.

A gyártó a hibát javító patch-et a v3.60, v3.70, v3.80, v3.81, v3.90, v4.00.01 és v4.10-es verziókhoz készítette el. A sérülékenységről bővebben az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-064-01

Sérülékenység Siemens SCALANCE X ipari switch-ekben

A Siemens ProductCERT bejelentése szerint egy sérülékenységet találtak a SCALANCE X ipari switch-ekben, ami a termékcsalád alábbi tagjait érinti:

- SCALANCE X-200 minden verziója;
- SCALANCE X-300 minden verziója;
- SCALANCE XP/XC/XF-200 minden, V4.1-nél korábbi verziója.

A gyártó az XP/XC/XF-200-as eszközök esetén a V4.1-es verzióba javította a hibát, az X-200-as és X-300-as eszközöknél kockázatcsökkentő intézkedésekre tett javaslatot. A sérülékenységről további információkat a Siemens ProductCERT 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.

Március 8-a óta Venezuela területének nagyjából 70%-án komoly áramszünetek vannak, emitt fennakadások vannak a tömegközlekedésben és egyes források szerint különböző kórházakban már legalább négyen haltak meg, szintén az áramszünetek következtében.

Venezuelai politikusok viszonylag gyorsan megvádolták az USA-t, hogy kibertámadást hajtottak végre a Venezuela Bolivár államában található Guri vízerőmű ellen, ami kb. az ország villamosenergia-ellátásának 70%-át adja. A hírt a LinkedIn-en több ICS biztonsági szakember is megosztotta (különböző forrásokból) és szinte rögtön megindult a vélemények áradata, részben tényként kezelve a venezuelai politikusok állítását, mások pedig nagyon határozottan foglaltak állást amellett, hogy az USA-nak semmilyen köze nincs, nem lehet az eseményekhez.

Egy biztos, egyelőre semmilyen bizonyíték nem támasztja alá sem a kibertámadás verzióját, sem azt a verziót (bár tény, hogy jóval valószínűbbnek látszik - számomra legalábbis), hogy az egyre nagyobb gazdasági nehézségekkel küzdő Venezuelában nem jut elég pénz, alkatrész és szakember az időszerű karbantartások elvégzésére, így akár egy "hétköznapi" üzemzavar is okozhat ekkor kiesést a villamosenergia-ellátásában.

Részletek az alábbi (és számos más) hírforrásokban:

- CNN

- BBC

- The Guardian

Fairuz Rafique, a Galactic Security munkatársa nemrég egy LinkedIn bejegyzésben írt arról, a grúziai Gudauri Ski Resort sífelvonóján még 2018 márciusban történt incidensről, amiben tizenketten sérültek meg. Bár a grúz illetékesek szerint a balesetet a sílift meghibásodása okozta, Fairuz szerint biztonsági kutatók ugyanazon a napon fedezték fel, hogy a sílift vezérlő rendszere elérhető volt az Internetről.

Az eset nyomán Joe Weiss ismét azt a (már 2015-ben is boncolt) témát járja körül, hogy az ICS rendszerek esetén van-e értelme különbséget tenni a szándékos (kibertámadás) és a nem szándékos (rendszerhiba, üzemeltetői hiba) ICS kiberbiztonsági incidensek között? Joe fontosabb észrevételei a téma kapcsán:

- Az NIST kiberbiztonsági szótára szerint "a kiberbiztonsági incidens olyan potenciális vagy ténylegesen bekövetkezett esemény, amely veszélyezteti az információs rendszer vagy az információs rendszer által feldolgozott, tárolt vagy továbbított információ bizalmas kezelését, integritását vagy elérhetőségét, vagy amely a biztonsági szabályok, eljárások megsértésének vagy közvetlen fenyegetésének minősül". Ebben a definícióban sehol nem szerepel a szándékos kitétel és ezen definíció alapján a fenti eset egyértelműen kiberbiztonsági incidensnek számít, hiszen a sílift rendelkezésre állása sérült (és akkor még nem is beszélünk a biztonsági - safety - tényező sérüléséről, hiszen emberek kerültek veszélybe és sérültek meg).

- Számos olyan esetről tudunk (az egyik még nevet is kapott, Stuxnet néven szoktuk emlegetni), amikor a szándékos és a véletlen ICS kiberbiztonsági incidenst csak az adott mérnök hozzáállása különböztette meg egymástól (az "A fenébe ezzel az egésszel!" és a "Hoppá..." pillanatok közötti különbség). Ráadásul egy jól felkészült támadó képes lehet a kibertámadása nyomán előálló üzemzavart egy ideig rendszerhibának álcázni - erre végképp tökéletes példa a Stuxnet.

- Az ICS rendszerekben, szemben az IT világával, a kiterjedt és alapos forensics vizsgálatoknak nincs meg a hagyománya és hiányzik a (kiberbiztonsági, főként forensics szempontból) megfelelően képzett OT mérnökök hada, akik képesek lennének az ICS rendszerek hosszabb ideig tartó leállása nélkül vizsgálni egy-egy incidens kiváltó okait. Az IT biztonsági incidensek esetén évek óta tudjuk, hogy az első támadás és a támadók felfedezése között akár 200-400 nap is eltelhet, ezért aztán, figyelembe véve az ICS kiberbiztonság igen korai érettségi állapotát, nem csoda, hogy az orosz hátterűnek tulajdonított, amerikai villamosenergia-rendszer elleni támadásokat 7 hónap utána fedezték fel, a 2015-ös ukrán áramszolgáltatók elleni támadás előtt a (szintén orosznak gyanított) támadók 9 hónapig rendelkeztek hozzáféréssel a kompromittált rendszerekhez - és akkor sem az adott cégek szakemberei fedezték fel a támadókat, hanem ők maguk mutatták meg magukat.

Joe záró gondolata, hogy alapvető fontosságú minden ICS biztonsági incidens alapos és minden részletre kiterjedő vizsgálatát elvégezni, még akkor is, ha "szinte biztos", hogy az adott üzemzavart nem kibertámadás okozta.

Már maga ez a cikk is érdekes gondolatokat vetett fel, de a SANS ICS Community-ben ennek nyomán elindult beszélgetés (csak regisztráció után olvasható!) még érdekesebb:

- Van, aki szerint igenis számít a különbség, mégpedig azért, ha meg akarjuk előzni egy incidens megismétlődését, akkor ismerni kell a kiváltó okát (root cause).

- Egy másik érv a biztosítási szektorból érkezik, akiket szintén nagyon érdekel egy adott incidens kiváltó oka.

Egy biztos, ezt a témát itthon eddig nem nagyon érintette senki. Szerintem itt lenne az ideje.

Sérülékenységek Moxa ipari switchekben

Ivan B, Sergey Fedonin és Vyacheslav Moskvin, a Positive Technologies munkatársai nem kevesebb, mint 10 sérülékenységet azonosítottak a Moxa alábbi, ipari környezetekbe szánt hálózati eszközeiben:

- IKS-G6824A sorozat 4.5 és korábbi verziói;
- EDS-405A sorozat 3.8 és korábbi verziói;
- EDS-408A sorozat 3.8 és korábbi verziói;
- EDS-510A sorozat 3.8 és korábbi verziói.

A gyártó a hibákat javító patch-eket már elérhetővé tette a weboldalán. A sérülékenységekről további információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-057-01

PSI GridConnect rendszerek sérülékenysége

M. Can Kurnaz egy Cross-site Scripting sérülékenységet talált a PSI GridConnect alábbi megoldásaiban:

- Telecontrol Gateway 3G 4.2.21, 5.0.27, 5.1.19, 6.0.16 és korábbi verziói;
- Telecontrol Gateway XS-MU 4.2.21, 5.0.27, 5.1.19, 6.0.16 és korábbi verziói;
- Telecontrol Gateway VM 4.2.21, 5.0.27, 5.1.19, 6.0.16 és korábbi verziói;
- Smart Telecontrol Unit TCG 5.0.27, 5.1.19, 6.0.16 és korábbi verziói;
- IEC104 Security Proxy 2.2.10 és korábbi verziói.

A gyártó a hibát az érintett szoftverek legújabb verzióiban javította. A sérülékenységgel kapcsolatban részleteket az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-059-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 Censys egy több, mint három éve létező kereső, ami a Shodan-hoz hasonlóan nem a webes tartalmakra keres kulcsszavak alapján, hanem az Internetre csatlakoztatott rendszerek és eszközök (így köztük különböző ICS eszközök) adataiban keres és képes akár ezeknek a rendszereknek és eszközöknek egyes konfigurációs adatait is hozzáférhetővé tenni.

A Censys a ZMap scannert használja, ami megjelenésekor azzal keltett nagy feltűnést, hogy a teljes publikus IPv4 címtartományt képes volt meglepően rövid idő alatt (egy napon belül) végigvizsgálni, így pedig lehetőséget ad arra, hogy a Censys-szel egy napi frissítettségű adatbázist lehessen létrehozni az Interneten elérhető rendszerekről és eszközökről.

A Censys ráadásul egyéni felhasználásra teljesen ingyenes (még a Shodan-nál szokásos évenkénti, black friday-hez kötött akciós, 5 dolláros egyszeri előfizetést sem kell kifizetni) és nagyon gyorsan nagyon részletes adatokat lehet gyűjteni egy adott ICS gyártó eszközeiről vagy egy adott szervezet Internetes jelenlétéről.

Mindezeket figyelembe véve megint csak azt tudom tanácsolni minden, ICS rendszerekkel/berendezésekkel foglalkozó kollégának: alaposan és kétszer vagy akár háromszor is fontolják meg, mielőtt bármilyen ICS eszközt publikus hálózatra csatlakoztatnak, ha pedig nincs más lehetőségük, rendszeresen vizsgálják meg, hogy az eszközeikről/rendszereikről a Shodan, a Censys és esetleges más, hasonló megoldások milyen információkat szolgáltatnak egy ügyesen kérdező embernek.

Pangea Communications rendszerek sérülékenysége

Ankit Anubhav, a NewSky Security munkatársa egy authentikáció megkerülést lehetővé tevő hibát fedezett fel a Pangea Communications Internet FAX ATA (Analóg-Telefon Adapter) berendezésének 3.1.8 és korábbi verzióiban.

A gyártó a hibát javító patch-et már elérhetővé tette az ügyfelei számára.

A sérülékenységről bővebben az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-045-01

Sérülékenység a gpsd nyílt forráskódú projektben

A GE Digital Cyber Security Services a GE-PSIRT együttműködve jelentett egy sérülékenységet az NCCIC-nek, ami a nyílt forráskódú GPS megoldás alábbi szoftverkomponenseit érinti:

- gpsd 2.9.0-től 3.17-ig terjedő verziói,
- microjson 1.0-tól 1.3-ig terjedő verziói.

A hibát a fejlesztők a gpsd 3.18-as és újabb, illetve a microjson 1.4 és újabb verzióiban javították. A sérülékenységről további információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-310-01

OSIsoft PI Vision sérülékenység

Az OSIsoft az alábbi, folyamatvirtualizációhoz használható megoldásaiban talált egy Cross-site Scripting sérülékenységet:

- PI Vision 2017,
- PI Vision 2017 R2.

A gyártó a hibát a PI Vision 2017 R2 SP1 verzióban javította. A sérülékenységgel kapcsolatoban részleteket az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-043-01

Sérülékenységek Intel szoftverekben

Az Intel Product Security Incident Response Team-je 11 különböző sérülékenységet azonosított és jelentett az NCCIC-nek, amik a gyártó Data Center Manager SDK 5.0.2-nél korábbi verzióit érintik.

Az Intel a sérülékenységeket a Data Center Manager SDK 5.0.2-es verziójában javította. A sérülékenységekkel kapcsolatban részletesebb információkat az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-050-01

Delta CNCSoft sérülékenység

Natnael Samson a ZDI-vel együttműködve egy sérülékenységet azonosított a Delta Industrial Automation CNCSoft ScreenEditor 1.00.84 és korábbi verzióiban.

A gyártó a hibát az 1.01.15-ös verzióban javította. A sérülékenységről részleteket az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-050-02

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

Egy névtelenségbe burkolózó biztonsági kutató a ZDI-vel együttműködve azonosított egy hibát a Horner Automation Cscape szoftverének 9.80 SP4-es és korábbi verzióiban.

A gyártó a hibát a Cscape legutolsó, 9.90-es verziójában javította. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-050-03

Rockwell Automation rendszerek sérülékenysége

Luca Chiou, az ACSI munkatársa két sérülékenységet talált a Rockwell Automation Allen-Bradley Power Monitor 1000 összes verziójában.

A gyártó jelenleg is dolgozik a sérülékenységek javításán és megerősítette, hogy a CheckPoint IPS eszközei már képesek felismerni a sérülékenységeket kihasználni próbáló hálózati forgalmakat. A sérülékenységekről további részleteket az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-050-04

Sérülékenységek Siemens SIMATIC IPC-k Intel AMT komponenseiben

A Siemens ProductCERT bejelentése szerint az Intel AMT komponensek három sérülékenysége érinti az alábbi SIMATIC IPC berendezéseket:

- SIMATIC FieldPG M5 minden, v22.01.06-nál korábbi verziója;
- SIMATIC IPC427E minden, v21.01.09-nél korábbi verziója;
- SIMATIC IPC477E minden, v21.01.09-nél korábbi verziója;
- SIMATIC IPC547E minden, R1.30.0-nél korábbi verziója;
- SIMATIC IPC547G minden, R1.23.0-nál korábbi verziója;
- SIMATIC IPC627D minden, v19.02.11-nél korábbi verziója;
- SIMATIC IPC647D minden, v19.01.14-nél korábbi verziója;
- SIMATIC IPC677D minden, v19.02.11-nél korábbi verziója;
- SIMATIC IPC827D minden, v19.02.11-nél korábbi verziója;
- SIMATIC IPC847D minden, v19.01.14-nél korábbi verziója;
- SIMATIC ITP1000 minden, v23.01.04-nél korábbi verziója.

A gyártó a hibákat az érintett szoftverek legújabb verzióiban javította. A sérülékenységekről bővebben a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet olvasni.

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

Lars Lengersdorf, az Amprion munkatársa egy sérülékenységet azonosított a Siemens alábbi berendezéseiben:

- EN100 Ethernet modul IEC-61850 protokollhoz minden, v4.35-nél korábbi firmware-verzió esetén;
- EN100 Ethernet modul MODBUS/TCP protokollhoz minden firmware-verzió esetén;
- EN100 Ethernet modul DNP3/TCP protokollhoz minden firmware-verzió esetén;
- EN100 Ethernet modul IEC-104 protokollhoz minden firmware-verzió esetén;
- EN100 Ethernet modul Profinet IO protokollhoz minden firmware-verzió esetén;
- SIPROTEC 5 relék CP300 és CP100 processzorral szerelt példányainak minden, v7.82-nél korábbi verziója;
- SIPROTEC 5 relék CP200 processzorral szerelt példányainak minden, v7.58-nál korábbi verziója.

A hibát a gyártó az érintett eszközök legújabb firmware-verzióiban javította. A sérülékenységről további információkat a Siemens ProductCERT és az ICS-CERT weboldalain lehet találni.

Siemens SICAM rendszerek licenckezelő szoftverének sérülékenységei

A Siemens három sérülékenységet jelentett az NCCIC-nek, amik a SICAM 230-as sorozatú berendezéseinek 7.20-as és korábbi verzióinál használt licenckezelő szoftverét érintik.

a gyártó a hibát a licenckezelő szoftver legújabb verziójában javította. A sérülékenységekkel kapcsolatban részletesebb információkat a Siemens ProductCERT és az ICS-CERT bejelentései tartalmaznak.

SPECTRE sérülékenység Siemes SIMATIC ipari vékonykliensekben

A Siemes ProductCERT bejelentése szerint az alábbi SIMATIC ipari vékonyklienseiket érintik a SPECTRE néven ismertté vált sérülékenység V1 és V4 variánsai:

- SIMATIC ITC1500 V3 összes, V3.1-nél korábbi verziója;
- SIMATIC ITC1500 V3 PRO összes, V3.1-nél korábbi verziója;
- SIMATIC ITC1900 V3 összes, V3.1-nél korábbi verziója;
- SIMATIC ITC1900 V3 PRO összes, V3.1-nél korábbi verziója;
- SIMATIC ITC2200 V3 összes, V3.1-nél korábbi verziója;
- SIMATIC ITC2200 V3 PRO összes, V3.1-nél korábbi verziója.

A hibákkal kapcsolatban a gyártó kockázatcsökkentő intézkedésekre tett javaslatokat. A sérülékenységekről bővebb információkat a Siemens ProductCERT oldalán tettek közzé: https://cert-portal.siemens.com/productcert/pdf/ssa-505225.pdf

Sérülékenységek Schneider Electric SoMachine és Modicon rendszerekben

A Schneider Electric publikációja szerint több sérülékenységet azonosítottak az alábbi termékeikben:

- SoMachine Basic összes verziója;
- Modicon M221 minden verziója a V1.10.0.0-nál korábbi firmware-ek esetén.

A gyártó a hibákat a Modicon M221 V1.10.0.0 firmware-verziójában és az EcoStruxure Machine Expert – Basic v 1.0-ban javította. A sérülékenységekről részleteket a Schneider Electric publikációjában lehet találni.

Schneider Electric Vijeo Designer Lite sérülékenység

A Schneider Electric Vijeo Designer Lite nevű szoftverében, amit az alábbi berendezéseik konfigurációjához lehet használni, egy sérülékenységet azonosítottak:

- XBTN200;
- XBTN400;
- XBTN401;
- XBTN410;
- XBTNU400;
- XBTR400;
- XBTR410;
- XBTR411;
- XBTRT500;
- XBTRT511.

A Vijeo Designer Lite gyártói támogatása 2017 júniusában megszűnt, így a hiba kapcsán a gyártó csak kockázatcsökkentő intézkedéset javasol:

- A Vijeo Designer Lite-ot használó ügyfelei a szoftvert csak erre dedikált rendszeren használják a minimálisan szükséges jogosultságokkal rendelkező jogosultságokkal;
- Csak megbízható forrásból származó DOP projektfájlokat nyissanak meg.

A sérülékenységről több információt a Schneider Electric bejelentéséből lehet szerezni.

Sérülékenységek Schneider Electric ipari kamerákban

A Schneider Electric által közzétett információk szerint az alábbi ipari kameráikban több sérülékenység is található:

Pelco Sarix Enhanced első generációs kamerák:
- Beltéri kamerák:
- IMES19-1I, IMES19-1S, IMES19-1P;
- IME119-1I, IME119-1S, IME119-1P;
- IME219-1I, IME219-1S, IME219-1P;
- IME319-1I, IME319-1S, IME319-1P;
- IME319-B1I, IME319-B1S, IME319-B1P;
- IME3122-1I, IME3122-B1I, IME3122-1S, IME3122-B1S, IME3122-1P, IME3122-B1P;
- Környezeti kamerák, mini dómok:
- IMES19-1EI, IMES19-1ES, IMES19-1EP;
- IME119-1EI, IME119-1ES, IME119-1EP;
- IME219-1EI, IME219-1ES, IME219-1EP;
- IME319-1EI, IME319-1ES, IME319-1EP;
- IME3122-1EI, IME3122-1ES, IME3122-1EP;
- Vandálbiztos mini dómok:
- IMES19-1VI, IMES19-1VS, IMES19-1VP;
- IME119-1VI, IME119-1VS, IME119-1VP;
- IME219-1VI, IME219-1VS, IME219-1VP;
- IME319-1VI, IME319-1VS, IME319-1VP;
- IME3122-1VI, IME3122-1VS, IME3122-1VP;
- Box kamerák:
- IXES1;
- IXE11;
- IXE21;
- IXE31;
Spectra Enchanced kamerák:
- D6220, D6220L;
- D6230, D6230L.

A gyártó a hibákat a Sarix Enchanced kamerák 2.2.3.0 és a Spectra Enchanced 2.11-es és újabb verziójú firmware-jeiben javította. A sérülékenységekkel kapcsolatban további információkat a Schneider Electric weboldalán lehet olvasni.

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.