Ipari és folyamatirányítási informatikai rendszerek biztonságáról magyarul.

ICS Cyber Security blog

IT-OT szembenállás az ICS biztonság kérdésében

2019. június 15. - icscybersec

Néhány hónapja volt egy szombati posztom "Hogyan építsünk ICS biztonsági programot és csapatot?" címmel, amiben Dale Peterson gondolatai nyomán tettem fel a kérdést, hogy hogyan lehet fejleszteni az ICS biztonság jelenleg sajnos igen lesújtó helyzetét.

Az abban a poszban hivatkozott Dale Peterson cikk számos visszajelzést kapott különböző felületeken és igen sokan nehezményezték Dale azon megállapítását, hogy az IT (és az IT biztonság) győzött az IT-OT szembenállásban. Ezzel kapcsolatban két gondolatom van:

1. Szerintem az ICS biztonságot nem az IT és az OT vetélkedéseként kéne felfogni és kezelni. Sajnos itthon mind a mai napig elvétve lehet olyan vezetőt találni, aki képes lenne elvonatkoztatni a hazai nagyvállalatok és különsen közmű cégek esetén a silós működés és szervezeti struktúra rendszerétől, ezért az ICS biztonságot is csak fekete-fehéren tudják megítélni és múltjuk, tapasztalataik alapján döntik el, ha megkérdezik őket, hogy hova kéne tartoznia az ICS biztonságnak. Érdekes megfigyelni, hogy mind az IT, mind az OT menedzserek hajlamosak ezt az OT problémájának tekinteni és csak kevesen (jellemzően, bár nem kizárólag IT biztonsági háttérrel rendelkezők) ismerik fel, hogy a hatékony ICS biztonsági programhoz nagyon jó IT-OT-IT biztonsági hármas együttműködésre van szükség. Ahogy ma már nem lehet szigorú (és fizikai) elkülönítést alkalmazni az IT és az OT között, ugyanúgy nem lehet az ICS biztonságot csak az egyik vagy csak a másik szakterület feladatául szabni, mert igenis mindhárom területet értő és ismerő szakemberek nagyon magas színvonalú együttműködése adhat csak esélyt arra, hogy a folyamatvezérlő rendszereket és végső soron a fizikai folyamatokat meg lehessen védeni a kibertér felől érkező fenyegetésektől.

2. Jelenleg Magyarországon az IT és az IT biztonság területén is hatalmas hiány van a jól képzett és tapasztalt szakemberek terén, ez az ICS biztonság területén hatványozottan igaz. Ezen a szakember hiányon az IT-OT szembenállás hangoztatásával és minden irányból történő táplálásával nem lehet változtatni, igenis tudomásul kell venni, hogy ICS biztonsági szakember senkiből nem lesz úgy, hogy kilép valamelyik felsőoktatási intézményből a frissen megkapott diplomáját szorongatva (mondjuk az a kérdés is megérne egy posztot - talán néhány héten belül nekiülök és összerántom a gondolataimat a témában -, hogy miért csak diplomás mérnökökben gondolkodik a szakma?). Az általam ismert ICS biztonsági szakemberek pontosan 100%-a érkezett vagy az IT/IT biztonság vagy az OT területéről - én sem vagyok kivétel, jó néhány éves IT/IT biztonsági múlttal a hátam mögött kezdtem beletanulni az ICS biztonság szép, de időnként piszok nehéz és komoly buktatókat rejtő világába. Amíg az IT/IT biztonsági és OT mérnökök kölcsönös gyanakvással, nem pedig egymást segítő kollégaként tekintenek egymásra, ne várjuk, hogy lesz elég ICS biztonsági szakemberünk.

Ezt helyzetet tovább rontja, hogy akik értenek a témához, nem beszélnek róla, mintegy ülnek a munkahelyük elefántcsont tornyában és egyedül próbálnak javítani valamit a saját rendszereik biztonsági helyzetén. Nagyon nagy szükség van a SeConSys-hez hasonló kezdeményezésekre, ahol az ICS biztonságot értő és a területen tevékenykedő szakemberek tudnak találkozni és tapasztalatot cserélni, vagy akár csak megvitatni az elmúlt időszak eseményeit. Nagyon hasznosnak tartanám, ha a nagyobb hazai IT biztonsági rendezvények (ITBN, ISACA konferencia, Sec-TOUR, Hacktivity, stb.) tudnának a témának egy-egy (akár zárt körű, meghívásos) szekciót szervezni, mert sajnos az látszik, hogy az állam ebben a témában nem igazán aktív (legjobb esetben is csak elfogadja az alulról jövő kezdeményezéseket).

ICS sérülékenységek CCVIII

Sérülékenységek Phoenix Contact, Geutebrück, Optergy és Panasonic rendszerekben

Sérülékenységek Phoenix Contact eszközökben

Zahra Khani, a Firmalyzer munkatársa és OPC Alapítvány több sérülékenységet azonosítottak a Phoenix Contact alábbi eszközeiben:

- AXC F 2152 2404267-es cikkszámú változatai;
- AXC F 2152 1046568-as cikkszámú változatai.

A gyártó a hibákkal kapcsolatban a legfrissebb elérhető firmware-verzió telepítését és kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységekről bővebben az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-155-01

Sérülékenység Phoenix Contact ipari switch-ekben

Maxim Rupp és a CERT@VDE a gyártóval együttműködve egy sérülékenységet találtak a Phoenix Contact alábbi ipari Ethernet switch-eiben:

- FL NAT SMN 8TX-M (2702443);
- FL NAT SMN 8TX-M-DMG (2989352);
- FL NAT SMN 8TX (2989365);
- FL NAT SMCS 8TX (2989378).

A hibával kapcsolatban a gyártó kockázatcsökkentő intézkedésekre tett javaslatot, a hibát javító új firmware-verzióról jelenleg nincs hír. A sérülékenységgel kapcsolatban részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-155-02

Geutebrück kamerák sérülékenységei

Romain Luyer és Guillaume Gronnier, a CEIS, valamint Davy Douhine, RandoriSec munkatársai két sérülékenységet jelentettek az NCCIC-nek a Geutebrück alábbi eszközeivel kapcsolatban:

- G-Code Encoder EEC-2xxx sorozatának eszközei 1.12.0.25 és korábbi firmware-verziók esetén;
- G-Cam kamerák 1.12.0.25 és korábbi firmware-verziók esetén:
- EBC-21xx;
- EFD-22xx;
- ETHC-22xx;
- EWPC-22xx.

A hibákat a gyártó az 1.12.13.2-es firmware-verzióban javította. A sérülékenységekről bővebben az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-155-03

Sérülékenységek Optergy épületmenedzsment rendszerekben

Gjoko Krstic, az Applied Risk munkatársa hét sérülékenységet azonosított az Optergy Proton/Enterprise épületmenedzsment rendszereinek 2.3.0a és korábbi verzióiban.

A gyártó a hibákat a Proton/Enterprise 2.4.5-ös és későbbi verzióiban javította. A sérülékenységekkel kapcsolatban részletesebb információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-157-01

Panasonic rendszerek sérülékenységei

A 9sg Security Team a ZDI-vel együttműködve két sérülékenységről publikált információkat, amik a Panasonic FPWIN Pro 7.3.0.0 és korábbi verzióit érintik.

A gyártó a hibákat az FPWIN Pro 7.3.1.0 és későbbi verzióiban javította. A sérülékenységekről az ICS-CERT publikációjában lehet több információt találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-157-02

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 Norsk Hydro ransomware-támadás pénzügyi hatásai

A Norsk Hydro elleni márciusi ransomware-támadás után lehetett tudni, hogy a cég 2019 elsõ negyedéves profitjára nagyon negatív hatással lesz az incidens, most azonban megérkeztek a konkrét számok. A Reuters cikke szerint a Norsk Hydro 2019 elsõ negyedéves profitja 559 millió norvég korona volt (nagyjából 64,3 millió amerikai dollár), ami 82 százalékos csökkenést jelent az elõzõ év azonos idõszakához mérve (és még így is 123 millió koronával magasabb érték volt, mint amit a Reuters által készített felmérésben résztvevõ elemezõk vártak).

Az incidens után a Norsk Hydro részvényei 20%-ot estek.

Ezek az adatok az ICS kiberbiztonság egy olyan aspektusát mutatják meg, amivel az OT és OT biztonsági mérnökök jóval ritkábban szoktak foglalkozni (és én sem igazán szoktam hangsúlyt helyezni egy-egy ICS biztonsági incidens pénzügyi következményeire), hiszen a kritikus infrastruktúrák és egyéb folyamatvezérlõ rendszerek elleni támadások elsõdleges hatásai szinte soha nem pénzügyiek és a legsúlyosabb következmények sem az anyagi veszteségben mutatkozhatnak meg, de ezek ellenére sem lehet figyelmen kívül hagyni.

ICS sérülékenység CCVII

Sérülékenységek Emerson és AVEVA rendszerekben

Sérülékenységek Emerson Ovation vezérlőkben

A VDLab két sérülékenységet jelentett az NCCIC-nek, amik az Emerson Ovation OCR400 Controller-ek 3.3.1-es és korábbi verzióit érintik.

A hibákkal kapcsolatban a gyártó kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységekkel kapcsolatban további információkat az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-148-01

AVEVA sérülékenység

A VAPT Team, a C3i Center és az IIT Kanpur egy sérülékenység részleteiről adott információkat az AVEVA-nak, ami a gyártó alábbi rendszereit érinti:

- Vijeo Citect 7.30 és 7.40-es verziói;
- CitectSCADA 7.30 és 7.40- es verziói.

A gyártó a hibával kapcsolatban a CitectSCADA 2018-ra történő frissítést 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-150-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.

Tanulmány a villamosenergia-rendszerek kiberbiztonsági ellenálló képességéről

Egy érdekes tanulmány jelent meg a Vermont-i Jogi Egyetem (Vermont Law School) Energetikai és környezettudományi intézetétől, amiben az amerikai villamosenergia-hálózat biztonságával kapcsolatos, hat hónapos vizsgálatuk kutatási eredményeit foglalják össze.

ICS sérülékenységek CCVI

Sérülékenységek Computrols, Mitsubishi Electric és Siemens Healthineers rendszerekben

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.

Letölthető olajkút-modell a Cisco Talos-tól

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

ICS sérülékenységek CCV

Sérülékenységek Siemens, Omron, Fuji Electric és Schneider Electric rendszerekben

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 legújabb RDP-sérülékenység lehetséges hatásai ICS rendszerekre

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).

Incidenskezelés ICS rendszerekben

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.