Ez a poszt a 2016.12.31-én megjelent, Egészségügyi folyamatvezérlő rendszerek kiberbiztonsága című írásom második része.

2013-14 során az FDA útmutatókat jelentetett meg az egészségügyi rendszerek biztonságával kapcsolatban, a végleges útmutató végül 2014 októberben vált elérhetővé. Az FDA útmutatója elsősorban az egészségügyi folyamatvezérlő eszközök biztonsági funkcióonak tervezési és fejlesztési fázisban történő alkalmazását hangsúlyozza. Részletesen az alábbi intézkedéseket nevesítik (nem meglepő módon ezek sokszor egybevágnak az ICS rendszerek biztonsága kapcsán már megismert intézkedésekkel):

- Eszközök, fenyegetések és sérülékenységek azonosítása;
- Az egészségügyi eszközök funkcionalitását és/vagy a pácienseket/végfelhasználókat érintő fenyegetések és sérülékenységek értékelése;
- A fenyegetések és a sérülékenységek kihasználásának valószínűségeinek értékelése;
- A kockázati szintek és a megfelelő kockázatcsökkentési stratégiák meghatározása;
- A maradványkockázatok és a kockázat elfogadási feltételek értékelése.

Az egészségügyi rendszerek biztonsági helyzete a jelenben

Napjainkra már megkezdődött az a folyamat, aminek során biztonsági szakértők bevonásával és egy átfogó megközelítés alkalmazásával probálják javítani az egészségügyi eszközök biztonsági szintjét. A problémák sokrétűek, hardver és szoftverhibák, a rádiós kommunikációs csatornák elleni támadások, malware-ek és a különböző sérülékenységek kihasználása egyaránt ide tartoznak. Egy, a témában 2014-ben készített felmérés az mutatta ki, hogy az egészségügyi eszközök biztonságával kapcsolatos fejlesztések elsősorban a telemetriai interfészek elleni támadásokra koncentráltak. Ezek a telemetriai interfészek döntő részben a rádiós kommunikációhoz kapcsolódnak. A felmérésből tisztán látszik, hogy a vezeték nélküli telemetriai adatforgalmazásnak öt fontos területe van: a biometrikus authentikáció, a rádióhullámokon keresztül távolról végrehajtott authentikáció, a többfaktoros authentikáció, a külső eszközök és az anomáliák észlelése.

Az egészségügyi rendszerek jövője

A ma hozott intézkedések nagy mértékben meghatározzák az egészségügyi rendszerek biztonságának jövőjét is. A biztonság mindig a kompromisszumokról szól és a tét az egészségügyi rendszerek esetén az egyik legnagyobb. Azonban így sem szabad hagyni, hogy az egészségügyi eszközök biztonságával kapcsolatos esetekből szenzációt kreáljanak, ehelyett józan, racionális és szisztematikus megközelítéssel meg kell érteni és csökkenteni kell a biztonsági kockázatokat. Az FDA javaslatai az NIST kiberbiztonsági keretrendszere alapján a következők:

- Azonosítani kell a védelemre szoruló folyamatokat és eszközöket;
- Definiálni kell az elérhető védelmi intézkedéseket;
- Incidens-felismerési technikákat kell kidolgozni;
- Intézkedési terveket kell kialakítani az incidensek kezelésére;
- Formalizált helyreállítási tervet kell készíteni.

Az egészségügyi rendszerekre leselkedő fenyegetések kiemelkedőek és az elkerülhetetlennek látszó nulladik napi támadásokkal is az egészségügyi eszközök teljes életciklusa alatt foglalkozni kell. Ez egy olyan feladat, amin az egészségügyi szolgáltatóknak, az eszközök gyártóinak, a szoftverek fejlesztőinek és a biztonsági szakembereknek együttműködve kell dolgozniuk - gyakran a páciensek bevonásával.

A Siemens ProductCERT tegnapi bejelentése szerint a SINUMERIK termékcsalád alábbi tagjaiban Man-in-The-Middle támadást lehetővé tevő hibát fedeztek fel:

- A SINUMERIK Integrate Access MyMachine/Ethernet AMM  Service  Engineer  Client  (ActiveX)-szel használt összes verziója;
- A SINUMERIK Integrate Access MyMachine/Ethernet és az Analyze  MyCondition SINUMERIK Integrate  Operate Client-tel használt verziói 2.0.3.00.016-tól a 2.0.6 előtti verzióig;
- A SINUMERIK Integrate Access MyMachine/Ethernet és az Analyze  MyCondition SINUMERIK Integrate  Operate Client-tel használt verziói 3.0.4.00.032-tól a 3.0.6 előtti verzióig;

A hiba által érintett SINUMERIK Integrate Operate kliensek:
- V4.5 SP6-tól a V4.5  SP6  Hotfix  8 előtti verzióig;
- V4.7 SP2 Hotfix 1-től a V4.7  SP4 előtti verzióig.

A hibát a Siemens az érintett szoftverek alábbi verzióiban javította:

- A SINUMERIK Integrate Access MyMachine/Ethernet és az Analyze  MyCondition SINUMERIK Operate V4.7 SP4 vagy SINUMERIK Integrate Operate Client V3.0.6;
- SINUMERIK Operate V4.5 SP6 Hotfix 8 vagy SINUMERIK Integrate Operate Client V2.0.6;
- A SINUMERIK Integrate Access MyMachine/Ethernet AMM  Service  Engineer  Client  (ActiveX)-szel használt szoftvereket az AMM  Service Client V4.1.0.5-tel javasolják kiváltani.

A sérülékenységgel kapcsolatban további információkat a Siemens ProductCERT publikációjában lehet olvasni: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-934525.pdf

Az elmúlt hét ismét elég erős termést hozott az ICS rendszerek sérülékenységei terén.

Siemens RuggedCom NMS webes sérülékenységek

A Siemens ProductCERT bejelentése alapján a RuggedCom NMS rendszer V2.1-nél korábbi minden (Windows-on és Linux-on futó) verziója tartalmaz egy-egy CSRF és XSS sérülékenységet.

A gyártó a hibákat a V2.1-es NMS verzióban javította és az új verzió telepítése mellett a weboldalán elérhető üzemeltetési útmutatóban leírtak alkalmazását javasolja.

A hibákkal kapcsolatban további információkat a Siemens ProductCERT bejelentése tartalmaz: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-363881.pdf

VIPA Controls WinPLC7 sérülékenység

A TrendMicro-hoz tartozó ZDI kutatója, Ariele Caltabiano (kimiya) egy puffer túlcsordulásos hibát talált a VIPA Controls nevű ICS gyártó WinPLC7 termékének 5.0.45.5921 és ennél korábbi verzióiban. A gyártó közzétett a hibával kapcsolatban egy javítást, ami innen tölthető le.

A sérülékenységről további információkat az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-054-01

Red Lion Controls termékek sérülékenységei

Mark Cross, a RIoT Solutions munkatársa beégetett titkosítási kulcsokat fedezett fel a Red Lion Controls alábbi termékeiben:

- Sixnet-Managed Industrial Switches, ha 5.0.196 vagy korábbi firmware-verziókat futtatnak;
- Az AutomationDirect által forgalmazott, de Red Lion Controls által gyártott Stride-Managed Ethernet Switches, ha 5.0.190 vagy korábbi firmware-verziókat futtatnak.

A gyártó a hibák javítására kiadta az SLX nevű firmware 5.3.174-es verzióját, amit innen lehet letölteni. Az AutomationDirect a Stride-Managed Ethernet Switches-hez használható firmware bináris itt érhető el: http://support.automationdirect.com/firmware/binaries.html

A hibával kapcsolatban további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-054-02

Schneider Electric Modicon M340 PLC sérülékenység

Luis Francisco Martin Liras jelentette a Schneider Electric-nek azt a hibát, amit a Modicon M340 PLC-család alábbi tagjainak 2.9-esnél korábbi firmware-verzióiban talált:

- BMXNOC0401;
- BMXNOE0100;
- BMXNOE0110;
- BMXNOE0110H;
- BMXNOR0200H;
- BMXP341000;
- BMXP342000;
- BMXP3420102;
- BMXP3420102CL;
- BMXP342020;
- BMXP342020H;
- BMXP342030;
- BMXP3420302;
- BMXP3420302H;
- BMXP342030H.

A hibát kihasználva egy támadó megfelelően kialakított hálózati csomagokkal képes lehet a PLC-ket lefagyasztani, ami után csak a fizikai újraindítással lehet ismét használható állapotba hozni az érintett berendezéseket.

A gyártó a hiba hatását csökkentő új (2.9-es) firmware-verziót elérhetővé tette a weboldalán: http://www.schneider-electric.com/en/download/document/BMXP342000_V29/

A hibával kapcsolatban részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-054-03

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áltasáok 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ű (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 laborkörülményekben célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

A különböző folyamatvezérlő rendszerek között külön csoportot képeznek az egészségügyben használt vezérlőrendszerek. Már a ’80-as években elterjedtek a különböző, szoftverekkel vezérelt, félig-meddig automatizáltan működő orvosi berendezések, például a terápiás röntgentgépek, inzulin és egyéb gyógyszeradagoló pumpák.

Ezek a rendszerek meglehetősen hosszú múltra tekintenek vissza és bizony számos súlyos incidensről is tudunk. Az 1980-as és 90-es években több súlyos, nem egy esetben halálesettel végződő incidens is történt (részletesebben a LEMIL blog General Protection Fault című sorozatának második részében lehet ezekről olvasni). Persze ezek az incidensek jellemzően tervezési/fejlesztési hibákra voltak visszavezethetőek, mert ekkor (még) senkinek nem jutott eszébe a különböző számítógép-vezérelte orvosi eszközöket Internetre vagy vezeték nélküli hálózatokra csatlakoztatni. Aztán ahogy az évek változtak, az Internet és a különböző vezeték nélküli kommunikációs megoldások egyre kényelmesebbé tették a mindennapi életet, elkezdték ezeket a technológiákat az ICS rendszerek mellett az egészségügyi folyamatvezérlők esetén is használni. Ezzel párhuzamosan megjelentek az implantálható egészségügyi folyamatvezérlő rendszerek is, például szívritmus-szabályozók, kisméretű inzulin-pumpák, stb. Ez a két technológiai fejleszts aztán azt eredményezte, hogy gyorsan elterjedtek a pánciensek testébe beépített, vezeték nélküli kommunikációt használó egészségügyi folyamatvezérlő rendszerek. Ez persze valahol érthető, hiszen mennyivel jobb és egyszerűbb mind az orvos, mind a páciens szempontjából, ha pl. a beépített szívritmus-szabályozóról WiFi-n keresztül tudja az orvos letölteni az összes fontos diagnosztikai adatot, mint ha ehhez mindenféle kábeleket kell csatlakoztatni a beteg testébe beépített gépre? Kényelmesnek természetesen kényelmes, azonban ha a fejlesztők nem foglalkoztak kellően alapos (vagy bármilyen) authentikációs eljárás leprogramozásával, akkor már közel sem ilyen jó a helyzet, hiszen ki tudja garantálni, hogy egy vezeték nélküli hálózaton csak azok az orvosok/kórházi alkalmazottak fognak gyengén védett eszközöket keresni, akik a pánciens gyógyulását akarják?

Azt, hogy ez a feltételezés mennyire nem légből kapott és paranoid gondolat, már a 2000-es évek közepén bemutatták biztonsági kutatók, amikor az implantálható egészségügyi eszközök szoftveres hibajavításaival kapcsolatos kutatások során azt találták, hogy ezek az eszközök különösen érzékenyek man-in-the-middle támadásokkal szemben.

2008-ban biztonsági kutatók egy ICD eszközben (Implantable Cardiatic Defibrillator - implantálható defibrillátor) olyan sérülékenységeket találtak, amelyeket kihasználva nem csak lehallgatható volt az ICD eszköz kommunikációja, de akár a defibrillátort arra is lehetett utasítani, hogy sokkolja a páciens szívét.

Szintén 2008-ban az USA legfelsőbb bírósága olyan ítéletet hozott, amely szerint az FDA (az USA Szövetségi Gyógyszer és Élelmiszerfelügyeleti Hatósága) által engedélyezett implantálható egészségügyi rendszerek által okozott károk esetén a gyártóknak csak korlátozott felelősségük van.

2011-ben számos implantálható inzulin-pumpával kapcsolatban jelentek meg biztonsági sérülékenységi információk, a legnagyobb nyilvánosságot kapott esetek Jerome Radcliffe Black Hat 2011-en, illetve Barnaby Jack Hacker Halted-on tartott előadásai voltak. Mindketten olyan kutatásokról számoltak be, amelyek során képesek voltak az implantálható inzulin-pumpák vezeték nélküli kommunikációs funkcióján keresztül az eszközök jogosultsági rendszerét megkerülve olyan műveletek végrehajtására utasítani az eszközöket, amik akár a pánciens halálához is vezethetnek.

2012 októberében, a melbourne-i Ruxcon Breakpoint biztonsági konferencián megint Barnaby Jack adott elő az implantálható egészségügyi rendszerek biztonságáról, ekkor az általa vizsgált pacemaker-ekben talált hibákról számolt be. Olyan hibákat is bemutatott, amikkel akár halálos mértékű áramütésre is képes lett volna utasítani egy szívbeteg páciensbe beültetett pacemaker-t - ismét csak az eszköz vezeték nélküli kommunikáció segítségével. Barnaby Jack a következő évben, a 2013-as Black Hat-re készülve, 35 éves korában halt meg kábítószer és gyógyszer túladagolásban San Francisco-ban.

A poszt második részében a 2013 után történt eseményeket, az egészségügyi rendszerek jelenét és jövőjét fogom áttekinteni.

Az elmúlt 1-2 évben új fogalmak jelentek meg az iparban: a negyedik ipari forradalomról vagy az ipari dolgok Internetéről (Industrial Internet of Things, IIoT) egyre gyakrabban lehet olvasni és hallani. Ahogy a konzumer IoT eszközök megváltoztatták a mindennapi életünket, úgy változtatják meg az IIoT rendszerek az ipari környezetek mostanáig meglehetősen statikus világát. Ezek változások azonban új kockázatokat és fenyegetéseket is magukkal hoznak, amelyeket értékelni és szükség esetén csökkenteni kell. Annál is inkább így van ez, mert az üzleti és pénzügyi szakterületek többnyire az IIoT bevezetése alapján tapasztalható hatékonyságnövelés és költségcsökkentés lehetőségeit látják, azzal azonban már jóval kevésbé vannak tisztában, milyen problémákat okozhat az új technológiák és a különböző eszközök fokozott méretű összekapcsolása. Az IoT kiberbiztonsági problémáinak legjobb példája a 2016. október 21-i, DynDNS elleni DDoS-támadás, amit a nem megfelelően üzembe helyezett és kompromittált IoT eszközök százezreivel hajtottak végre. Ezek az eszközök (pl. vezeték nélküli CCTV rendszerek) is egyre jobban terjednek az ipari környezetekben, de ezeket még nem nevezhetjük IIoT-nek.

Az előrejelzések szerint az IIoT eszközök 2015-2020 között 228%-os növekedést fognak produkálni, 2030-ra pedig várhatóan a 2015-ös érték 15-szörösére fognak nőni. Ez a mértékű növekedés várhatóan azt is fogja jelenteni, hogy a fenyegetések száma is exponenciálisan fog nőni.

Az ipari rendszerek biztonsága ma

Az ipari szektorban már az Internet megjelenése és térnyerése, valamint a vállalati és ipari hálózatok egyre gyakoribb és egyre szorosabb összekapcsolása is sok évtizedes beidegződések és szokások megváltoztatását követelte. Ezek a változások sok helyen a mai napig nem vagy csak nehezen indultak meg - a különböző ICS kiberbiztonsági konferenciákon és előadásokon még mindig alapvető mondanivaló az IT és OT szakterületek közötti együttműködés javításának fontossága. Ahogy látható, a legtöbb szervezet még ezeknek a kihívásoknak sem képes megfelelni, most pedig az IIoT térnyerésével a kockázatok és fenyegetések egy újabb, még magasabb szintre fognak lépni.

2010-ig, a Stuxnet nyilvánosságra kerüléséig az ICS kiberbiztonság egy nagyon szűk és nagyon megválogatott kör témája volt, éppen ezért szinte senki más nem is tudott róla. Az elmúlt közel 7 évben a helyzet alapjaiban változott meg, nem utolsó sorban a különböző ICS rendszerek izoláltságának fokozatos megszűnése miatt és ez korábban nem látott növekedést hozott a kockázatok és fenyegetések terén az ICS rendszerek számára. Az IIoT megjelenésével ugyanez a folyamat játszódik le újra - az IIoT alkalmazásától remélt pozitív hatások mellett a biztonsági megfontolások legjobb esetben is csak másodlagosak a döntéshozók szemében. További probléma, hogy a különböző rendszerek fokozottabb összekapcsolása miatt korábban nem látott fenyegetések kerülnek egyre közelebb az ICS rendszerekhez is. Elég a tavaly november végén, San Francisco-ban történt incidenst említeni, amikor egy zsaroló vírus miatt a tömegközlekedési vállalatnak - annak ellenére, hogy az ICS rendszereikig nem ért el a malware - jelentős kieséseket okozott a támadás. Ráadásul a támadók motivációi is sokszínűek lehetnek, az állami háttérrel rendelkező (kvázi kiberháborús műveleteket végrehajtó) csoportok mellett az IoT és IIoT eszközöket tisztán pénzszerzési céllal támadó csoportok is kezdik felfedezni az ipari környezetek biztonsági hiányosságait.

Mi lehet a megoldás?

Annak érdekében, hogy az IIoT térnyerése ne rontsa tovább az ICS kiberbiztonság egyébként sem magas szintjét, két vonalon kell mielőbb fejlődést elérni. Ezek egyáltalán nem új gondolatok, az IT rendszereknél ezeket már több, mint egy évtizede ismerik és sok esetben használják is.  Egyrészt az IIoT fejlesztések során a rendszertervezési fázistól foglalkozni kell a kiberbiztonság kérdéseivel és a biztonságot a rendszer elválaszthatatlan részeként kell kezelni. Másrészt az elkészült rendzsereket a teljes életciklus során rendszeresen biztonsági teszteknek kell alávetni és a feltárt sérülékenységeket kezelni kell. Nem lehet elégszer kiemelni, hogy az ICS rendszerek életciklus az IT rendszerekénél sokkal hosszabb, gyakran akár 15-20 év is lehet, így az ICS fejlesztőknek sokkal hosszabb támogatási ciklusokkal kell számolniuk - az IIoT fejlesztőkre ez fokozottan igaz, hiszen amíg egy, a gyártó által már nem támogatott ICS rendszer esetén megfelelő kompenzáló kontroll lehet a rendszer minden elemének egy zárt és biztonságosnak tekintett hálózatba történő használata, az IIoT rendszereknél ez sokkal nehezebb - ha egyáltalán megvalósítható.

A tendenciákat figyelve csak idő kérdése, hogy a támadók (és a különböző exploit kit-eknek köszönhetően akár az egészen alacsony technikai tudású támadók is) célba vegyék az IIoT rendszereket. Az ipari rendszerek, folyamatok és elsősorban az emberek biztonságának biztosítása az üzemeltetők és fejlesztők felelőssége, ezért fontos, hogy az együttműködésük a biztonságosabb IIoT rendszerek kialakításáért minél előbb elkezdődjön.

A napokban ismét két gyártó termékeivel kapcsolatban jelentek meg sérülékenységi információk az ICS-CERT weboldalán.

Advantech WebAccess sérülékenység

Li MingZheng Kuangn az Advantech WebAccess 8.1-es és korábbi verzióiban azonosított egy DLL hijacking hibát. A gyártó a sérülékenységet a 8.2-es verzióban javította.

A hibával kapcsolatban bővebb információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-045-01

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

Florent Montel és Frédéric Cikala, illetve Davy Douhine, a RandoriSec munkatársai két sérülékenységet fedeztek fel a Geutebrück G-Cam/EFD-2250 típusú IP kameráinak 1.11.0.12-es verziójú firmware-t futtató példányaiban.

Az első hiba a rendszer authentikációs eljárásának megkerülését teszi lehetővé, a második hiba pedig a parancssori adatbevitel nem megfelelő ellenőrzése miatt root jogosultságú operációs rendszer-hozzáférést adhat egy támadónak. A kettő közül bármelyik hiba sikeres kihasználása távoli kódfuttatást tesz lehetővé.

A gyártó weboldalán már elérhetővé tette a javítást a hibákra.

A sérülékenységekről további információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-17-045-02

A fenti sérülékenységekkel kapcsolatban az ICS-CERT ezúttal is a szokásos kockázatcsökkentő intézkedések alkalmazását javasolja:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel;
- 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!

Hanwha Techwin Smart Security Manager sérülékenységek

Steven Seeley, a Source Incite munkatársa két sérülékenységet fedezett fel a Hanwha Techwin Smart Security Manager 1.5-ös és korábbi verzióiban. Az első hiba egy könyvtár-bejárásos támadásra nyújt lehetőséget, a másik pedig egy Cross-site Request Forgery.

A Dél-koreai gyártó a weboldalán elérhetővé tette patch-eket az 1.3-as, 1.4-es és 1.5-ös verziókhoz.

A sérülékenységekkel kapcsolatban további információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-040-01

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

A Siemens ProductCERT bejelentése szerint a SIMATIC Logon V1.5 SP3 Update2-nél korábbi verzióiban egy olyan hibát fedeztek fel, ami lehetővé teszi a beépített, alkalmazás-szintű authentikáció megkerülését. A SIMATIC Logon-t több Siemens által gyártott ipari rendszer használja felhasználó és jogosultságkezelési feladatokra:

- SIMATIC WinCC V7.x;
- SIMATIC WinCC Runtime  Professional minden verziója;
- SIMATIC PCS 7 minden verziója;
- SIMATIC PDM minden verziója;
- SIMATIC IT minden verziója.

A Siemens a hibát a SIMATIC Logon V1.5 SP3 Update2-ben javította és elérhetővé tette ipari termékeihez fenntartott support weboldalán.

A sérülékenységről további információkat a Siemens ProductCERT bejelentésében lehet találni: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-931064.pdf

A fenti hibákkal kapcsolatban is fontos kiemelni, hogy a megfelelően alkalmazott biztonsági intézkedések jelentősen csökkenthetik a sérülékenységek által érintett rendszerek kockázatait is:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel;
- 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!

Korábban már írtam a SANS belépő szintű ICS biztonsági képzéséről az ICS410: ICS/SCADA Security Essentials nevű képzésről. Ma a másik, 400-as sorozatba, vagyis alap szintű képzésről lesz szó, ami a NERC CIP (Critical Infrastructure Protection, kritikus infrastruktúra védelem) témakörét mutatja be a tanfolyam résztvevőinek. Bár a NERC alapvetően egy, az USA villamosenergia-rendszerére kitalált szabvány, Európában és szerte a világon egyre több helyen alkalmazzák vagy használják a saját, helyi vagy régiós szabályok alapjául, így adott esetben hasznos lehet ez a tanfolyam is.

A NERC CIP-nek jelenleg 11 fejezete van, ezek közül egy (a CIP-014-2) a fizikai biztonsággal, a maradék 10 pedig a kiberbiztonsági terület különböző témáival foglalkozik.

Ahogy az ICS/SCADA Security Essentials, a NERC CIP tanfolyam is 5 napos. Az első napon a villamosenergia-rendszerre vonatkozó szabályozói környezet történetével és a jelenlegi környezet áttekintésével keződik a képzés, majd bemutatásra kerül a NERC funkcionális modellje és a NERC megbízhatósági szabvány. Ezután a tanfolyam résztvevői röviden áttekintik a kritikus infrastruktúra védelem történetét, ami után megismerkednek a NERC CIP által használt kifejezésekkel és definíciókkal. Az első nap utolsó blokkjában megismerik a NERC CIP-002 (A nagyfeszültségű villamosenergia-rendszer informatikai rendszereinek kategorizálása) és a CIP-003 (Biztonsági menedzsment kontrollok) fejezeteit.

A tanfolyam második napja a hozzáférés-vezérlés és ellenőrzés területeivel foglalkozik. Elsőként a CIP-005 (elektronikus határvédelem) témája kerül terítékre, majd az interaktív távoli hozzáférésekről illetve a route-olható külső kommunikáció és az elektronikus hozzáférési pontok témáját tekintik át a résztvevők. A következő részben a CIP-006 alapján a nagyfeszültségű villamosenergia-rendszer informatikai rendszereinek fizikai biztonságáról, majd a fizikai biztonsági tervről és a látogatók ellenőrzési programjáról ad átfogó képet a tanfolyam. A nap két utolsó fejezetében a fizikai hozzáférés-vezérléshez használt rendszerek karbantartásával és tesztelésével, majd a CIP-014 (fizikai biztonság) fejezettel ismerteti meg a tanfolyam a hallgatókat.

A harmadik nap a rendszerek menedzsmentje témakör köré épül. A nap első felében a CIP-007 (rendszermenedzsment) keretében a fizikai és logikai portok, a patch menedzsment, a kártékony kódok elleni védelem és a felhasználói fiókok kezelésének témaköreit tekinti át a tanfolyam, majd a nap második felében a CIP-010 (Konfiguráció és változáskezelés, sérülékenység vizsgálat) alapján a változáskezelési programokkal, az alapkonfigurációkkal és a változáskezelési riasztásokkal és incidensmegelőzési lehetőségekkel foglalkozik részletesen a képzés.

A negyedik nap a kritikus infrastruktúrákkal kapcsolatos információk védelme köré épül. A CIP-004 (személyzet és képzés) fejezete alapján bemutatja a biztonságtudatossági program és a kritikus infrastruktúra védelemmel kapcsolatos képzési programokat, majd a humánbiztonsági kockázatelemzési folyamattal ismerkednek meg a képzésben résztvevők. A második blokkban a CIP-011 (információvédelem) alapján az információk védelmével kapcsolatos programokkal és az adatok biztonsági ellenőrzésével foglalkozik a tanfolyam. A következő részben a CIP-008 (incidensek jelentése és incidens-elhárítás tervezés) fejezete alapján az incidenskezelési terv elkészítését és tervezését ismerik meg a résztvevők, majd részletesen áttekintik a NERC CIP jelentéstételi kötelezettségekkel kapcsolatos részleteit is. A nap utolsó részében a CIP-009 (helyreállítási tervek a nagyfeszültségű villamosenergia-rendszer informatikai rendszerei esetén) bemutatásával a helyreállítási tervekről és a rendszerek mentéseiről szól a tanfolyam.

Az utolsó napon a tanfolyam bemutatja azokat a folyamatokat, amelyek segítenek fenntartani a NERC CIP megfelelőséget, segítséget nyújtanak az auditra történő felkészülés és az audit utáni feladatok elvégzése során. Betekintést nyújt a képzés a kritikus infrastruktúra-védelemmel foglalkozó iparág tevékenységeibe és a szabvánnyal kapcslatos folyamatokban is, zárásként pedig szóba kerül a jövő kritikus infrastruktúra-védelme.

Az elmúlt egy hét ismét termékenynek bizonyult ICS sérülékenységek terén, három gyártó különböző temrékeivel kapcsolatban jelentek meg új sérülékenységi információk.

Honeywell XL sérülékenységek

A Honeywell XL termékcsaládjának alábbi tagjaiban Maxim Rupp független biztonsági kutató fedezett fel 5 különböző hibát:

- XL1000C500 XLWebExe-2-01-00 és korábbi verziói;
- XLWeb 500 XLWebExe-1-02-08 és korábbi verziói.

A hibák között olvasható formában tárolt jelszó, nem megfelelően védett felhasználói adatok, nem megfelelő jogosultság-kezelés, könyvtárbejárást lehetővé tevő hiba mellett egy olyan hiba is található, amivel egy támadó egy már authentikált felhasználói munkamenetet tud átvenni. A gyártó a hibákat a 3.04.05.05-ös verzióban javította a hibákat.

A sérülékenységekről további információkat az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-033-01

BD Alaris sérülékenységek

A Becton, Dickinson and Company (BD) több termékében is olyan hibát fedezett fel, ami miatt a felhasználói adatok védelme kijátszható. A hiba az alábbi termékeket érinti:

- Alaris 8000 PC, minden verzió;
- Alaris 8015 PC, Version 9.5 és korábbi verziók;
- Alaris 8015 PC, Version 9.7 és korábbi verziók.

A hibával kapcsolatban a gyártó nem tervezi javítás kiadását, azonban a kockázatok csökkentését célzó javaslatokat tett a hiba által érintett termékeit használóknak:

- A felhasználóknak javasolt telepíteni egy fizikai eszközök kezelését naplózó rendszert, amivel az eszközök követése és leltározása történik;
- Az Alaris PC eszközök vezeték nélküli kapcsolatainak authentikációs adatait javasolt törölni, ha az eszközöket le kell szerelni vagy szállítani kell. A vezeték nélküli kapcsolat authentikációs adatainak törlési eljárását az Alaris System Maintenance Software User Manual című kézikönyv tartalmazza;
- Javasolt rendszeresen változtatni az érintett Alaris PC típusú eszközökön a vezeték nélküli kapcsolathoz használt authentikációs adatokat. Amennyiben felmerül annak a lehetősége, hogy valaki fizikailag hozzáférhetett egy, a sérülékenység által érintett Alaris PC-hez, javasolt azonnal megváltoztatni az authentikációs adatokat;
- Amennyiben az eszközökön nincs használatban a vezeték nélküli kommunikáció lehetősége, javasolt a vezeték nélküli authentikáció beállítását nélkülözni;
- Javasolt ACL-ekkel szűrni, hogy mely fizikai (MAC) és logikai (IP) címekről illetve portokon, protokollokon és szolgáltatásokkal lehet elérni a sérülékenység által érintett Alaris PC eszközöket;
- Javasolt az Alaris PC-ket egy szeparált, dedikált SSID-vel ellátott hálózatban elhelyezni. A BD azt is javasolja, hogy gyakran változzon az SSID és a vezeték nélküli kapcsolathoz használt authentikációs adatok. (Én személy szerint az authentikációhoz használt adatok változtatásának lelkes híve vagyok, de az SSID változatását értelmetlennek tartom, valószínűleg annyi eredménye lehet, hogy az üzemeltető személyzetnek kicsit nehézkesebb lesz fejben tartani a rendszeres SSID változásokat, de egy támadót maximum 1-2 percre tart fel egy ilyen "biztonsági intézkedés").

A fenti hibákkal kapcsolatban az ICS-CERT két bejelentést is publikált:
https://ics-cert.us-cert.gov/advisories/ICSMA-17-017-01
https://ics-cert.us-cert.gov/advisories/ICSMA-17-017-02

A gyártó által kiadott, Alaris PC modell 8015-höz kiadott biztonsági közlemény itt érhető el: http://www.carefusion.com/customer-support/alerts-and-notices/product-security-bulletin-for-alaris-pc-unit-model-8000

Sielco Sistemi Winlog SCADA Software sérülékenység

Karn Ganeshen független biztonsági kutató egy DLL hijacking-et lehetővé tevő hibát fedezett fel az olasz Sielco Sistemi Winlog SCADA nevű szoftverének alábbi verzióiban:

- Winlog Lite SCADA Software 3.02.01 előtti verziói;
- Winlog Pro SCADA Software 3.02.01 előtti verziói.

A gyártó a hibát a Winlog SCADA legújabb verziójában javította és az új verziót elérhetővé tette a weboldalán: https://www.sielcosistemi.com/en/download/public/download.html

A sérülékenységgel kapcsolatos további részletek az ICS-CERT bejelentésében érhetőek el: https://ics-cert.us-cert.gov/advisories/ICSA-17-038-01

A hibákkal kapcsolatban az ICS-CERT a már ismert kockázatcsökkentő intézkedések alkalmazását javasolja:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel;
- 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!

Az IEC 60870-5-104, közismertebb (és rövidebb) nevén a 104-es protokoll elsősorban Európában terjedt el széles körben az ICS rendszerek közötti kommunikáció eszközeként. A Talos, a Cisco biztonsági laborja december második felében 33 új Snort szabályt tett elérhetővé, kifejezetten a 104-es protokollon történő kommunikáció jobb elemzésének támogatására. Ezekkel az új szabályokkal az ipari folyamatirányító rendszereket üzemeltető szervezetek egy újabb eszközt kapnak, hogy képesek legyenek ellenőrizni a 104-es protokollon történő adatforgalmazást és a lehető leggyorsabban tudják feltárni a különböző (szándékos vagy véletlen hibából bekövetkező) incidensek hátterét. Annak érdekében, hogy ezek a szabályok a lehető leghatékonyabb forgalomelemzést biztosítsák, körültekintően kell konfigurálni őket, az egyes hálózatok egyedi karakterisztikáit figyelmbe véve. Például a SIDS 41053-41077-es szabály számos TypeID-t képes azonosítani, ezt a szabályt akkor célszerű engedélyezni, ha a védendő ICS rendszerben nem használják ezeket a TypeID-kat. A SIDS 41078-41079-es szabály az ICS hálózatba be- illetve onnan kilépő 104-es protokoll alapú kommunikációt figyeli. Amennyiben az adott ICS rendszernél az üzemszerű működéshez nem szükséges a 104 protokollra alapuló kommunikációnak elhagynia az ICS hálózatot, ezt a szabályt javasolt bekapcsolni.

A Cisco még 2013-ban jelentette be a SourceFire felvásárlását, azóta tartozik a portfóliójukba a FirePower termékcsalád, amelyeknél ezeket az új szabályokat is használni lehet.

Természetesen a különböző ICS rendszerek esetén az IPS-ek blokkolás funkcióját csak nagyon körültekintően szabad alkalmazni, azonban ezek az eszközök (még az inline IPS-ek is) alkalmasak IDS-módban is működni, amikor nem blokkolják, csak észlelik (és a beállítások szerint akár riasztanak is) gyanús hálózati forgalom esetén. Ezek az eszközök nagy segítséget jelenthetnek az ICS rendszerek elleni támadások mielőbbi felfedezése során, így mindenképp célszerű megfontolni az alkalmazásukat.