A következő néhány posztban az ismertebb ICS/SCADA-fejlesztő cégeket fogom röviden bemutatni.

Yokogawa

A Yokogawa-t 1915-ben alapították Japánban és 1917-ben gyártótta az első elektromos mérőberendezéseit. A nemzetközi piacon 1957 óta vannak jelen, ekkor alapították az Észak-amerikai vállalatukat. Az 1960-as években kezdtek olyan különböző berendezéseket gyártani, amelyekkel az ipari szektor igényeinek széles spektrumát tudták lefedni. 1974-ben szingapúri és európai cégalapításokkal a világ egyre nagyobb részén rendelkeztek képviselettel, a következő évben pedig megjelent a CENTRUM nevű folyamatirányító rendszerük, amit a világ első DCS rendszereként tartanak számon. 1983-ban, a Hokushin Electric Works, Ltd-vel való egyesülés után a cég neve Yokogawa Hokushin Electric Corp. nevet vette fel.

Advantech

Az Advantech-et 1983-ban alapították, jelenleg a beágyazott rendszerek, ipari automatizálási rendszerek és orvos-egészségügyi rendszerek piacán jelen lévő taivani cégnek további 21 országban vannak kirendeltségei. Hálózati és telekommunikációs termékeket/szolgáltatásokat szintén nyújtanak ügyfeleiknek, termékeik az autóipartól a gyógyszergyártáson keresztül a teherszállító hajók vezérléséig számos területen megtalálhatóak, emellett egyre nagyobb hangsúlyt fektetnek a különböző intelligens rendszrekre, ilyen többek között a vasúti áramellátást percről-percre monitorozó megoldásuk.

Cogent

A Cogent-et 1995 májusában alapították Kanadában és az eltelt 20 évben DataHub néven egész middleware termékcsaládot építettek fel, ameyek interfészként működnek a különböző ICS rendszerek között. Emiatt a cég ügyelei között számos ismert ICS-fejlesztő vállalat jelenik meg, rajtuk kívül pénzügyi, vegyipari, egészségügyi és gyógyszeripari, valamint élelmiszeripari vállalatok is.

Schneider Electric (Modicon)

A Schneider Electric (korábban Modicon néven ismerték a céget, ezt a nevet egyes termékeiknél a mai napig megőrizték) a ICS rendszerek piacán az egyik legismertebb és legnagyobb múltra visszatekintő vállalat, amelynek központja Franciaországban, Párizsban van. Nevükhöz fűződik többek között a Modbus protokol kifejlesztése is. A közel 180 éves múltra visszatekintő cég napjainkban számos iparágnak kínál különböző ICS rendszereket, a teljesség igénye nélkül ezek közé tartoznak a villamosipar berendezések, épület-automatizálási megoldások valamint a különböző szenzorok és RFID-rendszerek.

Moxa

A Moxa tajvani vállalat, amely ipari hálózati, számítástechnikai és automatizálási megoldásokat gyárt és értékesít. Termékeik között egyebek mellett megtalálhatóak ipari Ethernet-eszközök, vezetéknélküli megoldások és média konverterek is, melyeket számos iparágban használnak okosrendszerek kialakítása során (szállítmányozás - smart rail, villamos-energia - smart grid, olaj és gázipar, bányászat, stb.). Termékeik között többek között számos konverter eszköz található, sok egyéb mellett üvegszálas és rezes, valamint soros és Ethernet eszközök közé illeszthető interfészek.

SMA Solar Technology AG

Az SMA Solar Technology AG egy német ICS gyártó, amely a napeneria-termelésben használt ICS-eszközök gyártására specializálódott. Az általuk gyártott eszközök jellemzően az elmúlt egy évtizedben Európában egyre inkább elterjedő, többnyire családi házakra szerelt napelemes (fotovoltalikus) berendezésekhez kapcsolódóan kerülnek üzembe helyezésre, leggyakrabban a 100 kW-tól néhány MW-ig terjedő teljesítményű házi erőműveket vezérelve.

Egyik leányvállalatukon (SMA Railway Technology) keresztül a szállítmányozási szektorban is jelen vannak.

A tegnapi napon a CAREL PlantVisor Enhanced termékével kapcsolatban jelent meg egy bejelentés az ICS-CERT weboldalán. Maxim Rupp, független biztonsági tanácsadó egy authentikáció megkerülését lehetővé tevő sérülékenységet fedezett fel.

A hibát távolról is ki lehet használni és bár jelenleg még nincs információ a hibát kihasználó exploit-ról, de figyelembe véve, hogy egy, ezt a hibát kihasználó exploit elkészítése nem igényel komoly technikai tudást, a sérülékeny szoftvert használók számára a kockázatok nem elhanyagolhatóak. Tovább rontja a helyzetet, hogy a gyártó az érintett PlantVisorEnhanced termékvonalat 2007 óta már nem fejleszti, így hibajavítás sem várható ezekhez. Helyett a CAREL a PlantVisorEnhanced utódjaként megjelent PlantVisorPRO termékre történő frissítést javasolja.

Az ICS-CERT azok számára, akik valamilyen oknál fogva kénytelenek továbbra is a sérülékeny verziót használni, a szokásos tanácsokat adja:

- Minimálisra kell csökkenteni az ipari rendszerek/hálózatok kapcsolatát az Internettl;
- Az ipari rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari 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!

További részleteket az ICS-CERT bejelentése tartalmaz.

Január 18-án a SANS ICS Security blogjában megjelent Chris Sistrunk villamosenergia-átviteli és elosztó rendszerekkel kapcsolatos biztonsági sorozatának második része (az első részről itt írtam).

Ebben a részben Chris áttekinti a lehetséges támadási vektorokat, példákat mutat be a való életből és további olvasnivalóakat javasol az villamosenergia-rendszer alállomásainak témájában.

Az ICS-CERT tegnapi bejelentése szerint Aditya Sood, független biztonsági kutató XSS sérülékenységet talált a Siemens OZW672-es és 772-es típusú eszközeiben. A sérülékenység minden, v6.00 és korábbi verziójú szoftvert futtató eszközt érinti, a hiba kihasználásával egy támadó adatokat és beállításokat változtathat meg a sérülékeny eszközökön.

A Siemens mindkét terméktípushoz elérhetővé tette a hibát javító új firmware verziót. Azoknak a felhasználóknak, akik valamilyen ok miatt nem tudják frissíteni a firmware-t, az ICS-CERT az alábbi kompenzáló kontrollokat javasolja:

- Minimálisra kell csökkenteni az ipari rendszerek/hálózatok kapcsolatát az Internettl;
- Az ipari rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari 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 elmúlt héten számos olyan cikk jelent meg, amelyek egy-egy, jellemzően a nemzeti kritikus infrastruktúrák közé sorolt iparág kiberbiztonsági helyzetét vizsgálja. A mai posztban ezekből a cikkekből fogok szemlézni.

Atomenergia-szektor

Több helyen jelent meg cikk azzal a Nuclear Threat Initiative (NTI) által 2013-ban készített és ez év elején aktualizált tanulmánnyal kapcsolatban, ami 47 országban üzemelő atomerőművek kiberbiztonsági állapotát mérte fel.

A felmérés szerint a nukleáris létesítmények informatikai hálózataiban történt kiberbiztonsági incidensek száma az átlagos (kormányzati szervezeteknél regisztrált incidensek) 9,7%-os emelkedésével szemben 18% növekedést mutatott. A vizsgált 47 országból 24 olyan volt, amelyekben akár atomfegyverekhez használható hasadóanyagot is elő lehet állítani, a másik 23 ország atomerőművei pedig csak békés célú felhasználásra alkalmas létesítmények.

A 2013-as vizsgált 47 országból mindössze 13 ország (köztük Magyarország is, ezúton szeretnék gratulálni a paski és csillebérci reaktorok környékén dolgozó biztonsági szakembereknek) ért el tökéletes eredményt, azonban 20 ország eredménye lett nulla pontos (köztük számomra meglepő módon Belgium, Olaszország, Szlovákia és Spanyolország is!). Ezek közül az országok közül az elmúlt két évben 8 jelentős javulást ért el a kiberbiztonság területén.

Villamosenergia-ipar

Szintén több, IT biztonsággal foglalkozó híroldal hozta le az ICS-CERT-nél dolgozó Marty Edwards S4 konferencián tartott előadásának összefoglalóját, amiben arról beszélt, hogy a kritikus infrastruktúráknál dolgozó informatikusok és vezetők nagyon gyakran kapcsolják össze az ICS hálózatokat a vállalati hálózatokkal, időnként az Internettel is, mert úgy gondolják, hogy ezzel üzleti/technológiai előnyökre tehetnek szert, azonban az ezzel járó kockázatokkal már nem foglalkoznak.

Kőolaj- és földgáz-szektor

Ugyancsak múlt heti a hír, hogy a Tripwire felmérése szerint jelentősen (82% felett) nőtt az olaj és gázipari cégek hálózataiban történt kiberbiztonsági incidensek száma. Ami igazán aggasztó a felmérésben, hogy a válaszadók 69%-a szerint a vállalatok nincsenek megfelelően felkészülve egy esetleges kibertámadás észlelésére (arra nem tér ki a felmérés, hogy akik észlelni tudják, azoknál vajon megvan-e a képesség az észlelt támadások elhárítására).

Egy másik érdekesség a felmérésben, hogy a válaszadók szerint az ICS hálózatok és a vállalati, Internet-kapcsolattal rendelkező hálózatok az esetek többségében nincsenek összekapcsolva egymással, így egy támadás során annak a kockázata, hogy a támadók képesek eljutni az ICS rendszerekig, meglehetősen kicsi (ez mondjuk az elmúlt évek során a legkülönbözőbb ICS biztonsági körökben általam hallottaknak ellentmond, én sokkal gyakrabban hallottam mostanáig azt, hogy különböző okok miatt, pl. jogszabályi, üzleti, technológiai okok miatt, bár nem akarták, mégis össze kellett kapcsolniuk az ICS és vállalati hálózatokat).

Most mondhatja bárki azt, hogy ezekben a cikkekben nincs semmi újdonság (vagy legalábbis nem sok) azok számára, akik figyelemmel követik az ICS biztonság témáját, de annyit biztos, hogy amint egyre többet fogunk tudni a Nyugat-ukrajnai áramkimaradás hátteréről, a különböző ICS rendszereket üzemeltető vállalatoknak újra kell értékelniük az ezekkel a rendszerekkel kapcsolatos kockázataikat. Ezt persze már a Stuxnet nyilvánosságra kerülése után is meg kellett volna tenni, de a kritikus infrastruktúrákat üzemeltetők, legyünk őszinték, nagyon kevés kivételtől eltekintve) elpazarolták az elmúlt 5 évet.

2016.01.14-én az ICS-CERT számos, az Advantech WebAccess 8.0 és azt megelőző verzióit érintő sérülékenységet hozott nyilvánosságra. Az Advantech érintett termékcsaládja egy webes ICS/SCADA rendszer HMI modullal.  A sérülékenységek meglehetősen széles skálán mozognak:

- Jogosulatlan memória-hozzáférés;
- Korlátozás és hitelesítés nélküli fájlfeltöltés;
- Jogosulatlan könyvtár-hozzáférés;
- Különböző stack- és heap-based puffer-túlcsordulások;
- Nem megfelelő hozzáférés-vezérlés;
- Nem megfelelő bevitt adat-ellenőrzés;
- Cross-site scripting;
- SQL injection;
- Cross-site request forgery;
- Bizalmas adatok olvasható szöveges formában tárolása;
- Távoli kódfuttatás böngészú plug-in alkalmazásával.

A gyártó a hibákat a WebAccess 8.1-es verzióban javította, ami elérhető a vállalat weboldalán keresztül. Az ICS-CERT a frissítés telepítése mellett tanácsokkal szolgál a sérülékenységek jelentette kockázatok csökkentése érdekében:

Minimálisra kell csökkenteni az ipari rendszerek/hálózatok kapcsolatát az Internettl;
Az ipari rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
Az ipari 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 ICS-CERT tanácsai sokaknak maguktól értetődőek lehetnek (legalábbis erősen remélem, hogy ezek a legtöbb informatikus számára nem jelentenek újdonságot), mégis az, hogy az ICS-CERT egy teljesen átlagos (bár az egy szoftverrel kapcsolatban bejelentett hibák száma ebben az esetben nem mindennapos) esetben ezeket az intézkedéseket javasolja, jól mutatja, hogy mlyen alapvető biztonsági problémák vannak nagyon sok ipari rendszerben/hálózatban.

A SANS ICS Security Blog-ját az ukrán áramszolgáltatók elleni kibertámadás kapcsán már hivatkoztam itt a blogon, múlt héten pénteken pedig  Chris Sistrunk tollából egy két részes blogbejegyzés első része jelent meg, ahol a villamosenergia-szektor elleni kibertámadásokkal foglalkoznak részletesen.

Chris a Mandiant tanácsadója, a kritikus infrastruktúrák kiberbiztonsági kérdéseire, elsősorban ICS/SCADA biztonságra specializálódott. Korábban 11 évig volt mérnök az Entergy-nél, azt megelőzően pedig átviteli és villamosenergia-elosztó rendszereket vezérlő ICS/SCADA rendszerek szakértőjeként dolgozott.

A blogbejegyzés első részében egy rövid villamosenergia-ipari történeti áttekintés után az alállomásokon használt eszközöket, azok védelmét, felügyeletét és vezérlését mutatja be, majd zárásként a Smart Grid-ről is hosszabban ír.

A blogbejegyzést ajánlom minden olyan IT biztonsággal foglalkozó szakember figyelmébe, akiket érdekel az ICS biztonság, de nagyon hasznos lehet az ICS/SCADA üzemeltetésben dolgozóknak is, mert az Ő aktív részvételük nélkül nem lehet hatékony védelmet biztosítani ezeknek a rendszereknek.

2013-ban az USA Szövetségi Energetikai Szabályozó Bizottsága (Federal Energy Regulatory Commission, FERC) egy tanulmányában arra a következtetésre jutott, hogy 9 alállomás elleni támadással az Egyesült Államok területének jelentős részén lehet áramkimaradásokat okozni.

Ebből a tanulmányból kiindulva, hasonlóan a Digital Pearl Harbor, illetve az annak nyomán Dr. Kovács Lajos alezredes és Dr. Krasznay Csaba által készített Digitális Mohács kutatásokhoz, az iSight kutatócsoportja azt vizsgálta, hogy egy kis terrorista csoport képes lenne-e csak publikusan elérhető információkra építve azonosítani a 9 kulcsfontosságú alállomást, amelyeket ezek után már érdemes (fizikai eszközökkel vagy a kibertéren keresztül vagy akár a kettő kombinálásával) támadni annak érdekében, hogy egy jelentős áramkimaradást idézzenek elő?

A kutatás során, aminek a Gridstrike nevet adták, publikusan elérhető adatokat kerestek az átviteli rendszer alállomásairól, térképeket, a Google Earth adatait és az átviteli hálózat túlterhelődéséről szóló dokumentációkat használtak fel és ezeket vetették össze a 10 legnagyobb amerikai várost kiszolgáló alállomások adataival. Végül képesek voltak beazonosítani 15 alállomást, amelyek az amerikai villamosenergia-rendszer gerincét alkotják - ezek kiiktatásával állításuk szerint országos áramszünetet lehetne előidézni.

A Gridstrike részleteiről a kutatók a Miami-ban holnap kezdődő S4x16 ICS biztonsági konferencián fognak beszámolni, részben ennek felvezetéseként nyilatkoztak a Darkreading.com kiberbiztonsági híroldalnak . Abban biztos vagyok, hogy ennek a kutatásnak még komoly visszhangja lesz, ha máshol nem is, de az ICS kiberbiztonsággal foglalkozó szakemberek között biztosan - különösen most, hogy alig több, mint két hete minden szakmabelit a karácsony előtti, ukrajnai áramszünet kiberbiztonsági kérdései és az incidens lehetséges utóélete foglalkoztat.

A SANS ICS blogján a szervezet szakterület igazgatójának írása foglalja össze a legújabb fejleményeket a 2015. december 23-i, ukrán áramszolgáltatók elleni kibertámadással kapcsolatos vizsgálatról. A SANS vizsgálatát az érintett áramszolgáltatóktól kapott információk is segítik, ezek alapján egyre nagyobb biztonsággal állítják, hogy a támadás egy jól szervezett, szándékosan előidézett incidens volt (az ICS rendszerek esetén egyáltalán nem számít ritkának a véletlenül előidézett incidens, de ebben az esetben a vizsgálat során eddig gyűjtött információk egyértelműen a szándékosságot támasztják alá).

A támadók nem csak magas szintű szervezési és koordinációs képességekkel rendelkeztek, de képesek voltak malware-ekkel és feltételezhetően közvetlen távoli hozzáféréssel lehetetlenné tenni, hogy a megtámadott áramszolgáltatók diszpécserei irányításuk alatt tudják tartani a villamosenergia-rendszert. Az áramszolgáltatóktól származó információk alapján egyre pontosabban lehet látni a támadások idővonalát. Ezek alapján a Kyivoblenergo rendszerében 2015 december 23-án 15:35 és 16:30 között hajtottak végre sikeres támadást a 35-110 kV-os rendszert vezérlő alállomási SCADA-rendszer ellen. Miután előidézték az áramszünetet, a KillDisk modullal használhatatlanná tették a vezérlő rendszert, ezzel is tovább növelve a támadás utáni helyreálláshoz szükséges időt és növelve az áramszünet időtartamát - a Kyivoblenergo munkatársai elismerésre méltó gyorsasággal váltottak manuális vezérlésre, de az áramszolgáltatás ennek ellenére csak helyi idő szerint 18:56-ra állt helyre mindenhol. A számítógépes rendszerek elleni támadással egyidőben DDoS-támadást indítottak az áramszolgáltatók weboldalai és call centerei ellen, így nehezítve az ügyfelek számára a hibabejelentéseket és megosztva a támadás elhárításán dolgozó szakemberek figyelmét.

További részletek a SANS ICS blogján olvashatóak.

A mai posztban folytatom a múlt héten elkezdett gondolatot az ICS rendszerek általános biztonsági problémáiról.

Üzemeltetés kontra biztonság

ICS rendszerek esetén a klasszikus CIA-modell nagyon jelentősen el tud és el is szokott tolódni a rendelkezésre állás felé. Ez nem csoda, hiszen a ICS rendszerek jellemzően olyan kritikus infrastruktúra-elemek központi folyamatvezérléséért felelnek, amelyek esetében nem engedhető meg a legkisebb üzemzavar vagy szolgáltatás-kiesés sem, sőt, nagyon gyakran egy ilyen, üzembiztonsági incidens akár személyi sérüléshez is vezethet. Mindezekt végiggondolva belátható, hogy a ICS rendszerek esetén a rendelkezésre állás valóban kiemelt fontosságú szempont és ezért van az, hogy a ICS rendszerek üzemeltetőit hosszú évtizedek óta úgy képezik, hogy a rendelkezésre állási mutatók az egyik (ha nem a) legfontosabb mutatószáma legyen a rendszereik működésének értékelése során.

Azonban pont emiatt az üzemeltetők jellemzően újabb akadályát jelentik a ICS rendszerek biztonságosabbá tételének. A legtöbb ICS rendszer üzemeltető a fentiekben leírtak miatt mind a mai napig csak és kizárólag a rendszerek rendelkezésre állására  koncentrál és ezt szem előtt tartva az esetek igen jelentős hányadában elvetik a hibajavítások telepítésének és az éppen éles konfiguráció módosításának a lehetőségét is. Még rosszabb a helyzet amiatt, hogy a ICS rendszert üzemeltetők többsége meggyőződéssel vallja, hogy az általa üzemeltetett rendszer már azért sem lehet célpontja sikeres támadásnak, mert csak az ért hozzá, akinek ez feladata, akinek pedig nincs dolga az adott ICS rendszerrel, annak esélye sincs átlátni és megérteni a működését, így pedig nem képes sikeres támadást indítani ellene (ezzel a tévhittel kapcsolatban mindenkinek szeretettel ajánlom Marina Krotofil előadásait).

Ugyanez a tévhit az oka egy másik biztonsági hiányosságnak. A legtöbb ICS rendszer esetén a hálózatbiztonság, a határvédelem és a végponti védelem nincs olyan szinten, mint az átlagos vállalati hálózatok és rendszerek esetén. Többnyire azzal érvelnek a ICS rendszereket üzemeltető informatikusok, hogy nincs szükség ilyen eszközökre és intézkedésekre, hiszen a ICS rendszerek nincsenek összekapcsolva semmilyen más rendszerrel vagy hálózattal. Ez a tévhit még abból az időből ered, amikor a vállalati informatika gyerekcipőben járt, azonban mióta az IT az élet és a vállalati mindennapok elválaszthatatlan része lett, üzleti vagy technológiai okok miatt szinte minden ICS rendszernek van valamilyen szintű kapcsolata az egyéb, vállalaton belüli informatikai rendszerekkel. Ilyen formán pedig ezek a rendszerek igenis támadhatóvá válnak pl. az Internet vagy a vállalat irodai WiFi hálózata felől.

Fejlesztés kontra biztonság

Azok számára, akik IT biztonsággal foglalkoznak, nem újdonság, hogy a fejlesztők jellemzően nem a biztonság szem előtt tartásával készítik a különböző szoftvereket. Ennek számos oka lehet, az érdektelenségtől az időhiányon át a hozzá nem értésig és ez alól nem jelentenek kivételt a ICS rendszerek sem. A ICS fejlesztők (hasonlóan az üzemeltetőkhöz) hosszú ideig abban a tévhitben éltek, hogy nem szükséges biztonságos protokollokat alkalmazva biztonságra törekedniük a fejlesztés során, hiszen a rendszer működését úgyis csak azok értik, akiknek érteniük kell és egyébként sem fér hozzá senki illetéktelen az általuk írt kódot futtató rendszerekhez. Ehhez társult még az a probléma, hogy (jellemzően költséghatékonysági okokból) a ICS fejlesztők egyre gyakrabban használnak különböző széles körben ismert és használt megoldásokat, amiknek a hibái is széles körben ismertté válnak, szinte azonnal (ilyenek voltak többek között a Heartbleed és a Shellshock néven elhíresült sérülékenységek, amik bizony számos ICS rendszert is érintettek).

A ICS-felhasználók jelentette biztonsági probléma

Minden informatikai rendszer esetén a felhasználó jelenti az egyik legkomolyabb biztonsági kockázatot, nincs ez másként a ICS rendszerek esetén sem. A legtöbb ICS rendszer esetén a felhasználó informatikai és informatikai biztonsági tudása és képességei nem haladják meg az átlag felhasználó szintjét. Feladataikhoz ez többnyire nem is szükséges, az adott ICS rendszert a feladataik elvégzéséhez szükséges mértékben ismerik, azonban pont ez vezethet ahhoz, hogy rajtuk keresztül könnyen lehet kompromittálni az adott rendszert (ez történt a Stuxnet esetében is).