A mai posztban egy kicsit távolabb megyünk az ICS kiberbiztonság világától (illetve majd a poszt végén röviden megmutatom, miért is nincs ez a téma olyan távol a blog szokásos témáitól) és kicsit az árampiac, illetve hivalatosabb nevén (ahogy a HUPX Magyar Szervezett Villamosenergia-piac Zrt. nevében is megjelenik) a villamosenergia-piac kiberbiztonságával fogunk foglalkozni.

Ahogy a megújuló energiatermelési formák (főként a nap- és szélerőművek illetve egyes európai országokban, pl. Ausztriában és Norvégiában a vízerőművek) egyre nagyobb részarányt szereznek az európai villamosenergia-termelésben, illetve ezzel párhuzamosan a liberalizált villamosenergia-piac folyamatai a villamosáramot is egy (viszonylag) szabadon kereskedhető termékké tették. Más hasonló termékekkel szemben azonban a villamosenergiának vannak olyan sajátosságai (pl. a tárolhatóságban meglévő korlátok), amik miatt ezen a területen ugyanolyan időkritikusak lesznek a kereskedési folyamatok, mint a pénz- és értékpapír piacokon és az itt mozgó pénzek is nagyon gyorsan elérhetik a sok milliárdos összegeket (nem feltétlenül csak Forintban értve). Ez pedig azt jelenti, hogy az árampiaci kereskedésekhez használt rendszerek várhatóan ugyanúgy célpontjai lesznek a kiberbűnözőknek, mint ahogy a banki és más pénzügyi szektorban működő cégek rendszerei már évtizedek óta folyamatosan célkeresztben vannak. Ez pedig azt jelenti, hogy ezeknek a rendszereknek a védelmére is fokozottan fel kell készülni.

Annyiban nem veszélyes ez a helyzet, hogy a szervezett villamosenergia-piaci rendszerek jellemzően ugyanolyan IT komponensekből épülnek fel, mint a legtöbb (nagy)vállalati IT rendszer, az a fajta időkritikus működés pedig, ami az egyik legkomolyabb követelményként jelentkezik ezeknél a rendszereknél, szintén nem ismeretlen pl. az azonnali átutalások világára évek óta készülő banki rendszerek környékén edződött IT és IT biztonsági szakemberek számára.

Mindezekből azt a következtetést lehet levonni, hogy a pénzügyi szektorral szemben támasztott követelmények mintájára hasznos lenne mielőbb egy nagyon hasonló kiberbiztonsági követelményrendszert kidolgozni és kötelezővé tenni a szervezett villamosenergia-piacon működő cégek számára és egy megfelelően felkészült, képzett szakmai auditorokkal rendelkező felügyeleti szervet kijelölni ezeknek a követelményeknek a betartatására (hasonlóan az MNB-ben működő pénzügyi felügyeleti feladatokkal foglalkozó részlegéhez).

Ami pedig az árampiaci rendszerek és az ICS rendszerek összefüggését illeti, már jelenleg is igaz, a jövőben pedig ez fokozottan igaz lesz, hogy az árampiaci ügyletek nyomán történő szerződések egyre inkább hatással vannak egy-egy régió vagy ország villamosenergia-rendszerének működésére, akár úgy is, hogy egyes árampiaci rendszerekből érkező adatok meghatározhatják a DCS vagy SCADA rendszerek bizonyos működési paramétereit. Ha pedig innen nézzük az árampiaci rendszerek kiberbiztonságát, már nem is tűnik olyan távolinak a téma a minket érdeklő ICS rendszerek kiberbiztonságától.

A BleepingComputer cikke szerint még novemberben, az amerikai hálaadás idején DoppelPaymer ransomware-támadás érte a világ legnagyobb elektronikai gyártó vállalatának, a kínai Foxconn-nak a rendszereit. A támadók 34 millió amerikai dollárnak megfelelő váltságdíjat követeltek ("természetesen" Bitcoin-ban) és már el is kezdték publikálni az ellopott, bizalmas adatokat.

A hírek szerint a Foxconn Mexikóban, Ciudad Juárez-ben lévő gyárát érte támadás, amiben végül (a támadók állítása szerint) több, mint 1000 szervert kompromittáltak és 100 GB-nyi adatot loptak el. A feltételezések szerint a Foxconn többi létesítményét nem érintette az incidens.

Az esetről további részleteket a BleepingComputer weboldalán lehet olvasni.

December 8-án jelentette be a FireEye nevű IT biztonsági cég, hogy egy nagyon összetett és kifinomult támadás következtében számos olyan, általuk fejlesztett és sérülékenység vizsgálatok során használt eszközöket (exploit-okat) loptak el a rendszereikből. Mivel az incidensről szóló első hírek után számos IT (és néhány OT) biztonsági cég is reagált az ellopott eszközök jelentette fenyegetésekre, ezért ezt még önmagában nem tartottam annyira fontosnak, hogy írjak róla.

December 13-án azonban kiderült, hogy a FireEye incidensnél a támadók a SolarWinds nevű, IT menedzsment és IT biztonsági megoldásokat gyártó cég egyik termékén, az Orion nevű monitoring rendszeren keresztül jutottak be a FireEye hálózatába, méghozzá nem is akárhogy!

Az elmúlt 5 napban egyre több részlet látott napvilágot arról a beszállítói-lánc támadásról (supply-chain attack), ami mostanra az USA egyik legnagyobb IT biztonsági incidensévé kezd válni. A támadók első lépésként egy (egyes hírek szerint egy Github-on meglehetősen könnyelműen, sima szöveges formában szabadon elérhető) felhasználónév-jelszó párral authentikálva jutott be a SolarWinds egyik, termékek buildelésére használt szerverére és még nem teljesen világos, hogy hogyan, de képesek voltak backdoor-t elhelyezni a a SolarWinds Orion binárisaiban. Más források szerint több, viszonylag friss Orion verziót backdoor-oltak a támadók, amiket aztán nagy számú (legalább 18.000) ügyfél töltött le és telepített a saját hálózatában működő SolarWinds Orion telepítésére. Ezután a backdoor-olt Orion-okat felhasználva (amennyiben azok tudtak az Interneten keresztül kommunikálni a támadók infrastruktúrájával) a támadók már viszonylag könnyen képesek voltak hozzáférni az immár kompromittált hálózatban működő rendszerekhez - hiszen a monitoring rendszereket jellemzően még a legjobban szegmentált hálózatokban is engedik kommunikálni szinten az összes rendszerrel.

Az eddig megjelent információk alapján a legalább 18.000 érintett szervezet között sok más mellett a Fortune 500-as listán szereplő cégek közül kb. 400 érintett lehet, mások mellett a Microsoft is, a BleepingComputer cikke szerint.

Cégek mellett számos amerikai kormányzati szerv is az érintett (és kompromittált) szervezetek listáján van, többek között az amerikai államkincstár (U.S. Department of the Treasury), a Külügyminisztérium (U.S. Department of State), a Belbiztonsági Minisztérium (U.S. Department of Homeland Security - DHS), ahova többek között a CISA és az amerikai ICS-CERT is tartozik és a sok más mellett az amerikai atomfegyverek őrzéséért is felelős Energiaügyi Minisztérium (U.S. Department of Energy - DoE) is. Részben ez is indokolta a DHS CISA részéről a 21-01-es sorszámú vészhelyzeti irányelv kiadását december 13-án, amiben számos, az incidens hatásainak és a kockázatok mérséklésére irányuló intézkedést rendeltek el.

Ezután a némileg hosszú felvezetés után lássuk, mi köze lehet ennek a valóban szokatlanul kiterjedt és kifinomult támadás-sorozatnak az ICS rendszerek biztonságához?

Ahogy az ipari folyamatirányító rendszereket használó szervezetek a digitalizálás útján gyorsabban vagy lassaban, de haladnak előre, úgy nő az esélye annak is, hogy egy SolarWinds Orion rendszer megjelenik az OT rendszerek és akár a level1/level0 eszközök monitorozása szerepkörben is. Ráadásul egyes források (konkrétan Joe Weiss az Unfettered blogon) részletesen írnak arról is, hogy a SolarWinds Orion által az eszközök monitorozására használt SNMP protokoll használatával nem csak számos IT rendszert, hanem bizony sok ICS berendezést is kompromittálni lehet. Mivel jelenleg csak sejteni lehet, hogy a SolarWinds incidensben érintett sok ezer cég közül hány helyen üzemelhetnek ICS rendszerek (az én személyes és bátor tippem az lenne, hogy kb. 18.000+, mert ha mást nem, hát a szervertermek, adatközpontok épületautomatizálási rendszerei szinte biztos, hogy minden érintett szervezetnél jelen vannak), ezért azt nem lehet megjósolni, hogy a konkrét incidens közvetlenül mekkora és milyen hatással lesz egyes ICS rendszerek biztonságára.

Amit viszont már most látni lehet:

1. A supply-chain attack-jellegű támadások a szállító-ügyfél között eddig meglévő bizalmi kapcsolatokat alapjaiban aknázhatja alá. Eddig is lehetett olyan véleményeket hallani, hogy a hibajavítások telepítése az ismert sérülékenységek újakra cserélését jelenti és ez a hozzáállás az OT üzemeltetői mérnökök között alapvetően meglévő, patch-elést elutasító viselkedést csak tovább erősíti, hihetetlen nagy károkat okozhat, hiszen a patch-elési folyamatok minden hibája és az összes eddig látott beszállítói-lánc támadás ellenére is a hibajavítások telepítése nagyjából az egyetlen létező módja annak, hogy kezelhető szinten tartsuk az IT és OT rendszerek fenyegetettségét.

2. A SolarWinds Orion backdoor-olása nagyon tisztán megmutatja, mennyire fontos (lenne) úgy az IT, mint az OT rendszerek esetén egy, a biztonságot is fókuszban tartó tervezéssel kezdeni mindenfajta fejlesztési (sőt, bármilyen változtatási) folyamatot. Ha ugyanis a mostani incidensben backdoor-olt SolarWinds Orion monitoring rendszerek egy általánosan (és nem extrém paranoid módon) biztonságosra tervezett hálózatban működnének, ami azt is jelenti, hogy ha nem szükséges, akkor semmilyen Internetes kapcsolatuk nincs, ha pedig bármilyen ok miatt szükséges, akkor a minimális Internetes kommunikációt engedélyezik ezeknek a szervereknek, akkor a mostani incidensek száma a jelenlegi töredéke lehetne.

Az incidensről számos helyen írtak, én most a SANS Emergency Webcast-ját emelném ki, ahol Jake Williams foglalta össze a legfontosabb információkat: https://www.youtube.com/watch?v=qP3LQNsjKWw

Frissítés: Két nagyon jó blogbejegyzést is találtam a DomainTools.com oldalon Joe Slowik (veterán biztonsági kutató, jelentős ICS biztonsági tapasztalatokkal) tollából/billentyűzetéből erről az incidensről:

Unraveling Network Infrastructure Linked to the SolarWinds Hack

Continuous Eruption: Further Analysis of the SolarWinds Supply Chain Incident

Sérülékenységek beágyazott rendszerek TCP/IP stack-jeiben

A DHS CISA publikációja szerint az AMNESIA:33 néven ismertté vált sérülékenységek (összesen 33) számos, ipari környezetekben is használt megoldást érintenek. A poszt írásának pillanatában az alábbiak ismertek:

- uIP-Contiki-OS (EOL - a termék már elérte életciklusa végét, várhatóan nem fog hibajavítás megjelenni hozzá) 3.0 és korábbi verziói;
- uIP-Contiki-NG 4.5 és korábbi verziói;
- uIP (EOL) 1.0 és korábbi verziói;
- open-iscsi 2.1.12 és korábbi verziói;
- picoTCP-NG 1.7.0 és korábbi verziói;
- picoTCP (EOL) 1.7.0 és korábbi verziói;
- FNET 4.6.3 és korábbi verziói;
- Nut/Net 5.1 és korábbi verziói.

A fentieken túl az alábbi gyártók egyes termékei is érintettek:

- Devolo;
- EMU Electronic AG;
- FEIG;
- Genetec;
- Harting;
- Hensoldt;
- Microchip;
- Nanotec;
- NT-Ware;
- Tagmaster;
- Uniflow;
- Yanzi Networks.

A hibákkal kapcsolatban az egyes gyártók bejelentései mellett az ICS-CERT publikációja is további részleteket tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-20-343-01

Sérülékenység Siemens SiMATIC vezérlők webszervereiben

A Siemens ProductCERT publikációja szerint egy sérülékenységet találtak az alábbi SiMATIC vezérlők webszervereiben:

- SIMATIC ET 200SP Open Controller (beleértve a SIPLUS változatokat is) 20.8-as verziója;
- SIMATIC S7-1500 Software Controller 20.8-as verziója.

A gyártó a hibát az érintett termékek 21.8-as verziójában javította. A sérülékenység részleteiről a Siemens ProductCERT és az ICS-CERT publikációiban lehet olvasni.

Sérülékenységek Siemens SiMATIC termékekben

A Kaspersky még 2019 végén talált több sérülékenységet egyes Siemens SIMATIC termékekbe beépített TightVNC komponensben. Az érintett termékek és verzióik az alábbiak:

- SIMATIC HMI Comfort Outdoor Panelek 7 és 15 colos sorozatainak (beleértve a SIPLUS változatokat is) minden, 16 update 3-nál korábbi verziója;
- SIMATIC HMI Comfort Panel 4-től 22 colosig terjedő sorozatainak (beleértve a SIPLUS változatokat is) minden, 16 update 3-nál korábbi verziója;
- SIMATIC HMI KTP400F, KTP700, KTP700F, KTP900 és KTP900F típusú KTP mobil panelek minden, 16 update 3-nál korábbi verziója;
- SIMATIC ITC1500 v3.1 minden verziója;
- SIMATIC ITC1500 v3.1 PRO minden verziója;
- SIMATIC ITC1900 v3.1 minden verziója;
- SIMATIC ITC1900 v3.1 Pro minden verziója;
- SIMATIC ITC2200 v3.1 minden verziója;
- SIMATIC ITC2200 v3.1 PRO minden verziója;
- SIMATIC WinCC Runtime Advanced minden, 16 update 3-nál korábbi verziója;
- SIMATIC WinCC Runtime Professional minden, 16 update 3-nál korábbi verziója.

A gyártó kiadta a hibát javító újabb verziókat. A sérülékenységekkel kapcsolatban további információkat a Siemens ProductCERT és az ICS-CERT bejelentései tartalmaznak.

Siemens SICAM rendszerek sérülékenysége

Sam Hamra, a KTH Royal Institute of Technology munkatársa egy sérülékenységet fedezett fel a Siemens SICAM RTU-inak alábbi verzióiban:

- SICAM A8000 CP-8000 minden,16-osnál régebbi verziója;
- SICAM A8000 CP-8021 minden,16-osnál régebbi verziója;
- SICAM A8000 CP-8022 minden,16-osnál régebbi verziója.

A hibával kapcsolatban érintett RTU-kat használó ügyfeleinek a gyártó a 16-os verzióra történő frissítést javasolja. A sérülékenységről bővebb információkat a Siemens ProductCERT és az ICS-CERT weboldalain lehet találni.

Sérülékenységek Siemens XHQ Operations Intelligence rendszerekben

A Siemens 7 sérülékenységet talált az XHQ Operations Intelligence nevű termékük minden, 6.1-nél korábbi verzióiban.

A gyártó a hibával kapcsolatban a 6.1-es verzióra történő frissítést illetve az XHQ dokumentációban található, Internet Information Services (IIS) webszerverek biztonságos konfigurálásával kapcsolatos ajánlásainak alkalmazását javasolja. A sérülékenységek részleteit a Siemens ProductCERT és az ICS-CERT publikációiban lehet megtalálni.

Beágyazott TCP/IP stack sérülékenység (AMNESIA:33) Siemens termékekben

Daniel dos Santos, Stanislav Dashevskyi, Jos Wetzels és Amine Amri, a Forescout Research Labs munkatársai több, IoT rendszereket érintő sérülékenységet találtak, amelyek közül egy a Siemens egyes ipari rendszereit is érinti:

- SENTRON PAC3200 2.4.5-ös és korábbi verziók;
- SENTRON PAC4200 2.0.1-es és korábbi verziók;
- SIRIUS 3RW5 Modbus/TCP kommunikációs modulok minden verziója.

A gyártó a hibával kapcsolatban a SENTRON termékekhez frissítet verziókat, a SIRIUS kommunikációs modulokat használó ügyfeleinek pedig kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről további részletek a Siemens ProductCERT és az ICS-CERT bejelentéseiben érhetőek el

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

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

- GOT2000 sorozat, GT21-es modelljének
- GT2107-WTBD változata, minden verzió;
- GT2107-WTSD változata, minden verzió;
- GT2104-RTBD változata, minden verzió;
- GT2104-PMBD változata, minden verzió;
- GT2103-PMBD változata, minden verzió;
- GOT SIMPLE sorozat, GS21-es modelljének
- GS2110-WTBD változata, minden verzió;
- GS2107-WTBD változata, minden verzió;
- Tension vezérlők
- LE7-40GU-L változatának minden verziója.

A gyártó a hiba javítását tartalmazó új verziók kiadását a közeli jövőre tervezi. A sérülékenység részleteiről az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-343-02

Sérülékenységek GE orvostechnikai eszközökben

Lior Bar Yosef és Elad Luz, a CyberMDX munkatársai 2 sérülékenységet találtak a GE alábbi orvostechnikai rendszereiben:

MR rendszerek:
- 3.0T Signa HDxt/3.0T Signa HDx, HD16 és HD23 verziók;
- 1.5T Brivo MR355/Optima MR360, SV20.1 és SV23.0 verziók;
- 1.5T Signa HDx/1.5T Signa HDx, Signa HDi/Signa VIBRANT, HD16 és HD23 verziók;

Ultrahang, általános képalkotó rendszerek:
- LOGIQ 5 [BT03];
- LOGIQ 7 (BT03, BT04, BT06];
- LOGIQ 9 [BT02, BT03, BT04, BT06];

Ultrahang, kardiovaszkuláris rendszerek:
- Vivid I [BT06];
- Vivid 7 {BT02-BT06];
- EchoPAC (Turnkey) [BT06];
- Image Vault (Turnkey) [4.3];

Ultrahang, nőgyógyászati rendszerek:
- Voluson 730 [BT05, BT08];

Fejlett vizualizációs megoldások:
- AW 4.0-tól 4.6-ig terjedő verziók;
- AWS2.0-tól 3.0-ig terjedő verziók;

Intervenciós rendszerek:
- Innova 2000, 3100, 4100, 2100-IQ, 3100-IQ, 4100-IQ, 212-IQ, 313-IQ verziók;
- Optima 320, CL320i, CL323i, CL320, 3100 verziók;
- Optima IGS 320, 330; Innova IGS 5x0, 6x0, 7x0 verziók;

Röntgen-megoldások:
- Brivo XR118, XR383, XR515, XR575;
- Definium 5000, 6000, 8000, AMX 700;
- Discovery XR650, XR656, XR656+;
- Optima XR640, XR646, XR220amx, XR200amx;
- Precision 500D, WDR1;

Mammográfiai megoldások:
- Seno 200D, DS, Essential;
- Senographe Pristina;

Computer tomográfiai rendszerek
- BrightSpeed Elite, Elite Select, Edge, Edge Select;
- Brivo CT385;
- Discovery CT590RT, CT750HD;
- LightSpeed VCT, Pro16, RT16;
- Optima Advance, CT520, CT540, CT660, CT580, CT580RT, CT580W, CT670, CT680 Quantum, Expert & Professional;
- Revolution EVO,HD,ACT, ACTs, CT, Discovery CT, Frontier, Frontier ES;

PET/CT rendszerek:
- Brivo NM 615;
- Discovery NM 630, NM 750b, NM D530c, NM/CT D570c, NM/CT 670;
- Infinia;
- Discovery NM830, NM/CT 860, NM/CT850, NM/CT 870, MI MI DR, IQ;
- Optima NM/CT 640;
- Ventri;
- Xeleris;
- PET Discovery IQ, IQ upgrade;
- PETrace 800.

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 részleteket az ICS-CERT publikációjában lehet találni: https://us-cert.cisa.gov/ics/advisories/icsma-20-343-01

Host Engineering rendszerek sérülékenysége

Uri Katz, a Claroty munkatársa egy sérülékenységet azonosított a Host Engineering ECOM100 típusú Ethernet kommunikációs modul (PLC rendszerekhez) alábbi verzióiban:

- H0-ECOM100 Modul:
- Hardware 6x és korábbi verziói 4.0.348 és korábbi firmware-verziókkal;
- Hardware 7x verziói 4.1.113 és korábbi firmware-verziókkal;
- Hardware 9x verziói 5.0.149 és korábbi firmware-verziókkal;
- H2-ECOM100 Modul:
- Hardware Versions 5x és korábbi verziói 4.0.2148 és korábbi firmware-verziókkal;
- Hardware Version 8x verziói 5.0.1043 és korábbi firmware-verziókkal;
- H4-ECOM100 Modulok 4.0.2148 és korábbi firmware-verziókkal.

A gyártó a hibával kapcsolatban a legújabb elérhető verziókra történő frissítést javasolja. A sérülékenységgel kapcsolatos további információkat az ICS-CERT bejelentésében lehet elérni:
https://us-cert.cisa.gov/ics/advisories/icsa-20-345-02

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

A Mitsubishi Electric egy sérülékenységről közölt részleteket a DHS CISA-val, ami a MELSEC iQ-F sorozatú eszközeik FX5U(C) CPU modullal szerelt példányait érinti, ha azok az 1.060-as és korábbi firmware-verziót használják.

A gyártó a hibát az 1.061-es firmware-ben javította. A sérülékenység részletiről az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-345-01

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

A Sternum nevű izraeli cég munkatársai, valamint kutatók (Eric Gustafson, Sara Rampazzi, Paul Grosen, Christopher Kruegel és Giovanni Vigna) a Kaliforniai Santa Barbara Egyetemről, a Floridai Egyetemről és a Michigan-i Egyetemről 3 sérülékenységet találtak a Medtronic Smart Model 25000 Patient Reader nevű megoldásában. A sérülékenység a rendszer összes verziójában megtalálható.

A gyártó a hibát javító újabb firmware-verziót már elérhetővé tette. A sérülékenységekről részletesebb információkat az ICS-CERT publikációja tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsma-20-345-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.

Zsarolóvírus-támadás érte az Advantech ICS gyártó rendszereit

November utolsó napjaiban került nyilvánosságra, hogy ransomware-támadás érte az Advantech, tajvani ICS gyártó infomatikai rendszereit. Az újabb generációs ransomware-támadásokhoz hasonlóan ebben az esetben is egy kombinált, titkosító-adatlopó támadásról van szó. A BleepingComputer beszámolója szerint az Advantech-től ellopott (és a támadók által részben már publikált) bizalmas dokumentumok a kisebb értékű, vállalati adminisztratív folyamatok dokumentumai közül kerültek ki.

Az incidensről megjelent információk arról szólnak, hogy a támadás a Conti ransomware-hez köthető. Egyelőre nincs hír arról, hogy az incidens érintette volna az Advantech gyártósorait illetve termékeit.

Az Advantech elleni ransomware-támadásról bővebben a BleepingComputer cikkében lehet olvasni.

Ransomware-támadás a Vancouver-i tömegközlekedési vállalat rendszerei ellen

December 1-jén zsarolóvírus-támadás érte a kanadai Vancouver városának tömegközlekedési vállalatát, a TransLinket. A támadás nem érintette a vállalat folyamatirányításért felelős rendszereit, de az utasok nem tudtak készpénzmentes fizetési módokat használni a jegyvásárláshoz. Az incidens során a támadók (a mostanában szokásos elkövetési mód szerint) el is loptak egyes, bizalmas adatokat tartalmazó fájlokat és azok nyilvánosságra hozásával is fenyegetik az áldozatot.

Az esetről bővebben a BitDefender blogján és a SecurityWeek cikkében lehet olvasni.

Kibertámadás érte egy izraeli víziközmű cég ICS rendszereit

Az OTORIO nevű ipari IT biztonsági cég által publikált részletek szerint (feltételezések szerint iráni) támadók hozzáfértek egy izraeli víztározó ICS rendszerének védtelenül hagyott HMI-ához. A támadók december 1-jén publikáltak egy videót a támadásról.

Mivel a vízellátás egyre inkább kulcskérdésnek számít a Közel-Keleten és az izraeli-iráni viszony talán minden korábbinál feszültebb az utóbbi idők eseményei után, kifejezetten nagy hiba fontos ICS rendszerek komponenseit védtelenül, az Internetre csatlakoztatva működtetni.

Mitsubishi Electric berendezések sérülékenysége

Xiaofei Zhang egy sérülékenységet talált a Mitsubishi Electric MELSEC iQ-R sorozatú berendezéseinek alábbi modelljeiben:

- R00/01/02CPU 19-es és korábbi firmware-verziói;
- R04/08/16/32/120(EN)CPU 51-es és korábbi firmware-verziói;
- R08/16/32/120SFCPU 22-es és korábbi firmware-verziói;
- R08/16/32/120PCPU minden verziója;
- R08/16/32/120PSFCPU minden verziója;
- RJ71EN71 47-es és korábbi firmware-verziói;
- RJ71GF11-T2 47-es és korábbi firmware-verziói;
- RJ72GF15-T2 07-es és korábbi firmware-verziói;
- RJ71GP21-SX 47-es és korábbi firmware-verziói;
- RJ71GP21S-SX 47-es és korábbi firmware-verziói;
- RJ71C24(-R2/R4) minden verziója;
- RJ71GN11-T2 minden verziója.

A gyártó a hibát az érintett eszközökhöz kiadott újabb firmware-verziókban javította. A sérülékenységről bővebben az ICS-CERT publikációjában lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-324-05

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

Tran Van Khang, a VinCSS munkatársa egy sérülékenységet jelentett a ZDI-nek, ami a Fuji Electric V-Server Lite termékének 3.3.24.0-nál korábbi verzióit érinti.

A gyártó a hibát a 3.3.25.0 verzióban javította. 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-329-02

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

Sharon Brizinov, a Claroty munkatársa 3 sérülékenységet azonosított a Rockwell Automation FactoryTalk Linx 6.11-es és korábbi verzióiban.

A gyártó a hibával kapcsolatban a legújabb elérhető verzióra történő frissítést javasolja. A sérülékenységek részleteit az ICS-CERT weboldalán lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-20-329-01

National Instruments vezérlők sérülékenysége

A Titanium Industrial Security munkatársai egy sérülékenységet jelentettek a spanyol Nemzeti Kiberbiztonsági Intézetnek (INCIBE), ami a National Instruments CompactRIO nevű, valósidejú beágyazott vezérlőinek drivereit érinti, a 20.5-ös verziónál korábbi verziók használata esetén.

A gyártó a hibát a driver 20.5-ös verziójában javította, aminek alkalmazásához a vezérlők firmware-jét is frissíteni kell a 8.5-ös vagy újabb verzióra. A sérülékenységgel kapcsolatos bővebb információkat az ICS-CERT publikációjában lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-338-01

A sérülékenységek negatív hatásainak csökkentése érdekében az ICS-CERT az alábbi kockázatcsökkentő intézkedések bevezetését javasolja:

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

Ahogy szinte minden iparágban, úgy a tengerhajózásban is folyamatosan nő a kibertámadások száma. A 2017-es NotPetya-támadások a Maersk számára okozott 300 millió dolláros kárt, azóta pedig támadások érték a barcelonai és San Diego-i kikötőket, az Austal nevű ausztrál hajógyártót és a COSCO amerikai hajózási vállalatot is. 2020-ban az MSC hajózási vállalat rendszereit (és emiatt többek között a Genova-i központját) kellett leállítani Ryuk ransomware fertőzés miatt, legutóbb pedig az iráni Shahid Rajaee kikötőt érték sorozatos kibertámadások.

Ahogy általában a különböző iparágakban, a kiberbiztonság a legutóbbi időkig a tengerhajózási vállalatoknál is az IT feladata volt. Azonban (hasonlóan a többi iparághoz), az OT biztonsági kihívásokra nem lehet kizárólag a hagyományos IT biztonsági megoldásokkal és módszerekkel választ adni. Ezt felismerve a Nemzetközi Tengerhajózási Szervezet (Internation Maritime Organization, IMO) 2021. januártól konkrét elvárásokat fogalmaz meg a szektorban működő vállalkozások safety rendszereinek kiberbiztonságával kapcsolatban. Ezzel párhuzamosan az USA kormánya is változtat a témával kapcsolatos hozzáállásán és a Trump-kabinet is prioritásként kezd tekinteni a tengerhajózásban használt rendszerek kiberbiztonságára - nem utolsósorban az USA világpolitikai pozíciójához kapcsolódó tengeri haderő miatt is.

Ez utóbbinak egyébként már 2019-ben is láthattuk jeleit, amikor a US Cyber Command egy tengeri kikötő elleni kibertámadást szimulált. A gyakorlatról a CyberScoop cikkében lehet bővebben olvasni: https://www.cyberscoop.com/us-cyber-command-simulated-seaport-cyberattack-test-digital-readiness/

Néhány hete hozták nyilvánosságra, hogy zsarolóvírus-támadás érte a világ egyik legnagyobb játékgyártó cégének, a Mattel-nek a rendszereit. A rendelkezésre álló információk szerint az incidens nem érintette a vállalat gyártássutomatizálásért felelős rendszereit és (eltérően az utóbbi idők kombinált, titkosító-zsaroló és adatlopásra felkészített malware-jeitől) nem történt adatlopás az incidens során.

Bár az incidens hatásai a jelek szerint nem voltak súlyosak, maga a tény, hogy 2020-ban ennyire megszaporodtak az ipari szervezetek, gyakran kritikus infrastruktúrák elleni ransowmare-támadások, nagyon erős figyelemfelkeltő hatással kéne, hogy legyen a döntéshozókra. Ennek sajnos egyelőre a nyomait sem igen látjuk, ez pedig oda vezethet, hogy itthon is várható(ak) lesznek komolyabb, akár egyes szektorok ellátásbiztonságát is veszélyeztető incidensek. A kérdés valójában nem az, hogy lesz-e ilyen incidens, hanem az, hogy mikor?

Schneider Electric Modicon berendezések sérülékenységei

Kai Wang, a Fortinet FortiGuard laboratóriumának munkatára 3 sérülékenységet fedezett fel a Schneider Electric alábbi termékeiben:

- M340 CPU -k BMX P34x modelljeinek minden verziója;
- M340 Ethernet kommunikációs modulok:
- BMX NOE 0100 (H) modelljeinek minden verziója;
- BMX NOE 0110 (H) modelljeinek minden verziója;
- BMX NOC 0401 modelljeinek minden verziója;
- BMX NOR 0200H modelljeinek minden verziója;
- Premium processzorok integrált Ethernet kommunikációs processzorokkal:
- TSXP574634, TSXP575634, TSXP576634 modellek minden verziója;
- Premium kommunikációs modulok:
- TSXETY4103 modellek minden verziója;
- TSXETY5103 modellek minden verziója;
- Quantum processzorok integrált Ethernet kommunikációs processzorokkal:
- 140CPU65xxxxx modellek minden verziója;
- Quantum kommunikációs modulok:
- 140NOE771x1 modellek minden verziója;
- 140NOC78x00 modellek minden verziója;
- 140NOC77101 modellek minden verziója.

A gyártó jelenleg is dolgozik a sérülékenységek javításán és kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekkel kapcsolatos további információkat a Schneider Electric publikációjában lehet megtalálni.

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

Lasse Trolle Borup, a Danish Cyber Defence munkatársa egy sérülékenységet talált a Schneider Electric alábbi rendszereiben:

EcoStruxure™ Operator Terminal Expert Runtime 3.1 Service Pack 1A és korábbi verziói, amiket régebbi BIOS verzióval működő Windows PC-kre vagy Harmony iPC-kre (HMIG5U és HMIG5U2 verziókra) telepítettek.

A gyrátó a hibát a 3.1 Service Pack 1B verzióban javította. A sérülékenység részleteiről a Schneider Electric bejelentéséből lehet tájékozódni.

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

kimiya, a ZDI-vel együttműködve 9 sérülékenységről közölt információkat a Schneider Electric-kel, amik a gyártó Interactive Graphical SCADA System (IGSS) nevű rendszerében 14.0.0.20247-es és korábbi verzióit érintik.

A gyártó a hibákat a 14.0.0.20248-as verzióban javította. A sérülékenységek részleteiről a Schneider Electric és az ICS-CERT weboldalain lehet olvasni.

Sérülékenységek Schneider Electric EcoStruxure Building Operation rendszerekben

Luis Vázquez, Francisco Palma és Diego León, a Zerolynx munkatársai, együttműködésben az INCIBE CERT-tel, valamint Alessandro Bosco, Luca Di Giuseppe, Alessandro Sabetta és Massimiliano Brolli, a TIM Security Red Team Research (TIM S.p.A.) munkatársai 7 sérülékenységet találtak a Schneider Electric EcoStruxure Building Operation alábbi komponenseiben:

- WebReports V1.9-től V3.1-ig terjedő verziói;
- WebStation V2.0-tól V3.1-ig terjedő verziói;
- Enterprise Server telepítő V1.9-től V3.1-ig terjedő verziói;
- Enterprise Central telepítő V2.0-tól V3.1-ig terjedő verziói.

A hibákkal kapcsolatban a gyártó az EcoStruxure Building Operation 3.2-es verziójára történő frissítést javasolja. A sérülékenységekkel kapcsolatos bővebb információkat a Schneider Electric publikációja tartalmazza.

Schneider Electric Modicon PLC-k sérülékenységei

Yehuda Anikster és Rei Henigman, a Claroty valamint Seok Min Lim és Bryon Kaan, a Trustwave munkatársai összesen 4 sérülékenységet találtak a Schneider Electric Modicon M221-es típusú PLC-iben.

A hibákkal kapcsolatban a gyártó kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységekről részletesebben a Schneider Electric bejelentésében lehet olvasni.

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

Evgeniy Druzhinin és Ilya Karpov, a Rostelecom-Solar munkatársai egy sérülékenységet fedeztek fel a Schneider Electric Easergy T300 típusú RTU-inak 2.7-es és régebbi firmware-verzióiban.

A gyártó a hibát a 2.7.1-es firmware-verzióban javította. A sérülékenységgel kapcsolatos részleteket a Schneider Electric weboldalán lehet elérni.

Sérülékenységek Schneider Electric EcoStruxure Control Expert PLC szimulátorokban

Alexander Perez-Palma és Jared Rittle, a Cisco Talos munkatársai, a Parity Dynamics kutatócsoportja és Flavian Dola az Airbus Cybersecurity munkatársa 5 sérülékenységet találtak a Schneider Electric alábbi termékeiben:

- EcoStruxure™ Control Expert PLC szimulátor minden verziója;
- Unity Pro PLC szimulátor minden verziója.

A hibával kapcsolatos javításokat a gyártó az EcoStruxure™ Control Expert 15.0 verziójában tette elérhetővé. A sérülékenységekkel kapcsolatos további részleteket a Schneider Electric és az ICS-CERT publikációi tartalmazzák.

Siemens SCALANCE rendszerek sérülékenysége

A Siemens egy sérülékenységről közölt információkat a DHS CISA-val, ami a SCALANCE W 1750D megoldásuk minden verzióját érinti.

A gyártó a hibát az érintett termékek legújabb firmware-verziójában 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.

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

Wang Fang Li, a Beijing Winicssec Technology CO munkatársa egy sérülékenységet jelentett a Siemens-nek, ami a gyártó alábbi termékeit érinti:

- SIMATIC S7-300 CPU-család (beleértve a kapcsolódó ET200-as CPU-kat és SIPLUS változatokat) minden verziója;
- SINUMERIK 840D sl minden verzió.

A hibával kapcsolatos javításon a gyártó jelenleg is dolgozik és kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységgel kapcsolatosan további információkat a Siemens ProductCERT és az ICS-CERT weboldalain lehet találni.

Sérülékenységek OSIsoft PI Vision rendszerekben

Az OSIsoft 2 sérülékenységet jelentett a DHS CISA-nak, amik a PI Vision nevű termékük 2020-as verzióját érintik.

A gyártó hibák a PI Vision 2020 3.5.0 verziójában javította. A sérülékenységekről bővebben az ICS-CERT publikációjában lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-315-02

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

Az OSIsoft 1 sérülékenységről közölt információkat a DHS CISA-val, amit a PI Interface for OPC XML-DA nevű termékük 1.7.3.x-nél korábbi verzióiban találtak.

A gyártó a hibát az 1.7.3.x verzióban javította. A sérülékenység részleteit az ICS-CERT bejelentésében lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-20-315-01

Sérülékenység Mitsubishi MELSEC iQ-R berendezésekben

Xiaofei Zhang egy sérülékenységet azonosított a Mitsubishi MELSEC iQ-Rsorozatú CPU modelljeinek alábbi vezrióiban:

- R00/01/02 CPU-k 05-től 19-ig terjedő firmware-verziói;
- R04/08/16/32/120(EN) CPU-k 35-től 51-ig terjedő firmware-verziói.

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

BD rendszerek sérülékenysége

A Medigate egy sérülékenységet talált a BD alábbi, orvostechnikai eszközeiben:

- BD Alaris PC Unit, Model 8015 9.33.1 és korábbi verziói;
- BD Alaris Systems Manager 4.33 és korábbi verziói.

A gyártó a hibát az érintett termékekhez kiadott újabb verziókban javította. A sérülékenység részleteiről az ICS-CERT publikációjában lehet tajékozódni: https://us-cert.cisa.gov/ics/advisories/icsma-20-317-01

Sérülékenység Real Time Automation rendszerekben

Sharon Brizinov, a Claroty munkatársa egy sérülékenységet talált a Real Time Automation 499ES típusú EtherNet/IP-adapterének forráskódjában.

A hiba javításáról jelenleg nem érhető el publikus információ. A sérülékenység részleteit az ICS-CERT bejelentése tartalmazza: https://us-cert.cisa.gov/ics/advisories/icsa-20-324-03

Paradox rendszerek sérülékenységei

Omri Ben-Bassat, az Azure Defender for IoT-hez tartozó Section 52 munkatársa két sérülékenységet talált a Paradox IP150 típusú berendezéseinek 5.02.09-es verziójú firmware-jében.

A gyártó a hibával kapcsolatban érdeklődő ügyfeleit a terméktámogatói csoportjukhoz irányítja. A sérülékenységek részleteit az ICS-CERT publikációjában lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-20-324-02

Sérülékenység Sensormatic Electronics rendszerekben

Joachim Kerschbaumer egy sérülékenységet jelentett a Sensormatic anyavállalatának, a Johnson Controls-nak, ami a Sensormatic alábbi termékeit érinti:

- victor Web Client v5.6 és korábbi verziói;
- C•CURE Web Client v2.90 és korábbi verziói.

A gyártó a hibát javító újabb verziókat már elérhetővé tette. A sérülékenységgel kapcsolatos bővebb információkat az ICS-CERT bejelentésében lehet elolvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-324-01

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.

Az OT és ICS rendszerek elleni kiberbiztonsági kockázatok folyamatosan nőnek. Ez nem újdonság, de az amikor egyes állami ügynökségek ez nyíltan beismerik és a kockázatok csökkentését célzó javasolatokat adnak ki, az már az. Ez történt még július végén, amikor az USA-ban a Department of Homeland Security-hez tartozó Cybersecurity & Infrastructure Security Agency (CISA) és az NSA közös publikációban adott tanácsokat a kritikus infrastruktúrák OT üzemeltetői számára.

A tanácsok között szerepel az OT/ICS rendszerekre és berendezésekre vonatkozó incidenskezelési és működésfolytonossági tervek készítése, ide értve az adatok (nem utolsósorban a helyes konfigurációs beállítások) rendszeres mentését és a mentések tesztelését, az incidenskezelési tervek kidolgozását, tesztelését és rendszeres felülvizsgálatát, valamint az OT hálózatban végzett monitoring tevékenységet a potenciális fenyegetések mielőbbi felismerése érdekében.