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

ICS Cyber Security blog

ICS Cyber Security blog

Az ICS Cyber Security Kill Chain II

Mi az a Cyber Security Kill Chain? - folytatás

2017. május 27. - icscybersec

Ma a múlt héten elkezdett, Cyber Security Kill Chain bemutatását folytatom.

4. A sérülékenység kihasználása (Expoitation): Hozzáférés szerzése a célba vett rendszeren

A támadók tevékenységei: A támadóknak ahhoz, hogy hozzáférést szerezzenek a célba vett rendszeren, ki kell használniuk egy vagy több korábban felfedezett sérülékenységet - ezek adódhatnak szoftveres, hardveres vagy emberei hibákból. Ebben a fázisban egyaránt elképzelhetőek a támadó által kiváltott sérülékenység-kihasználások (a legtöbb szerver oldali sérülékenység ilyen) vagy olyan, emberi hibákból adódó támadási vektorok, mint például egy kártékony kódot tartalmazó e-mail megnyitása vagy egy ártó szándékú webhelyre mutató hivatkozás követése.

A védők tevékenységei: A célba vett rendszerek esetén a hagyományos hardening-technikák nyújthatnak bizonyos fokú ellenálló képességet, de például a nulladik napi sérülékenységeket célzó támadások elhárításához egyedi képességekre is szükség van. A védekezésben fontos szerep jut a biztonságtudatossági képzéseknek, a fejlesztők biztonságos fejlesztési technikákra történő oktatása, rendszeres sérülékenység vizsgálatok és betöréstesztek végrehajtása. Kiemelten kell foglalkozni a végponti berendezések hardening-jével, elsősorban az adminisztratív jogosultságok szigorú korlátozásával, a kódvégrehajtás lehetőségének minimálisan szükséges szintre történő korlátozásával és az olyan szoftverek alkalmazásával, amikkel csökkenteni lehet egy támadás sikerességének az esélyét (az ilyen szoftverek közül a legismertebb talán a Microsoft EMET, aminek a fejlesztése a hírek szerint rövidesen megszűnik, azonban helyette több ingyenes és fizetős megoldás is néhány perces kereséssel elérhető).

5. Hátsó ajtók telepítése (Installation): Hídfő kiépítése az áldozat rendszerében

A támadók tevékenységei ebben a fázisban a megszerzett hozzáférés(ek) hosszabb időn át történő fenntartására koncentrálnak, különböző hozzáférési módok kialakításával, pl. webshell vagy különböző backdoor-ok telepítésével. Egyes támadók arra is figyelnek, hogy az így létrehozott fájlok létrehozási/utolsó módosítási dátumát visszaállítsák, hogy úgy tűnjön, a fájl az adott rendszer telepítésekor lett létrehozva.

A védők tevékenységei: A védők ebben a fázisban leginkább a különböző végponti biztonsági eszközökkel, host IPS-ekkel és más végpontvédelmi megoldásokkal tudnak védekezni. Fontos továbbá, hogy megértsék, az adott malware, amivel a támadók hozzáférést szereztek az adott rendszerhez, adminisztrátori vagy felhasználói jogosultságokkal fertőz. A védekezésben sokat segíthet a végponti folyamatok auditálására illetve a fájl konzisztencia ellenőrzésre használható megoldások, valamint a digitálisan aláírt futtatható állományok tanúsítványainak vizsgálata is. Érdemes ellenőrizni a támadáshoz használt malware fordításának idejét is, amiből elég jó következtetéseket lehet levonni arra vonatkozóan, hogy egy új vagy egy régebbi malware-rel van-e dolguk a védőknek.

6. Irányítás (Command&Control - C2): A kompromittált rendszer távoli vezérlése

A támadók tevékenységei: Ebben a fázisban a támadók olyan kétirányú kommunikációt próbálnak építeni a kompromittált eszköz és egy, a saját irányításuk alatt lévő szerver között, amivel később is a céljaiknak megfelelően tudják használni az adott eszközt. Az ilyen szervereket hívják Command&Control, röviden C2 szervereknek. A leggyakoribb C2 csatornák a webes, DNS és e-mail protokollok.

A védők tevékenységei: A védők számára ebben a fázisban nyílik utoljára lehetőség arra, hogy megakadályozzák a támadók műveleteit, azzal, hogy blokkolják a C2 csatornákat. Ha ez sikeres, a támadók nem tudják majd irányítani a megfertőzött eszközt és így a védők megelőzhetik a nagyobb károkat. A védekezés során hasznos eszköz lehet a malware-analízis, amivel be lehet azonosítani az adott malware által használt C2 infrastruktúrát és ezzel lehetőség nyílik tökéletesen blokkolni a C2 forgalmat. A hálózaton végzett biztonsági hardening (az Internetes jelenléthez használt pontok számának minimalizálása és a leggyakoribb forgalmak, pl. HTTP, DNS proxy-kon keresztül történő átengedése). Szintén hatékonyabbá teheti a védekezést a nyílt forrású információgyűjtésből (és a szektoriális jellegű együttműködésekből!) származó újabb és újabb C2 infrastruktúrák adatai.

7. A cél elérése (Actions on objectives)

A támadók tevékenységei: Az utolsó fázisban a támadók már azt teszik, amiért az egész műveletet elkezdték. Felhasználói adatokat gyűjtenek össze és lopnak ki a megtámadott rendszerből, magasabb (jellmezően adminisztrátori) jogosultságokat próbálnak szerezni, a megtámadott szervezet belső hálózatát próbálják felderíteni és további rendszerekben próbálják megvetni a lábukat vagy akár használhatatlanná tesznek rendszereket, felülírnak vagy titkosítanak adatokat.

A védők tevékenységei: Ha egy IT biztonsági incidens eljut a CSKC 7. fázisáig, akkor a védőknek már az kell, hogy legyen az elsődleges szempontjuk, hogy minél rövidebb idő alatt meg tudják szakítani a támadók hozzáférését a kompromittált rendszerekhez, ugyanis minél tovább van hozzáférésük a támadóknak egy rendszerhez, annál nagyobb károkat tudnak okozni. Ahhoz, hogy a védők minél előbb meg tudják szüntetni a támadók hozzáféréseit, jól kidolgozott és begyakorolt incidenskezelési forgatókönyveket kell alkotni és elengedhetetlen a felelős vezetők bevonása és egy hatékony kommunikációs terv kialakítása. A műszaki megoldásokból ebben a fázisban azok a megoldások a leginkább hatékonyak, amelyekkel észlelni lehet a nagyobb mennyiségű kimenő adatot, a nem engedélyezett felhasználói fiókok használatát, az incidenskezelésben használható különböző vizsgálati eszközök előtelepítését az egyes végpontokra és a hálózati forgalom rögzítését végző eszközöket, amelyek adataiból a vizsgálat során fel lehet építeni a támadás menetét.

Utólagos elemzések - a támadási minták azonosítása

A fentiek alapján elemzett támadások alapján egészen jó képet lehet kapni az egyes támadások közötti hasonlóságokról. A védők ezek alapján megtanulhatják felismerni és meghatározni a támadásokat és megérteni a támadók céljait. A CSKC alkalmazásával a szervezetek megelőzhetik a jövőbeli támadások egy részét és ellenállóbbá válhatnak azokkal, amelyek mégis be fognak következni.

ICS sérülékenységek CXIV

Schneider Electric, Miele Professional, B. Braun Medical, Rockwell Automation, Moxa és Siemens Healthineers rendszerek sérülékenységei

Az elmúlt egy hétben ismét számos új, ICS rendszereket érintő sérülékenységi információ látott napvilágot, nem teljesen függetlenül a WannaCry ransomware-támadások utóhatásaitól.

Sérülékenység a Miele Professional PG 85 sorozatú berendezésekben

Jens Regel, a Schneider & Wulf munkatársa mindenfajta előzetes egyeztetés nélkül publikált egy, a Miele Professional PG 85 sorozatú berendezéseiben felfedezett, könyvtár-bejárást lehetővé tevő hibát. A sérülékenység az alábbi verziókat érinti:

- PG8527, 2.02, 2.51, 2.52 és 2.54-es verziók;
- PG8528, 2.02, 2.51, 2.52 és 2.54-es verziók;
- PG8535, 1.00 és 1.04-es verziók;
- PG8536, 1.10 és 1.14-es verziók.

A gyártó a hiba javítását május 4-én adta ki, a sérülékeny verziókat használó ügyfelek az alábbi verziókra frissítve javíthatják a hibát:

- PG8527, 2.02-es verzió esetén a 2.12-es verzióval;
- PG8527, 2.51-es verzió esetén a 2.61-es verzióval;
- PG8527, 2.52-es verzió esetén a 2.62-es verzióval;
- PG8527, 2.54-es verzió esetén a 2.64-es verzióval;
- PG8528, 2.02-es verzió esetén a 2.12-es verzióval;
- PG8528, 2.51-es verzió esetén a 2.61-es verzióval;
- PG8528, 2.52-es verzió esetén a 2.62-es verzióval;
- PG8528, 2.54-es verzió esetén a 2.64-es verzióval;
- PG8535, 1.00-ás verzió esetén az 1.10-es verzióval;
- PG8535, 1.04-es verzió esetén az 1.14-es verzióval;
- PG8536, 1.10-es verzió esetén az 1.20-as verzióval;
- PG8536, 1.14-es verzió esetén az 1.24-es verzióval.

A hibával kapcsolatban bővebb információkat az ICS-CERT bejelentésében és a gyártó sajtóközleményéből lehet megtudni.

Schneider Electric Wonderware sérülékenység

Karn Ganeshen egy helytelen alapértelmezett jogosultsági beállításból fakadó sérülékenységet talált a Wonderware InduSoft Web Studio v8.0 Patch 3 és azt megelőző verzióiban. A hiba kihasználásával egy támadó képes lehet a jogosultsági szintjének emelésére a sérülékeny rendszerekben.

A Schneider Electric a hibát a Wonderware InduSoft Web Studio v8.0 + Service Pack 1 verzióban javította.

A sérülékenységről további részleteket az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-138-02

Sérülékenység B. Braun Medical rendszerekben

Marc Ruef és Rocco Gagliardi of scip AG munkatársai egy URL átirányítást lehetővé tevő hibát találtak a B. Braun Medical alábbi SpaceCom moduljaiban:

- A 8713142U cikkszámú SpaceCom modulok 012U000040-nél korábbi verziói;
- A 8713140U cikkszámú SpaceStation berendezések 8713160U cikkszámú SpaceCom moduljainak 012U000040-nél korábbi verziói.

A B. Braun Medical a hibát a 012U000040-es verzióban javította, amit (telepítési tanácsokkal együtt) a gyártó FTP-szerveréről lehet letölteni.

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

Sérülékenység egyes Rockwell Automation Allen-Bradley MicroLogix rendszerekben

A Rockwell Automation Allen-Bradley MicroLogix alábbi berendezéseit érintő hibát egymástól függetlenül David Formby és Raheem Beyah, a GeorgiaTech és a Fortiphyd Logic, Inc. kutatói, valamint Ilya Karpov, a Positive Technologies munkatársa fedezték fel:

- MicroLogix 1100 PLC-k:
- 1763-L16AWA, A és B sorozat, 16.00 és ennél korábbi verziók;
- 1763-L16BBB, A és B sorozat, 16.00 és ennél korábbi verziók;
- 1763-L16BWA, A és B sorozat, 16.00 és ennél korábbi verziók;
- 1763-L16DWD, A és B sorozat, 16.00 és ennél korábbi verziók;
- MicroLogix 1400 PLC-k:
1766-L32AWA, A és B sorozat, 16.00 és ennél korábbi verziók;
1766-L32BWA, A és B sorozat, 16.00 és ennél korábbi verziók;
1766-L32BWAA, A és B sorozat, 16.00 és ennél korábbi verziók;
1766-L32BXB, A és B sorozat, 16.00 és ennél korábbi verziók;
1766-L32BXBA, A és B sorozat, 16.00 és ennél korábbi verziók;
1766-L32AWAA, A és B sorozat, 16.00 és ennél korábbi verziók.

A kutatók által feltárt hibák az alábbiak:
- A korábbi TCP szekvencia-számokból megjósolható a következő érték, amit kihasználva egy támadó képes lehet meghamisítani az érintett eszközök kommunikációját;
- Egyszer használatos értékek ismételt felhasználása az alkalmazott titkosítási eljárásban;
- A felhasználói adatok sima HTTP GET-tel történő továbbítása lehetőséget ad a felhasználói adatok rögzítésére;
- Nincs semmilyen kontroll a nyers erőn alapuló jelszótörési kísérletek kivédésére;
- Gyenge jelszavak használatának lehetősége.

A hibát a Rockwell Automation a MicroLogix 1400 B sorozatú eszközeihez kiadott, FRN 21.00 firmware-verzióban javította. A MicroLogix 1100 A és B, valamint az 1400 A sorozatú eszközökhöz a gyártó már nem adta ki a hibák javítását tartalmazó firmware-verziót, helyett a kockázatokat csökkentő intézekdések bevezetését javasolja:

- Ha nem szükséges, le kell tiltani az érintett eszközök beépített webszerverét;
- Az érintett eszközöket futási módban kapcsolva megvédhetjük a a sérülékeny berendezéseket.

A sérülékenységgel kapcsolatban további részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-115-04

Moxa OnCell sérülékenységek

Maxim Rupp három hibát talált a Moxa alábbi, nagy sebességű, ipari szintű átjáróiban:

- OnCell G3110-HSPA 1.3 build 15082117 és korábbi verziók;
- OnCell G3110-HSDPA 1.2 Build 09123015 és korábbi verziók;
- OnCell G3150-HSDPA 1.4 Build 11051315 és korábbi verziók;
- OnCell 5104-HSDPA;
- OnCell 5104-HSPA<
- OnCell 5004-HSPA.

A hibákról dióhéjban:
- Az első sérülékenységet a nyers erőn alapuló jelszótörések elleni védelem hiánya okozza;
- A második hiba a jelszavak olvasható, szöveges formában történő tárolásából adódik;
- A harmadik hiba pedig egy CSRF.

A fenti hibákat a Moxa csak az alábbi modellek esetén javíotta, az OnCell G31x0-HSPA és OnCell 5x04-HSPA modellek esetén az 1.4-es vagy újabb firmware-verziók már javítják a fenti sérülékenységeket. Az OnCell G31x0-HSPA és OnCell 5x04-HSPA modellek esetén a felhasználók számára javasolt letilteni a HTTP kapcsolatokat és helyette inkáb a HTTPS használatát tanácsolják.

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-17-143-01

EternalBlue (WannaCry) sérülékenység Siemens Healthineers egészségügyi rendszerekben

A Siemens számos, Siemens Healthineers termékcsaláddal kapcsolatos bejelentést publikált, amikben az alábbi termékek EternalBlue sérülékenységére és annak már elérhető javításaira hívják fel a figyelmet:

- syngo Multimodality Workplace (MMWP) minden verziója;
- MAGNETOM® MRI rendszerek minden verziója;
- Molekuláris képalkotó rendszerek:
- PET/CT rendszerek: minden modell minden verziója;
- SPECT/CT rendszerek: minden modell minden verziója;
- SPECT rendszerek: minden modell minden verziója;
- SPECT rendszerek: minden modell minden verziója;
- Laboratóriumi diagnosztikai rendszerek:
- Atellica® COAG 360 minden verziója;
- BCS® XP minden verziója;
- BN ProSpec® minden verziója;
- Atellica NEPH 630 minden verziója;
- BEP 2000 Advance® minden verziója;
- Quadriga BeFree minden verziója;
- ADVIA® 2120i minden verziója;
- ADVIA 120 minden verziója;
- Sysmex® CS-2000i/2100i minden verziója;
- Sysmex CS-2500 minden verziója;
- Sysmex CS-5100 minden verziója;
- ADVIA 560 minden verziója;
- ADVIA Chemistry 1800 minden verziója;
- ADVIA Chemistry 2400 minden verziója;
- ADVIA Chemistry XPT minden verziója;
- ADVIA Centaur® XP minden verziója;
- ADVIA Centaur CP minden verziója;
- ADVIA Centaur XPT minden verziója;
- Dimension Vista® minden verziója;
- IMMULITE® 1000 minden verziója;
- IMMULITE 2000 minden verziója;
- syngo® Laboratory Connectivity Manager: minden verziója;
- syngo Laboratory Data Manager minden verziója;
- Aptio® Automation minden verziója;
- ADVIA Automation minden verziója;
- VersaCell® minden verziója;
- VersaCell X3 minden verziója;
- VivaTM minden verziója;
- Röntgenográfiai, mobil röntgen és mammográfiai rendszerek:
- Mammomat Inspiration® minden verziója;
- Mammomat Fusion® minden verziója;
- syngo® MammoReport minden verziója;
- Mammomat Novation minden verziója;
- AXIOM® Aristos FX/MX/VX/TX minden verziója;
- MULTIX® M minden verziója;
- MULTIX® Swing mFD minden verziója;
- Mobilett XP digital® minden verziója;
- Molekuláris diagnosztikai rendszerek:
- VERSANT kPCR Molecular System minden verziója;
- VERSANT kPCR Sample Prep minden verziója;
- Tissue Preparation System minden verziója;
- Onkológiai sugárkezelő rendszerek:
- RTT minden verziója;
- Coherence Therapist / Primeview 3i minden verziója;
- Coherence Oncologist minden verziója;
- Coherence Dosimetrist minden verziója;
- Coherence Physicist minden verziója;
- Syngo RT Therapist minden verziója;
- Syngo RT Oncologist minden verziója;
- Syngo RT Dosimetrist minden verziója;
- ModuLeaf minden verziója;
- Simview 3000/NT minden verziója;
- Beamview NT minden verziója;
- Lantis minden verziója;
- Mosaiq (Elekta product) minden verziója;
- Biograph mMR rendszer minden verziója;
- Point-of-Care rendszerek:
- RAPIDPoint 400 minden verziója;
- RAPIDPoint 500 minden verziója;
- RAPIDLab 1200 minden verziója;
- CLINITEK AUWi minden verziója;
- Terápiás rendszerek:
- Artis minden típus és verzió;
- Sensis minden típus és verzió;
- Leonardo/X-Workplace minden verzió;
- Arcadis Family minden verzió;
- Ultrahang rendszerek:
- ACUSON SC2000™ ultrahang rendszer: 4.x és 5.x verziók;
- syngo® SC2000™ Workplace: 4.x és 5.x verziók;
- ACUSON X700™ ultrahang rendszer: 2.0-nál korábbi verziók;
- ACUSON P500™ ultrahang rendszer minden verzió;
- ACUSON P300™ ultrahang rendszer minden verzió;

A felsorolt termékek EternalBlue sérülékenység általi érintettségéről további információkat az alábbi, Siemens ProductCERT publikációkból lehet megtudni:

http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-354910.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-832636.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-161640.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-286693.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-492736.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-966341.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-774661.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-740012.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-709509.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-023589.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-701903.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_bulletin_ssb-412479.pdf

Ezzel párhuzamosan az ICS-CERT újabb, ICS/egészségügyi gyártók által kiadott publikációkat adott közre az EternalBlue sérülékenység által érintett különböző ipari rendszerekről:

- GE;
- Philips;
- Smith Medical;
- Johnson & Johnson;
- Medtronic;
- Tridium;
- Emerson Automation Solutions;
- Honeywell;


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

ICS sérülékenységek CXIII

Sérülékenységek Schneider Electric, Hanwha Techwin és Detcon rendszerekben, EternalBlue sérülékenység ipari rendszerekben

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

Zhou Yu, független biztonsági kutató két sérülékenységet talált a Schneider Electric SoMachine nevű, PLC programozásra használható szoftverének 2.1.0 és korábbi verzióiban. Az első hiba egy puffer túlcsordulás, a második pedig DLL hijack támadást tesz lehetővé.

A gyártó a sérülékenységek által érintett ügyfeleinek azt tanácsolja, hogy frissítsenek a SoMachine HVAC Programming Software 2.2-es verziójára.

A sérülékenységekről további részleteket a Schneider Electric és az ICS-CERT bejelentéseiből lehet megtudni.

Schneider Electric VAMPSET sérülékenység

Kushal Arvind Shah, a Fortinet-nél működő Fortiguard Labs munkatársa egy memóriakorrupciós hibát fedezett fel a VAMPSET 2.2.189-nél korábbi verzióiban.

A gyártó a hibát a 2.2.191-es verzióban javította.

A hibával kapcsolatban további információkat a gyártó és az ICS-CERT által kiadott tájékoztatókból lehet szerezni.

Hanwha Techwin SRN-4000 sérülékenység

Can Demirel és Faruk Unal, a Biznet Bilisim munkatársai egy authentikáció nélküli, adminisztrátori szintű hozzáférést biztosító hibát találtak a Hanwha Techwin SRN-4000 típusú eszközeinek SRN4000_v2.16_170401-nél korábbi verzióiban.

A gyártó a hibát a RN4000_v2.16_170401-es és újabb verziókban már javította.

A sérülékenységről további részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-136-03

Detcon SiteWatch Gateway sérülékenység

Maxim Rupp független biztonsági kutató két sérülékenységet (nem megfelelő authentikáció, olvasható formában tárolt jelszavak) fedezett fel a Detcon SiteWatch Gateway nevű termékeiben. A sérülékenységek a SiteWatch Gateway minden verzióját érintik, a gyártó közlése szerint a mobil kommunikációs termékeket azonban nem.

A gyártó már nem forgalmazza az érintett SiteWatch Gateway termékeket és támogatást sem nyújt hozzájuk.

A sérülékenységekről bővebb információkat az ICS-CERT bejelentéséből lehet megtudni: https://ics-cert.us-cert.gov/advisories/ICSA-17-136-01

EternalBlue sérülékenység ipari rendszerekben

A WannaCry ransomware-támadásokat lehetővé tevő, EternalBlue-nak nevezett SMB-sérülékenységgel kapcsolatban jelentetett meg egy figyelmeztetést, amiben az alábbi, ipari rendszereket gyártó cégek bejelentéseit gyűjtötték össze az EternalBlue sérülékenységgel kapcsolatban:

- Rockwell Automation;
- Becton, Dickinson and Company;
- Schneider Electric;
- ABB;
- Siemens.

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

Az ICS Cyber Security Kill Chain I

Miben különbözik az ICS rendszerek elleni támadás, az IT rendszereknél megszokottól?

Az ICS rendszerek elleni kibertámadások nagyon sok jellemzőjükben különböznek az IT rendszerek elleni támadásoktól, ez még akkor is igaz, ha az utóbbi időben nyilvánosságra került jelentősebb ICS biztonsági incidenseknek komoly IT biztonsági része is volt.

Ahhoz, hogy mélyrehatóbban tudjunk foglalkozni az ICS Cyber Security Kill Chain-nel, először kicsit át kell tekinteni, hogy mi is az ennek a keretrendszernek az alapját adó Cyber Security Kill Chain, ezt fogjuk egy kicsit részletesebben áttekinteni a mai és a jövő heti posztban.

Mi az a Cyber Security Kill Chain?

A CSKC-t a Lockheed Martin munkatársai dolgozták ki 2011-ben és munkájuk során (ahogy a kiberbiztonság során már oly sokan előttük) ők is az angolszász katonai terminológiához nyúltak vissza. A Kill Chain kifejezés a katonai zsargonban az ellenséggel való harcérintkezés fázisait foglalja össze.

Ennek mintájára alkották meg a Lockheed-Martin munkatársai a CSKC-t, ami az APT-nek is nevezett kibertámadások jellemző felépítését ismerteti, mind a támadók, mind a védekezésben résztvevő kiberbiztonsági szakemberek feladatait ismertetve az egyes fázisokban. A CSKC 7 fázisra bontja a kifinomult kibertámadásokat, ezek az alábbiak (már az egyes fázisok neve is egészen jól visszautal arra, hogy ez a keretrendszer a katonai terminológiából építkezik):

1. Felderítés (Reconnaissance): A célpont(ok) beazonosítása.

A támadók tevékenységei: Ebben a fázisban a támadók a műveleteik megtervezését végzik, információt gyűjtenek, hogy megértsék a megtámadni tervezett rendszer működését, esetleges hibák után kutatnak, amiknek a kihasználásával elérhetik a céljaikat. Ehhez e-mail címeket gyűjtenek,  a megtámadni tervezett szervezet munkatársait próbálják beazonosítani a közösségi oldalakon, átvizsgálják a sajtóban megjelent híreket, konferencia-résztvevők listáit és felmérik a szervezet Interneten elérhető szervereinek körét.

A védők tevékenységei: A támadók felderítéssel kapcsolatos tevékenységeit normális esetben nehéz lehet észlelni, de ha sikerül, az így szerzett információk nagy segítséget jelenthetnek a támadók céljainak azonosításában. Ilyen információkat lehet találni az Interneten elérhető szerverek logjaiban, a látogatásokról készült webes analitikákból (böngésző statisztikák, látogatási idők, stb.).

2. “Fegyverkezés” (Weponization): Felkészülés a műveletre.

A támadók tevékenységei: A támadók ebben a fázisban a korábban gyűjtött és elemzett adatokra építve elkezdik a felkészülést magára a támadásra. Ehhez általában publikusan vagy csak zárt körben elérhető, esetleg házon belül, egyedileg fejlesztett eszközöket (exploit kit-eket, egyedi exploit-okat) használnak. A fájl-alapú exploit-okhoz elkészítik a megfelelő csali-dokumentumokat és előkészítik a kompromittált eszközökre szánt hátsó ajtókat biztosító szoftvereket, valamint a C2 (command&control) infrastruktúrákat majd lefordítják a megalkotott programkódokat.

A védők tevékenységei: A CSKC-nek ez az a fázisa, ami alapvető fontosságú a védők számára, hogy megértsék. Annak ellenére, hogy nem képesek észlelni a támadók tevékenységét ebben a fázisban, mégis a széleskörű malware-elemzés (nem csak azt vizsgálva, hogy milyen kártékony kódot használ az adott malware, hanem a teljes működési modelljét), segíthet átlátni a támadók módszereit és segíthet olyan eszközöket és technikákat kifejleszteni, amik javítják az adott szervezet észlelési képességeit. Fontos részlet lehet, hogy egy adott malware mikor készült. Egy régebben készült malware újra és újra megjelenhet az adott szervezetnél (hiszen a támadók gyakran nem képesek vagy nem akarnak jelentős erőforrásokat fordítani egy új malware létrehozására, csak újrahasznosítanak egy régebbit), azonban egy új, korábban nem ismert malware megjelenése valószínűleg aktív, célzott támadásra utalhat. A védőknek ehhez a fázishoz érdemes fájlokat és meta-adatokat gyűjteni, ami segítségükre lehet a később elemzések során. Érdemes figyelemmel követni, hogy a támadók milyen eszközöket (exploit kit-ek, újrahasznosított egyedi fejlesztési malware-ek, stb.) milyen támadásoknál használtak, azok széles körben használtak vagy csak néhány, jól meghatározható esetben?

3. A támadás megindítása (Delivery): A malware célba juttatása

A támadók tevékenységei: Ebben a fázisban a támadók szinte kizárólag két módszerrel szoktak élni, az első az aktív támadás, amikor az Interneten elérhető szervereket veszik célba és azok sérülékenységeit kihasználva szereznek hozzáférést. A másik módszernél a különböző csali eszközöket (e-maileket vagy fizikai adathordozókat juttatnak a célponthoz vírusos fájlokkal, különböző közösségi oldalakon végrehajtott műveleteket vagy fertőző weboldalak, gyakran legitim weboldalakon elhelyezett exploitokat használva).

A védők tevékenységei: A védekezésben résztvevőknek ebben a fázisban van először igazi esélyük arra, hogy megakadályozzák a támadókat abban, hogy elérjék a céljaikat. Ehhez célszerű elemezniük a malware-ek célba juttatását és későbbi irányítását szolgáló infrastruktúrát. A védőknek meg kell érteniük a célba vett szerverek működését, a velük kapcsolatba kerülő emberek feladatait, szerepüket és felelősségeiket, valamint az ezekkel kapcsolatban elérhető információkat. Fontos pont, hogy a védők megértsék, a támadók mi alapján választották ki a célpontjukat. A legtöbb esetben a védők számára is elérhetőek a támadók által használt eszközök (vagy legalábbis ezek egy része), ezeket tanulmányozva a támadás korai fázisában nagyobb esély nyílhat a megállítására. Szintén vizsgálni kell, hogy melyik napszakban indult egy támadás, ha a támadók láthatóan munkaidőn kívül tevékenykednek, akkor jó okkal lehet feltételezni (bár korántsem 100%-os biztonsággal), hogy egy célzott támadással van dolgunk. Ebben a fázisban az is nagyon fontos, hogy az összes releváns logot összegyűjtsék, mert még ha nem is sikerül megakadályozni a támadást, később sokat segíthet, ha be lehet azonosítani, mikor és hogyan kezdődött a támadás.

A jövő heti blogposztban befejezzük a Cyber Security Kill Chain áttekintését, utána pedig belekezdünk az ICS Cyber Security Kill Chain részletekbe menő bemutatásába.

ICS sérülékenységek CXII

Sérülékenységek Phoenix Contact és Satel Iberia rendszerekben

Phoenix Contact GmbH mGuard sérülékenységek

Az ICS-CERT bejelentése szerint a Phoenix Contact GmbH mGuard hálózati eszközökben több sérülékenységet is talált gyártó:

- mGuard firmware-ek 8.3.0-tól 8.4.2-es verziókig terjedően.

A gyártó a 8.5.0 firmware-verzióban javította a hibákat, amik között egy DoS-támadást lehetővé tevő hiba és egy nem megfelelő authentikáció található.

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

Satel Iberia SenNet Data Logger és elektromos mérőórák sérülékenysége

Karn Ganeshan biztonsági kutató egy olyan hibát fedezett fel a Satel Iberia SenNet Data Logger nevű termékében és elektromos mérőóráiban, amit kihasználva egy támadó teljes hozzáférést szerezhet a sérülékeny rendszerekhez:

- SenNet Optimal DataLogger V5.37c-1.43c és korábbi verziói;
- SenNet Solar Datalogger V5.03-1.56a és korábbi verziói;
- SenNet Multitask Meter V5.21a-1.18b és korábbi verziói.

A gyártó a sérülékeny verziókat használó ügyfeleinek azt tanácsolja, hogy lépjenek kapcsolatba a terméktámogatási csoporttal és igényeljék a fenti rendszerekhez a legújabb szoftver-verziót.

A sérülékenységről további részleteket az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-131-02

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

ICS biztonság a WannaCry ransomware-támadások tükrében

Az elmúlt nagyjából 48 órában a szakmai és igen jelentős részben a mainstream sajtó is a WannaCry néven elhíresült ransomware-féreg támadásaitól volt hangos. Bár mindezidáig nem érkezett olyan hír, hogy ipari környezeteket vagy rendszereket is elértek volna a támadások, de kritikus infrastruktúrák (kórházak, telekommunikációs szolgáltató cégek, stb.) szerte a világon és részben Magyarországon is érintettek (amiről eddig tudni lehet, az a Telenor és a T-csoport egyes vállalatainak érintettségéről szólnak).

Arról, hogy mi is a WannaCry vagy WannaCrypt0r 2.0, csak röviden írok, ahogy a poszt végén található linkekből látszik, a szaksajtó és a különböző IT biztonsági cégek két napja nagyjából másról sem írnak. A támadások alapjául a Shadow Brokers nevű hackercsoport által az NSA-től ellopott, majd publikált sérülékenységek egyike, a Windows rendszereket érintő MS17-010-es biztonsági frissítésben részletezett, számos (már elavult vagy aktív támogatással rendelkező) Windows verziót érintő, SMBv1-et érintő hiba szolgált (egyes források szerint SMBv2 is érintett, de a Microsoft hibával kapcsolatos publikációja csak a v1-et említi). Egy forrásom szerint egyébként a hibát az MS17-008-as biztonsági és az MS17-006 havi összesített frissítések tartalmazzák. A támadások pénteken délután váltak egyre komolyabbá, 18:00 körül már 74 országból érkeztek hírek egyre komolyabb károkról, többek között a brit egészségügyi szolgálat (NHS) rendszereit is használhatatlanná tette.

A támadás olyan méreteket öltött, hogy a Microsoft, soron kívül és saját szabályait félretéve javítást adott ki a már nem támogatott operációs rendszereihez (Windows XP, Windows Server 2003 család, Vista, 8) is. Most (vasárnap este) úgy tűnik, hogy viszonylagos nyugalom van (miután egy brit biztonsági kutató mondhatni véletlenül elérte, hogy a WannaCry leálljon, miután regisztrálrta azt a domaint, amit aktívnak látva a WannaCry felfüggesztette a működését), de szakértők szerint a következő nagyobb támadási hullám a hétfő reggeli munkakezdéshez kapcsolódhat, amikor ismét tömegesen jelenhetnek meg a hálózatokon még nem frissített számítógépek, illetve a támadók (bárki is álljon e mögött a ransomware-kampány mögött) bármikor módosíthatják a kódjukat, hogy az eddigi védelmi intézkedések hatástalanok legyenek (kivéve persze az SMBv1 hiba javítását).

Hogy hogyan hat ez a támadás az ICS rendszerekre? Ezt egyelőre nehéz megmondani, de az alábbi, ICS biztonsági körökben rendszeresen hangoztatott problémák tökéletes terepet kínálnak egy ilyen szinten virulens féregnek:

1. Internetre csatlakoztatott ICS rendszerek: Bár hosszú évek óta nagyon sok ICS kiberbiztonsággal foglalkozó kutató hangoztatja, hogy az ipari rendszerek közvetlen Internet kapcsolatait minél előbb meg kell szüntetni (az már világos, hogy az ipari hálózatok teljes, fizikai szeparálása a legtöbb szervezetnél üzleti és/vagy technológiai okok miatt nem megoldható), tíz és százezrével találhatóak az Interneten ipari rendszerek.

2. Napjainkban az ipari rendszerek egyik legelterjedtebb operációs rendszere a Microsoft Windows, ennek a családnak is jellemzően a régebbi verziói (főként Windows XP és 2003 verziók, de a termelésirányításban sok helyen akár még Windows NT 4.0-val is találkozhatnak a bennfentesek), ami bizony azt jelenti, hogy ezeknél a rendszereknél az üzemeltetőknek szombatig esélyük sem volt telepíteni a hibajavítást.

3. Az, hogy már minden Windows 2000-nél újabb Windows verzióhoz van elérhető hibajavítás a célba vett SMBv1 sérülékenységhez, nem jelenti azt, hogy napokon (vagy akár heteken) belül védettek lehetnek az érintett ipari rendszerek. Pont az ICS rendszerek sajátos patch-menedzsment eljárása (illetve sok esetben a patch-menedzsment eljárás teljes hiánya) miatt akár hónapokra is szükség lehet, amíg egy-egy rendszerre felkerül a most kiadott frissítés.

Ha a fenti problémák nem lennének önmagukban is elég súlyosak és együtt egyenesen a tökéletes forgatókönyv egy ICS biztonsági incidenshez, az elmúlt évek tendenciája, hogy a különböző nemzetállamok  kormányai (és nem csak globális nagyhatalmak, hanem regionális hatalmak, sőt, akár kisebb országok is) ipari méretekben kezdték felhalmozni a különböző elterjedt operációs rendszerek sérülékenységeit és készítettek ezeket a sérülékenységeket kihasználó exploit-okat, amik most már lassan menetrendszerűen kerülnek nyilvánosságra, hogy utána a legkülönbözőbb hacker-csoportok használják fel ezeket a saját céljaikra, kifejezetten aggasztó kéne hogy legyen az ICS biztonságért és a kritikus infrastruktúrákért felelős vezetők számára.

Egyelőre nem látható, hogy a WannaCry-támadásoknak hol lehet a vége és milyen hatással lehet az egyes országok (kritikus) infrastruktúráira, de úgy gondolom, hogy az ICS biztonság helyzete minden ilyen, IT biztonsági incidenssel csak tovább romlik, a megoldás pedig messzebb van tőlünk, mint korábban bármikor.

Néhány alaposabb sajtócikk a WannaCry-ról:

Kaspersky Blog
TrendMicro Blog

Sérülékeny ipari robotok

Tanulmány az ipari robotizálás biztonságáról

A TrendMicro-n belül működő TrendLabs és a Politecnico Milano közös kutatásáról készült tanulmány alig több, mint egy hete látott napvilágot. Manapság már egyáltalán nem számít rendkívülinek, ha újabb cikkek, tanulmányok és blogposztok jelennek meg a különböző ipari folyamatvezérlő rendszerek és eszközök kiberbiztonságáról, a most megjelent tanulmány abban mindenképp az elsők közé tartozik, hogy az iparban, különösen a gyártástechnológiában használt robotok kiberbiztonsági helyzetéről nyújt egy alaposabb áttekintést.

A kutatók munkájuk során olyan, mindenki számára szabadon elérhető eszközöket használtak, mint pl. a Shodan, a ZoomEye vagy a Censys keresőmotorok.

Ezekkel az eszközökkel tucatnyi, kifejezetten ipari környezetbe szánt router-eket gyártó cég több, mint 80.000 router-ét térképezték fel az Interneten. Nem lehet eléggé hangsúlyozni, hogy mennyire fontos, hogy legalább az ipari rendszerek közvetlen Internet-kapcsolatait szüntessük meg - azzal kapcsolatban már régen senkinek nincsenek illúziói, hogy az ipari rendszereket és a vállalati/irodai/ügyviteli hálózatok összekötését meg lehet-e előzni vagy ha már összekapcsolták őket, meg lehet-e szüntetni ezeket a kapcsolatokat, de az ipari rendszerek/berendezések közvetlen Internetre történő csatlakoztatása több nagyságrenddel növeli az érintett szervezetek kockázatait.

Tovább árnyalja a gyártástechnológiai rendszerek kiberbiztonsági helyzetének sötét képét az a szám, hogy a kutatók által feltérképezett több, mint 80.000 ipari router közül több, mint 5.000-nél még a legalapvetőbb bejelentkezésre sincs szükség ahhoz, hogy bárki hozzáférést szerezhessen ezeken az eszközökön. Tudva, hogy az ipari rendszerek esetén még ma is mennyire kevéssé elterjedt a hibajavítások rendszeres telepítése, még egy nem privilegizált hozzáférés is nagyon komoly biztonsági kockázatokat jelent.

A kutatás során nem csak ipari router-eket, hanem 5 különböző gyártó 28 ipari robotját is elérték az Interneten keresztül. A legtöbb robothoz az azok vezérlő szoftverébe épített FTP-szerveren keresztül sikerült hozzáférést szerezni.

A kutatóknak az általuk vizsgált ipari robotokban feltárt, ismert vagy 0. napi sérülékenységek labor-körülmények között történő kihasználásával számos támadási forgatókönyvet sikerült vázolni, többek között a gyártott termékek szabotálásától (gondoljuk csak el az autó vagy repülőgép-gyártósorokon működő robotok kompromittálásával okozható károk méretét - vegyünk csak egy, az autógyártástól annyira függő országot, mint Magyarország és képzeljük el, mi történne a magyar GDP-vel, ha a legnagyobb hazai autógyárak robotizált gyártósorait egyszerre kéne napokra vagy akár hetekre leállítani egy kiterjedt és összehangolt kibertámadás nyomán...) a robotokban történő károkozáson és az ipari kémkedésen át egészen az emberi sérüléssel vagy halállal járó incidensig.

Ahogy az ipari dolgok Internete (IIoT) és a negyedik ipari forradalom (Industry 4.0) egyre inkább a mindennapok részévé válnak az ICS világban, mindenkinek, a döntéshozóktól az OT-ban dolgozó mérnökökön át az ICS biztonsági szakemberekig tudomásul kell venniük, hogy csak közösen, az egyes szakterületek tudását és tapasztalatait ötvözve leszünk képesek megfelelni az ipari rendszerek egyre nagyobb kiberbiztonsági kihívásainak. A gyártástechnológiai ICS rendszerek esetén sem kell ismét feltalálni a kereket, a SCADA rendszereknél már több, mint fél évtizede fejlesztett biztonsági eljárások és eszközök a megfelelő tervezéssel, teszteléssel és körültekintéssel alkalmazva a gyártósorokon alkalmazott automatizálási rendszerek esetén is hatékonyan használhatóak - feltéve, hogy az OT és az ICS biztonsági területek képesek a megfelelő szintű együttműködésre.

ICS sérülékenységek CXI

Sérülékenységek Siemens, Rockwell Automation és Cisco rendszerekben

Az elmúlt napokban furcsa kettősség volt a friss ICS sérülékenységekről szóló bejelentésekben, a Siemens számos termékében javított a bevitt adatok nem megfelelő ellenőrzéssel kapcsolatos hibákat, a Rockwell Automation pedig egy termékcsaládjában javított nem kevesebb, mint 41 különböző sérülékenységet és gyenge pontot.

Siemens SIMATIC WinCC és STEP 7 (TIA Portal) sérülékenység

Duan JinTong, Ma ShaoShuai és Cheng Lei, az NSFOCUS Security Team tagjai jelezték a Siemensnek, hogy az alábbi SIMATIC WinCC és STEP 7 (TIA Portal) termékeiben egy, a PROFINET Discovery and Configuration Protocol-lal (DCP-vel) kapcsolatos hibát fedeztek fel:

- SIMATIC WinCC (TIA Portal)
  - V13: minden, V13 SP2-nél korábbi verzió;
  - V14: minden, V14 SP1-nél korábbi verzió;
- SIMATIC STEP 7 (TIA Portal)
  - V13: minden, V13 SP2-nél korábbi verzió;
  - V14: minden, V14 SP1-nél korábbi verzió;
- SIMATIC STEP 7 V5.X: minden verzió;
- STEP 7 - Micro/WIN SMART: minden verzió;
- SMART PC Access V2.0,
- SIMATIC Automation Tool: minden verzió;
- SIMATIC WinCC: minden verzió;
- SIMATIC PCS 7: minden verzió;
- SIMATIC NET PC-Software: minden verzió;
- Primary Setup Tool (PST): minden verzió;
- Security Configuration Tool (SCT): minden verzió;
- SINEMA Server: minden verzió;
- SINAUT ST7CC: minden verzió;
- SIMATIC WinAC RTX 2010 SP2: minden verzió;
- SIMATIC WinAC RTX F 2010 SP2: minden verzió;
- SINUMERIK 808D Programming Tool: minden verzió;
- SIMATIC WinCC flexible 2008: minden verzió.

Egy támadó a PROFINET DCP hibát kihasználva szolgáltatás-megtagadásos (DoS) támadást indíthat a sérülékeny rendszerek ellen, amit csak az érintett eszközök manuális újraindításával lehet elhárítani. A Siemens a hibát az alábbi verziókban javította:

- SIMATIC WinCC (TIA Portal) V13 SP2;
- SIMATIC WinCC (TIA Portal) V14 SP1;
- SIMATIC STEP 7 (TIA Portal) V13 SP2;
- SIMATIC STEP 7 (TIA Portal) V14 SP1.

A sérülékenységről további információkat a Siemens ProductCERT és az ICS-CERT publikációiban lehet találni.

A DCP hiba hasonló módon érint számos Siemens terméket:

- SIMATIC CP 343-1 Std, CP 343-1 Lean: minden verzió;
- SIMATIC CP 343-1 Adv: minden verzió;
- SIMATIC CP 443-1 Std, CP 443-1 Adv: V3.2.17-nél korábbi verziók;
- SIMATIC CP 443-1 OPC-UA: minden verzió;
- SIMATIC CP 1243-1: minden verzió;
- SIMATIC CM 1542-1: V2.0-nál korábbi verziók
- SIMATIC CP 1543SP-1, CP 1542SP-1 és CP 1542SP-1 IRC: minden verzió;
- SIMATIC CP 1543-1: V2.1-nél korábbi verziók;
- SIMATIC RF650R, RF680R, RF685R: V3.0-nál korábbi verziók;
- SIMATIC CP 1616, CP 1604, DK-16xx PN IO: V2.7-nél korábbi verziók;
- SCALANCE X200: minden verzió;
- SCALANCE X200 IRT: minden verzió;
- SCALANCE X300, X408, X414: minden verzió;
- SCALANCE XM400, XR500: minden verzió;
- SCALANCE W700: V6.1-nél korábbi verziók;
- SCALANCE M-800,S615:minden verzió;
- Softnet PROFINET IO for PC-based Windows systems: minden verzió;
- IE/PB-Link: V3.0-nál korábbi verziók;
- IE/AS-i Link PN IO: minden verzió;
- SIMATIC Teleservice Adapter Standard Modem, IE Basic, IE Advanced: minden verzió;
- SITOP PSU8600 / UPS1600 PROFINET: minden verzió;
- SIMATIC ET 200 PROFINET IO-hoz való interfész modulok:
  - SIMATIC ET 200AL: minden verzió;
  - SIMATIC ET 200ecoPN: minden verzió;
  - SIMATIC ET 200M: minden verzió;
  - SIMATIC ET 200MP: V4.0.1-nél korábbi verziók;
  - SIMATIC ET 200pro: minden verzió;
  - SIMATIC ET 200S: minden verzió;
  - SIMATIC ET 200SP: minden verzió;
  - PN/PN Coupler: minden verzió;
- PROFINET IO fejlesztői és teszt készletek:
  - DK Standard Ethernet Controller: V4.1.1 Patch04-nél korábbi verziók;
  - EK-ERTEC 200P PN IO: V4.4.0 Patch01-nél korábbi verziók;
  - EK-ERTEC 200 PN IO: V4.2.1 Patch03-nál korábbi verziók;
- SIMATIC S7-200 SMART: minden verzió;
- SIMATIC S7-300, F és T sorozat is: V3.X.14-nél korábbi verziók;
- SIMATIC S7-400, F és H sorozat: minden verzió;
- SIMATIC S7-1200, F sorozat: V4.2.1-nél korábbi verziók;
- SIMATIC S7-1500m F, T és TF sorozat: V2.1-nél korábbi verziók;
- SIMATIC S7-1500 szoftveres kontroller, F sorozat: V2.1-nél korábbi verziók;
- SIMATIC WinAC RTX 2010, F sorozat: minden verzió;
- SIRIUS ACT 3SU1 PROFINET interfész modul: minden verzió;
- SIRIUS Soft starter 3RW44 PN: minden verzió;
- SIRIUS Motor starter M200D PROFINET: minden verzió;
- SIMOCODE pro V PROFINET: minden verzió;
- SINAMICS:
  - SINAMICS DCM: minden verzió;
  - SINAMICS DCP: minden verzió;
  - SINAMICS G110M / G120(C/P/D) w. PN: V4.7 SP6 HF3-nél korábbi verziók;
  - SINAMICS G130 és G150: V4.8 HF4-nél korábbi verziók;
  - SINAMICS S110 w. PN: minden verzió;
  - SINAMICS S120: V4.8 HF4-nél korábbi verziók;
  - SINAMICS S150: V4.8 HF4-nél korábbi verziók;
  - SINAMICS V90 w. PN: minden verzió;
- SIMOTION: V4.5 HF1-nél korábbi verziók;
- SINUMERIK 828D:
  - V4.5-nél korábbi verziók;
  - V4.7: V4.7 SP4 HF1-nél korábbi verziók;
- SINUMERIK 840D sl:
  - Minden, V4.5 SP6 HF8-nál korábbi verzió;
  - V4.7: V4.7 SP4 HF1-nél korábbi verziók;
- SIMATIC HMI Comfort Panels, HMI Multi Panels, HMI Mobile Panels: minden verzió.

A hibát a gyártó ezekben a termékekben is javította, az alábbi verziókban:

- SIMATIC CP 443-1 Std: V3.2.17;
- SIMATIC CP 443-1 Adv: V3.2.17;
- SIMATIC CM1542-1: V2.0;
- SIMATIC CP 1543-1: V2.1;
- SIMATIC RF650R, RF680R, RF685R: V3.0;
- SIMATIC CP 1616, CP 1604, DK-16xx PN IO: V2.7;
- SCALANCE W700: V6.1.0;
- IE/PB-Link: V3.0;
- PROFINET IO fejlesztői és teszt készletek:
  - DK Standard Ethernet Controller: V4.1.1 Patch04-nél korábbi verziók;
  - EK-ERTEC 200P PN IO:V4.4.0 Patch01-nél korábbi verziók;
  - EK-ERTEC 200 PN IO: V4.2.1 Patch03-nál korábbi verziók;
- SIMATIC S7-300, F és  T sorozat: V3.X.14;
- SIMATIC S7-1200, F sorozat:V4.2;
- SIMATIC S7-1500, F, T és TF sorozat: V2.1;
- SIMATIC S7-1500 szoftveres kontroller, F sorozat: V2.1;
- SINAMICS:
  - SINAMICS G110M/G120(C/P/D) w. PN: V4.7 SP6 HF3;
- SINAMICS G130 és G150: V4.8: V4.8 HF4;
- SINAMICS S120: V4.8: V4.8 HF4;
- SINAMICS S150: V4.8: V4.8 HF4;
- SIMOTION: V4.5 HF1;
- SINUMERIK 828D: V4.7: V4.7 SP4 HF1;
- SINUMERIK 840D sl:
  - V4.5-nél korábbi verzióknál: V4.5 SP6 HF8;
  - V4.7: V4.7 SP4 HF1.

A sérülékenységről ezeknél az eszközöknél is a Siemens ProductCERT és az ICS-CERT bejelentéseiből lehet többet megtudni.

Sérülékenység Siemens SIMATIC WinCC és WinCC Runtime Professional termékekben

Sergey Temnikov és Vladimir Dashchenko, a Kaspersky Lab kritikus infrastruktúra védelmi csapatának tagjai szintén egy, a bevitt adatok nem megfelelő ellenőrzésével kapcsolatos hibát találtak a SIMATIC WinCC és a WinCC Runtime Professional szoftverek alábbi verzióiban:

- SIMATIC WinCC:
  - V7.3: V7.3 Update 11-nél korábbi verziók;
  - V7.4: V7.4 SP1-nél korábbi verziók;
- SIMATIC WinCC Runtime Professional:
  - V13: V13 SP2-nél korábbi verziók;
  - V14: V14 SP1-nél korábbi verziók;
- SIMATIC WinCC (TIA Portal) Professional:
  - V13: V13 SP2-nél korábbi verziók;
  - V14: V14 SP1-nél korábbi verziók.
 
A hibát a sérülékeny rendszerek DCOM interfészére küldött, speciálisan kialkaított üzenetekkel lehet kihasználni. A hiba kihasználáshoz a támadó által használt felhasználói fióknak adminisztrátori jogosultságokkal kell rendelkeznie. Egy sikeres támadás eredményeképp a sérülékeny rendszer összeomolhat, ezzel gyakorlatilag szolgáltatás-megtagadás idézhető elő.

A Siemens a hibát az alábbi verziókban javította:

- SIMATIC WinCC:
  - V7.3: Update to WinCC V7.3 Update 13;
  - V7.4: Update to WinCC V7.4 SP1;
- SIMATIC WinCC Runtime Professional:
  - V13: Update to V13 SP2;
  - V14: Update to V14 SP1;
- SIMATIC WinCC (TIA Portal) Professional:
  - V13: Update to V13 SP2;
  - V14: Update to V14 SP1.

A sérülékenységről bővebben a Siemens ProductCERT és az ICS-CERT publikációiban lehet olvasni.

Rockwell Automation Stratix 5900 sérülékenységek

A Rockwell Automation-nek a Cisco jelezte, hogy a Cisco kódbázisra épülő Stratix 5900-as routerek 15.6.3-nál korábbi firmware-jei számos (számszerűen 41 különböző) hibát tartalmaznak. A sérülékenységek között több, a bevitt adatok nem megfelelő ellenőrzéssel kapcsolatos hiba, erőforrás-kezelési hibák, nem megfelelő authentikációból adódó hibák és könyvtár-bejárást lehetővé tevő hibák vannak.

A gyártó a hibákat a Stratix 5900-asok 15.6.3-as firmware-jében javította.

A sérülékenységekről számos részletet tartalmaz az ICS-CERT publikációja: https://ics-cert.us-cert.gov/advisories/ICSA-17-094-04

Sérülékenység Cisco ipari környezetekbe szánt hálózati eszközökben

A Cisco bejelentése szerint az alábbi, ipari környezetekbe szánt hálózati eszközeiben találtak olyan, Cluster Management Protocol (CMP) hibát, ami távoli kódfuttatást tesz lehetővé:

- Cisco IE 2000-16PTC-G Industrial Ethernet Switch;
- Cisco IE 2000-16T67 Industrial Ethernet Switch;
- Cisco IE 2000-16T67P Industrial Ethernet Switch;
- Cisco IE 2000-16TC Industrial Ethernet Switch;
- Cisco IE 2000-16TC-G Industrial Ethernet Switch;
- Cisco IE 2000-16TC-G-E Industrial Ethernet Switch;
- Cisco IE 2000-16TC-G-N Industrial Ethernet Switch;
- Cisco IE 2000-16TC-G-X Industrial Ethernet Switch;
- Cisco IE 2000-24T67 Industrial Ethernet Switch;
- Cisco IE 2000-4S-TS-G Industrial Ethernet Switch;
- Cisco IE 2000-4T Industrial Ethernet Switch;
- Cisco IE 2000-4T-G Industrial Ethernet Switch;
- Cisco IE 2000-4TS Industrial Ethernet Switch;
- Cisco IE 2000-4TS-G Industrial Ethernet Switch;
- Cisco IE 2000-8T67 Industrial Ethernet Switch;
- Cisco IE 2000-8T67P Industrial Ethernet Switch;
- Cisco IE 2000-8TC Industrial Ethernet Switch;
- Cisco IE 2000-8TC-G Industrial Ethernet Switch;
- Cisco IE 2000-8TC-G-E Industrial Ethernet Switch;
- Cisco IE 2000-8TC-G-N Industrial Ethernet Switch;
- Cisco IE 3000-4TC Industrial Ethernet Switch;
- Cisco IE 3000-8TC Industrial Ethernet Switch;
- Cisco IE-3010-16S-8PC Industrial Ethernet Switch;
- Cisco IE-3010-24TC Industrial Ethernet Switch;
- Cisco IE-4000-16GT4G-E Industrial Ethernet Switch;
- Cisco IE-4000-16T4G-E Industrial Ethernet Switch;
- Cisco IE-4000-4GC4GP4G-E Industrial Ethernet Switch;
- Cisco IE-4000-4GS8GP4G-E Industrial Ethernet Switch;
- Cisco IE-4000-4S8P4G-E Industrial Ethernet Switch;
- Cisco IE-4000-4T4P4G-E Industrial Ethernet Switch;
- Cisco IE-4000-4TC4G-E Industrial Ethernet Switch;
- Cisco IE-4000-8GS4G-E Industrial Ethernet Switch;
- Cisco IE-4000-8GT4G-E Industrial Ethernet Switch;
- Cisco IE-4000-8GT8GP4G-E Industrial Ethernet Switch;
- Cisco IE-4000-8S4G-E Industrial Ethernet Switch;
- Cisco IE-4000-8T4G-E Industrial Ethernet Switch;
- Cisco IE-4010-16S12P Industrial Ethernet Switch;
- Cisco IE-4010-4S24P Industrial Ethernet Switch;
- Cisco IE-5000-12S12P-10G Industrial Ethernet Switch;
- Cisco IE-5000-16S12P Industrial Ethernet Switch.

A Cisco új firmware verziót adott ki az érintett eszközökhöz, amiben javította a hibát.

A sérülékenységről további részleteket a Cisco bejelentéséből lehet megtudni: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170317-cmp

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

ICS sérülékenységek CX

Hikvision, Dahua Technology Co., Ltd, Advantech és Rockwell Automation rendszerek sérülékenységei

Hikvision kamerák sérülékenységei

A "Montecrypto" nevű IPcamtalk felhasználó két hibát talált a Hikvision alábbi kameráiban és szoftver verzióiban:

- DS-2CD2xx2F-I sorozat, V5.2.0 build 140721-től V5.4.0 build 160530-ig;
- DS-2CD2xx0F-I sorozat, V5.2.0 build 140721-től V5.4.0 Build 160401-ig;
- DS-2CD2xx2FWD sorozat, V5.3.1 build 150410-től V5.4.4 Build 161125-ig;
- DS- 2CD4x2xFWD sorozat, V5.2.0 build 140721-től V5.4.0 Build 160414-ig;
- DS-2CD4xx5 sorozat, V5.2.0 build 140721-től V5.4.0 Build 160421-ig;
- DS-2DFx sorozat, V5.2.0 build 140805-től V5.4.5 Build 160928-ig;
- DS-2CD63xx sorozat, V5.0.9 build 140305-től V5.3.5 Build 160106-ig.

A két hiba közül az első az authentikációs eljárásban található, a második pedig abból adódik, hogy egyes konfigurációs fájlokban jelszavak lehetnek.

Az authentikáció hibáját a gyártó egy új firmware-verzióban javította, a konfigurációs állományokban található jelszavak problémájára azonban egyelőre nincs javítás.

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-124-01

Sérülékenység Dahua Technology Co., Ltd digitális videórögzítő rendszerekben és IP kamerákban

Egy Bashis néven ismert kutató talált hibákat a Dahua Technology Co., Ltd egyes DVR és IP kamera rendszerekben. Az alábbi kamerák érintettek:

- DH-IPC-HDBW23A0RN-ZS;
- DH-IPC-HDBW13A0SN;
- DH-IPC-HDW1XXX;
- DH-IPC-HDW2XXX;
- DH-IPC-HDW4XXX;
- DH-IPC-HFW1XXX;
- DH-IPC-HFW2XXX;
- DH-IPC-HFW4XXX;
- DH-SD6CXX;
- DH-NVR1XXX;
- DH-HCVR4XXX és
- DH-HCVR5XXX.

Érintettek továbbá az alábbi digitális videórögzítő rendszerek:

- DHI-HCVR51A04HE-S3;
- DHI-HCVR51A08HE-S3 és
- DHI-HCVR58A32S-S2.

Az első hiba lehetővé teszi egy támadó számára, hogy pass-the-hash támadást hajtson végre a sérülékeny rendszerek ellen, a második pedig (ma már nem először) a jelszavak konfigurációs fájlokban történő megjelenéséből adódik.

A gyártó elkészítette és elérhetővé tette a hibák javítását tartalmazó firmware-verziót és további információkat publikált a sérülékenységekről:

http://us.dahuasecurity.com/en/us/Security-Bulletin_030617.php
http://www.dahuasecurity.com/en/us/single.php?nid=354
http://www.dahuasecurity.com/en/us/single.php?nid=364
http://us.dahuasecurity.com/en/us/Security-Bulletin_04032017.php

A sérülékenységekkel kapcsolatos ICS-CERT publikáció itt érhető el: https://ics-cert.us-cert.gov/advisories/ICSA-17-124-02

Advantech WebAccess sérülékenység

Zhou Yu, a ZDI-vel együttműködő kutató egy könyvtárbejárást lehetővé tevő hibát talált az Advantech WebAccess 8.1-es és korábbi verzióiban.

A gyártó a hibát a 8.2_20170330 verzióban javította, amit a hibát jelentő kutató is tesztelt és megerősítette, hogy a javítás nyomán a sérülékenység megszűnt.

A sérülékenységgel kapcsolatban további információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-124-03

Rockwell Automation ControlLogix és CompactLogix sérülékenység

Az ICS-CERT bejelentése szerint a Rockwell Automation alábbi rendszereiben egy DoS-támadást lehetővé tevő hibát azonosítottak:

- ControlLogix 5580 vezérlők V28.011, V28.012 és V28.013 verziói;
- ControlLogix 5580 vezérlők V29.011 verziója;
- CompactLogix 5380 vezérlők V28.011 verziója és
- CompactLogix 5380 vezérlők V29.011 verziója.

A hibát a gyártó a későbbi verziókban már javította, így minden, érintett verziójú vezérlőt használó ügyfelének azt javasolja, hogy frissítsenek, a ControlLogix 5580-as a CompactLogix 5380-as vezérlők esetén is a V30.011-es verzióra.

A sérülékenységgel kapcsolatban bővebb információkat az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-17-094-05

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

Az ICS kiberbiztonság hiányzó láncszeme

Miért fontos kérdés a terepi/gyártósori ICS eszközök kiberbiztonsága?

A különböző ipari rendszereket a múltban és a jelenben is a megbízhatóságot, a biztonságot (safety) és a különböző szabályozói előírásoknak való megfelelést szem előtt tartva fejlesztik. Ahogy az ipari rendszerek mind több ponton kerültek összekapcsolásra a vállalati IT-val és ezzel párhuzamosan egyre több IT komponens került beépítésre az ipari rendszerekbe, megjelent az ICS kiberbiztonság fogalma, majd rögtön ezután az igény a megvalósítására is - különösen a Stuxnet nyilvánosságra kerülése után vált ez mind népszerűbb témává (e sorok írójára is igen mély benyomást tett a Stuxnet, majd az azt követő években nyilvánosságra kerülő többi ICS rendszerekkel kapcsolatos incidens, ennek egyenes következménye volt a blog elindítása is). Az ICS kiberbiztonság igen sokáig az OT által használt szerverek, HMI-ok, mérnöki munkaállomások biztonsági kérdéseire fókuszált, ezek mellett jóval kisebb figyelmet kaptak a Purdue modell első szintjére sorolt komponensek (szenzorok, szabályozó, elemző és vezérlő eszközök). Ezek gyakran még ma is soros porton kommunikálnak és egy soros-Ethernet átalakítón keresztül csatlakoznak a TCP/IP hálózatokra. A felsorolt eszközöknek még az OT által használt számítógépekénél is rosszabb a biztonsága, pedig a különböző ICS szerverek, HMI-ok, MMI-ok biztonsága is komoly hiányosságokkal küzd.

A Purdue referencia modell kialakításakor markáns elkülönítést fogalmaztak meg az alkotók az egyes szinteken működő eszközök között. Ahogy azonban a modern IT technológiái egyre inkább teret nyernek az ipari eszközökben, így a Purdue modell első szintjén üzemelő eszközökben is mind több IT komponens jelent meg, ami folyamatosan nehezebbé teszi, hogy az első szintet elválasszuk a második, de időnként még a harmadik szinttől is.

Felmerülhet a kérdés, hogy ez miért jelent problémát? A Purdue modell első szintjén működő eszközöket gyakran nevezik mező vagy gyártósori eszközöknek (field/plant floor device). Ezeket az eszközöket szinte minden esetben speciális fizikai igénybevételre (a normál IT eszközökhöz képest extrém meleg vagy hideg, por, vibráció, stb. elviselésére) tervezik, viszont a kiberbiztonsági kihívások megválaszolására kevés vagy éppen semennyi erőforrást sem fordítanak. Éppen emiatt a legtöbb mező/gyártósori eszköz számos alapvető kiberbiztonsági hiányosságot hordoz:

- Nincs vagy csak nagyon alapszintű biztonsági kontrollokkal rendelkeznek (pl. egyetlen, közös felhasználónév-jelszó, gyakori a beégetett jelszavak használata);
- Az általuk használt kommunikációs protokollokról (vezetékes és Wireless HART, Profibus, Fieldbus, stb.) számos alkalommal bizonyították már be, hogy komoly sérülékenységek találhatóak bennük, de az ipari rendszer hosszú életciklusa miatt a protokollok biztonságosabbra cserélése kifejezetten nehéz és lassú;
- Egyre több az IP-alapon kommunikáló eszköz és mind több eszköz képes vezeték nélküli kapcsolatot kiépíteni;
- Nő a száma azoknak az eszközöknek, amik már a Purdue modell több szintjén kommunikálnak., egyre gyakoribbak az olyan mező/gyártósori eszköz, ami közvetlenül küld adatokat a második/harmadik szinten üzemelő rendszerekbe.

A probléma tehát adott, a kérdés, hogy mit is kéne tennünk azért, hogy az ICS rendszereket üzemeletető szervezetek meg tudjanak felelni a kihívásnak és képesek legyenek megelőzni a komolyabb ICS kiberbiztonsági incidenseket. Amennyire én ma látom, erre a legjobb esély az lehet, ha a ma még élesen elkülönülő IT biztonsági és OT szakterületek elkezdenek végre együttműködni és megérteni a másik szakterület munkáját, prioritásait. Mindaddig, amíg az OT szakemberek többsége új keletű úri hóbortként tekint az IT biztonságra, aminek sem keresnivalója, sem hatása nem lehet az ipari rendszerekre, az IT biztonsági szakemberek nagy része pedig csak a 90-es évekből (vagy még korábbról) itt felejtett, múzeális számítógépeket látnak az ipari rendszerekben, nem lesz esélyünk eredményesen védekezni a mind nagyobb fenyegetések ellen.

süti beállítások módosítása