A Reuters cikke szerint számos, különböző ipari szektorokban tevékenykedő cég (többek között a Siemens-et, a Bayer-t, a BASF-et, a Henkelt, a Roche-t, a Sumitomo-t, a Shin-Etsu-t nevesítették) szenvedett el kibertámadásokat az utóbbi időben. A támadásokat vizsgáló szakértők a támadásokhoz a Winnti malware-t használták és bizonyos, feltételezések szerint kínai állami háttérrel rendelkező APT-csoportok állhatnak mögöttük.

Bár ezek a támadások minden jel szerint az érintett cégek adatainak ellopását célozhatták, felmerül a kérdés, hogy ha egyes államok támogatását bíró támadói csoportok ilyen félelmetes erőforrásokkal és hatékonysággal képesek az ipari kémkedésre és adatlopásra a saját gazdaságuk/iparuk fejlesztése érdekében, mikor jön el az a pont, amikor már nem csak az üzleti és technológiai titkokat akarják kibertámadásokkal megszerezni, hanem a konkurenciát hátrányos helyzetbe hozni vagy ellehetetleníteni?

Sérülékenységek Prima Systems rendszerekben

Gjoko Krstic, a Applied Risk munkatársa 9 sérülékenységet jelentett a DHS CISA-nak, amik a Prima FlexAir 2.3.38 és korábbi verzióit érintik.

A gyártó a hibát a 2.5.12-es verzióban javította. A sérülékenységekről további részleteket az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-211-02

Wind River VxWorks sérülékenységek

Gregory Vishnepolsky, Dor Zusman és Ben Seri, az Armis kutatói 11 különböző sérülékenységről osztottak meg részleteket a DHS CISA-val, amik VxWorks valósidejű operációs rendszer (Real Time Operating System, RTOS) alábbi verzióit érintik:

- Minden, jelenleg támogatással rendelkező VxWorks verzió (6.9.4.11, Vx7 SR540, Vx7 SR610);
- Régebbi, támogatással már nem rendelkező verziók 6.5-ig visszamenőleg;
- A támogatással már nem rendelkező Advanced Networking Technology (ANT) minden verziója.

Az alábbi termékeket és verziókat a most publikált sérülékenységek nem érintik:

- VxWorks 7 SR620 (a legújabb VxWorks verzió);
- VxWorks 5.3-tól VxWorks 6.4-ig;
- VxWorks Cert minden verziója;
- VxWorks 653 2.x és korábbi verziói;
- VxWorks 653 MCE 3.x Cert Edition és későbbi verziói.

A gyártó a még támogatással rendelkező, érintett verziókhoz javításokat és kockázatcsökkentő intézkedéseket jelentett be. A sérülékenységek több más gyártó (mostanáig a Rockwell Automation és a Xerox lettek megnevezve) egyes termékeit is érintik. Egyes források szerint az érintett rendszerek száma akár 200 millió is lehet világszerte. A sérülékenységekkel kapcsolatban bővebb információkat az ICS-CERT bejelentésében lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-211-01

Sérülékenységek LCDS rendszerekben

Francis Provencher (PRL) a ZDI-vel együttműködve két sérülékenységet azonosított a LAquis SCADA 4.3.1.71-es verziójában.

A gyártó a hibákat a 4.3.1.323-as verzióban javította. A sérülékenységekről részleteket az ICS-CERT weboldalán lehet elérni: https://www.us-cert.gov/ics/advisories/icsa-19-213-06

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

kimiya, a 9SG biztonsági csoport tagja két sérülékenységet talált a Rockwell Automation Arena Simulation Software nevű termékének 16.00.00 és korábbi verzióiban.

A gyártó a hibákat a 16.00.01-es verzióban javította. A sérülékenységekről bővebb információkat az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-213-05

Sérülékenység 3S-Smart Software Solutions termékekben

JunYoung Park egy sérülékenységet azonosított a 3S-Smart Software Solutions CODESYS termékcsaládjának alábbi tagjaiban:

- CODESYS Control for BeagleBone;
- CODESYS Control for emPC-A/iMX6;
- CODESYS Control for IOT2000;
- CODESYS Control for Linux;
- CODESYS Control for PFC100;
- CODESYS Control for PFC200;
- CODESYS Control for Raspberry Pi;
- CODESYS Control RTE V3;
- CODESYS Control RTE V3 (for Beckhoff CX);
- CODESYS Control Win V3 (also part of the CODESYS Development System setup);
- CODESYS V3 Simulation Runtime (part of the CODESYS Development System);
- CODESYS Control V3 Runtime System Toolkit;
- CODESYS HMI V3.

A hibát a gyártó az érintett termékek legújabb, 3.5.16.0 verziójában fogja javítani, ami a tervek szerint 2020. februárban fog megjelenni. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT bejelentésében lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-213-04

3S-Smart Software Solutions CODESYS V3 sérülékenységek

A 3S-Smart Software Solutions két sérülékenységről osztott meg információkat a DHS CISA-val, amik az alábbi termékeiket érintik:

- CODESYS Control for BeagleBone;
- CODESYS Control for emPC-A/iMX6;
- CODESYS Control for IOT2000;
- CODESYS Control for Linux;
- CODESYS Control for PFC100;
- CODESYS Control for PFC200;
- CODESYS Control for Raspberry Pi;
- CODESYS Control V3 Runtime System Toolkit;
- CODESYS Gateway V3;
- CODESYS V3 Development System.

A gyártó a hibákat a v3.5.14.20-as és a v3.5.15.0 verziókban javította. A sérülékenységek részleteiről az ICS-CERT weboldalán lehet információkat találni: https://www.us-cert.gov/ics/advisories/icsa-19-213-03

Fuji Electric rendszerek sérülékenysége

kimiya, a 9SG biztonsági csapat tagja a ZDI-vel együttműködve egy sérülékenységet azonosított a Fuji Electric FRENIC Loader nevű termékének 3.5.0.0 és korábbi verzióiban.

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

Sérülékenység Advantech rendszerekben

Mat Powell és a ZDI egy, az Advantech WebAccess HMI Designer 2.1.9.23-as és korábbi verzióit érintő sérülékenységről publikált információkat.

A hibát a gyártó a 2.1.9.31-es verzióban javította. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT weboldalán lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-213-01

Sérülékenységek Siemens SIPROTEC 5 hálózati kommunikációs modulokban

A Siemens ProductCERT a Wind River-rel, valamint Pierre Capillon-nal, Nicolas Iooss-szal és Jean-Baptiste Galet-vel, az ANSSI munkatársaival együttműködve 12 sérülékenységről hozott nyilvánosságra részleteket, amik a SIPROTEC 5 termékcsalád alábbi tagjait érintik:

- SIPROTEC 5 CP300 és CP100 plug-in kommunikációs modulok minden, V7.91-nél korábbi verziói;
- SIPROTEC 5 CP200 plug-in kommunikációs modulok minden verziója;
- SIPROTEC 5 CP300-as CPU-val szerelt változatainak minden verziója.

A gyártó az egyik sérülékenységhez bizonyos érintett eszközök esetében adott ki javítást, a többi esetben kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységről bővebben a Siemens ProductCERT publikációjában lehet olvasni: https://cert-portal.siemens.com/productcert/pdf/ssa-632562.pdf

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.

A múltkori bejegyzésem, ami az IT/IT biztonsági és OT szakterületek közötti, finoman fogalmazva sem ideális viszonyokat boncolgatta, elég gyorsan vetett néhány hullámot, bizonyítva, hogy létező és komoly problémáról van szó.

Mivel a probléma felvetése szerintem csak egy (első) lépés az úton, megpróbálok adni néhány ötletet, hogyan lehetne javítani ezen a nem éppen jó helyzeten.

1. Kommunikáció (tudom, tudom, elég bullshit-nek fog tűnni, esélyes, hogy néhány kollégám ezért a bekezdésért meg akar majd dobálni, de bármennyire is közhelynek hangzik, innen kell indulni): Nem lehet megúszni azt, hogy az IT/IT biztonsági és OT szakterületek a nem létező vagy éppen csak érintőleges kapcsolatok helyett sokkal szorosabb szakmai együttműködést építsenek ki. Ebben beletartozik egymás feladatainak és napi kihívásainak, problémáinak valamilyen szintű ismerete is - személy szerint úgy gondolom, hogy kerüljön bármennyi időbe és energiában, mindenképp fontos, hogy a jobb szakmai együttműködés egy jobb személyes kapcsolatra épüljön, ezért pedig szükséges, hogy az IT/IT biztonsági és OT mérnökök időnként igenis üljenek le beszélgetni. Ha pedig ez a beszélgetés néha túlmutat a szakmai témákon, az sem baj.

2. Képzések: Elsősorban és leginkább azokra az alapozó képzésekre gondolok, amelyek keretében mind az OT, mind az IT (elsősorban IT biztonsági) mérnökök betekintést nyerhetnek az ICS biztonság világába (ilyenek pl. az Idaho National Labs és az ENCS - erről később fogok írni - képzései illetve a SANS ICS 410-es tanfolyama). Tudom, hogy ezeknek a tanfolyamoknak az ára meglehetősen magas, de fel kell tenni a kérdést az érintett szervezetek felelős vezetőinek: meg tudják egyáltalán becsülni (), hogy egy komolyabb ICS biztonsági incidens (mint például a Norsk Hydro vagy a TSMC elleni támadások) mekkora anyagi veszteséget eredményezhet a cégük számára? Ehhez hasonlítva még mindig soknak tűnik évente 1-2 ember számára fejenként 3000-5000 Eurót ilyen tanfolyamokra költeni (főleg, ha ezek az emberek utána a megszerzett tudást át is tudják adni a kollégáiknak)?

3. Információcsere: Részben a kommunikációhoz is tartozik, de tapasztalataim szerint jelenleg gyakorlatilag nulla információcsere van az OT és az IT biztonsági területek között. Ez pedig azt is jelenti, hogy még ha egy adott cél IT biztonsági szakterülete folytat is fenyegetés-elemzést és gyűjt információkat különböző forrásokból, ezek az információk szinte biztosan nem jutnak el az ICS rendszerek és eszközök üzemeltetéséért felelős szakemberekhez.

A fentiekben megfogalmazott feladatok/célok nyilván csak egy kis szeletét fedik le annak, amit tenni lehetne és kéne egy jobb IT-OT együttműködésért, de ha ezek mentén elkezd fejlődni egy szervezet, már az is hatalmas változásokat eredményezhet.

Sérülékenység Cisco ipari termékekben

A Cisco publikációja szerint egy sérülékenységet találtak az ipari hálózati eszközeik menedzsmentjéhez használható Industrial Network Director (IND) nevű rendszerük 1.7-nél korábbi verzióiban.

A hibát a gyártó az IND 1.7-es verziójában javította. A sérülékenységgel kapcsolatban további információk a Cisco publikációjában találhatóak.

Johnson Controls rendszerek sérülékenysége

Gjoko Kristic, a Zero Science Lab munkatársa egy sérülékenységet fedezett fel a Johnson Controls exacqVision server nevű megoldásának 9.6-os és 9.8-as verzióiban.

A gyártó a hibát a termék legújabb, 19.03-as verziójában javította. A sérülékenységről bővebben az ICS-CERT bejelentésében lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-199-01

Sérülékenységek Mitsubishi Electric rendszerekben

Az Applied Risk két sérülékenységről közölt információkat az amerikai Cyber Infrastructure Security Agency-vel (CISA). A sérülékenységek a Mitsubishi Electric FR Configurator2 rendszerének 1.16S és korábbi verzióit érintik.

A gyártó a hibát az 1.17T verzióban javította. A sérülékenységekről további információkat az ICS-CERT bejelentése tartalmaz: https://www.us-cert.gov/ics/advisories/icsa-19-204-01

Sérülékenység NREL EnergyPlus rendszerekben

Karn Ganeshen egy, az NREL EnergyPlus 8.6.0 és feltételezhetően korábbi verzióit érintő sérülékenységet jelentett a CISA-nak.

A gyártó a hibával kapcsolatban az érintett termék legújabb, v9.0.1-es verziójának használatát javasolja. A sérülékenységről részleteket az ICS-CERT weboldalán lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-204-02

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 hírek szerint csütörtökön ransomware-támadás érte a johannesburgi (a Dél-afrikai Köztársaság pénzügyi központjának számító város) áramszolgáltató informatikai rendszereit. Bár a különböző források szerint a támadás a cég egyes IT rendszereit érintette (többek között a telefonos ügyfélszolgálati valamint a munka és eszközkezelő rendszerekről esik szó) és nincs szó arról, hogy a villamosenergia-ellátásban közvetlenül érintett ICS rendszerekig ért volna a ransomware. Azonban a hírek szerint azok az ügyfelek, akik előre fizetnek a villamosáramért (jellemzően ezek a legszegényebb rétegek lehetnek ugyanúgy, mint Magyarországon), szintén érintettek, mert a feltöltőkártyás rendszer is érintett. Ráadásul mivel a déli féltekén most tél van, a hideg időjárás miatt előfordulhat, hogy a nagyobb rendszerterhelések következtében kialakuló meghibásodások áramkimaradásokhoz vezetnek, amiket a szolgáltató (a ransomware által titkosított rendszereik hiányában) a normálisnál jóval lassabban tud elhárítani.

Az incidensről jelenleg részleteket a Dark Reading és a Reuters cikkeiben olvashatóak.

A jelek szerint az idei év az ipari szereplők (és a különböző városi szolgáltatók és önkormányzati szervek) elleni ransomware-támadások éve lesz, elég csak a nemrég napvilágot látott floridai városok vagy éppen a Norsk Hydro elleni ransomware-támadásokra gondolni. A kérdés már csak az, mit tesznek azok, akiknek az a dolguk, hogy megelőzzék ezeket a támadásokat?

Nemrég egy közel 5 éves esetről olvastam, ami rávilágít arra, hogy az ICS kiberbiztonság világában is komoly kockázati tényezőt jelenthetnek a hamisított eszközök. A Yokogawa bejelentése szerint ismeretlenek Yokogawa logóval ellátott, EJA-110E sorozatú érzékelőket árulnak. Az érintett eszközöket számos szektorban használják, kereskedelmi, gyártástechnológiai és védelmi rendszerek mellett atomerőművek SCRAM (safety) rendszereiben is.

Bár a hamisításnak feltételezhetően tisztán pénzügyi okai lehetnek, nem szabad szó nélkül elmenni amellett a lehetőség mellett, hogy egy ilyen berendezésen keresztül mennyivel könnyebben lehet valótlan adatokat eljuttatni a felügyeleti rendszerekbe, ezáltal idézni elő egy komolyabb ICS biztonsági incidenst. Ráadásul mivel magát a szenzort kompromittálták a támadadók, ezért a hagyományos, host szintű vagy hálózatbiztonsági megoldások az ilyen támadások ellen nem vagy csak sokkal kisebb hatásfokkal tudnak védelmet nyújtani.

Ez a régi eset is rávilágít arra, hogy az ICS biztonság terén is kiemelten fontos az egyenszilárd biztonság kialakítása, ami magában kell, hogy foglalja a lvl1/lvl0 szinteken működő berendezések biztonsági kontrolljait. Mivel ezekhez az eszközökhöz általában már sem az IT biztonsági, sem az OT biztonsági mérnökök nem értenek, elkerülhetetlen, hogy a fent említett biztonsági szakemberek és a folyamatirányításért felelős OT mérnökök között nagyon szoros szakmai együttműködés létezzen, mert csak ez biztosíthatja, hogy a kialakításra kerül ICS biztonsági programnak nem lesznek vakfoltjai a Purdue-modell alacsonyabb szintjein működő berendezéseknél.

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

A Rockwell Automation egy sérülékenységet jelentett az NCCIC-nek, ami a PanelView 5510-es HMI rendszerük minden, 2019 március 13-a előtt gyártott verzióját érinti, amit még nem frissítettek a v4.003, v5.002 vagy későbbi verziókra.

A sérülékenységről további részleteket az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-190-02

Sérülékenység Emerson DCS rendszerekben

Benjamin Crosasso, a Sanofi munkatársa egy sérülékenységet talált az Emerson DeltaV DCS rendszerének 11.3.x és 12.3.x verzióiban.

A gyártó a hibát az elérhető legfrissebb verzióban javította. A sérülékenységgel kapcsolatban további információkat az ICS-CERT bejelentésében lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-190-01

Sérülékenység GE orvostechnikai berendezésekben

Elad Luz, a CyberMDX munkatársa egy sérülékenységet azonosított a GE alábbi anezteziológiai berendezéseiben:

- GE Aestiva and Aespire Versions 7100;
- GE Aestiva and Aespire Versions 7900.

A hibára a gyártó már tervezi a javítás kiadását, addig is kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenység részleteiről az ICS-CERT weboldalán lehet olvasni: https://www.us-cert.gov/ics/advisories/icsma-19-190-01

Sérülékenységek Schneider Electric és Aveva rendszerekben

A Schneider Electric négy sérülékenységet fedezett fel a Floating License Manager nevű termékének 2.3.0.0 és korábbi verzióiban. A hiba érinti az Aveva Vijeo Citect és Citect SCADA rendszereit is, ahol használják a Schneider Electric Floating License Manager-ét.

A Schneider Electric a hibát a Floating License Manager 2.3.1.0 verzióban javította, ami elérhető mind a Schneider Electric, mind az Aveva érintett rendszereit használó ügyfelei számára. A sérülékenységekről bővebben az ICS-CERT alábbi bejelentéseiben lehet olvasni:

https://www.us-cert.gov/ics/advisories/icsa-19-192-07
https://www.us-cert.gov/ics/advisories/icsa-19-192-05

Delta Electronics rendszerek sérülékenységei

Natnael Samson a ZDI-vel együttműködve két sérülékenységet jelentett az NCCIC-nek, amik a Delta Electronics CNCSoft ScreenEditor Versions 1.00.89-es és korábbi verzióit érintik.

A gyártó a hibát az 1.00.94-es verzióban javította. A sérülékenységek részleteivel kapcsolatban részleteket az ICS-CERT weboldalán lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-192-01

Sérülékenység Philips orvostechnikai rendszerekben

A Philips egy sérülékenységről közölt részleteket az NCCIC-vel, ami a Holter 2010 Plus nevű orvostechnikai rendszerük minden verzióját érinti. A hibával kapcsolatban jelenleg javítás nem, csak kockázatcsökkentő intézkedésekre vonatkozó ajánlások érhetőek el. 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/icsma-19-192-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 múlt heti posztban Joe Weiss S4x-es előadása nyomán azt a kérdést hagytam nyitva, hogy vajon az ICS rendszerek hálózatbiztonsága (ide értve az ICS/SCADA rendszereket és az ICS rendszerek mérnöki munkaállomásait és HMI-ait is) vagy a Purdue-modell alapján level1/level0-nak nevezett berendezések (PLC-k, RTU-k és különböző motorok, szelepek, áramváltók, digitális védelmek, stb.) kiberbiztonsága a fontosabb-e?

Előre kell bocsátanom, hogy az alábbiak az én személyes véleményemet mutatják be.

Szóval én úgy látom, hogy erre a kérdésre nem lehet egyszerű választ adni, mert nem vagy-vagy kérdésről van szó. Egyrészt úgy gondolom, hogy Joe igazát nem lehet elvitatni, a level1/level0 szintű eszközök esetében a Stuxnet óta mindig felmerül a kérdés, hogy a tőlük kapott adatok valósak-e? (Ugye erről írtam a múlt héten a Boeing 737 MAX katasztrófákat példaként hozva, de a Stuxnet gyakorlatilag ugyanezt a biztonsági rést használta ki arra, hogy százasával tegye tönkre az iráni centrifugákat - senkinek nem jutott eszébe megkérdőjelezni az ottani ICS rendszerbe beérkező adatok hitelességét, pedig az urándúsító centrifugák fordulatszáma kb. minden más volt, csak az az érték nem, ami a kijelzőkön megjelent). Ezért aztán úgy gondolom, hogy a szakmának igenis nagyon komolyan foglalkoznia kell azzal a problémával, amire Joe immár vagy 3 éve folyamatosan próbálja ráirányítani a figyelmet.

A másik oldalon ott az ICS rendszerek hálózat- és host szintű biztonságának kérdése. Ha alaposan elolvassuk a különböző, fizikai folyamatok vezérlését célzó támadásokról készült elemzéseket, igen gyorsan fel lehet fedezni azt a közös pontot, hogy minden ilyen incidens azzal kezdődött, hogy a támadók valamilyen, kifinomult, de korántsem forradalmian újszerű IT biztonsági rést kihasználva szereztek hozzáférést az adott szervezet hálózatához (még ha ehhez adott esetben egy vagy több nulladik napi sérülékenységet használtak is fel - ahogy arról már volt szó itt a blogon is, nem túl nehéz egy-egy nulladik vagy első napi sérülékenységet találni az ICS rendszerek tágabb környezetében). Éppen ezért tartom fontosnak, hogy a "hagyományos" IT biztonsági eszközökkel és eljárásokkal a lehető legjobban megerősítsék a szervezetek az IT és ICS rendszereik biztonságát, ahol lehet, a megelőzésre koncentrálva, ahol pedig a megelőző kontrollok és biztonsági megoldások alkalmazása valamilyen ok miatt nem lehetséges, ott az incidensek (legyenek azok akár rosszindulatúak, akár jó szándékú beavatkozásból származóak) mielőbbi észlelésére és hatékony felszámolására alkalmas eszközökre és incidenskezelési eljárásokra van szükség.

Az érintett szervezetek (fejlesztők, integrátorok, üzemeltetők és ne tagadjuk le: még az ICS biztonsági szakma is) meglehetősen lassan ébredtek a Stuxnet nyilvánosságra kerülése óta elmúlt 9 évben és sajnálatos módon nem koncentráltak eléggé az ICS rendszerek és berendezések biztonságának egyenszilárd növelésére, így ma már nem kockáztathatjuk, hogy az ICS rendszereink csak egyik vagy csak másik elemének biztonságát fejlesztjük. Új megközelítésre van szükség, ahol az ICS rendszerek minden szintjén egyetlen nagy képet figyelve fejlesztjük a kiberbiztonságot, nem pedig arra, hogy az IT-OT szembenállás mellett felépítsük az IT-OT-folyamatirányítási mérnökök hármas patthelyzeti vitáját. Észre kell végre venni, hogy ha az ICS rendszerek körül dolgozó szakemberek nem fognak össze mindannyian, akkor a támadók (akinek nincsenek ilyen problémáik, mert nem vesztegetik az időt kicsinyes, szakmai és felségterületi féltékenységből fakadó vitákra) nagyon rövid időn belül fölénk fognak kerekedni, az pedig nem csupán egy adott szervezet belső problémája lesz, hanem régiók, országok fogják nyögni a következményeit!

Sérülékenység Schneider Electric Modicon eszközökben

Zhang Xiaoming, Zhang Jiawei, Sun Zhonghao és Luo Bing a CNCERT/CC munkatársai egy sérülékenységet azonosítottak a Schneider Electric Modicon vezérlőcsaládjának alábbi tagjaiban:

- Modicon M340: v3.01-nél korábbi firmware-verziók;
- Modicon M580: v2.80-nál korábbi firmware-verziók;
- Modicon Quantum: Minden firmware-verzió;
- Modicon Premium: Minden firmware-verzió.

A gyártó a hibát az M340-es és M580-as sorozatú eszközöknél új firmware-verziók kiadásával javította, a Quantum eszközök gyártói támogatása már véget ért, ezekhez nem várható javítás. 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/icsa-19-183-01

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

A Schneider Electric bejelentése szerint a 9sg biztonsági csapata egy memóriakezelési hibát talált a Zelio Soft 2 v5.2 és korábbi verzióiban.

A gyártó a hibát az 5.3-as verzióban javította. A sérülékenységről bővebben a Schneider Electric bejelentésében lehet olvasni.

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

A Schneider Electric publikációja szerint mdm és rgod, a 9sg biztonsági csapat tagjai egy sérülékenységet azonosítottak az Interactive Graphical SCADA System 14-es és korábbi verzióiban.

A gyártó a hibát a 13.0.0.19140-es és a 14.0.0.19120-as verziókban javította. A sérülékenységgel kapcsolatban részleteket a Schneider Electric weboldalán lehet találni.

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

A Schneider Electric weboldalán közzétett információk alapján egy puffer-kezelési hibát találtak az alábbi Modicon termékekben:

- Modicon M580 CPU - BMEP582040 minden, V2.90-nél korábbi verziója;
- Modicon Ethernet Module BMENOC0301 minden, V2.16-nál korábbi verziója.

A gyártó a hibát az érintett eszközökhöz kiadott új verziókban javította. A sérülékenységekkel kapcsolatban további információkat a Schneider Electric publikációjában lehet elérni.

Régi és új sérülékenységek Schneider Electric Modicon vezérlőkben

A Schneider Electric egy meglehetősen furcsa publikációban 13 darab 2018-as és 3 új sérülékenységről hozott nyilvánosságra részleteket. A sérülékenységek az alábbi Modicon vezérlőket érintik:

- Modicon M580 minden verziója;
- Modicon M340 minden verziója;
- Modicon Premium minden verziója;
- Modicon Quantum minden verziója.

A gyártó a különböző sérülékenységek esetén javított verziók használatát vagy kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekről további részleteket a Schneider Electric publikációjában lehet találni.

Sérülékenység Quest rendszerekben

Juan Pablo Lopez Yacubian egy sérülékenységet talált a Quest KACE menedzsment appliance-ének alábbi verzióiban:

- KACE SMA minden, 8.0.x verziója;
- KACE SMA minden, 8.1.x verziója;
- KACE SMA minden, 9.0.x verziója.

A gyártó a hibát a 9.1-es és újabb 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-19-183-02

Sérülékenységek Siemens SIPROTEC és DIGSI berendezésekben

A Siemens ProductCERT bejelentése szerint Pierre Capillon, Nicolas Iooss és Jean-Baptiste Galet, az ANSSI munkatársai két sérülékenységet találtak az alábbi Siemens termékekben:

- SIPROTEC 5 berendezések CP300 és CP100 CPU-val szerelt következő változatai: 6MD85, 6MD86,6MD89, 7UM85, 7SA87, 7SD87, 7SL87, 7VK87,7SA82, 7SA86, 7SD82, 7SD86, 7SL82, 7SL86,7SJ86, 7SK82, 7SK85, 7SJ82, 7SJ85, 7UT82,7UT85, 7UT86, 7UT87 és 7VE85 minden, V7.90-nél korábbi firmware-verzió használata esetén;
- Minden más, az előző pontban fel nem sorolt SIPROTEC 5 változat minden verziója;
- SIPROTEC 5 relék CP200 CPU-val szerelt változatainak minden verziója;
- A DIGSI 5 mérnöki szoftver minden, V7.90-nél korábbi verziója.

A gyártó a sérülékenységekkel kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekről további információkat a Siemens ProductCERT bejelentésében lehet olvasni: https://cert-portal.siemens.com/productcert/pdf/ssa-899560.pdf

Sérülékenység Spectrum Power 3 rendszerekben

A Siemens ProductCERT által nyilvánosságra hozott információk szerint a Spectrum Power nevű SCADA rendszer alábbi verzióiban egy cross-site scripting sérülékenységet találtak:

- Spectrum Power 3 (Corporate User Interface) v3.11 és korábbi verziói;
- Spectrum Power 4 (Corporate User Interface) v4.75 verziója;
- Spectrum Power 5 (Corporate User Interface) v5.50 és korábbi verziói;
- Spectrum Power 7 (Corporate User Interface) v2.20 és korábbi verziói.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja, kiemelten, hogy a Spectrum Power UI kliensek számára NE engedélyezze senki az Internet bármilyen elérését! A sérülékenységről részleteket a Siemens ProductCERT weboldalán lehet találni: https://cert-portal.siemens.com/productcert/pdf/ssa-747162.pdf

Sérülékenység Siemens WinCC TIA Portal komponensben

Joseph Bingham, a Tenable munkatársa egy hiányzó authentikációból adódó sérülékenységet fedezett fel a Siemens WinCC TIA Portal TIA Administrator komponensének V1.0 SP1 Upd1-nél korábbi verzióiban.

A hibához a gyártó kockázatcsökkentő intézkedéseket publikált. A sérülékenységgel kapcsolatban további részleteket a Siemens ProductCERT publikációjában lehet olvasni: https://cert-portal.siemens.com/productcert/pdf/ssa-721298.pdf

Processzor sérülékenységek Siemens berendezésekben

A biztonsági kutatók által korábban publikált, ZombieLoad és Microarchitec-tural Data Sampling (MDS) névre keresztelt sérülékenységek a Siemens ProductCERT bejelentése szerint érintik az alábbi SIMATIC, SIMOTION és SINUMERIC berendezéseiket:

- SIMATIC Field PG M4 minden verziója;
- SIMATIC Field PG M5 minden verziója;
- SIMATIC Field PG M6 minden verziója;
- SIMATIC IPC127E minden verziója;
- SIMATIC IPC2X7E minden verziója;
- SIMATIC IPC3000 SMART V2 minden verziója;
- SIMATIC IPC327E minden verziója;
- SIMATIC IPC347E minden verziója;
- SIMATIC IPC377E minden verziója;
- SIMATIC IPC427C minden verziója;
- SIMATIC IPC427D minden verziója;
- SIMATIC IPC427E minden, V21.01.11-nél korábbi BIOS verzió;
- SIMATIC IPC477C minden verziója;
- SIMATIC IPC477D minden verziója;
- SIMATIC IPC477E minden, V21.01.11-nél korábbi BIOS verzió;
- SIMATIC IPC477E Pro minden, V21.01.11-nél korábbi BIOS verzió;
- SIMATIC IPC527G minden verziója;
- SIMATIC IPC547E minden verziója;
- SIMATIC IPC547G minden verziója;
- SIMATIC IPC627C minden verziója;
- SIMATIC IPC627D minden verziója;
- SIMATIC IPC627E minden, V25.02.04-nél korábbi BIOS verzió;
- SIMATIC IPC647C minden verziója;
- SIMATIC IPC647D minden verziója;
- SIMATIC IPC647E minden, V25.02.04-nél korábbi BIOS verzió;
- SIMATIC IPC677C minden verziója;
- SIMATIC IPC677D minden verziója;
- SIMATIC IPC677E minden, V25.02.04-nél korábbi BIOS verzió;
- SIMATIC IPC827C minden verziója;
- SIMATIC IPC827D minden verziója;
- SIMATIC IPC847C minden verziója;
- SIMATIC IPC847D minden verziója;
- SIMATIC IPC847E minden, V25.02.04-nél korábbi BIOS verzió;
- SIMATIC ITP1000 minden verziója;
- SIMATIC S7-1500 CPU S7-1518-4 PN/DP MFP(MLFB: 6ES7518-4AX00-1AC0) minden verziója;
- SIMATIC S7-1500 CPU S7-1518F-4 PN/DP MFP(MLFB: 6ES7518-4FX00-1AC0) minden verziója;
- SIMOTION P320-4E minden verziója;
- SIMOTION P320-4S minden verziója;
- SINUMERIK 840 D sl (NCU720.3B, NCU730.3B,NCU720.3, NCU730.3) minden verziója;
- SINUMERIK PCU 50.5 minden verziója;
- SINUMERIK Panelek integrált TCU-val rendelkező minden kiadott verziója;
- SINUMERIK TCU 30.3 minden verziója.

Az értintett eszközök egy részéhez a gyártó kiadta a hibát javító BIOS verziókat, a többi esetében kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységekről a Siemens ProductCERT weboldalán lehet további információkat találni: https://cert-portal.siemens.com/productcert/pdf/ssa-616472.pdf

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

A Siemens ProductCERT bejelentése szerint három, elavult TLS verziók használatával kapcsolatos sérülékenységet javítanak az alábbi SIMATIC berendezésekben:

- RF615R minden, V3.2.1-nél korábbi verziója;
- RF68XR minden, V3.2.1-nél korábbi verziója.

A gyártó a javított verzió kiadásán túl kockázatcsökkentő intézkedésekre is javaslatot tett. A sérülékenységek részleteiről a Siemens ProductCERT bejelentésében lehet olvasni: https://cert-portal.siemens.com/productcert/pdf/ssa-556833.pdf

Sérülékenység SIMATIC WinCC és SIMATIC PCS7 rendszerekben

A Siemens ProductCERT publikációja szerint egy sérülékenységet azonosítottak az alábbi termékeikben:

SIMATIC PCS 7 V8.0 és korábbi verzióinak minden firmware-verziója;
SIMATIC PCS 7 V8.1 minden verzió;
SIMATIC PCS 7 V8.2 minden, WinCC V7.4 SP1Upd11-gyel telepített, V8.2 SP1-nél korábbi verziója;
SIMATIC PCS 7 V9.0 minden, WinCC V7.4 SP1Upd11-gyel telepített, V9.0 SP2-nél korábbi verziója;
SIMATIC WinCC Professional (TIA Portal V13) minden verziója;
SIMATIC WinCC Professional (TIA Portal V14) minden verziója;
SIMATIC WinCC Professional (TIA Portal V15) minden verziója;
SIMATIC WinCC Runtime Professional V13 minden verziója;
SIMATIC WinCC Runtime Professional V14 minden verziója;
SIMATIC WinCC Runtime Professional V15 minden verziója;
SIMATIC WinCC V7.2 és korábbi verzióinak minden firmware-verziója;
SIMATIC WinCC V7.3 minden verziója;
SIMATIC WinCC V7.4 minden, V7.4 SP1 Upd 11-nél korábbi verziója;
SIMATIC WinCC V7.5 minden, V7.5 Upd 3-nál korábbi verziója.

A gyártó egyes érintett termékverziókhoz elérhetővé tette a javításokat, a többi esetén kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről további információkat a Siemens ProductCERT publikációja tartalmaz: https://cert-portal.siemens.com/productcert/pdf/ssa-121293.pdf

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.

Kb. egy hónapja találtam egy videót, ami Joe Weiss S4 konferencián tartott előadásáról került fel a YouTube-ra.

A fél órás előadásból csak néhány percig volt szó a LionAir Boeing 737 MAX repülőgépének katasztrófájáról. Joe ebben az esetben is azt próbálta megvilágítani, amiről már évek óta beszél, hogy a (Purdue modell szerinti) level 0/level 1 szinteken működő vezérlő rendszerek (nem is kizárólag az ipari vezérlő rendszerek - ICS -, hanem a tágabban értelmezett vezérlő rendszerek, orvosi, közlekedésben használt, stb. vezérlő rendszerek) berendezéseibe semmilyen biztonsági kontroll vagy megoldás nincs jelen. Ez pedig azt jelenti, hogy ha valaki képes lehet kompromittálni ezeket a berendezéseket, akkor a mérnökök, akik az ezekben a berendezésekben működő szenzorokból érkező adatok alapján irányítják az adott rendszereket és folyamatokat, óhatatlanul hibás döntéseket fognak hozni, még akkor is, ha személy szerint semmilyen szakmai hibát nem követnek el, hiszen nem valós bemenő adatokkal dolgoznak.

Ráadásul ez az előadás még a januári S4x19 konferencián hangzott el, jóval az Ethiopean 737 MAX lezuhanása előtt, de a jelenleg megismerhető vizsgálati eredmények azt mutatják, hogy Joe-nak igaza volt, a repülőgép szenzorai valótlan adatokat szolgáltattak a repülőgép átesést megelőző vezérlő rendszerének, ami a nem valós adatok alapján működött és ez vezetett a katasztrófákhoz és több száz ember halálához. Még rosszabb, hogy a két esetben a pilóták nem tudták pontosan, mi és miért történik illetve nem voltak képesek felülbírálni a hibás adatok alapján működő vezérlő rendszert.

A témához kapcsolódik Joe legfontosabb üzenete, amire az elmúlt 2-3 évben koncentrál, mégpedig az, hogy az ICS rendszerek hálózatbiztonsága vagy a level0/level1 berendezések biztonsága fontosabb-e? A jövő heti posztban ezt a kérdést fogom körüljárni a saját nézőpontomból.