Sérülékenységek Computrols CBAS Web rendszerekben

Gjoko Krstic, az Applied Risk munkatársa kilenc sérülékenységet fedezett fel a Computrols CBAS Web nevű épület-automatizálási rendszerének összes, az alábbi verzióknál korábbi verzióiban:

- 19.0.1;
- 18.0.1;
- 15.0.1;
- 14.0.1;
- 8.0.7;
- 7.2.1-Beta;
- 6.9.2;
- 4.8.2;
- 3.15.1.

A gyártó a hibákat javító verziót már elérhetővé tette. A sérülékenységekről további információkat az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-141-01

Sérülékenység Mitsubishi Electric MELSEC-Q berendezésekben

Younes Dragoni és Alessandro Di Pinto, a Nozomi Networks munkatársai egy sérülékenységet találtak a Mitsubishi Electric alábbi, MELSEC-Q sorozatú Ethernet moduljaiban:

- QJ71E71-100 sorozatszámú eszközök 20121 és korábbi verziói.

A gyártó a hibát 20122-es firmware-ben javította. A sérülékenységgel kapcsolatban bővebben az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-141-02

RDP sérülékenységek Siemens Healthineers termékekben

A Siemens ProductCERT publikáció szerint számos terméküket érinti a Microsoft Windows egyes operációs rendszereit érintő RDP-sérülékenység:

- Point of Care diagnosztikai termékek:
  - AUWi minden verziója;
  - AUWi Pro minden verziója;
  - Rapid Point 500 2.2-es verziója;
  - Rapid Point 500 2.2.1-es verziója;
  - Rapid Point 500 2.2.2-es verziója;
  - Rapid Point 500 2.3-as verziója;
  - Rapid Point 500 2.3.1-es verziója;
  - Rapid Point 500 2.3.2-es verziója;
- Röntgenográfiai és mobil röntgen berendezések:
  - AXIOM Multix M minden, Canon detektorral szerelt verziója;
  - AXIOM Vertix MD Trauma minden, Canon detektorral szerelt verziója;
  - AXIOM Vertix Solitaire M minden, Canon detektorral szerelt verziója;
  - MOBILETT XP Digital minden, Canon detektorral szerelt verziója;
  - MULTIX PRO ACSS P minden, Canon detektorral szerelt verziója;
  - MULTIX PRO P minden, Canon detektorral szerelt verziója;
  - MULTIX PRO/PRO ACSS/PRO Navy minden, Canon detektorral szerelt verziója;
  - MULTIX Swing minden, Canon detektorral szerelt verziója;
  - MULTIX TOP minden, Canon detektorral szerelt verziója;
  - MULTIX TOP ACSS minden, Canon detektorral szerelt verziója;
  - MULTIX TOP P/TOP ACSS P minden, Canon detektorral szerelt verziója;
  - VERTIX SOLITAIRE minden, Canon detektorral szerelt verziója.
- Laboratóriumi diagnosztikai termékek:
  - Atellica Solution minden verziója;
  - Siemens Aptio minden verziója;
  - Inpeco Aptio minden verziója;
  - StreamLab minden verziója;
  - CentraLink minden verziója;
  - syngo Lab Process Manager minden verziója;
  - Viva E minden verziója;
  - Viva Twin minden verziója;
  - Atellica COAG 360 minden, Windows 7-es verziója;
  - Atellica NEPH 630 minden, Windows 7-es verziója;
  - BCS XP minden, Windows 7-es verziója;
  - BCS XP minden, Windows XP-s verziója;
  - BN ProSpec minden, Windows 7-es verziója;
  - BN ProSpec minden, Windows XP-s verziója;
  - CS 2000 minden, Windows 7-es verziója;
  - CS 2000 minden, Windows XP-s verziója;
  - CS 2100 minden, Windows 7-es verziója;
  - CS 2100 minden, Windows XP-s verziója;
  - CS 2500 minden, Windows 7-es verziója;
  - CS 5100 minden, Windows 7-es verziója;
  - CS 5100 minden, Windows XP-s verziója;
- Onkológiai radiológiai termékek:
  - Lantis minden verziója;
- Siemens Healthineers szoftverek:
  - MagicLink A minden verzió;
  - Magic View 1000W minden verzió;
  - Magic View 300 minden verzió;
  - Medicalis Clinical Decision Support minden verzió;
  - Medicalis Intelligo minden verzió;
  - Medicalis Referral Management minden verzió;
  - Medicalis Workflow Orchestrator minden verzió;
  - Screening Navigator minden verzió;
  - syngo Dynamics VA10 és korábbi verziói;
  - syngo Imaging minden verzió;
  - syngo Plaza minden verzió;
  - syngo Workflow MLR minden verzió;
  - syngo Workflow SLR minden verzió;
  - syngo.via minden verzió;
  - syngo.via View&GO minden verzió;
  - syngo.via WebViewer minden verzió;
  - teamplay (csak a fogadó szoftver) minden verzió;
- Siemens Healthineers fejlett terápiás termékek:
  - SYSTEM ACOM.NET, Mat. Nr. 04815549 VC20A, VC21B, VC22B és VX22A verziói;
  - System ACOM.net 2.0, Mat. Nr. 05568386 VC20A, VC21B, VC22B és VX22A verziói;
  - System ACOM-Net, Mat. Nr. 5903872 VC20A, VC21B, VC22B és VX22A verziói;
  - Sensis SIS Server Machine, Mat. Nr. 06648153 VC11C/D, VC12B/C és VC12L/M verziói;
  - Sensis High End SIS Server, Mat. Nr. 10140973 VC11C/D, VC12B/C és VC12L/M verziói;
  - SENSIS Dell High-End Server (VC12), Mat. Nr.10910620:VC11C/D, VC12B/C és VC12L/M verziói;
  - VM SIS Virtual Server, Mat. Nr. 10765502 VC11C/D, VC12B/C és VC12L/M.

Az egyes érintett termékeknél javasolt megvizsgálni, hogy rendelkezésre áll-e a megfelelő hibajavítás. A sérülékenységekről a Siemens ProductCERT bejelentései tartalmaznak részletesebb információkat:

https://cert-portal.siemens.com/productcert/pdf/ssa-616199.pdf
https://cert-portal.siemens.com/productcert/pdf/ssa-932041.pdf
https://cert-portal.siemens.com/productcert/pdf/ssa-832947.pdf
https://cert-portal.siemens.com/productcert/pdf/ssa-433987.pdf
https://cert-portal.siemens.com/productcert/pdf/ssa-406175.pdf
https://cert-portal.siemens.com/productcert/pdf/ssa-166360.pdf

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.

Még február közepén a Cisco Talos egy nagyon aranyos és még annál is hasznosabb kis projektet publikált, 3D nyomtatható olajkút-modell és az azt vezérlő PLC terveit és a kapcsolódó forráskódot tette elérhetővé, így a megfelelő felszerelés birtokában bárki, akár otthon megépítheti ezt a kis szimulált olajkutat.

Túl azon, hogy szórakozásnak sem utolsó egy ilyen modell, a korábbi ICS biztonsági képzések során már én is tapasztaltam, hogy tanulásnak sem utolsó egy működő folyamatvezérlő rendszer működését közelről figyelni és akár be is avatkozni a rendszer működésébe.

A Talos blogposztja itt érhető el a modell egy igen részletes leírásával együtt: https://blog.talosintelligence.com/2019/02/oil-pumpjack.html

Sérülékenységek Siemens LOGO!8 BM rendszerekben

Manuel Stotz és Matthias Deeg, a SySS GmbH munkatársai három sérülékenységet találtak a Siemens LOGO!8 BM rendszerében. A hibák a LOGO!8 BM minden verzióját érintik.

A gyártó a hibákkal kapcsolatban kockázatcsökkentő intézkedéseket javasol. A sérülékenységekről további részleteket a Siemens ProductCERT és az ICS-CERT publikációiban lehet olvasni.

Siemens SIMATEC panelek és WinCC (TIA Portal) sérülékenységek

A Siemens ProductCERT három sérülékenységről publikált információkat, amik az alábbi Siemens termékeket érintik:

- SIMATIC HMI Comfort 4–22 colos panelek minden, v15.1 Update 1-nél korábbi verziói;
- SIMATIC HMI Comfort Outdoor 7 és 15 colos panelek minden, v15.1 Update 1-nél korábbi verziói;
- SIMATIC HMI KTP Mobile panelek: KTP400F, KTP700, KTP700F, KTP900, KTP900F minden, v15.1 Update 1-nél korábbi verziói;
- SIMATIC WinCC Runtime Advanced minden, v15.1 Update 1-nél korábbi verziói;
- SIMATIC WinCC Runtime Professional minden, v15.1 Update 1-nél korábbi verziói;
- SIMATIC WinCC (TIA Portal) minden, v15.1 Update 1-nél korábbi verziói;
- SIMATIC HMI Classic Devices (TP/MP/OP/MP Mobile Panel) minden, v15.1 Update 1-nél korábbi verziói.

A gyártó a hibákat az érintett termékek v15.1 Update 1 verziójában javította. A sérülékenységekkel kapcsolatban bővebb információkat a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet találni.

Sérülékenységek Siemens SCALANCE W1750D rendszerekben

A Siemens öt különböző sérülékenységet fedezett fel a SCALANCE W1750 minden, 8.4.0.1-nél korábbi verziójában.

A hibákat a gyártó 8.4.0.1-es verzióban javította. A sérülékenységekkel kapcsolatban további információkat a Siemens ProductCERT és az ICS-CERT weboldalain lehet olvasni.

Sérülékenység SINAMICS PERFECT HARMONY rendszerekben

A Siemens két sérülékenységet talált a SINAMICS PERFECT HARMONY termékcsalád alábbi, középfeszültségű transzformátoraiban:

- SINAMICS PERFECT HARMONY GH180 NXG I vezérlők: 6SR2. . . -, 6SR3. . . -, 6SR4. . . - minden verziója a G21, G22, G23, G26, G28, G31, G32, G38, G43 vagy G46-os opciókkal;
- SINAMICS PERFECT HARMONY GH180 NXG II vezérlők: 6SR2. . . -, 6SR3. . . -, 6SR4. . . - minden verziója a G21, G22, G23, G26, G28, G31, G32, G38, G43 vagy G46-os opciókkal.

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

Siemens LOGO! Soft Comfort sérülékenység

Egy axt néven ismert biztonsági kutató, az iDefense Labs-szal együttműködve egy sérülékenységet jelentett a Siemens-nek, ami a LOGO! Soft Comfort minden verzióját érinti.

A hibával kapcsolatban a gyártó kockázatcsökkentő intézkedéseket javasol az ügyfeleinek. A sérülékenységről bővebb információkat a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet olvasni.

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

Vladimir Dashchenko és Sergey Temnikov, a Kaspersky Lab munkatársai egy sérülékenységet találtak a Siemens alábbi rendszereiben:

- SIMATIC PCS 7 v8.0 és korábbi verziói;
- SIMATIC PCS 7 v8.1 és újabb verziói (ha a "Titkosított kommunikáció" funkció ki van kapcsolva)
- SIMATIC WinCC v7.2 és korábbi verziói;
- SIMATIC WinCC v7.3 és újabb verziói (ha a "Titkosított kommunikáció" funkció ki van kapcsolva)

A Siemens a hibát a SIMATEC WinCC v7.3 és újabb verzióiban, a SIMATIC PCS 7 v8.1 és újabb verziójban javította, valamint azt javasolja, hogy amennyiben lehetséges, kapcsolják be "Titkosított kommunikáció" funkciót. A sérülékenységről további részleteket a Siemens ProductCERT és az ICS-CERT weboldalain lehet találni.

Sérülékenységek Siemens SISHIP licenc-kezelő szoftverekben

A Siemens ProductCERT bejelentése szerint a SISHIP termékcsaládban használt WibuKey Digital Rights Management (DRM) megoldásban három sérülékenységet találtak. Az érintett rendszerek az alábbiak:

- SISHIP EMCS minden verziója;
- SISHIP IMAC minden verziója;
- SISHIP IPMS minden verziója.

A gyártó a hibát az érintett szoftverek legújabb verzióiban javította. A sérülékenységekről bővebb információkat a Siemens ProductCERT publikációjában lehet olvasni.

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

Vladimir Dashchenko és Sergey Temnikov, a Kaspersky Lab munkatársai, a CNCERT/CC és ChengBin Wang, a Guoli Security Technology munkatársa három sérülékenységet azonosítottak a Siemens alábbi termékeiben:

- SIMATIC PCS 7 v8.0 és korábbi verziói;
- SIMATIC PCS 7 v8.1 verziója;
- SIMATIC PCS 7 v8.2 verziója;
- SIMATIC PCS 7 v9.0 verziója;
- SIMATIC WinCC (TIA Portal) v13 verziója;
- SIMATIC WinCC (TIA Portal) v14 verziója;
- SIMATIC WinCC (TIA Portal) v15 verziója;
- SIMATIC WinCC Runtime Professional minden verziója;
- SIMATIC WinCC v7.2 és korábbi verziója;
- SIMATIC WinCC v7.3 verziója;
- SIMATIC WinCC v7.4 verziója;
- SIMATIC WinCC v7.5 minden v7.5 Update 3-nál korábbi verziója.

A gyártó a SIMATIC WinCC esetén a v7.5 Update 3 verzióban javította a hibát, a többi érintett termék esetén kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységekkel kapcsolatban további információkat a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet elérni.

Siemens SINAMICS PERFECT HARMONY sérülékenység

A Siemens egy DoS-támadást lehetővé tevő hibát talált az alábbi termékeiben:

- SINAMICS PERFECT HARMONY GH180 NXG I vezérlők: 6SR2. . . -, 6SR3. . . -, 6SR4. . . - minden verziója a G28 opcióval;
- SINAMICS PERFECT HARMONY GH180 with NXG II vezérlők: 6SR2. . . -, 6SR3. . . -, 6SR4. . . - minden verziója a G28 opcióval.

A gyártó az érintett eszközök frissítését javasolja az NXGpro vezérlőkre. A sérülékenységről bővebben a Siemens ProductCERT és az ICS-CERT weboldalain lehet olvasni.

Sérülékenység Omron rendszerekben

Egy n0b0dy név mögött megbújó biztonsági kutató egy sérülékenységről adott információkat az NCCIC-nek, ami az Omron DeviceNet Safety 3.41 és korábbi verzióihoz használható Network Configurator szoftvert érinti.

A gyártó a hiba javítását a közeli jövőben tervezi kiadni, addig is kockázatcsökkentő intézkedésekre tett javaslatot. A sérülékenységről bővebben az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-134-01

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

A kimiya néven ismert, a 9SG Security Team tagjaként dolgozó biztonsági kutató a ZDI-vel együttműködve egy memóriakezelési hibáról hozott nyilvánosságra információkat, amik a Fuji Electric Alpha7 PC Loader vezérlőinek 1.1-es és korábbi verzióit érinti.

A gyártó a hibát az 1.2-es verzióban javította. A sérülékenységről további részleteket az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-136-02

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

David Formby, a Fortiphyd Logic és Raheem Beyah, a Georgia Tech munkatársai egy sérülékenységet találtak a Schneider Electric alábbi termékeiben:

- Modicon M580, 2.30-nál korábbi firmware-verziói;
- Modicon M340, minden firmware-verzió;
- Modicon Premium, minden firmware-verzió;
- Modicon Quantum, minden firmware-verzió.

A gyártó a Modicon M580-eshez kiadta a hibát javító új firmware-verziót, a M340-eshez és a Premium és Quantum eszközökhöz kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységről bővebben az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-136-01

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

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

A Microsoft a május 14-i patch kedden adott ki egy javítást, amivel az RDP egy eddig ismeretlen sérülékenységét (CVE-2019-0708) javították. A sérülékenység kihasználásával egy féreg-tulajdonságokkal rendelkező malware képes lehet kompromittálni a sérülékeny Windows verziókat (jelen pillanatban a rendelkezésre álló információk szerint a Windows 8/10/2012 és újabb verziók nem érintettek, a régebbiek viszont mind, ide értve a Windows 7-et/2008R2-t/2008-at/2003 különböző verzióit és az XP - a hiba súlyosságát jól érzékelteti, hogy a Microsoft - ahogyan az EternalBlue sérülékenység idején is - ezúttal is kiadta a hibát javító patch-et Windows XP-re és 2003 Server-re. Részletek itt).

Hogyan érinti ez az ICS rendszereket? Meglehetősen súlyosan, hiszen számos régebben telepített rendszer még az érintett verziókon fut és láthattunk már hasonló malware-támadások esetén (szinte pontosan két éve, a WannaCry-támadások idején), hogy a Windows-ra épített ICS rendszerek mennyire könnyen eshetnek áldozatul egy féregként terjedő malware-nek. A probléma annál súlyosabb lehet, hogy az RDP-t (a távoli hozzáférések terjedése miatt) az ICS rendszerek egyre nagyobb hányadában engedélyezik - hiszen a legtöbb szervezetnél nem áll rendelkezésre megfelelő számú OT mérnök az érintett rendszerek helyszíni üzemeltetéséhez.

Tovább súlyosbítja az ICS rendszerek helyzetét a sérülékenységgel kapcsolatban, hogy bár a Microsoft kiadta a hibát javító patch-et, annak telepítése az ICS rendszereknél megszokott módon valószínűleg jóval több időt fog igényelni, mint más rendszerek esetén.

A patch telepítése mellett (előtt - azt le sem szívesen írom, hogy helyette, bár sejtem, hogy lesz számos olyan érintett szervezet, akár itthon is, ahol nem fogják telepíteni ezt a javítást sem) van még egy lehetőség a sérülékenység kihasználásának megelőzésére, ez pedig a hálózati szintű hitelesítés használata, mert ebben az esetben a sérülékenység kihasználásához sikeres authentikációra van szükség (ehhez persze az sem árt, ha az authentikációhoz egy biztonságosnak tekinthető jelszót kelljen megadni és nem a 25 leggyakoribb jelszó egyikét).

Az elmúlt közel egy évtizedben teljes mértékben át kellett értékelni az ICS rendszerek biztonságát és ez nem hagyja érintetlenül az ICS rendszerekkel kapcsolatos incidenskezelési folyamatok és eszközök területét sem. A vállalati IT biztonság területén jó ideje legalább olyan fontossá vált a biztnosági incidensek észlelésének és elhárításának feladata, mint a támadások megelőzésének szempontja, az ICS világában azonban ez az érettségi állapot még nem jött el, jelenleg még mindig él a régi 80/20 szabály, az ICS biztonsági ráfordítások 80%-át költik a preventív és csak 20%-át a detektív és reaktív intézkedésekre. Ma már észre lehet venni a változások első jeleit, ilyen például az EU NIS direktívája (amit már a magyar jogrendbe is beillesztettek, főként a kritikus infrastruktúra védelméről szóló illetve ahhoz kapcsolódó törvényekbe illesztve).

Az ICS rendszerek esetén az incidensek észlelése és elhárítása különböző okok miatt egyszerre lehet nehezebb és könnyebb, mint az ügyviteli IT rendszerek esetén.

Könnyebbséget jelenthet az ICS rendszerek relatív statikussága, mert ez a körülmény könnyebbé teheti a nem engedélyezett változtatások mielőbbi felfedezését és így a támadók tevékenységének minél korábbi észlelését. Ha az IT/IT biztonsági és OT szakterületek közötti kommunikáció és együttműködés magas szintű, az incidenskezelés során a szokásosnál több és az adott rendszert mélyebben ismerő szakértői csapat állhat a szervezet rendelkezésére.

Nehézséget jelent ugyanakkor a tény, hogy az ügyviteli IT rendszerek esetén már egy ideje használt incidenskezelési eljárások egy része az ICS incidenskezelés során nem vagy csak jelentős változtatásokkal használható. Vegyük példának a malware-fertőzés esetét, az ügyviteli hálózatok esetén a fertőzött számítógéppel kapcsolatos első tevékenység az adott számítógép fizikai leválasztása a hálózatról, igaz? Nos az ICS incidenskezelést oktató tanfolyamok (pl. ez) ennél több mérlegelést javasolnak, az incidenskezelő csoportra illetve az azt vezető menedzserek döntésére bízva, hogy az adott incidens kockázatait (úgy a biztonsági, mint az üzembiztonsági kockázatait) mérlegelve végül szabad-e eltávolítani az adott ICS berendezést a hálózatról vagy produktív működés közben kell eltávolítani az adott kártékony kódot.

Egy másik problémás pont az ICS rendszerek és berendezések esetén a naplózási kapacitásaik véges természete, jellemzően sokkal rövidebb időtáv logjait képesek tárolni, mint az ügyviteli IT rendszerek és mostanáig az ICS rendszerek és berendezések SIEM-integrációja sem számít mindennapos gyakorlatnak.

Az ICS incidenskezelés területén a legfontosabb tevékenység a felkészülés. Mivel az ICS rendszerek esetén gyakran rendelkezésre áll szimulátor vagy labor körülmények között üzemelő rendszer, ami sok tekintettben hasonlít a produktív rendszerre, ezeket (az OT és IT biztonsági területek megfelelő együttműködése esetén) fel lehet használni olyan incidenskezelési felkészülés tesztekre, ahol az érintett, különböző területekről bevont szakemberek üzembiztonsági kockázatok nélkül tudják gyakorolni az incidenskezelési folyamatban rájuk osztott feladatokat. Az ilyen felkészítő gyakorlatok nagyon fontosak, egy éles incidens elhárítása során a különbséget jelenthetik siker és kudarc (és annak következtében egy jelentős üzemzavar) között.

A második legfontosabb lépés az incidensek felfedezése, ami jelenlegi ismereteink szerint az egyik legnehezebb feladat. Az ügyviteli IT rendszerek esetén évekkel ezelőtt még 400 napnál magasabb volt az átlagos IT biztonsági incidensek felfedezésének ideje és ez még ma is valamivel 200 nap felett van. Az ICS biztonsági incidensek esetén ezek a számok jellemzően jóval magasabbak (a Stuxnet, a Duqu és más, feltételezhetően titkosszolgálati hátterű csoportok által végrehajtott támadások akár évekig is észrevétlenek maradtak, de a 2015-ös ukrán áramszolgáltatók elleni támadást is 9 hónapnyi felderítő tevékenység előzte meg az érintett szervezetek hálózataiban). Az incidensek észlelése során kiemelten fontos feladat a rendellenes hálózati forgalmak és események felismerése és helyes kategorizálása, ehhez még ma sem állnak rendelkezésre olyan műszaki megoldások, amivel jelentős és komoly tapasztalatokkal rendelkező biztonsági (és OT - nem lehet eleget hangsúlyozni az IT-OT együttműködés fontosságát!) szakértők bevonása nélkül lehetne hatékonyan felismerni az ICS rendszerek elleni támadásokat.

Az incidenskezelés következő lépése a felfedezett támadás behatárolása, ami az ICS rendszerek esetén megint egy érzékeny pont lehet, mert egy incidensre adott túlzott reakció nagyobb károkat okozhat az ICS berendezések által vezérelt fizikai folyamatokban, mint maga a biztonsági incidens (pl. egy bitcoin-bányász malware által fertőzött számítógép performancia-vesztése okozhat nehézségeket az adott szervezetnek, de vajon a csökkentett funkcionalitás vagy az adott számítógép teljes elvesztése jelent nagyobb kockázatot?).

A támadás nyomainak felszámolása és az üzemszerű működés helyreállítása a következő tevékenység, ami szintén jelenthet nehézségeket, ilyen például a rendszeresen elkészített mentések (ha készülnek) ugyancsak rendszeres ellenőrzése, tesztelése - gondolok itt nem csak maguknak a mentéseknek a tesztelésére, hanem a mentések helyreállítási folyamatainak a tesztelésére, hiszen egy mentés önmagában semmit nem ér, ha a mérnökök, akiknek abból helyre kell állítaniuk egy rendszer működését, nem tudják pontosan mi is a feladatuk - egy ilyen szituációban még a legjobb esetben is a feltétlenül szükséges leállási idő többszörösére lehet szükségük, rosszabb esetben nem lesz teljesen sikeres a helyreállítás.

Az utolsó tevékenység az incidenskezelési folyamat során szerzett tapasztalatok értékelése és az ebből tanultak beépítése az incidenskezelési eljárásokba, majd a módosított tervek újratesztelése.

Ahogy a fentiekből is látszik, a ICS incidensek sikeres kezelésének két fontos része van, a teljes incidenskezelési ciklus rendszeres tesztelése és a tanultak alkalmazása valamint a minél szorosabb és hatékonyabb IT-OT együttműködés.

A Purdue-modell, amiről korábban már én is írtam a blogon és tartottam több előadást is itthon, főként az Magyar Elektrotechnikai Egyesület felkérésére hosszú időn keresztül alapvető hálózati architektúra modellnek számított a biztonságot is szem előtt tartó ICS tervezés területén. Ahogy az Ipar 4.0, IIoT, ipari felhő megoldások egyre inkább kezdenek teret nyerni, az USA-ban több neves ICS biztonsági szakértő kezdett arról beszélni, hogy vajon túlhaladottá vált-e a Purdue-modell?

A januári S4X konferencián egy nagyon érdekes panel keretében vitatták meg a Purdue-modell jelenlegi helyzetét olyan, az ICS biztonság világában ismert szakemberek, mint Brad Hegrat, Joel Langill és Dale Peterson. Hármuk beszélgetéséből (ami podcast formában itt érhető el) egy nem várt válasz körvonalazódott, miszerint a Purdue-modell nem halott, de (már) az ICS világában megjelenő változásokkal már nem olyan hihetetlenül hasznos, mint korábban volt. Azzal, hogy az ipari eszközöknek egyre több esetben kell különböző felhő-szolgáltatásokkal együttműködniük és IIoT eszközök is egyre gyakrabban kerülnek telepítésre az OT hálózatokban, meg kell találni annak a módját, hogy a Purdue-modell alapú hálózatok egyszerre tudjanak új megoldásokat felhasználni és megőrizni az elmúlt évtized munkája során elért biztonsági fejlesztések eredményeit.

Ez is egy olyan területe az ICS biztonságnak, amit önállóan sem az OT mérnökök (fejlesztők, integrátorok, üzemeltetők), sem az IT/IT biztonsági szakemberek nem lesznek képesek megoldani, vagyis minden korábbinál jobban szükség lesz az IT és OT szakterületek érdemi, partneri együttműködésére, már az IIoT eszközök ICS rendszereinkbe és hálózatainkban történő beillesztésének tervezése során.

Rockwell Automation sérülékenységek

ounes Dragoni, a Nozomi Networks munkatársa két sérülékenységet talált a Rockwell Automation alábbi rendszereiben:

- CompactLogix 5370 L1 vezérlők 20-tól 30.014-es verziói;
- CompactLogix 5370 L2 vezérlők 20-tól 30.014-es verziói;
- CompactLogix 5370 L3 vezérlők 20-tól 30.014-es verziói;
- Compact GuardLogix 5370 vezérlők 20-tól 30.014-es verziói;
- Armor Compact GuardLogix 5370 vezérlők 20-tól 30.014-es verziói.

A hibákat a gyártó az FRN 31.011 és később verziókban javította. A sérülékenységekről további részleteket az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-120-01

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

Rafael Honorato egy Cross-site Scripting sérülékenységet fedezett fel a Philips Tasy EMR 3.02.1744-es és korábbi verzióiban.

A hibát a gyártó a Tasy EMR utolsó firmware-verziójában javította. A sérülékenységről bővebb információkat az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSMA-19-120-01

Sierra Wireless rendszerek sérülékenységei

Carl Hurd és Jared Rittle, a Cisco Talos munkatársai hét különböző sérülékenységet azonosítottak a Sierra Wireless alábbi rendszereiben:

- LS300, GX400, GX440 és ES440: 4.4.8 és korábbi verziók;
- GX450 és ES450: minden, 4.9.4-nél korábbi verzió
- MP70, MP70E, RV50, RV50X, LX40 és LX60: minden, 4.12-nél korábbi verzió.

A hibákat a gyártó a legutolsó verziókban javította. A sérülékenységekkel kapcsolatban további részleteket az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-122-03

Sérülékenységek General Electric Communicator komponensekben

Reid Wightman, a Dragos munkatársa öt sérülékenységet talált a GE Communicator alábbi komponenseiben:

- Communicator Installer;
- Communicator Application;
- Communicator PostGreSQL;
- Communicator MeterManager;
- Communicator WISE Uninstaller.

A gyártó a hibákat a Communicator 4.0.517-es és későbbi verzióiban javította. A sérülékenységekről részletesebben az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-122-02

Sérülékenységek Orpak SiteOmat rendszerekben

Ido Naor, a Kaspersky Lab munkatársa hat sérülékenységet fedezett fel az Orpak alábbi rendszereiben:

- SiteOmat 6.4.414.122 verzió;
- SiteOmat 6.4.414.084 és korábbi verziói.

A hibákat a gyártó a 6.4.414.139-es és későbbi verziókban javította. A sérülékenységekről további részleteket az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-122-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.

Az USA National Energy Technology Laboratory nevű szervezete 2019 első negyedéves riportjában hozta nyilvánosságra, hogy 2019.03.05-én a Western Electricity Coordinating Council (WECC) illetékességi területén egy meg nem nevezett villamosenergia-ipari cég ellen végrehajtott DoS-támadás miatt fennakadások voltak a villamosenergia-rendszer irányításában. Az incidens szolgáltatás-kiesést az érintett cég ellátási területén nem okozott, de a riport alapján mintegy 9 és fél óra volt az időtartama.

Az esetről további részleteket az E&E cikkében lehet olvasni: https://www.eenews.net/stories/1060254751

Maga a publikált táblázat egy nagyon érdekes anyag, úgy vélem, igazán hasznos lenne, ha például a Magyar Energetikai és Közműszabályozási Hivatal készítene hasonló (legalább az iparágon belül, korlátozottan terjesztett) időszakos összefoglalókat.

Sérülékenység Rockwell Automation berendezésekben

Josiah Bryan és Geancarlo Palavicini egy eddig ismeretlen hibát azonosítottak a Rockwell Automation alábbi berendezéseiben:

- MicroLogix 1400 kontrollerek
- A sorozatának minden verziója;
- B sorozatának v15.002 és korábbi verziói;
- MicroLogix 1100 kontrollerek v14.00 és korábbi verziói;
- CompactLogix 5370 L1 kontrollerek v30.014 és korábbi verziói;
- CompactLogix 5370 L2 kontrollerek v30.014 és korábbi verziói;
- CompactLogix 5370 L3 kontrollerek (a CompactLogix GuardLogix kontrollerek is) v30.014 és korábbi verziói.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések bevezetését javasolja, javításról egyelőre nincs hír. A sérülékenységről további részleteket az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-113-01

Sérülékenységek FujiFilm rendszerekben

Marc Ruef és Rocco Gagliardi, a Scip AG munkatársai két sérülékenységet találtak a FujiFilm alábbi rendszereiben:

- CR-IR 357 FCR Carbon X;
- CR-IR 357 FCR XC-2;
- CR-IR 357 FCR Capsula X.

A gyártó a hibákkal kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekről bővebben az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSMA-19-113-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 ICS rendszerek és hálózatok egyik első számú biztonsági ajánlása, hogy az ICS eszközök és hálózatok ne rendelkezzenek Internet-kapcsolattal, azonban számos olyan eset fordulhat elő, amikor az Internetről származó adatokat vagy fájlokat kell eljuttatni az ICS környezetekbe. Ilyenkor a legegyszerűbb és leginkább kézenfekvő megoldásnak az USB adathordozók használata látszik - talán nem véletlen, hogy a Stuxnet esetén is az USB adathordozókon történő terjedés volt a támadók választása a malware ICS hálózatokba történő eljuttatáshoz. Arra azonban a Stuxnet (ismét) tökéletesen alkalmas, hogy szemléltetni lehessen az USB adathordozók ICS környezetekre jelentette fenyegetéseket.

Ezt mérte fel és próbálja üzleti modellé formálni a Symantec. Az IT biztonsági szakma egyik nagy és ismert gyártója tavaly év végén jelentette be, hogy Industrial Control System Protection (ICSP) Neural néven egy hálózat-integrált USB bevizsgáló állomást dob piacra, amivel a különböző ICS rendszereket üzemeltető szervezeteknek egy olyan megoldást kínál, amivel azok ellenőrizni tudják, hogy az ICS környezethez csatlakoztatni akart USB adathordozón található-e malware. A megoldás a Symantec malware és threat intelligence megoldásait ötvözve kínál ellenőzési lehetőséget és ezeken túlmenően lehetőséget biztosít arra is, hogy az ICS környezetben működő egyéb számítógépek blokkoljanak minden adatátviteli próbálkozást olyan USB adathordozók esetén, amik még nem estek át ellenőrzésen.

Alapvetően próbálok nem gyártófüggő megoldásokról írni a blogon, de azt hiszem, az ehhez hasonló, ICS-specifikus megoldásokra a jövőben is igyekezni fogok sort keríteni, mert jónak tartom azt, hogy a nagy IT biztonsági gyártók kezdenek nyitni az ICS világa felé.