Szinte napra pontosan két éve kétszer is írtam arról, hogy cryptovaluta-bányász malware-eket találtak ICS rendszerekben. Ez a fajta fenyegetés, bár mostanában a zsarolóvírusok (ransomware-ek) mintha nagyobb kockázatokat jelentenének az ICS rendszereket üzemeltető szervezetek számára, nem tűntek el, bár a különböző cryptovaluták árfolyamainak kilengéseitől függően változhat, mennyire érdemes ilyen támadásokat indítani. Egyes biztonsági kutatók szerint az ICS rendszerek továbbra is potenciális célpontjai lehetnek a cryptovaluta-bányász malware-ek fejlesztőinek, elsősorban azok a rendszerek, amelyek az Interneten is elérhetőek, dacára azoknak a tanácsoknak, amiket az ICS biztonsági szakértők mindig elsőként említenek: ne csatlakoztassunk ICS rendszereket publikus hálózatokra! (Elég csak elolvasni a BlackCell ICS/OT Snapshot 2019 címmel publikált tanulmányát, ami első alkalommal, kifejezetten az Interneten elérhető magyar ipari folyamatirányító rendszereket és eszközöket kereste és vizsgálta.)

Egy másik ok, ami miatt az ICS rendszerek (és itt most elsősorban a SCADA rendszerekre érdemes gondolni) vonzó célpontot jelenthetnek cryptovaluta-bányász malware-ek számára, az a SCADA rendszerekbe gyakran beépített tetemes performancia-tartalék lehet. Szemben a folyamatirányítási világban használt céleszközök (RTU-k, PLC-k, stb.) tervezésével, a SCADA rendszereket előszeretettel méretezik jelentősen nagyobbra, mint amekkora a várható terhelésük lesz. Ez viszont azt is jelenti, hogy ha ezt a performancia-tartalékot észrevétlenül ki lehet használni, akkor jelentős hasznot is generálhatnak a támadók számára - azzal a kockázattal pedig a támadók nem fognak foglalkozni, hogy mi történhet, ha a rendszer valamilyen rendkívüli esemény miatt nagyobb teljesítmény igénnyel találja magát szembe és emiatt például megnőnek a válaszidők.

Emellett a SCADA rendszerek átlagos áramfelhasználása általában is elég maga, ezért sokszor nem is foglalkoznak vele, így nehéz lehet észrevenni a megnövekedett terhelést és azzal járó fogyasztást. Ugyanígy, a rendszerterhelésre figyelő monitoring sem olyan fejlett a legtöbb esetben, mint azt sokan gondolnák, így ez sem segít gyorsabban azonosítani egy ilyen incidenst.

Mit kellene tenniük az ICS rendszereket üzemeltető szervezeteknek a folyamatirányításban használt rendszereik elleni cryptovaluta-bányász malware-ek jelentette fenyegetések elhárítására?

1. Nem lehet elégszer ismételni: Ne csatlakoztassunk ICS rendszereket az Internetre! Ha mindenképp szükséges távoli elérést biztosítani a szervezet egyes munkatársai vagy külső támogatói számára ezekhez a rendszerekhez, akkor telepítsünk egy megbízható (és lehetőleg több faktoros authentikációt használó) VPN-szolgáltatást a távoli hozzáférésekhez!

2. Alkalmazzunk átfogó és alapos monitoring megoldást és beállításokat (nem csak az ICS rendszerek esetén, de ezeknél mindenképp)!

Ezen két intézkedésen túl számos más fejlesztéssel lehet javítani az ICS rendszerek kiberbiztonsági helyzetén, de már ez a két intézkedés is jelentősen csökkentheti az ipari folyamatirányító rendszerekre leselkedő, cryptovaluta-bányász malware-ek jelentette kockázatokat.

Emerson OpenEnterprise SCADA Server sérülékenység

Roman Lozko, a Kaspersky ICS CERT részlegének munkatársa egy sérülékenységet fedezett fel az Emerson OpenEnterprise SCADA Server termékének alábbi verzióiban:

- OpenEnterprise Server 2.83, ha a Modbus vagy ROC interfészeket telepítették és használják;
- OpenEnterprise 3.1-től 3.3.3-ig terjedő összes verziója.

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

Sérülékenység Honeywell INNCOM rendszerekben

A Honeywell egy sérülékenységről közölt információkat a DHS CISA-val, ami az INNCOM INNControl 3 3.21-es és korábbi verzióit érinti.

A gyártó az érintett rendszerek frissítését és kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységgel kapcsolatban részleteket az ICS-CERT bejelentése tartalmaz: https://www.us-cert.gov/ics/advisories/icsa-20-049-01

GE ultrahang-készülékek sérülékenysége

Marc Ruef és Rocco Gagliardi, a scip AG, valamint Michael Aguilar, a Secureworks és Jonathan Bouman, aProtozoan.nl munkatársai egy sérülékenységet jelentettek a GE-nek, ami az alábbi, ultrahangos vizsgáló berendezéseiket érinti:

- Vivid termékcsalád minden verziója;
- LOGIQ minden verziója, a LOGIQ 100 Pro kivételével;
- Voluson minden verziója;
- Versana Essential minden verziója;
- Invenia ABUS Scan station minden verziója;
- Venue minden verziója, kivéve a Venue 40 R1-3 és Venue 50 R4-5 verziókat.

A hibával kapcsolatban a gyártó kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenység részleteit az ICS-CERT weboldalán lehet elérni: https://www.us-cert.gov/ics/advisories/icsma-20-049-02

Sérülékenység Spacelabs termékekben

A Spacelabs információkat adott át a DHS CISA a Microsoft által felfedezett és BlueKeep néven ismertté vált Remote Desktop Protocol-sérülékenység által érintett alábbi termékeikkel kapcsolatban:

- Xhibit Telemetry Receiver (XTR), 96280-es modelszámú berendezése v1.0.2-es verziói;
- Arkon (99999) minden verziója.

A gyártó az XTR berendezések esetén a hibát a v1.2.1-es verzióban javította, az Arkon (99999) termékvonal forgalmazása és támogatása viszont már megszűnt, így ehhez javítás sem készül. A sérülékenységről bővebb információkat az ICS-CERT publikációja tartalmaz: https://www.us-cert.gov/ics/advisories/icsma-20-049-01

Sérülékenységek Auto-Maskin rendszerekben

Az ICS-CERT az Auto-Masking alábbi rendszereivel kapcsolatos sérülékenységekről hozott nyilvánosságra információkat:

- RP210E remote panel termékek 3.7-es és korábbi verziói;
- DCU210E digitális vezérlő egység 3.7-es és korábbi verziói.

A gyártó a hibákat a legújabb firmware-verzióban javította. A sérülékenységekről további információkat az ICS-CERT bejelentésében lehet elérni: https://www.us-cert.gov/ics/advisories/icsa-20-051-04

Honeywell Notifier Web Server sérülékenységek

Gjoko Krstikj két sérülékenységet azonosított a Honeywell Notifier Web Server nevű termékének 3.50-es és korábbi verzióiban.

A gyártó a hibákat a legújabb firmware-verzióban javította. A sérülékenységekről bővebben az ICS-CERT weboldalán lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-20-051-03

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

rgod a ZDI-vel együttműködve egy, a Rockwell Automation FactoryTalk Diagnostics minden verzióját érintő sérülékenységről közölt információkat a DHS CISA-val.

A gyártó jelenleg is dolgozik a hiba javításán, annak kiadásáig kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységgel kapcsolatban az ICS-CERT publikációja tartalmaz részleteket: https://www.us-cert.gov/ics/advisories/icsa-20-051-02

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

Yehuda Anikster és Amir Preminger, a Claroty munkatársai egy SNMP sérülékenységet találtak a B&R alábbi termékeiben, amely authentikáció nélküli konfiguráció módosítást tesz lehetővé:

- Automation Studio 2.7, 3.0.71, 3.0.80, 3.0.81, 3.0.90, 4.0-tól 4.6.4-ig terjedő és 4.7.2-es verziói;
- Automation Runtime 2.96, 3.00, 3.01, 3.06, 3.07, 3.08 to 3.10, 4.00 to 4.03, 4.04-től 4.03-ig, 4.04-től 4.63-ig terjedő, valamint 4.72 és újabb verziói.

A gyártó közlése szerint jelenleg nincs mód megszüntetni az SNMP felhasználói adatok módosíthatóságát és emiatt kockázatcsökkentő intézkedések alkalmazását javasolja, amíg elkészülnek a hibát javító új verziókkal. A sérülékenységről bővebb információkat az ICS-CERT bejelentésében lehet találni: https://www.us-cert.gov/ics/advisories/icsa-20-051-01

Sérülékenységek Honeywell WIN-PAK rendszerekben

A Honeywell 3, a WIN-PAK 4.7.2 Web és korábbi verziókat érintő sérülékenységről osztott meg információkat a DHS CISA-val.

A hibákat a gyártó a WIN-PAK 4.7.2 B1072.3.4-es verzióban javította. A sérülékenység részletei az ICS-CERT weboldalán érhetőek el: https://www.us-cert.gov/ics/advisories/icsa-20-056-05

Moxa EDS-sorozatú Ethernet switch-ek sérülékenységei

Ilya Karpov és Evgeniy Druzhinin, a Rostelecom-Solar, valamint Georgy Zaytsev, a Positive Technologies munkatársai 7 sérülékenységet azonosítottak a Moxa alábbi Ethernet switch-eiben:

- EDS-G516E sorozatú eszközök 5.2-es és korábbi firmware-verziói;
- EDS-510E sorozatú eszközök 5.2-es és korábbi firmware-verziói.

A gyártó az EDS-G516E sorozathoz kiadta a hibát javító firmware-verziót, az EDS-510E sorozatot használó ügyfeleit pedig a Moxa Technical Support-tal történő kapcsolatfelvételre kéri, valamint kockázatcsökkentő intézkedések bevezeté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://www.us-cert.gov/ics/advisories/icsa-20-056-04

Moxa PT-sorozatú Ethernet switch-ek sérülékenységei

Ilya Karpov és Evgeniy Druzhinin, a Rostelecom-Solar, valamint Georgy Zaytsev, a Positive Technologies munkatársai 6 sérülékenységet azonosítottak a Moxa alábbi Ethernet switch-eiben:

- PT-7528 sorozatú eszközök 4.0 és korábbi firmware-verziói;
- PT-7828 sorozatú eszközök 3.9 és korábbi firmware-verziói.

A gyártó a hibát javító verziókat a Moxa Technical Support-on keresztül tette elérhetővé. A sérülékenységekkel kapcsolatban bővebb információkat az ICS-CERT bejelentése tartalmaz: https://www.us-cert.gov/ics/advisories/icsa-20-056-03

Sérülékenységek Moxa ioLogik vezérlő rendszerekben

Ilya Karpov és Evgeniy Druzhinin, a Rostelecom-Solar munkatársai 3 sérülékenységet találtak a Moxa alábbi termékeiben:

- ioLogik 2500 sorozatú eszközök 3.0 és korábbi firmware-verziói;
- IOxpress konfigurációs eszköz 2.3.0 é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égekről részleteket az ICS-CERT publikációja tartalmaz: https://www.us-cert.gov/ics/advisories/icsa-20-056-02

Moxa protokoll gateway sérülékenységek

Ilya Karpov és Evgeniy Druzhinin, a Rostelecom-Solar munkatársai 9 sérülékenységet fedeztek fel a Moxa alábbi berendezéseiben:

- MB3170 sorozatú eszközök 4.0 és korábbi firmware-verziói;
- MB3270 sorozatú eszközök 4.0 és korábbi firmware-verziói;
- MB3180 sorozatú eszközök 2.0 és korábbi firmware-verziói;
- MB3280 sorozatú eszközök 3.0 és korábbi firmware-verziói;
- MB3480 sorozatú eszközök 3.0 és korábbi firmware-verziói;
- MB3660 sorozatú eszközök 2.2 és korábbi firmware-verziói.

A gyártó a hibákat javító legújabb firmware-verziókat már letölthetővé tette. A sérülékenységekről bővebben az ICS-CERT bejelentésében lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-20-056-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.

A hét elején két újabb, ipari szervezeteket ért ransomware-támadásról hallottam, tegnap pedig még egybe botlottam.

Az első az INA horvát olajtársaságot, a MOL-csoport tagját érte még február 14-én. A hírek szerint az incidensért a CLOP ransomware egy újabb variánsa a felelős, amit készítői már arra is képessé tettek, hogy a McAfee Endpoint Security és a MalwareBytes Anti-Ransomware-megoldásait is ki tudja kapcsolni. Az INA közleménye szerint az incidens az üzemanyag-előállításért és ellátásért felelős rendszereket (részben ICS rendszereket) nem érintette, azonban a számlázó- és pontgyűjtő-kártya-rendszereket, az új mobil-kuponok és elektronikus matricák kibocsátásáért valamint az INA lakossági földgáz-üzletágának fogyasztói esetén a számlák kiegyenlítéséért felelős rendszereit igen.

A támadás részleteiről több forrás is beszámolt:
SOC Prime
ZDNet
SecurityAffairs

A másik incidensről szóló hír tegnap, február 28-án jelent meg az Index.hu-n, de már a hét elején lehetett pletykákat hallani arról, hogy az Egis Gyógyszergyárban kiberbiztonsági incidens történt (és arról is, hogy az Egis mellett más magyar gyógyszergyárban is történt incidens, erről azonban az Index egyébként elég szűkszavú cikke nem szól, más forrást pedig nem sikerült találnom). Az Index cikke alapján jelenleg az feltételezhető, hogy a termelésirányításért felelős rendszer nem volt érintett, a logisztikát támogató rendszerek némelyike azonban igen. Bár részleteket pénteken délután, amikor ezt a posztot írom, még nem lehet tudni, de a sorok között olvasva és az utóbbi idők tendenciái alapján van egy olyan érzésem, hogy ebben az esetben is valamilyen ransomware-variáns állhat az incidens hátterében (ezt este 19:40-re már meg is erősítették).

Sajnos ez a két eset is nagyon jól rávilágít arra, hogy a preventív intézkedések sokszor minden erőfeszítés ellenére is kevesek lehetnek, legalább ilyen fontosak az incidensek észlelésére és elhárítására vonatkozó képességek és eljárások. Ami pedig nagyon szomorú, hogy a jelek szerint a Norsk Hydro elleni, alig egy évvel ezelőtti ransomware-támadás óta sem igen sikerült a Közép-európai cégeknél elsajátítani azt a fajta transzparenciát, amivel a norvég központú alumínium-ipari óriás kezelte az esetet, mifelénk egy hasonló incidensre adott első reakció még mindig a "nehogy bárki megtudja" gondolat és az ezt képviselő emberek keresztül is tudják vinni az akaratukat. Kár, hogy a jelek szerint továbbra sem ismerték fel, hogy külön-külön előbb vagy utóbb minden szervezetnek szembe kell néznie valamilyen súlyos kiberbiztonsági incidenssel és a legtöbb ipari szervezetnél még mindig uralkodik a nézet, hogy "velünk nem fog semmi hasonlóan rossz dolog történni".

Már összekészítettem ezt a posztot, amikor este (az Egis-incidensről olvasott friss információk után) szembetalálkoztam a Massachusetts állambeli Reading önkormányzati villamosenergia-szolgáltató cége (Reading Municipal Light Department - RMLD) elleni ransomware-támadásról szóló hírrel:

infosecurity
SecurityAffairs

A rendelkezésre álló információk alapján az RMLD elleni támadás is az ügyviteli/vállalati IT rendszereket (pl. a weboldalukat kiszolgáló rendszereiket) érintették és a villamosenergia-rendszer működtetéséhez használt ICS rendszerekig nem jutott el a ransomware.

Synergy Systems & Solutions eszközök sérülékenységei

Az indiai VAPT csoport két sérülékenységet azonosított a Synergy Systems & Solutions HUSKY RTU 6049-E70 RTU-inak 5.0 és korábbi firmware-verzióiban.

A gyártó a hiba javítására az 5.1.2-es vagy újabb firmware-verziók telepítését javasolja. A sérülékenységről bővebben az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-20-042-01

Siemens rendszerek sérülékenységei

Artem Zinenko, a Kaspersky Lab munkatársa két sérülékenységet fedezett fel a Siemens alábbi rendszereiben használt, SNMP-alapú funkciókban:

- IE/PB LINK PN IO (beleértve a SIPLUS NET változatokat is) minden verziója;
- SCALANCE S602 minden verziója;
- SCALANCE S612 minden verziója;
- SCALANCE S623 minden verziója;
- SCALANCE S627-2M minden verziója;
- SIMATIC CP 1623 minden, 14.00.15.00_51.25.00.01-nél korábbi verzió;
- SIMATIC CP 1626 minden verziója;
- SIMATIC CP 1628 minden, 14.00.15.00_51.25.00.01-nél korábbi verzió;
- SIMATIC CP 343-1 Advanced (beleértve a SIPLUS NET változatokat is) minden verziója;
- SIMATIC CP 443-1 (beleértve a SIPLUS NET változatokat is) minden verziója;
- SIMATIC CP 443-1 Advanced (beleértve a SIPLUS NET változatokat is) minden verziója;
- SIMATIC CP 443-1 OPC UA minden verziója;
- TIM 1531 IRC (beleértve a SIPLUS NET változatokat is) minden verziója.

A gyártó már több érintett termékéhez kiadta a hibát javító újabb verziókat, a többihez pedig jelenleg is dolgoznak a javításon. A sérülékenységgel kapcsolatban további információkat a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet elérni.

Sérülékenységek Schneider Electric Magelis HMI panelekben

Az indiai VAPT csoport egy sérülékenységet azonosított a Schneider Electric alábbi rendszereiben:

- Magelis HMIGTO sorozat minden firmware-verziója;
- Magelis HMISTO sorozat minden firmware-verziója;
- Magelis XBTGH sorozat minden firmware-verziója;
- Magelis HMIGTU sorozat minden firmware-verziója;
- Magelis HMIGTUX sorozat minden firmware-verziója;
- Magelis HMISCU sorozat minden firmware-verziója;
- Magelis HMISTU sorozat minden firmware-verziója;
- Magelis XBTGT sorozat minden firmware-verziója;
- Magelis XBTGC sorozat minden firmware-verziója;
- Magelis HMIGXO sorozat minden firmware-verziója;
- Magelis HMIGXU sorozat minden firmware-verziója.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységről bővebben a Schneider Electric és az ICS-CERT weboldalain lehet olvasni.

Schneider Electric Modicon eszközök sérülékenységei

Az indiai VAPT csoport három sérülékenységet talált a Schneider Electric BMXNOR0200H típusú eszközeinek minden firmware-verziójában.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések alkalmazását ajánlja. A sérülékenységekről további információkat a Schneider Electric és az ICS-CERT publikációiban lehet elérni.

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

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

A DHS CISA figyelmeztetése szerint ransomware-támadás ért egy földgázcéget az USA-ban, aminek következtében az érintett cég 2 napra teljesen leállította minden rendszerét és üzleti valamint technológiai folyamatait.

Az incidens elemzése alapján (amit a MITRE ATT&CK for ICS keretrendszerét használva végeztek) a támadók célzott adathalász támadással juttatták a ransomware-t a célba vett szervezet IT rendszerébe és onnan jutottak át az OT rendszerekbe, majd mindkét hálózatban elindították a titkosítást végző komponenst. A támadás által érintett eszközök és rendszerek között voltak a földgáz cég HMI-ai, történeti adatbázisai és a szenzorokból adatokat kinyerő szerverei is, aminek következtében a rendelkezésre állás mellet sérült a fizikai folyamatok fölött gyakorolt felügyelet is, ellenben a támadás a rendelkezésre álló információk szerint nem érintett PLC-ket.

Bár az incidens csak az ICS rendszer egyes részeit (a Windows-alapú rendszereket) és csak egy telephelyen érintette, a gázszolgáltató úgy határozott, hogy a teljes szervezetben minden rendszert és a teljes gázvezeték-hálózatot leállították 2 napra.

A cég megkezdte új eszközökre visszatölteni az utolsó, még bizonyítottan jó konfigurációkat, azonban a szervezetnek, bár volt BCP/DRP terve, de ezek elsősorban a safety-re koncentráltak és nem foglalkoztak a kibertámadások elhárításával, emiatt aztán a katasztrófa-elhárítási gyakorlatok nem biztosították a mostani incidens hatékonyabb kezeléséhez szükséges tapasztalatokat.

A CISA publikációjában számos további hasznos tanulságot lehet találni, többek között a hálózati és eszközgazdálkodási, tervezési és üzemeltetési valamint incidenskezelési témákban.

Úgy látszik, 2020-ra kezd beigazolódni az a 2-3 évvel ezelőtti jóslat, hogy a zsarolóvírusok (és íróik) egyre gyakrabban és egyre eredményesebben vesznek célba ICS rendszereket és az azokat használó vállalatokat. Ideje lenne felkészülni itthon is arra, hogy nem minden támadási kísérletet lesznek képesek az egyes cégek szakemberei megelőzni, akkor pedig csak a megfelelő incidenskezelési tervek és gyakorlatok adhatnak reményt a komolyabb üzemzavarok megelőzésére!

Schneider Electric ProSoft Configurator sérülékenység

Yongjun Liu, az nsfocus munkatársa egy sérülékenységet talált a Schneider Electric ProSoft Configurator PMEPXM0100 (H) moduljaiban a v1.002 és korábbi verziók használta esetén.

A gyártó a hibát a v1.003 verzióban javította. A sérülékenységgel kapcsolatban további információk a Schneider Electric publikációjában találhatóak.

Sérülékenységek Moxa OnCell eszközökben

Alexander Zaytsev, a Kaspersky Lab munkatársa 7 sérülékenységet fedezett fel a Moxa alábbi termékeiben:

- OnCell G3470A-LTE sorozatú eszközök 1.6-os és korábbi firmware-verziói;
- OnCell G3100-HSPA sorozatú eszközök 1.7-es és korábbi firmware-verziói.

A gyártó a hibákat a legújabb firmware-verziókban javította. A sérülékenységek részletei elérhetőek a Moxa weboldalán.

Siemens ipari tűzfalak sérülékenységei

Melih Berk Ekşioğlu három sérülékenységről közölt információkat a Siemens-szel, amik a SCALANCE S-600 ipari tűzfalcsalád alábbi tagjait érintik:

- SCALANCE S602 minden, v3.0 és újabb verziója;
- SCALANCE S612 minden, v3.0 és újabb verziója;
- SCALANCE S623 minden, v3.0 és újabb verziója;
- SCALANCE S627-2M minden, v3.0 és újabb verziója.

A hibákkal kapcsolatban a gyártó kockázatcsökkentő intézkedések bevezetését illetve újabb termékre (SCALANCE SC-600 Industrial Security Appliance) történő váltást javasolja. A sérülékenységekkel kapcsolatban további információkat a Siemens ProductCERT és az ICS-CERT bejelentéseiben olvashatóak.

Sérülékenység Siemens OZW webszerverekben

Maxim Rupp egy sérülékenységet fedezett fel a Siemens alábbi termékeiben:

- OZW672 webszerverek 10.0-nál korábbi verziói;
- OZW772 webszerverek 10.0-nál korábbi verziói.

A gyártó a hibát a 10.0 verzióban javította. A sérülékenységről további részleteket a Siemens ProductCERT és az ICS-CERT weboldalain lehet találni.

Siemens SIPORT MP sérülékenység

A Siemens egy sérülékenységről közölt információkat, ami a SIPORT MP 3.1.4-esnél korábbi verzióit érinti.

A gyártó kiadta a javítást a hibára. A sérülékenység részleteiről a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet olvasni.

Sérülékenység Siemens SCALANCE X hálózati eszközökben

A Siemens egy sérülékenységgel kapcsolat adott át információkat a DHS CISA-nak, ami az alábbi, ipari környezetekbe tervezett hálózati eszközeit érinti:

- SCALANCE X-200 switch család (a SIPLUS NET változatok is érintettek) minden, 5.2.4-nél korábbi firmware-verziója;
- SCALANCE X-200IRT switch család (a SIPLUS NET változatok is érintettek) minden verziója;
- SCALANCE switch család ( az X408-as és SIPLUS NET változatok is érintettek) minden, 4.1.3-nál korábbi firmware-verziója.

A gyártó a hibát a legújabb, elérhető firmware-verzióban javította. A sérülékenységről bővebb információkat a Siemens ProductCERT és az ICS-CERT publikációiban lehet elérni.

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

Nicholas Miles, a Tenable munkatársa egy sérülékenységet talált a SIMATIC szoftvercsalád alábbi tagjaiban:

- OpenPCS 7 v8.1 minden verziója;
- OpenPCS 7 v8.2 minden verziója;
- OpenPCS 7 v9.0 minden verziója;
- SIMATIC BATCH v8.1 minden verziója;
- SIMATIC BATCH v8.2 minden verziója;
- SIMATIC BATCH v9.0 minden verziója;
- SIMATIC NET PC Software minden verziója;
- SIMATIC PCS 7 v8.1 minden verziója;
- SIMATIC PCS 7 v8.2 minden verziója;
- SIMATIC PCS 7 v9.0 minden verziója;
- SIMATIC Route Control v8.1 minden verziója;
- SIMATIC Route Control v8.2 minden verziója;
- SIMATIC Route Control v9.0 minden verziója;
- SIMATIC WinCC (TIA Portal) v13 minden, v13 SP2-nél korábbi verziója;
- SIMATIC WinCC (TIA Portal) v14.0.1 minden verziója;
- SIMATIC WinCC (TIA Portal) v15.1 minden verziója;
- SIMATIC WinCC (TIA Portal) v16 minden verziója;
- SIMATIC WinCC v7.3 minden verziója;
- SIMATIC WinCC v7.4 minden verziója;
- SIMATIC WinCC v7.5 minden, v7.5.1 Upd1-nél korábbi verziója.

A gyártó a WinCC (TIA Portal) v13-hoz és a WinCC v7.5-höz kiadta a hibát javító új verziókat, a többi érintett verzió esetén pedig kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységgel kapcsolatban részleteket a Siemens ProductCERT és az ICS-CERT weboldalain lehet találni.

Siemens SIMATIC S7 sérülékenység

A kínai ICS CERT (China Industrial Control Systems Cyber Emergency Response Team - CIC) egy sérülékenységet jelentett a Siemens-nek, ami az alábbi, SIMATIC S7 eszközöket érinti:

- SIMATIC S7-1200 CPU család (beleértve a SIPLUS változatokat is) minden, v4.1-nél korábbi verziója;
- SIMATIC S7-300 PN/DP CPU család (beleértve az ET200-as CPU-kat és a SIPLUS változatokat is) minden verziója;
- SIMATIC S7-400 PN/DP v6 és korábbi CPU család (beleértve a SIPLUS változatokat is) minden verziója;
- SIMATIC S7-400 PN/DP v7 CPU család (beleértve a SIPLUS változatokat is) minden verziója.

A gyártó a SIMATIC S7-1200 CPU családhoz kiadta a hibát javító verziót, a többi érintett berendezést használó ügyfelüknek kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről bővebben a Siemens ProductCERT és az ICS-CERT publikációiban lehet olvasni.

Sérülékenység a Siemens PROFINET-IO Stack-ben

Yuval Ardon és Matan Dobrushin, az OTORIO munkatársai egy sérülékenységet találtak a Siemens PROFINET-IO Stack-ben, amit az alábbi Siemens termékekben használnak:

- PROFINET IO fejlesztői/tesztelő csomagok:
- DK Standard Ethernet Controller minden verziója;
- EK-ERTEC 200 minden, 4.5-nél korábbi verziója;
- EK-ERTEC 200P minden, 4.6-nál korábbi verziója;
- PROFINET Driver for Controller minden, 2.1-nél korábbi verziója;
- RUGGEDCOM RM1224 minden, 4.3-nál korábbi verziója;
- SCALANCE M-800/S615 minden, 4.3-nál korábbi verziója;
- SCALANCE W700 IEEE 802.11n minden, 6.0.1-nél korábbi verziója;
- SCALANCE X-200 switch család (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SCALANCE X-200IRT switch család (beleértve a SIPLUS NET variánsokat is) minden, 5.3-nál korábbi verziója;
- SCALANCE X-300 switch család (beleértve az X408-as és a SIPLUS NET variánsokat is) minden verziója;
- SCALANCE XB-200, XC-200, XP-200, XF-200BA és XR-300WG minden, 3.0-nál korábbi verziója;
- SCALANCE XM-400 switch család minden, 6.0-nál korábbi verziója;
- SCALANCE XR-500 switch család minden, 6.0-nál korábbi verziója;
- SIMATIC CP 1616 és CP 1604 minden, 2.8-nál korábbi verziója;
- SIMATIC CP 343-1 (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC CP 343-1 Advanced (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC CP 343-1 ERPC minden verziója;
- SIMATIC CP 343-1 LEAN (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC CP 443-1 (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC CP 443-1 Advanced (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC CP 443-1 OPC UA minden verziója;
- SIMATIC ET200AL IM 157-1 PN minden verziója;
- SIMATIC ET200M IM153-4 PN IO HF (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC ET200M IM153-4 PN IO ST (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC ET200MP IM155-5 PN HF (beleértve a SIPLUS NET variánsokat is) minden, 4.2.0-nál korábbi verziója;
- SIMATIC ET200MP IM155-5 PN ST (beleértve a SIPLUS NET variánsokat is) minden, 4.1.0-nál korábbi verziója;
- SIMATIC ET200S (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC ET200SP IM155-6 PN Basic (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC ET200SP IM155-6 PN HF (beleértve a SIPLUS NET variánsokat is) minden, 3.3.1-nél korábbi verziója;
- SIMATIC ET200SP IM155-6 PN ST (beleértve a SIPLUS NET variánsokat is) minden, 4.1.0-nál korábbi verziója;
- SIMATIC ET200ecoPN (kivéve a 6ES7148-6JD00-0AB0 és 6ES7146-6FF00-0AB0 sorozatszámú modelleket) minden verziója;
- SIMATIC ET200pro, IM 154-3 PN HF minden verziója;
- SIMATIC ET200pro, IM 154-4 PN HF minden verziója;
- SIMATIC IPC Support, Package for VxWorks minden verziója;
- SIMATIC MV400 család minden verziója;
- SIMATIC PN/PN Coupler 6ES7158-3AD01-0XA0 (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC RF180C minden verziója;
- SIMATIC RF182C minden verziója;
- SIMATIC RF600 minden, 3-asnál korábbi verziója;
- SINAMICS DCP minden, 1.3-nál korábbi verziója.

A hibával kapcsolatban a gyártó számos érintett termékhez kiadta a javítást tartalmazó újabb verziókat, a többi esetében pedig kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről további információkat a Siemens ProductCERT és az ICS-CERT lehet elérni.

Sérülékenységek Siemens SIMATIC kommunikáció processzorokban

A Siemens publikációja szerint két sérülékenységet találtak a SIMATIC CP 1543-1 típusú (beleértve a SIPLUS NET variánsokat is) kommunikációs processzorok 2.0-nél újabb és 2.2-nél régebbi verzióiban.

A gyártó a hibákat a 2.2-es verzióban javította. A sérülékenységekkel kapcsolatban részleteket a Siemens ProductCERT és az ICS-CERT lehet találni.

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.

Azok számára, akik olvassák egy ideje a blogot, nem titok, hogy sok szempontból előremutatónak tartom, ahogy az USA-ban a kritikus infrastruktúrák információ és IT biztonságával foglalkoznak.

Május közepén Texas államban két törvényt is hoztak, amik a villamosenergia-hálózat kiberbiztonságára vonatkozóan tartalmaznak előírásokat. A törvények alapján a Texas-i kormányzó megbízásából felállítanak egy testületet, aminek az alábbi feladatokat kell kidolgozniuk:

- Képzési programok és marketing anyagok a villamosenergia-hálózatban dolgozók információbiztonsági képzéséhez;
- Kiberbiztonsági program kidolgozása a villamosenergia-hálózat számára;
- Fel kell készülniük a villamosenergia-hálózatot érintő incidensekre;
- Az állami vészhelyzeti tervek frissítése a villamosenergia-hálózat kiberbiztonsági fenyegetéseivel.

A hatályba helyezett jogszabályok itt érhetőek el:

https://capitol.texas.gov/tlodocs/86R/billtext/html/SB00475S.htm
https://capitol.texas.gov/tlodocs/86R/billtext/html/SB00936I.htm

Az elmúlt kb. egy hétben számos egészen érdekes cikket olvastam ICS biztonság témában és sajnos nincs annyi időm, hogy mindegyikről írjak egy-egy teljes posztot, szóval most jött el a kiváló alkalom arra, hogy elindítsam az ICS biztonsági sajtófigyelő rovatot. Íme az első rész:

Hálózatok kompromittálása Philips Hue okos izzókon keresztül

A Check Point blogján egy egészen érdekes, bár kevésbé klasszikus ICS mint inkább okosotthonhoz kapcsolódó (ami azért valahol mégis csak digitális folyamatvezérlés) cikk jelent meg arról, hogyan lehet a Philips által gyártott okos izzókon keresztül kompromittálni az izzó által kommunikációra használt hálózatot. A Check Point PoC tesztjében a ZigBee protokoll egy sérülékenysége is szerepet kapott.

Ransomware támadás értel a Toll ausztrál szállítmányozási cég rendszereit

A BitDefender Hot For Security oldalán olvasható egy cikk a Toll nevű ausztrál szállítmányozási cég elleni ransomware-támadásról. A cikk ugyan nem említi, hogy ICS rendszerek érintettek lennének, de ha emlékszünk még a 2019. tavaszán történt Norsk Hydro-incidensre és az eset automatizált raktárkezelésre gyakorolt hatásáról készült videóra, akkor nem lehet kizárni, hogy a Toll több, mint ezer érintett szervere közül lehetnek olyanok, amik automatizált folyamatok irányításáért felelősek.

Az IBM X-Force tanulmánya szerint 2000%-kal nőtt az OT rendszerek elleni támadások száma 2019-ben

Az IBM-en belül működő X-Force biztonsági kutatócsoport idén is megjelentette az elmúlt év kiberbiztonsági fenyegetéseit összefoglaló jelentését (a 49 oldalas publikáció regisztráció után tölthető le), amely szerint 2019-ben több, mint 2000%-kal, vagyis hússzorosára nőtt az OT rendszerek elleni kibertámadások száma. A kutatók kiemelték, hogy a legtöbb támadás mögött, amit észleltek, feltehetően a Xenotime és a Magnallium/APT33 néven ismert APT-csoportok állhatnak. Az IBM X-Force munkatársai 2020-ban az OT rendszerek elleni támadások számának további növekedésére számítanak.

Az ipari hálózatok a legújabb geopolitikai csataterek

A 2020-as RSA konferencia felvezetéseként jelent meg egy cikk Galina Antova, a Claroty üzletfejlesztési vezetőjétől a SecurityWeek oldalán, amiben arról ír, hogyan váltak a kritikus infrastruktúrák ipari hálózatai geopolitikai csatatérré. A 2015-ös és 2016-os ukrán villamosenergia-rendszer elleni támadások, majd a WannaCry és a NotPetya incidenseken mutatja be az újfajta hadviselés fejlődését és vázolja, szerinte mi várható a közeli jövőben.

Sérülékenység AutomationDirect rendszerekben

Joel Langill, az Amentum Mission Engineering & Resilience munkatársa egy kritikus besorolású sérülékenységet talált az AutomationDirect C-More Touch Panels EA9 sorozatú eszközeinek 6.53-nál korábbi firmware-verzióiban.

A gyártó a hibát a 6.53-as firmware-verzióban javította. A sérülékenység részleteiről az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-20-035-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 elmúlt években a zsaroló vírusok (ransomware-ek) váltak az egyik leggyakoribb kiberbiztonsági fenyegetéssé, azonban az ICS rendszereket jellemzően nem szándékosan, inkább csak járulékos veszteségként érték ransomware-támadások.

A Dragos és a Sentinel One cikkei alapján most ez is megváltozni látszik. A két biztonsági cég elemzői egyre több bizonyítékot találtak arra, hogy a Snake vagy ENAKS (ami ugye a snake visszafelé olvasva) ransomware-t alkotói kifejezetten ICS rendszerek elleni támadásokra tervezték.

A már megszokottnak nevezhető ransomware-támadásokkal ellentétben a Snake/ENAKS ransomware nem csak egyszerűen titkosítja a megtámadott eszközökön található fájlokat, képes 64 különböző szoftver folyamatait leállítani. Az érintett 64 folyamat között számos olyan található, amelyek az érintett ICS rendszerekben a fizikai folyamatok vezérléséért felelős.

A Dragos elemzése szerint a Snake/ENAKS nem az első, hanem a Megacortex nevű, 2019. tavaszán feltűnt ransomware után a második kártevő, ami ilyen módon működik és akár még a Snake/ENAKS elődje is lehet.

A kutatók egyelőre sötétben tapogatóznak azzal kapcsolatban, hogy kik állhatnak a Snake/ENAKS ransomware mögött, de már felmerültek olyan feltételezések, hogy nem állami hátterű APT csoportok, hanem kiberbűnözők közé tartozhatnak a zsarolóvírus alkotói. Ez pedig egy meglehetősen új és egyben aggasztó fejlemény, mert ha valóban bűnözői csoportok kezdik célba venni az ICS rendszereket, akkor a korábbinál nagyságrendekkel nagyobb fenyegetésekkel kell szembenézniük az ICS eszközök és rendszerek üzemeltetőinek és a biztonságukért felelős szakembereknek.