Bejelentés dátuma: 2024.01.23.
Gyártó: APsystems
Érintett rendszer(ek):
- Energy Communication Unit Power Control Software C1.2.2-es verziója;
- Energy Communication Unit Power Control Software v3.11.4-es verziója;
- Energy Communication Unit Power Control Software W2.1.NA verziója;
- Energy Communication Unit Power Control Software v4.1SAA verziója;
- Energy Communication Unit Power Control Software v4.1NA verziója;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Improper Access Control (CVE-2022-44037)/súlyos;
Javítás: Nincs információ.
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-24-023-01

Bejelentés dátuma: 2024.01.23.
Gyártó: Crestron
Érintett rendszer(ek):
- Crestron AirMedia Presentation System AM-300 1.4499.00018-as verziója;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- OS Command Injection (CVE-2023-6926)/súlyos;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-24-023-02

Bejelentés dátuma: 2024.01.23.
Gyártó: Voltronic Power
Érintett rendszer(ek):
- ViewPower Pro UPS menedzsment szoftver 2.0-22165-ös verziója;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Deserialization of Untrusted Data (CVE-2023-51570)/kritikus;
- Missing Authentication for Critical Function (CVE-2023-51571)/súlyos;
- Exposed Dangerous Method or Function (CVE-2023-51573)/kritikus;
- OS Command Injection (CVE-2023-51572)/kritikus;
Javítás: Nincs információ.
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-24-023-03

Bejelentés dátuma: 2024.01.23.
Gyártó: Westermo
Érintett rendszer(ek):
- Lynx: Model Version L206-F2G1;
- Lynx 4.24-es firmware-verziója;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Cross-site Scripting (CVE-2023-40143)/közepes;
- Cross-site Scripting (CVE-2023-45222)/közepes;
- Code Injection (CVE-2023-45735)/súlyos;
- Cross-Origin Resource Sharing (CVE-2023-45213)/közepes;
- Cross-site Scripting (CVE-2023-42765)/közepes;
- Cross-site Scripting (CVE-2023-40544)/közepes;
- Cross-Site Request Forgery (CVE-2023-38579)/súlyos;
- Cross-site Scripting (CVE-2023-45227)/közepes;
Javítás: A gyártó jelenleg is dolgozik a hibák javításán, a patch megjelenéséig kockázatcsökkentő intézkedések alkalmazását javasolja.
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-24-023-04

Bejelentés dátuma: 2024.01.23.
Gyártó: Lantronix
Érintett rendszer(ek):
- XPort Device Server Configuration Manager 2.0.0.13-as verziója;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Weak Encoding for Password (CVE-2023-7237)/közepes;
Javítás: Az érintett termékhez nincs, akinek titkosításra van szüksége, annak az újabb verzióra, az XPort Edge-re történő frissítést javasolja a gyártó.
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-24-023-05

Bejelentés dátuma: 2024.01.25.
Gyártó: MachineSense
Érintett rendszer(ek):
- FeverWarn ESP32;
- FeverWarn RaspberryPi;
- FeverWarn DataHub RaspberryPi;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Missing Authentication for Critical Function (CVE-2023-6221)/súlyos;
- Use of Hard-coded Credentials (CVE-2023-46706)/kritikus;
- Missing authentication for Critical Function (CVE-2023-49617)/kritikus;
- Missing authentication for Critical Function (CVE-2023-49115)/súlyos;
- Improper Access Control (CVE-2023-47867)/súlyos;
- Improper Input Validation (CVE-2023-49610)/súlyos;
Javítás: Nincs
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-24-025-01

Bejelentés dátuma: 2024.01.25.
Gyártó: SystemK
Érintett rendszer(ek):
- NVR 504 2.3.5SK.30084998-as verziója;
- NVR 508 2.3.5SK.30084998-as verziója;
- NVR 516 2.3.5SK.30084998-as verziója;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Command Injection (CVE-2023-7227)/kritikus;
Javítás: Nincs információ.
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-24-025-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.

Nemrég írtam én is arról, hogy a 2022 őszi, ukrán villamosenergia-rendszer elleni Sandworm-kibertámadások során már nem valamilyen malware-t vetettek be (mint 2015-ben a BlackEnergy-t, 2016-ban az Industroyer-t, 2022 tavaszán pedig az Industroyer2-t és a PipeDream-et), hanem a célpont rendszerekben megtalálható legitim szoftvereket használták fel a támadáshoz (Living-of-the-Land támadási mód).

Nem sokkal az incidens részleteinek publikálása után jelent meg egy cikk Dean Parsons-tól, a SANS ICS biztonsági képzési programjának egyik kulcsemberétől egy cikk, amiben a Living-of-the-Land támadások alapjait ismerteti (legitim felhasználónevek és jelszavak, ICS/OT protokollok, scriptelési lehetőségek, mérnöki folyamatvezérlő alkalmazások támadásra történő felhasználási lehetőségei, példák LotL-támadásokra) és ami még fontosabb, tanácsokat is ad arra vonatkozóan, hogyan lehet védekezni a LotL-támadások ellen:

- Értsük meg az adott ICS/OT rendszerben használt ipari protokollok működését és felépítését;
- Erősítsük meg a kritikus ICS/OT rendszereink/eszközeink védelmét;
- Fejlesszük az ICS/OT rendszereink védelméért felelős kollégák tudását és képességeit;
- Monitorozzuk a legfontosabb ipari eszközeink adatforrásait;
- Készítsünk el és folyamatosan tartsuk napra készen az ICS/OT-specifikus incidens-kezelési terveinket (és, teszem hozzá én, fordítsunk különösen nagy figyelmet a tervek begyakoroltatására az összes érintett kollégával!);
- Aktívan keressük az ICS/OT rendszereinkre leselkedő fenyegetéseket a hálózatainkban (ICS threat hunting).

Bejelentés dátuma: 2024.01.16.
Gyártó: SEW-EURODRIVE
Érintett rendszer(ek):
- MOVITOOLS MotionStudio 6.5.0.2-es verziója;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Improper Restriction of XML EXTERNAL Entity Reference (CVE-2023-6926)/közepes;
Javítás: Nincs információ.
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-24-016-01

Bejelentés dátuma: 2024.01.16.
Gyártó: Integration Objects
Érintett rendszer(ek):
- OPC UA Server Toolkit minden verziója;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Improper Output Neutralization for Logs (CVE-2023-7234)/közepes;
Javítás: Nincs információ.
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-24-016-02

Bejelentés dátuma: 2024.01.18.
Gyártó: AVEVA
Érintett rendszer(ek):
- PI Server 2023;
- PI Server 2018 SP3 P05-ös és korábbi verziói;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Improper Check or Handling of Exceptional Conditions (CVE-2023-34348)/súlyos;
- Missing Release of Resource after Effective Lifetime (CVE-2023-31274)/közepes;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-24-018-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.

Egy 2020-ban megjelent tanulmány (én a LinkedIn-en találtam, a hivatkozás is az oda feltöltött dokumentumra mutat) szerint ennyi idő kell ahhoz, hogy egy támadó brute-force módszerekkel, két sérülékenységet kihasználva hozzáférést tudjon szerezni egyes Siemens HMI-okon, amik lehetővé teszik, hogy nem csak az Sm@rtClient alkalmazással, hanem VNC-vel is távoli hozzáférést lehessen felépíteni az érintett HMI-okon futó SM@rtServer funkcióhoz. Ráadásul ehhez elég az a Hydra nevű eszköz, amit a szabadon és ingyen letölthető Kali Linux nevű penteszter platformmal bárki használhat (még én is tudok így tesztelni, pedig még a legnagyobb jóindulattal is elég távol állok attól, hogy penteszternek vagy etikus hackernek lehessen nevezni).

Az említett sérülékenységek a CVE-2020-15786 (ez teszi lehetővé a brute-force jelszótörést) és a CVE-2020-15787, ami a VNC használatakor csonkolja a 8 karakternél hosszabb jelszavakat 8 karakteresre.

Mit lehet tenni az ilyen sérülékenységekkel és az általuk okozott kockázatokkal? Alapvető biztonsági szabályok betartásával jelentős kockázatcsökkentést lehet elérni:

- Ne csatlakoztassunk ipari folyamatirányító rendszereket publikus (pl. Internet) vagy irodai/IT hálózatokra. Ha mégis muszáj Interneten keresztül távkezelési lehetőséget biztosítani az OT szakterületen dolgozó kollégák számára, akkor mindenképp erős titkosítással konfigurált site-to-site VPN vagy erős titkosítással és több faktoros authentikációval védett SSL VPN kapcsolattal biztosítsuk, hogy csak az arra feljogosított felhasználók próbálhassanak meg authentikálni az érintett folyamatvezérlő rendszerekben.
- A folyamatirányító rendszerek hálózatát megfelelő szintű tűzfalazással válasszuk le a folyamatirányító rendszerek hálózatától. Amennyiben lehetséges, használjunk erős (több faktoros) authentikációt biztosító privilégizált felhasználó menedzsment rendszert az ipari rendszerek távoli hozzáférése során.

Az eset részleteiről a Bristol-i egyetem munkatársainak, Joseph Gardiner és Awais Rashid publikációjában lehet olvasni ami a fenti linken érhető el.

Bejelentés dátuma: 2024.01.11.
Gyártó: Siemens
Érintett rendszer(ek):
- Spectrum Power 7 minden verziója;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Incorrect Permission Assignment for Critical Resource (CVE-2023-44120)/súlyos;
Javítás: Elérhető
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2024.01.11.
Gyártó: Siemens
Érintett rendszer(ek):
- SIMATIC CN 4100 minden, V2.7-nél korábbi verziója;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Authorization Bypass Through User-Controlled Key (CVE-2023-49251)/súlyos;
- Improper Input Validation (CVE-2023-49252)/súlyos;
- Use of Default Credentials (CVE-2023-49621)/kritikus;
Javítás: Elérhető
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2024.01.11.
Gyártó: Siemens
Érintett rendszer(ek):
- JT2Go minden, V14.3.0.6-nál korábbi verziója;
- Teamcenter Visualization V13.3 minden, V13.3.0.13-nál korábbi verziója;
- Teamcenter Visualization V14.1 minden, V14.1.0.12-nél korábbi verziója;
- Teamcenter Visualization V14.2 minden, V14.2.0.9-nél korábbi verziója;
- Teamcenter Visualization V14.3 minden, V14.3.0.6-nál korábbi verziója;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Out-of-bounds Read (CVE-2023-51439)/súlyos;
- NULL Pointer Dereference (CVE-2023-51744)/alacsony;
- Stack-based Buffer Overflow (CVE-2023-51745)/súlyos;
- Stack-based Buffer Overflow (CVE-2023-51746)/súlyos;
Javítás: Elérhető
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2024.01.11.
Gyártó: Siemens
Érintett rendszer(ek):
- Solid Edge SE2023 minden, V223.0 Update 10-nél korábbi verziója;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Heap-based Buffer Overflow (CVE-2023-49121)/súlyos;
- Heap-based Buffer Overflow (CVE-2023-49122)/súlyos;
- Heap-based Buffer Overflow (CVE-2023-49123)/súlyos;
- Out-of-bounds Read (CVE-2023-49124)/súlyos;
- Out-of-bounds Read (CVE-2023-49126)/súlyos;
- Out-of-bounds Read (CVE-2023-49127)/súlyos;
- Out-of-bounds Write (CVE-2023-49128)/súlyos;
- Stack-based Buffer Overflow (CVE-2023-49129)/súlyos;
- Access of Uninitialized Pointer (CVE-2023-49130)/súlyos;
- Access of Uninitialized Pointer (CVE-2023-49131)/súlyos;
- Access of Uninitialized Pointer (CVE-2023-49132)/súlyos;
Javítás: Elérhető
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2024.01.11.
Gyártó: Siemens
Érintett rendszer(ek):
- CP-8031 MASTER MODULE (6MF2803-1AA00) minden, CPCI85 V05.20-asnál korábbi verziója;
- CP-8050 MASTER MODULE (6MF2805-0AA00) minden, CPCI85 V05.20-asnál korábbi verziója;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Use of Uninitialized Resource (CVE-2023-42797)/közepes;
Javítás: Elérhető
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2024.01.11.
Gyártó: Siemens
Érintett rendszer(ek):
- SIMATIC IPC647E minden, V4.14.00.26068-nál korábbi verziója;
- SIMATIC IPC847E minden, V4.14.00.26068-nál korábbi verziója;
- SIMATIC IPC1047E minden, V4.14.00.26068-nál korábbi verziója;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Improper Input Validation (CVE-2023-51438)/kritikus;
Javítás: Elérhető
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2024.01.11.
Gyártó: Horner Automation
Érintett rendszer(ek):
- Cscape 9.90 SP10-es és korábbi verziói;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Stack-Based Buffer Overflow (CVE-2023-7206)/súlyos;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-24-011-04

Bejelentés dátuma: 2024.01.11.
Gyártó: Rapid Software LLC
Érintett rendszer(ek):
- Rapid SCADA 5.8.4-es és korábbi verziói;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Path Traversal (CVE-2024-21852)/súlyos;
- Relative Path Traversal (CVE-2024-22096)/közepes;
- Local Privilege Escalation through Incorrect Permission Assignment for Critical Resource (CVE-2024-22016)/súlyos;
- Open Redirect (CVE-2024-21794)/közepes;
- Use of Hard-coded Credentials (CVE-2024-21764)/kritikus;
- Plaintext Storage of a Password (CVE-2024-21869)/közepes;
- Generation of Error Message Containing Sensitive Information (CVE-2024-21866)/közepes;
Javítás: Nincs információ
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-24-011-03

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.

Ez a poszt eredetileg csak későbbre volt ütemezve, de látva, hogy egész érdekes beszélgetés kerekedett itt-ott a múlt heti, ICS/OT patch-elésről szóló posztról, úgy döntöttem, hogy érdemes előrébb hozni ez a mai írást. Főleg, mert szinte azonnal felmerült egy kérdés, ami persze várható volt: "Mégis mit tegyünk, ha valamilyen ok miatt nem patch-elhetünk?"

Ezzel kapcsolatban a Tripwire oldalán találtam egy cikket, ami persze magát a cég szolgáltatásait hivatott promózni, de ettől függetlenül is tartalmaz értékelhető gondolatokat a témában.

A bevezetőben a patch-elés előnyeit és kockázatait tekintik át, majd az IT és OT biztonsági szempontok közötti különbségeket (CIA kontra AIC háromszögek) mutatják be. A lényegi rész ezután következik, 6 kompenzáló intézkedést mutatnak be, mint a nem megvalósítható patch-elés alternatíváit:

- Eszköz-felderítés és menedzsment;
- Határvédelem;
- Hálózatszegmentálás;
- Naplómenedzsment;
- Sérülékenység-elemzés;
- Fájl-integritás monitoring;

Ezeknek az intézkedéseknek egy jelentős részét ma már a legalapvetőbb ICS/OT biztonsági program keretében a legtöbb ipari szervezet/kritikus infrastruktúra remélhetőleg már megvalósította és gyakorolja, ez a cikk inkább azt próbálja bemutatni, hogy milyen további előnyei lehetnek ezeknek a biztonsági kontroll-rendszereknek.

Bejelentés dátuma: 2023.12.21.
Gyártó: Mitsubishi Electric
Érintett rendszer(ek):
- GT SoftGOT2000 1.275M-től 1.290C-ig terjedő verziói;
- OPC UA adatgyűjtő SW1DND-DCOPCUA-M és SW1DND-DCOPCUA-MD moduljainak 1.04E és korábbi verziói;
- MX OPC Server UA szoftver MC Works64-el együtt használt verziói SW4DND-MCWDV-MT moduljainak 3.05F és későbbi verziói;
- OPC UA szerverek RD81OPC96 moduljának minden verziója;
- FX5-OPC 1.006-os és korábbi verziói;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Observable Timing Discrepancy (CVE-2022-4304)/közepes;
- Double Free (CVE-2022-4450)/súlyos;
- Type Confusion (CVE-2023-0286)/súlyos;
Javítás: Részben elérhető.
Link a publikációhoz: Mitsubishi Electric, ICS-CERT

Bejelentés dátuma: 2024.01.04.
Gyártó: Rockwell Automation
Érintett rendszer(ek):
- Factory Talk V4.00 verziója (a Wibu-Systems CodeMeter 7.60c-nél korábbi verzióit használó változat);
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Out-of-Bounds Write (CVE-2023-38545)/kritikus;
- Out-of-Bounds Write (CVE-2023-3935)/súlyos;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-24-004-01

Bejelentés dátuma: 2024.01.05.
Gyártó: Moxa
Érintett rendszer(ek):
- PT-G503 sorozatú eszközök 5.2-es és korábbi firmware-verziói;
- PT-7728 sorozatú eszközök 3.8-as és korábbi firmware-verziói;
- PT-7828 sorozatú eszközök 3.10-es és korábbi firmware-verziói;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Inadequate Encryption Strength (CVE-2005-4900)/közepes;
- Cross-site Scripting (CVE-2015-9251)/közepes;
- Prototype Pollution (CVE-2019-11358)/közepes;
- Cross-site Scripting (CVE-2020-11022)/közepes;
- Cross-site Scripting (CVE-2020-11023)/közepes;
- Sensitive Cookie Without 'HttpOnly' Flag (CVE-2023-4217)/közepes;
- Sensitive Cookie in HTTPS Session Without 'Secure' Attribute (CVE-2023-5035)/közepes;
Javítás: Elérhető
Link a publikációhoz: Moxa

Bejelentés dátuma: 2024.01.09.
Gyártó: Schneider Electric
Érintett rendszer(ek):
- Easergy Studio v9.3.5-nél korábbi verziói;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Deserialization of untrusted data (CVE-2023-7032)/súlyos;
Javítás: Elérhető
Link a publikációhoz: Schneider Electric

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.

Évről-évre egyre több sérülékenységről jelennek meg információk és ez a probléma már régóta nem csak az IT rendszerek sajátja (nehéz is lenne, ha figyelembe vesszük, hogy az ICS/OT rendszerek egyre nagyobb hányada használ OT komponenseket). Ha pedig egyre több a sérülékenység, akkor érthető módon jelenik meg az igény ezeknek a hibáknak a javítására (ha rendelkezésre áll a javítás az adott hibára) vagyis a patch-elésre. A kérdés csak az, hogyan csináljuk?

Kézenfekvő lenne a válasz, hogy kérjünk karbantartási ablakot az adott rendszer üzemeltetőitől/felelősétől, telepítsük a patch-eket. Ez - legalább is azok számára, akik IT rendszereken tanulták ki a sérülékenység-menedzsmentet - egyértelműnek tűnik, de ICS/OT rendszerek esetén ugyanez a tevékenység több részleten is elbukhat, ilyenek, a teljesség igénye nélkül:

• Nincs fejlesztői/teszt rendszer;
• A következő fél-egy évben nincs betervezett karbantartás, így karbantartási ablak sem;
• Az ICS/OT rendszer gyártója (még) nem vizsgálta be az adott hibát javító patch-et, ezért annak a telepítése súlyos negatív következményekkel (üzembiztonsági kockázat, safety kockázat, funkcióvesztés, garanciavesztés, stb.) járhat;

Részben ezek miatt érdemes a (bármilyen) folyamatvezérlő rendszereket üzemeltető szervezeteknek egy külön, OT rendszerekre vonatkozó sérülékenység-menedzsment eljárást kidolgozniuk, begyakorolniuk és alkalmazniuk. Egy ilyen eljárás jellemzően az alábbi lépésekből állhat (ezek egy jó része ismerős lehet egy jobb IT sérülékenység-menedzsment eljárásból):

1. Folyamatosan kövessük nyomon, hogy milyen ICS/OT sérülékenységekről jelennek meg információk (ehhez figyelhetjük a mi szervezetünk által használt OT rendszerek gyártóinak közleményeit és például az ICS-CERT publikációit is);
2. Vizsgáljuk meg, hogy egy adott ICS/OT sérülékenység érinti-e a szervezetünk által használt ICS/OT rendszereket (ehhez mondjuk nem árt egy naprakész eszközleltárral rendelkezni, de tapasztalataim szerint egy ilyen kialakítani és folyamatosan frissíteni egy meglehetősen komoly kihívásnak minősül szinte minden szervezet számára...);
3. Ha a sérülékenység jelen van az ICS/OT rendszereinkben, akkor következhet a kockázatelemzés. Az elemzés során több kérdésre érdemes választ keresni, ilyenek lehetnek egyebek mellett:

• Melyik rendszer(ek) érintett(ek)?
• Mikor működnek az érintett rendszerek éles üzemben?
• Léteznek-e és elérhetőek-e kompenzáló/alternatív kontrollok a sérülékenység okozta kockázatok csökkentésére?
• A sérülékenység hatására nőnek-e az ICS/OT rendszerekkel kapcsolatba kerülő emberek életét és/vagy testi épségét (safety) fenyegető kockázatok?
• Milyen következményei lehetnek, ha valaki kihasználja az adott sérülékenységet;

Fontos, hogy egy ICS/OT kockázatelemzés lefolytatásához minden érintett szakembert vonjunk be, mert csak úgy fogunk pontos kockázati eredményeket kapni, ha mindenkit (pl. OT mérnököket mindenképp) bevonunk az elemzésbe, akik a különböző szakterületeket és különböző nézőpontokat, szempontokat, prioritásokat megfelelően képviselni tudják.

A kockázatelemzés végén, a pontos kockázatokat ismerve és az adott ICS/OT rendszer (és az általa automatizált folyamatok) felelősével, mint az elemzés során vizsgált kockázatokat viselő felelős vezetőkkel egyeztetve válaszokat kell találni a következő kérdésekre:

• Szükséges-e változtatásokat tervezni a sérülékenység javítása érdekében?
• Ha szükséges, milyen gyorsan kell ezt megtenni?

Amint megvannak a válaszaink a fenti kérdésekre, lehet tervezni a további lépéseket.

Azt hiszem, a fentiekből is látszik, hogy az IT-OT konvergencia fejlődésével az olyan feladatok terén, mint az ICS/OT sérülékenység-menedzsment is egyre több hasonlóságot lehet felfedezni az IT és OT rendszerek között, ugyanakkor a különbségek ezek ellenére sem tűnnek el és ezeket a különségeket nem szabad sem figyelmen kívül hagyni, sem a fontosságukat kisebbíteni, különben nagyon komoly (esetenként akár safety) kockázatokat okozhat egy teljesen jóindulatú, de nem kellően körültekintően kezdeményezett változtatás. Emlékezzünk Joe Weiss egyik fontos gondolatára: attól, hogy egy incidens kiváltó oka egy nem rosszindulatú változtatás volt, attól az még incidens!

Bejelentés dátuma: 2023.12.23.
Gyártó: Moxa
Érintett rendszer(ek):
- Moxa ioLogik E1200 sorozatú eszközök v3.3-as és korábbi firmware-verziói;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Cross-Site Request Forgery (CVE-2023-5961)/súlyos;
- Use of a Broken or Risky Cryptographic Algorithm (CVE-2023-5962)/közepes;
Javítás: Elérhető a Moxa Technical Support-nál.
Link a publikációhoz: Moxa

Bejelentés dátuma: 2023.12.29.
Gyártó: Moxa
Érintett rendszer(ek):
- OnCell G3150A-LTE sorozatú eszközök v1.3-as és korábbi firmware-verziói;
Sérülékenység(ek) neve/CVSSv3 szerinti besorolása:
- Cryptographic Issues (CVE-2004-2761)/n/a;
- Inadequate Encryption Strength (CVE-2013-2566)/közepes;
- Exposure of Sensitive Information to an Unauthorized Actor (CVE-2016-2183)/súlyos;
- Clickjacking (CVE-2023-6093)/közepes;
- Cleartext Transmission of Sensitive Information (CVE-2023-6094)/közepes;
Javítás: Elérhető a Moxa Technical Support-nál.
Link a publikációhoz: Moxa

A fenti sérülékenységekkel kapcsolatban az ICS-CERT az alábbi kockázatcsökkentő intézkedések fontosságát hangsúlyozza:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- Az ipari/egészségügyi rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari/egészségügyi rendszerek/hálózatok távoli eléréséhez biztonságos módszereket (pl. VPN) kell használni, de szem előtt kell tartani azt is, hogy az egyes VPN-megoldásoknak is lehetnek sérülékenységeik és ezeket is folyamatosan frissíteni kell a legújabb elérhető verzióra. Nem szabad elfelejteni továbbá azt sem, hogy a VPN csak annyira biztonságos megoldás, mint az eszköz, amit a VPN-en keresztül a védett hálózathoz csatlakoztatnak;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgáltatások hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználókezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (valamilyen szinten tűzálló páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Az ISA/IEC-62443-3-3 bemutatása

https://icscybersec.blog.hu/2023/10/14/ics-biztonsagi-szabvanyok-xviii

után most következzen a 4-2.

A 4-2 az ipari automatizálási és vezérlő rendszerek (Industrial Automation and Control Systems, IACS) komponenseivel kapcsolatos műszaki-biztonsági követelményeket tartalmazza.A komponensek ebben az esetben egyaránt fedik az IACS-kategóriába tartozó szoftveralkalmazásokkal, beágyazott eszközökkel, hostokkal és hálózati eszközökkel kapcsolatos követelményeket. A 4-2-ben leírt követelmények az előzőekben felsorolt 4 komponens-típus esetén azonosak, ahol a komponens-típus alapján különbséget kell tenni a típusokra vonatkozó követelmények között.

A 3-3-hoz hasonlóan a 4-2 is 4 biztonsági szintbe (Security Level, SL-1-től SL-4-ig) sorolja az egyes IACS komponenseket annak érdekében, hogy a különböző biztonsági szintekhez esetenként eltérő követelményeket lehessen társítani és szintén a 3-3-hoz hasonlóan az 1-1-es részben ismertetett funkcionális követelmények (FR, Functional Requirements) részletes követelményeit ismerteti. Az CR fejezet és alfejezt után az RE a követelmény kifejtését (Requirement enhancement) tartalmazza, a fent ismertetett SL-szinteknek megfelelően, az alábbiak szerint:

FR 1 – Identification and authentication control

CR 1.1 – Human user identification and authentication
CR 1.2 – Software process and device identification and authentication
CR 1.3 – Account management
CR 1.4 – Identifier management
CR 1.5 – Authenticator management
CR 1.6 – Wireless access management
CR 1.7 – Strength of password-based authentication
CR 1.8 – Public key infrastructure certificates
CR 1.9 – Strength of public key-based authentication
CR 1.10 – Authenticator feedback
CR 1.11 – Unsuccessful login attempts
CR 1.12 – System use notification
CR 1.13 – Access via untrusted networks

FR 2 – Use control

CR 2.1 – Authorization enforcement
CR 2.2 – Wireless use control
CR 2.3 – Use control for portable and mobile devices
CR 2.4 – Mobile code
CR 2.5 – Session lock
CR 2.6 – Remote session termination
CR 2.7 – Concurrent session control
CR 2.8 – Auditable events
CR 2.9 – Audit storage capacity
CR 2.10 – Response to audit processing failures
CR 2.11 – Timestamps
CR 2.12 – Non-repudiation
CR 2.13 – Use of physical diagnostic and test interfaces

FR 3 – System integrity

CR 3.1 – Communication integrity
CR 3.2 – Protection from malicious code
CR 3.3 – Security functionality verification
CR 3.4 – Software and information integrity
CR 3.5 – Input validation
CR 3.6 – Deterministic output
CR 3.7 – Error handling
CR 3.8 – Session integrity
CR 3.9 – Protection of audit information
CR 3.10 – Support for updates
CR 3.11 – Physical tamper resistance and detection
CR 3.12 – Provisioning product supplier roots of trust
CR 3.13 – Provisioning asset owner roots of trust
CR 3.14 – Integrity of the boot process

FR 4 – Data confidentiality

CR 4.1 – Information confidentiality
CR 4.2 – Information persistence
CR 4.3 – Use of cryptography

FR 5 – Restricted data flow

CR 5.1 – Network segmentation
CR 5.2 – Zone boundary protection
CR 5.3 – General-purpose person-to-person communication restrictions
CR 5.4 – Application partitioning

FR 6 – Timely response to events

CR 6.1 – Audit log accessibility
CR 6.2 – Continuous monitoring

FR 7 – Resource availability

CR 7.1 – Denial of service protection
CR 7.2 – Resource management
CR 7.3 – Control system backup
CR 7.4 – Control system recovery and reconstitution
CR 7.5 – Emergency power
CR 7.6 – Network and security configuration settings
CR 7.7 – Least functionality
CR 7.8 – Control system component inventory

Ahogy korábban már szóba került, a 4 IACS-típushoz külön-külön is tartozhatnak komponens-szintű biztonsági követelmények:

Software application requirements

SAR 2.4 – Mobile code
SAR 3.2 – Protection from malicious code

Embedded device requirements

EDR 2.4 – Mobile code
EDR 2.13 – Use of physical diagnostic and test interfaces
EDR 3.2 – Protection from malicious code
EDR 3.10 – Support for updates
EDR 3.11 – Physical tamper resistance and detection
EDR 3.12 – Provisioning product supplier roots of trust
EDR 3.13 – Provisioning asset owner roots of trust
EDR 3.14 – Integrity of the boot process

Host device requirements

HDR 2.4 – Mobile code
HDR 2.13 – Use of physical diagnostic and test interfaces
HDR 3.2 – Protection from malicious code
HDR 3.10 – Support for updates
HDR 3.11 – Physical tamper resistance and detection
HDR 3.12 – Provisioning product supplier roots of trust
HDR 3.13 – Provisioning asset owner roots of trust
HDR 3.14 – Integrity of the boot process

Network device requirements

NDR 1.6 – Wireless access management
NDR 1.13 – Access via untrusted networks
NDR 2.4 – Mobile code
NDR 2.13 – Use of physical diagnostic and test interfaces
NDR 3.2 – Protection from malicious code
NDR 3.10 – Support for updates
NDR 3.11 – Physical tamper resistance and detection
NDR 3.12 – Provisioning product supplier roots of trust
NDR 3.13 – Provisioning asset owner roots of trust
NDR 3.14 – Integrity of the boot process
NDR 5.2 – Zone boundary protection
NDR 5.3 – General purpose, person-to-person communication restrictions

A 3-3-hoz hasonlóan a 4-2 is licencdíj ellenében érhető el, így ehhez sajnos csak a hivatalos, ISA weboldalra mutató hivatkozást tudom bemásolni, ahol 294 amerikai dollárért lehet megvásárolni a szabványt.