Az ICS biztonság több, mint egy évtizedes története során folyamatosan azt lehet látni, hogy a vállalati IT rendszerek biztonságának javítására használt eszközöket (tűzfalakat, IDS/IPS rendszereket, adat-diódákat, SIEM rendszereket, végpontvédelmi megoldásokat, stb.) és megközelítéseket, módszereket és eljárásokat (sérülékenység vizsgálat, patch menedzsment, hardening, biztonságos hálózati architektúra-tervezés, stb.) próbálnak (próbálunk) meg bevezetni az OT hálózatok és ICS berendezések, rendszerek esetén. Ezek a próbálkozások hol több, hol kevesebb sikerrel járnak, gyakran éppen az ICS rendszerek vállalati IT rendszerekétől alapvetően eltérő működési jellemzői miatt.

Nem kifejezetten meglepő, hogy az IT biztonságban néhány éve megfogalmazott, ún. Zero trust-megközelítés esetében is felmerült, hogy alkalmazni kéne az ICS rendszerek és OT hálózatok biztonságosabbá tételére.

A Zero trust koncepció alapja az az elv, hogy a hálózaton belül és azon kívül elhelyezkedő és ezekről a helyekről kommunikáló felek közül senkiben nem bízunk, minden egyes erőforrás-hozzáféréshez az adott kommunikációs partner ellenőrzése és előzetes jóváhagyás szükséges.

Jake Brodsky, az amerikai ICS biztonsági közösség egyik veteránja egy nemrég publikált blogposztjában a Zero trust megközelítés ICS rendszerek esetében történő alkalmazhatóságát tekinti át. Végkövetkeztetése az, hogy a valósidejű (illetve közel valósidejű) kommunikációt igényő ICS rendszerek és berendezések esetén a Zero trust koncepciót nem lehet megvalósítani, de egyes esetekben (pl. esemény-orientált SCADA rendszerek esetén) lehetséges alkalmazni a Zero trust megközelítést.

B&R Automation rendszerek sérülékenysége

Az ABB csoporthoz tartozó B&R Automation egy sérülékenységről hozott nyilvánosságra információkat, ami az Automation Runtime 4.7x és korábbi verzióit érinti.

A gyártó a hibát javító patch-eket a 4.2x és újabb verziókhoz már elérhetővé tette (kivéve a 4.6x verziókat, amikhez várhatóan 2020. harmadik negyedévben adják ki majd ki). A sérülékenységről bővebben a B&R Automation publikációjában

https://www.br-automation.com/downloads_br_productcatalogue/assets/1595163815396-de-original-1.0.pdf

lehet olvasni.

Sérülékenység WECON rendszerekben

Natnael Samson a ZDI-vel együttműködve egy sérülékenységet jelentett a DHS CISA-nak, amit a WECON alábbi rendszereiben talált:

- LeviStudioU 2019-09-21-es és korábbi verziói.

A hibával kapcsolatban született gyártói megoldásokért a WECON ügyfélszolgálatát lehet megkeresni. A sérülékenységgel kapcsolatban további információkat az ICS-CERT bejelentése tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-20-238-03

Emerson SCADA rendszerek sérülékenysége

Roman Lozko, a Kaspersky munkatársa egy sérülékenységet jelentett az Emerson-nak, amit a gyártó OpenEnterprise SCADA rendszerének 3.3.5-ösnél korábbi verzióit érinti.

A gyártó a hibát a 3.3.6-os verzióban javította. A sérülékenység részleteit az ICS-CERT weboldalán lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-20-238-02

Advantech iView sérülékenység

KPC, a Trend Micro ZDI munkatársa egy sérülékenységet fedezett fel az Advantech iView 5.7-es és korábbi verzióiban.

A gyártó a hibát az 5.7.02-es verzióban javította. A sérülékenységgel kapcsolatban további információkat az ICS-CERT publikációjában lehet találni: https://us-cert.cisa.gov/ics/advisories/icsa-20-238-01

Sérülékenységek Red Lion N-Tron berendezésekben

Thomas Weber, a SEC Consult Vulnerability Lab munkatársa 5 sérülékenységről közölt információkat a DHS CISA-val, amik a Red Lion alábbi, ipari hálózati eszközeit érintik:

- N-Tron 702-W minden verziója;
- N-Tron 702M12-W minden verziója.

A gyártó a 702-W sorozat támogatását 2018-ban megszüntette, ezért hibajavítás sem fog érkezni hozzá. A sérülékenységgel kapcsolatos további részletek az ICS-CERT bejelentésében érhetőek el: https://us-cert.cisa.gov/ics/advisories/icsa-20-240-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.

Az idei DefCon a járványhelyzet miatt szintén virtuális konferencia formában került megrendezésre. Ahogy az elmúlt években egyre inkább ez volt a tendencia, idén is egyre több ICS biztonsági témájú előadás volt, elsősorban az ICS Village nevű szekcióban.

Az elsőadásokat a YouTube-on az alábbi videókban lehet megnézni:

1. nap: https://www.youtube.com/watch?v=PVV7Ich0Axk
2. nap: https://www.youtube.com/watch?v=wSKYXVq-NuI

Néhány érdekesebb előadás:

- Tim Yardley: Building a Physical Testbed for Blackstart Restoration under Cyber Fire
- Chris Kubecka: Operationalizing Cyber Norms: Critical Infrastructure Protection
- Octavio Fernander, Victor Gomez: Industrial Cybersecurity in Mexico
- Can Kurnaz: ICS SecOps: Active Defense Concept with Effective Incident Resoponse in Industrial Control Systems
- Marina Krotofil: Confessiona of an Offensive ICS Cyber Security Researcher
- Can Demirel, Serkan Temel: Playing with Electricity: Hacking into Distribution Companies
- atlas of d00m and ac0rn: Vivisecting PowerPC
- Marie Collins and Otis Alexander: MITRE ICS ATT&CK

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

A Cleveland Clinic munkatársai három sérülékenységet fedeztek fel a Philips SureSigns VS4 típusú, betegek életjeleit ellenőrző berendezéseinek A.07.107-es és korábbi firmware-verzióiban.

A gyártó a hibákkal kapcsolatban kockázatcsökkentő intézkedések bevezetését és a SureSigns VS4-es készülekek újabb technológiát képviselő modellekre történő cseréjét javasolja. A sérülékenységekről további információkat az ICS-CERT publikációja tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsma-20-233-01

Schneider Electric PACTware rendszerek sérülékenységei

A Schneider Electric bejelentése szerint két sérülékenységet találtak a PACTware termékeik alábbi verzióiban:

- Schneider Electric PACTware V5.0.5.30 és korábbi verziói;
- Schneider Electric PACTware V4.1 SP5 és korábbi verziói.

A gyártó a hibákat javító új verziókat már elérhetővé tette. A sérülékenységekkel kapcsolatban bővebb információkat a Schneider Electric bejelentésében

https://download.schneider-electric.com/files?p_enDocType=Technical+leaflet&p_File_Name=SEVD-2020-224-08_PACTware_Security_Notification.pdf&p_Doc_Ref=SEVD-2020-224-08

lehet olvasni.

Sérülékenységek Moxa NPort berendezésekben

A Moxa által közölt információk alapján Evgeniy Druzhinin és Ilya Karpov, a Rostelecom-Solar munkatársai hat sérülékenységet azonosítottak az NPort IAW5000A-I/O sorozatú eszközeik 2.1-es és korábbi firmware-verzióiban.

A gyártó a hibákat a legújabb elérhető firmware-verzióban javította. A sérülékenységekről bővebben a Moxa weboldalán

https://www.moxa.com/en/support/support/security-advisory/nport-iaw5000a-io-serial-device-servers-vulnerabilities

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.

Nagyjából múlt héten pénteken, kevesebb mint egy nappal az IT-OT különbségekről szóló poszt élesedése előtt került elém a Cyber Today-ben megjelent cikk Robert M. Lee (Dragos alapító-vezérigazgató, SANS ICS oktató) tollából, ami az IT és OT kiberbiztonság különbségeiről szól.

A cikk (szerintem) legfontosabb gondolatai az alábbiak:

- Bár nyilvánvalóan vannak olyan IT biztonsági területről származó tanulságok, amiket az OT kiberbiztonság területén is lehet hasznosítani, nem érdemes simán lemásolni a vállalati IT biztonsági stratégiát az OT és ICS biztonsági stratégiához;
- A korábbiaknál szorosabb és jobb szakmai és emberi kapcsolatokat kell építeni a kiberbiztonsági mérnökök és a folyamatirányítási rendszerekért felelős mérnökök (gépécszmérnökök, villamosmérnökök, stb.) között;
- Mielőbb hozzá kell kezdeni a fenti szakterületek mérnökei közötti tudás-transzfert. Mindkét terület mérnökeinek legalább alapszinten érteniük kell a másik terület főbb céljait, kihívásait.
- Az egyik legfontosabb, hogy az OT (ICS) kiberbiztonság kérdésére ne IT vagy OT kérdésként (rosszabb esetben harcként) tekintsenek az adott szervezet mérnökei és vezetői, hanem a két szakterület legjobbjainak közös erőfeszítéseként építsék fel ezt az új feladatkört.

Siemens SICAM RTU sérülékenység

Emma Good, a KTH Royal Institute of Technology munkatársa egy sérülékenységet talált a Siemens SICAM A8000 RTU-k SICAM WEB változatának C05.30-asnál korábbi firmware-verziójában.

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

Sérülékenység Siemens Automation License Manager termékben

Lasse Trolle Borup, a Danish Cyber Defense munkatársa egy sérülékenységet azonosított a Siemens Automation License Manager alábbi verzióiban:

- Automation License Manager 5 minden verziója;
- Automation License Manager 6 minden, v6.0.8-nál korábbi verziója.

A gyártó a hibát csak az ALM 6 esetében javította. A sérülékenység részleteiről a Siemens ProductCERT és az ICS-CERT bejelentéseiből lehet tájékozódni.

Siemens Desigo CC rendszerek sérülékenysége

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

- Desigo CC 3.x és 4.x verziók;
- Desigo CC Compact 3.x és 4.x verziók.

A gyártó a hibát javító patch-eket már elérhetővé tette. A sérülékenységről bővebben a Siemens ProductCERT és az ICS-CERT weboldalain lehet olvasni.

Sérülékenység Siemens rendszerekben

A Siemens egy sérülékenységet jelentett a DHS CISA-nak, ami az alábbi rendszereit érinti:

- SIMATIC RF350M minden verziója;
- SIMATIC RF650M minden verziója;
- SIMOTICS CONNECT 400 minden verziója.

A hibával kapcsolatban a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenység részleteit a Siemens ProductCERT és az ICS-CERT publikációiban lehet megtalálni.

Siemens termékek sérülékenysége

A Siemens egy sérülékenységet azonosított az alábbi termékeiben:

- RUGGEDCOM RM1224 minden, 6.3-nál korábbi verzió;
- SCALANCE M-800/S615 minden, 6.3-nál korábbi verzió.

A gyártó a hibát az érintett termékek 6.3-as verziójában javította. A sérülékenységről további információkat a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet elérni.

Sérülékenység Tridium Niagara rendszerekben

A Honeywell egy sérülékenységet jelentett a DHS CISA-nak, ami a Tridium Niagara alábbi verzióit érinti:

- Niagara 4.6.96.28, 4.7.109.20, 4.7.110.32 és 4.8.0.110;
- Niagara Enterprise Security 2.4.31, 2.4.45 és 4.8.0.35.

A gyártó kiadta a hibát javító újabb verziókat az érintett termékeihez. A sérülékenységről további információkat az ICS-CERT weboldalán lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-20-224-03

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

rgod, a ZDI-vel együttműködve két sérülékenységet talált a Schneider Electric APC Easy UPS On-Line szoftverének SFAPV9601 v2.0 és korábbi verzióiban.

A gyártó a hibával kapcsolatban minden érintett ügyfelének a mielőbb történő frissítést javasolja a legújabb elérhető verzióra. A sérülékenységek részleteiről a Schneider Electric és az ICS-CERT publikációiban lehet tájékozódni.

Yokogawa DCS rendszerek sérülékenységei

Nataliya Tlyapova, Ivan Kurnakov és a Positive Technologies két sérülékenység részleteit osztották meg a Yokogawa-val, amik CENTUM DCS rendszereiben:

- CENTUM CS 3000 R3.08.10 - R3.09.50 verziói (beleértve a CENTUM CS 3000 Entry Class verziókat is);
- CENTUM VP R4.01.00 - R6.07.00 verziói (beleértve a CENTUM CS 3000 Entry Class verziókat is);
- B/M9000CS R5.04.01 - R5.05.01 verziói;
- B/M9000 VP R6.01.01 - R8.03.01 verziói.

A gyártó a hibákat a legújabb elérhető verziókban javította. A sérülékenységekkel kapcsolatban további infomációkat az ICS-CERT bejelentésében lehet találni: https://us-cert.cisa.gov/ics/advisories/icsa-20-224-01

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

A Schneider Electric publikációja szerint egy sérülékenységet találtak a Modicon M218-as vezérlőik 5.0.0.7 és korábbi verzióiban.

A gyártó a hibát az 5.0.0.8-as verzióban javította. A sérülékenységről részleteket a Schneider Electric publikációja tartalmaz.

Schneider Electric Modbus meghajtó szoftverek sérülékenysége

Nicolas Delhaye, az Airbus Cybersecurity munkatársa egy sérülékenységet jelentett a Schneider Electric-nek, ami a gyártó alábbi Modbus meghajtó szoftvereit érinti:

- Schneider Electric Modbus soros meghajtó (64 bites változat) V3.20 IE 30-nál korábbi verziói;
- Schneider Electric Modbus soros meghajtó (32 bites változat) V3.20 IE 30-nál korábbi verziói;
- Schneider Electric Modbus Driver Suite V14.15.0.0-nál korábbi verziói.

A gyártó a hibát a Modbus Driver Suite V14.15.0.0 verziójá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 termékekben

Ismail Tasdelen egy sérülékenységet talált a Schneider Electric alábbi rendszereinek minden hardveres verziójában:

- spaceLYnk;
- Wiser for KNX (korábbi nevén homeLYnk).

A gyártó a hibát a 2.5.1-es verzióban javította. A sérülékenység részleteit a Schneider Electric weboldalán lehet elolvasni.

Schneider Electric PowerChute Business Edition sérülékenység

Mateus Riad egy sérülékenységet fedezett fel a Schneider Electric PowerChute Business Edition V9.0.x és korábbi verzióiban.

A gyártó a hibát a V9.1-es és újabb verzióiban javította, az érintett termékek felhasználóinak 64-bites rendszer esetén használata esetén a V.10.x-nél, 32-bites rendszer esetén a V9.5-nél újabb verziókra történő frissítést javasolja. A sérülékenységgel kapcsolatos további információkat a Schneider Electric publikációjában lehet megtalálni.

Schneider Electric SoMove sérülékenység

Luis Alvernaz egy sérülékenységről közölt információkat a Schneider Electric-nek, ami a SoMove V2.8.1 és korábbi verzióit érinti.

A gyártó a hibát a V2.8.2-es 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 Harmony eXLhoist termékekben

A Schneider Electric publikációja szerint a Harmony eXLhoist termékek V04.00.02.00 és korábbi firmware-verzióját használó, alábbi modellek érintettek a SweynTooth nevű Bluetooth sérülékenység által:

- ZARB12W;
- ZARB12H;
- ZARB18H;
- ZARB18W;
- ZARB18HM;
- ZARB18WM.

A Harmony eXLhoist compact range modelleket nem érinti a sérülékenység.

A gyártó a hibát a V04.00.03.00 firmware-verzióban javította. A sérülékenységről további részleteket a Schneider Electric publikációja tartalmaz.

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.

Sokszor, sokan teszik fel a kérdést, hogy miért olyan nagyon más az OT (vagy ICS) biztonság, mint az IT biztonság, miért nem lehet egyszerűen ugyanazokat a megoldásokat és eljárásokat alkalmazni az ICS biztonság területén, amikkel már évtizedes tapasztalatokkal rendelkeznek az IT biztonsági szakemberek? A mai posztban ezt fogjuk röviden áttekinteni.

Talán a legfontosabb kérdés és egyben a legfontosabb különbség: mi a tevékenység célja az IT és az OT esetén? Az IT elsősorban adatokkal dolgozik, míg az OT rendszerek jellemzően fizikai folyamatok irányításáért felelősek. Ebből adódik az eltérő biztonsági szempontrendszer is. Az IT rendszerek esetén az információ/IT biztonságból ismerős CIA (Confidentiality, Integrity, Availability vagy magyarul BSR, Bizalmasság, Sértetlenség, Rendelkezésre állás) hármas adja a biztonsági szempontokat, az OT esetén viszont nem csak a CIS/BSR sorrendje változik (jellemzően fordul a sorrend és a rendelkezésre állás a legfontosabb, utána következik a sértetlenség és a bizalmasság a legtöbb esetben a legkevésbé fontos), de megjelenik két, ezeknél sokkal fontosabb biztonsági szempont, a safety (az OT rendszerek által vezérelt fizikai folyamatokkal kapcsolatba kerülő emberek életének és testi épségének a védelme) az elsődleges és a megbízhatóság (reliability) is jellemzően legalább annyira fontos, mint a rendelkezésre állás.

Jelentős különbség van az IT és OT rendszerek üzemeltetési körülményeiben is. Míg az IT rendszerek jellemzően stabil környezeti körülmények között, informatikai géptermekben, stabil klimatizálás és jól kontrollált hőmérsékleti és páratartalom mellett üzemelnek, addig az OT rendszerek működésében gyakorlatilag bármilyen, esetenként kifejezetten zord körülmények között (pl. összeszerelő üzemekben, villamosipari vagy viziközmű alállomásokon, szennyvíztelepeken vagy akár olajfúró tornyokon, a tenger közepén) is működőképesek kell, hogy maradjanak. Emiatt születtek meg az ún. ruggedized eszközök, amiket kifejezetten a mostoha környezeti körülmények között üzemelő OT rendszerekhez fejlesztettek.

Ezeknek a követelményeknek megfelelően különbözek az alkalmazott hardver eszközök és szoftverek az IT és OT rendszerek között. Az IT rendszerek esetén a megszokott hardvereket, szoftvereket és a szabványos IT protokollokat használják - ezek mind jól dokumentáltak és szinte minden dokumentáció szabadon elérhető. Az OT rendszerek esetében gyakran külön szabadalmaztatott, kizárólag az adott gyártóra jellemző egyedi hardver- és szoftver-megoldások, sokszor pedig a gyártó saját protokolljaira épülő rendszerek a jellemzőek, amiknél erősen korlátozott lehet a dokumentációhoz való hozzáférés is. Ennek egyébként egyik következménye lehet, hogy míg az IT rendszerek közötti együttműködés többnyire biztosított és legrosszabb esetben is egy nem túl bonyolult egyedi interfész-fejlesztéssel biztosítható, addig az OT rendszerek közötti kompatibilitási probléma sokkal gyakrabban és sokkal jelentősebb problémát okozhat.

A következő (és talán az egyik legnagyobb kihívást jelentő) különbség az IT és OT rendszereket tervező és üzemeltető mérnökök gondolkodásában található. Az IT-s mérnökök gondolkodásának középpontjában a hálózat illetve az alkalmazások állnak. Ezzel szemben az OT-s mérnökök gondolkodása az irányított fizikai folyamatokra illetve az azokkal kapcsolatban lévő, ipari folyamatirányításban kulcsfontosságú hardvere. Az OT rendszerek tervezésbe esetében a LAN hálózatok nagyon sokáig nem számítottak szempontnak - részben ebből is adódik a mai OT biztonsági kihívások egy jelentős része.

Egy újabb látványos különség az IT és OT rendszerek életciklusa. Napjainkban a legtöbb IT rendszert 3-5 évre tervezik és ennyi idő után már a lecserélése a feladat és ezeknél a rendszereknél igen gyakori karbantartási ablakok vannak (elég csak a Microsoft Windows-alapú rendszerek havi hibajavítási ciklusára gondolni, ami biztosan újraindítással jár). Ezzel szemben az OT rendszerek életciklusa minimálisan 10, de inkább 15-20 év és én már hallottam nem olyan régen 24-25 éves élettartamra tervezett rendszerekről illetve berendezésekről is, ráadásul ezt az élettartamot sokkal ritkább (nem ritkán évente vagy több évente egyszer esedékes) karbantartásokkal kell teljesíteni.

Ezeken kívül még számos kisebb-nagyobb különbség van az IT és OT rendszerek között, de talán azoknak, akik csak most ismerkednek az OT (ICS) kiberbiztonság világával, bevezetésnek elég lehet - ha van rá igény, akár folytathatom is ennek a témának a boncolgatását.

Sérülékenységek Siemens SPPA-T3000 rendszerekben

A Siemens ProductCERT publikációja szerint az alábbi SPPA-T3000-es rendszereiket érintik a JSOF kutatólabor által felfedezett és Ripple20 névre keresztelt sérülékenység illetve az Intel által közzétett Server Platform Services-t érintő hiba:

- SPPA-T3000 Application Server minden verziója;
- SPPA-T3000 Terminal Server minden verziója;
- SPPA-T3000 APC UPS AP9630 vagy AP9631 típusú NMC kártyákkal szerelt változatai.

A hibákkal kapcsolatban a gyártó 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 publikációja tartalmaz.

Moxa ipari routerek sérülékenység

Tal Keren, a Claroty munkatársa egy sérülékenységet jelentett a Moxa-nak, ami a gyártó alábbi ipari routereit érinti:

- EDR-G902 sorozatú eszközök 5.4-es és korábbi firmware verziói;
- EDR-G903 sorozatú eszközök 5.4-es és korábbi firmware verziói.

A hibával kapcsolatban a gyártó elérhetővé tette az azt javító patch-et. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT bejelentésében lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-20-196-02

Sérülékenységek Advantech iView rendszerekben

rgod, a ZDI-vel együttműködve 6 sérülékenységet jelentett a DHS CISA-nak az Advantech iView rendszerének 5.6-os és korábbi verzióival kapcsolatban.

A hibákat a gyártó az iView 5.7-es verziójában javította. A sérülékenységekről bővebben az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-196-01

Capsule Technologies rendszerek sérülékenysége

Patrick DeSantis, a Cisco Talos munkatársa egy sérülékenységről tett jelentést a Capsule Technologies felé, ami a gyártó SmartLinx Neuron 2 rendszerének 9.0-nál korábbi verzióit érinti.

A hibát a gyártó a 9.0 és újabb verziókban javította. A sérülékenységről további bővebb információkat az ICS-CERT publikációjában lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsma-20-196-01

Sérülékenységek Schneider Electric Triconex rendszerekben

Reid Wightman, a Dragos munkatársa 5 sérülékenységet fedezett fel a Schneider Electric Triconex safety termékcsaládjának alábbi tagjaiban:

- TriStation 1131, v1.0.0-től v4.9.0-ig terjedő, valamint v4.10.0 és 4.12.0 azon verziói, amik Windows NT, Windows XP és Windows 7 operációs rendszereken futnak;
- Tricon Communications Module (TCM) 4351-es, 4352-es, 4351A/B és 4352A/B modellek Tricon v10.0-tól v10.5.3-ig terjedő verzióira telepített rendszerek.

A gyártó a hibákat az érintett rendszerek újabb verzióiban javította. A sérülékenységekről további részleteket a Schneider Electric és az ICS-CERT bejelentései tartalmaznak.

HMS Industrial Networks rendszerek sérülékenységei

Sharon Brizinov, a Claroty munkatársa egy sérülékenységet azonosított a HMS Industrial Networks eCatcher VPN kliensének 6.5.5-nél korábbi verzióiban.

A gyártó a hibát a eCatcher 6.5.5-ös és újabb verzióiban javította. A sérülékenységgel kapcsolatosan bővebb információkat az ICS-CERT weboldalán lehet találni: https://us-cert.cisa.gov/ics/advisories/icsa-20-210-03

Sérülékenységek Softing Industrial Automation rendszerekben

Uri Katz, a Claroty munkatársa két sérülékenységet talált a Softing Industrial Automation OPC megoldásának minden, 4.47.0 verziójának legutolsó buildjénél korábbi verzióiban.

A gyártó a hibákat a legújabb verzióban javította. A sérülékenységek részleteit az ICS-CERT publikációjában lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-20-210-02

Secomea GateManager sérülékenységek

Sharon Brizinov és Tal Keren, a Claroty munkatársai négy sérülékenységet fedeztek fel a GateManager VPN szerver 9.2c-nél korábbi verzióiban.

A gyártó a hibákat a legújabb verzióban javította. A sérülékenységek részletiről az ICS-CERT bejelentésében lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-210-01

Mitsubishi Electric automatizálási rendszerek sérülékenysége

Mashav Sapir, a Claroty munkatársa egy sérülékenységet azonosított a Mitsubishi Electric alábbi rendszereiben:

- CW Configurator 1.010L és korábbi verziói;
- FR Configurator2 1.22Y és korábbi verziói;
- GX Works2 1.595V és korábbi verziói;
- GX Works3 1.063R és korábbi verziói;
- MELSEC iQ-R sorozatú Motion Module-ok minden verziója;
- MELSOFT iQ AppPortal minden verziója;
- MELSOFT Navigator minden verziója;
- MI Configurator minden verziója;
- MR Configurator2 minden verziója;
- MT Works2 1.156N és korábbi verziói;
- MX Component minden verziója;
- RT ToolBox3 1.70Y és korábbi verziói.

A gyártó a hiba javítását az alábbi termékek legújabb verziójában publikálta:

- CW Configurator;
- FR Configurator2;
- GX Works2;
- GX Works3;
- MT Works2;
- RT ToolBox3.

A sérülékenység részleteit az ICS-CERT weboldalán lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-20-212-03

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

Younes Dragoni, a Nozomi Networks munkatársa, az Applied Risk kutatócsoportja és Mashav Sapir, a Claroty munkatársa egy sérülékenységről közöltek információkat a Mitsubishi Electric-kel, ami a gyártó alábbi termékeit érinti:

- CPU Module Logging Configuration Tool 1.100E és korábbi verziói;
- CW Configurator 1.010L és korábbi verziói;
- Data Transfer 3.40S és korábbi verziói;
- EZSocket 4.5 és korábbi verziói;
- FR Configurator2 1.22Y és korábbi verziói;
- GT Designer3 Version1 (GOT2000) 1.235V és korábbi verziói;
- GT SoftGOT1000 minden verziója;
- GT SoftGOT2000 1.235 és korábbi verziói;
- GX LogViewer 1.100E és korábbi verziói;
- GX Works2 1.592S és korábbi verziói;
- GX Works3 1.063R és korábbi verziói;
- M_CommDTM-HART 1.00A verziója;
- M_CommDTM-IO-Link minden verziója;
- MELFA-Works 4.3 és korábbi verziói;
- MELSEC WinCPU Setting Utility minden verziója;
- MELSOFT EM Software Development Kit (EM Configurator) 1.010L és korábbi verziói;
- MELSOFT FieldDeviceConfigurator 1.03D és korábbi verziói;
- MELSOFT Navigator 2.62Q és korábbi verziói;
- MH11 SettingTool 2.002C és korábbi verziói;
- MI Configurator minden verziója;
- Motorizer 1.005F és korábbi verziói;
- MR Configurator2 1.105K és korábbi verziói;
- MT Works2 1.156N és korábbi verziói;
- MX Component 4.19V és korábbi verziói;
- Network Interface Board CC IE Control utility minden verziója;
- Network Interface Board CC IE Field Utility minden verziója;
- Network Interface Board CC-Link Ver.2 Utility minden verziója;
- Network Interface Board MNETH utility minden verziója;
- PX Developer 1.52E és korábbi verziói;
- RT ToolBox2 3.72A és korábbi verziói;
- RT ToolBox3 1.70Y és korábbi verziói;
- Setting/monitoring tools for the C Controller module minden verziója.

A gyártó a hibát számos érintett termék legújabb verziójában javította. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT publikációja tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-20-212-02

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

Mashav Sapir, a Claroty munkatrása egy sérülékenységet jelentett a DHS CISA-nak, ami az Ignition 8 8.0.13-asnál korábbi verzióit érinti.

A gyártó a hibát a 8.0.13-as verzióban javította. A sérülékenységről további információkat az ICS-CERT bejelentésében lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-212-01

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

Lutz Weimann, Tim Hirschberg, Issam Hbib és Florian Mommertz, az SRC Security Research & Consulting GmbH munkatársai egy sérülékenységet jelentettek a német Szövetségi Információbiztonsági Hivatalnak (BSI), ami a DreamMapper 2.24-es és korábbi verzióit érinti.

A gyártó tervei szerint a hibát javító új verziót 2021. június 30-án fogja kiadni. A sérülékenység részleteit az ICS-CERT weboldalán lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsma-20-212-01

Delta Electronics HMI-ok sérülékenységei

kimiya és egy Anonymous nevű biztonsági kutató három sérülékenységről közöltek részleteket a ZDI-vel közösen a DHS CISA-val, amik a Delta Delta Electronics Industrial Automation CNCSoft ScreenEditor nevű HMI-ának 1.01.23 és korábbi verzióit érintik.

A gyártó a hibákat a az 1.01.26-os verzióban javította. A sérülékenységek részletei az ICS-CERT publikációjában érhetőek el: https://us-cert.cisa.gov/ics/advisories/icsa-20-217-01

Sérülékenységek Delta TPEditor szoftverekben

Kdot, kimiya, Justin Taft és Chris Anastasio, a ZDI-vel együttműködve öt sérülékenységet jelentettek a DHS CISA-nak, amiket a Delta Electronics TPEditor 1.97-es és korábbi verzióiban találtak.

A gyártó a hibákat az 1.98-as verzióban javította. A sérülékenységek részleteiről az ICS-CERT bejelentésében lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-20-219-04

Geutebrück videó rendszerek sérülékenysége

Davy Douhine, a RandoriSec munkatársa egy sérülékenységet jelentett a DHS CISA-nak a Geutebrück alábbi termékeivel kapcsolatban, ha azok az 1.12.0.25-ös vagy korábbi firmware-verzióval futnak:

- G-Code:
- EEC-2xxx;
- G-Cam:
- EBC-21xx;
- EFD-22xx;
- ETHC-22xx;
- EWPC-22xx.

A gyártó a hibát 1.12.0.27-es firmware-verzióban javította. A sérülékenységgel kapcsolatban további információkat az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-219-03

Sérülékenységek Advantech WebAccess rendszerekben

kimiya és Natnael Samson, a ZDI-vel közösen hat sérülékenységről közöltek részleteket a DHS CISA-val, amik az Advantech WebAccess HMI Designer-ének 2.1.9.31-es és korábbi verzióit érintik.

A gyártó a hibákat a 2.1.9.81-es verzióban javította. A sérülékenységekről bővebb információkat az ICS-CERT publikációja tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-20-219-02

Mitsubishi Electric termékek sérülékenysége

Mashav Sapir, a Claroty munkatársa egy sérülékenységet talált a Mitsubishi Electric alábbi termékeiben:

- C Controller Interface Module Utility minden verziója;
- C Controller Module Setting and Monitoring Tool minden verziója;
- CC-Link IE Control Network Data Collector minden verziója;
- CC-Link IE Field Network Data Collector minden verziója;
- CPU Module Logging Configuration Tool 1.100E és korábbi verziói;
- CW Configurator 1.010L és korábbi verziói;
- Data Transfer minden verziója;
- EZSocket minden verziója;
- FR Configurator SW3 minden verziója;
- FR Configurator2 minden verziója;
- GT Designer2 Classic minden verziója;
- GT Designer3 Version1 (GOT1000) minden verziója;
- GT Designer3 Version1 (GOT2000) minden verziója;
- GT SoftGOT1000 Version3 minden verziója;
- GT SoftGOT2000 Version1 minden verziója;
- GX Developer 8.504A és korábbi verziói;
- GX LogViewer 1.100E és korábbi verziói;
- GX Works2 minden verziója;
- GX Works3 1.063R és korábbi verziói;
- M_CommDTM-IO-Link minden verziója;
- MELFA-Works minden verziója;
- MELSEC WinCPU Setting Utility minden verziója;
- MELSOFT Complete Clean Up Tool minden verziója;
- MELSOFT EM Software Development Kit minden verziója;
- MELSOFT iQ AppPortal minden verziója;
- MELSOFT Navigator minden verziója;
- MI Configurator minden verziója;
- Motion Control Setting 1.005F és korábbi verziói;
- Motorizer 1.005F és korábbi verziói;
- MR Configurator2 minden verziója;
- MT Works2 minden verziója;
- MTConnect Data Collector minden verziója;
- MX Component minden verziója;
- MX MESInterface minden verziója;
- MX MESInterface-R minden verziója;
- MX Sheet minden verziója;
- Network Interface Board CC IE Control Utility minden verziója;
- Network Interface Board CC IE Field Utility minden verziója;
- Network Interface Board CC-Link Ver.2 Utility minden verziója;
- Network Interface Board MNETH Utility minden verziója;
- Position Board utility 2 minden verziója;
- PX Developer minden verziója;
- RT ToolBox2 minden verziója;
- RT ToolBox3 minden verziója;
- Setting/monitoring tools for the C Controller module minden verziója;
- SLMP Data Collector minden verziója.

A gyártó az alábbi érintett termékek megjelölt verzióiban javította a hibát:

- CPU Module Logging Configuration Tool 1.106K és későbbi verziói;
- CW Configurator 1.011M és későbbi verziói;
- GX Developer 8.505B és későbbi verziói;
- GX LogViewer 1.106K és későbbi verziói;
- GX Works3 1.065T és későbbi verziói;
- Motion Control Setting 1.006G és későbbi verziói;
- Motorizer 1.010L és későbbi verziói.

A sérülékenységről további részleteket az ICS-CERT bejelentésében lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-212-04

Trailer és Brake eszközök kommunikációjában talált sérülékenység

Ben Gardiner, az NMFTA (National Motor Freight Traffic Association) munkatársa, valamint Dan Salloum, Chris Poore és Eric Thayer, az Assured Information Security munkatársai egy sérülékenységet találtak a Trailer és a Brake gyártotta Power Line Communications Bus/PLC4TRUCKS/J2497 berendezések kommunikációjában.

A sérülékenységgel kapcsolatos kockázatcsökkentő javaslatokat és további információkat az ICS-CERT weboldalán lehet találni: https://us-cert.cisa.gov/ics/advisories/icsa-20-219-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.

Májusban még csak feltételezésekre hivatkozva írtam arról, hogy a Microsoft érdeklődhet az IoT (és ICS) biztonsági területen komoly játékosként ismert CyberX iránt, de június végén már hivatalosan, a Microsoft blogján írtak arról, hogy a szoftvercég felvásárolja a CyberX-et, elsősorban annak IoT-biztonság területén betöltött szerepe miatt. A tervek szerint a CyberX által kínált IoT biztonsági és IoT biztonsági monitoring szolgáltatásokat a Microsoft Azure-platformjával fogják integrálni és így kínálni az ügyfeleknek.

A blogbejegyzésben nincs szó a CyberX ICS biztonsággal kapcsolatos tevékenységeiről, így a jövő egyik igazán érdekes kérdése az lesz, hogy a Microsoft a felvásárlás befejezése után mit tervez ezekkel a termékekkel és szolgáltatásokkal? Megtartja őket és valóban aktív résztvevővé válik az ICS biztonsági színtéren vagy ezeket eladja/leépíti, ahogy azt már számos esetben láttuk különböző IT biztonsági megoldások esetén különböző multinacionális nagyvállalatok esetén?

Az ipari automatizálási szektor egyik óriásaként a Siemens-re mindig is kiemelt figyelem fordult és fordul ma is az ICS kiberbiztonság területén is, ezért említésre méltó a hír, hogy a Siemens és a gépi tanulásra alapozott végpontvédelmi megoldásokat fejlesztő SparkCognition együttműködési megállapodást kötöttek.

Míg a megoldás pozitívuma, hogy támogatja az olyan, régóta semmilyen gyártói támogatással nem rendelkező (de különböző iparágak által ennek ellenére még mindig széles körben használt) operációs rendszereket, mint a Windows 2000/2003/XP, én némiképp szkeptikus vagyok azzal kapcsolatban, hogy vajon hány, ilyen végzetesen elavult szoftveres környezetekben futó ICS rendszer esetén fogják használni ezeket a megoldásokat?