Július második felében egy kiterjedt adathalász támadási hullám indult az amerikai energiaszektorban működő cégek ellen. A támadók, akik a támadást elemző kutatók szerint nagy valószínűséggel nemzetállami háttérrel rendelkezhetnek, a National Council of Examiners for Engineering and Surveying (NCEES) megszemélyesítésével, mérnöki vizsgák eredményeinek látszó e-maileket és azokhoz csatolt Microsoft Word dokumentumokat küldenek a célba vett szervezetek egyes munkatársainak. A dokumentumokban egy VBA script szolgál dropper célokra, ez a script tölti le a támadók által irányított, ncees[.]com domain-t kiszolgáló szerverről a LookBack trójai egy változatát.

A támadás és a malware elemzése a részletekbe menően a ProofPoint weboldalán található meg. A kérdés igazán az, hogy vajon mi lehet a támadók célja, "csak" adatokat akarnak szerezni a célba vett szervezetektől (és ha az adatlopás a cél, akkor mire akarják használni később a megszerzett adatokat) vagy az adatlopás csak álca, hogy ne legyen egyértelmű, hogy mélyebb hozzáférést akarnak a célba vett energiaszektorba tartozó cégek rendszereiben.

Különböző ukrán és orosz híroldalak forrásai szerint az ukrán biztonsági szolgálat nyomozói kriptobányászatra használt eszközöket találtak a Dél-ukrajnai Yuzhnoukrainsk atomerőműben. A cikkek szerint az erőmű kriptovalutát bányászó munkatársai külön erre a célra helyzetek üzembe számítógépeket és nem az erőmű saját rendszereit fogták be bányászni, azonban az Internetre kötött számítógépeken keresztül az erőmű fizikai biztonsági tervei illetéktelen kezekbe kerülhettek.

Bár sokan fenntartásokkal fogadják a Russia Today és hasonló orosz híroldalak tartalmát, én ebben az esetben kivételt tettem, nem utolsó sorban azért, mert ezt a cikket Anton Shipulin, a Kaspersky ICS biztonsági laborjának egyik ismert munkatársának az oldalán találtam.

A hír kapcsán megint felmerült a fizikai elkülönítés szükségességének kérdése ICS rendszerek esetén. Annyi biztos, hogy sok esetben, amikor egy OT mérnök a fizikai elkülönítésre hivatkozik, mint válaszra minden biztonsági kérdés esetén, érdemes kicsit mélyebben utánajárni, hogy vajon tényleg létezik-e a (többnyire roppant határozottan) állított fizikai leválasztás.

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

A Siemens két sérülékenységet talált a SCALANCE termékcsalád alábbi tagjaiban:

- SCALANCE SC-600 v2.0;
- SCALANCE XB-200 v4.1;
- SCALANCE XC-200 v4.1;
- SCALANCE XF-200BA v4.1;
- SCALANCE XP-200 v4.1;
- SCALANCE SR-300WG v4.1.

A gyártó egyelőre a SCALANCE SC-600-as eszközökhöz készített javítást. A sérülékenységekről bővebb információt a Siemens ProductCERT és az ICS-CERT oldalain lehet találni.

Siemens SINAMICS sérülékenység

A Siemens egy sérülékenységet jelentett a DHS CISA-nak, ami az alábbi termékeit érinti:

- SINAMICS GH150 v4.7 (vezérlő egység) minden verziója;
- SINAMICS GH150 v4.8 (vezérlő egység): minden, v4.8 SP2 HF6-nál korábbi verzió;
- SINAMICS GL150 v4.7 (vezérlő egység) minden verziója;
- SINAMICS GL150 v4.8 (vezérlő egység): minden, v4.8 SP2 HF7-nél korábbi verzió;
- SINAMICS GM150 v4.7 (vezérlő egység) minden verziója;
- SINAMICS GM150 v4.8 (vezérlő egység): minden, v4.8 SP2 HF9-nél korábbi verzió;
- SINAMICS SL150 v4.7 (vezérlő egység) minden verziója;
- SINAMICS SL150 v4.8 (vezérlő egység) minden verziója;
- SINAMICS SM120 v4.7 (vezérlő egység) minden verziója;
- SINAMICS SM120 v4.8 (vezérlő egység) minden verziója;
- SINAMICS SM150 v4.8 (vezérlő egység) minden verziója.

A gyártó a hibát a v4.8 SP2 HF9 verzióban javította. A sérülékenységről további információkat a Siemens ProductCERT és az ICS-CERT publikációiban lehet olvasni.

Sérülékenység SCALANCE X switch-ekben

Younes Dragoni és Alessandro Di Pinto, a Nozomi Networks munkatársai egy szolgáltatás-megtagadásos támadást lehetővé tevő hibát találtak az alábbi SCALANCE X switch-ekben:

- SCALANCE X-200 minden verziója;
- SCALANCE X-200IRT minden verziója;
- SCALANCE X-200RNA minden verziója.

A hibával kapcsolatban a gyártó kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységgel kapcsolatban részleteket a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet találni.

Sérülékenységek Siemens S7 eszközökben

A Siemens ProductCERT publikációja szerint a Haifa-i Műszaki egyetem Informatikai Karának munkatársai (Eli Biham, Sara Bitan, Aviad Carmel és Alon Dankner) és a Tel-Aviv-i Egyetem Villamosmérnöki Karának munkatársai (Uriel Malin és Avishai Wool) két sérülékenységet találtak a Siemens alábbi eszközeiben:

- SIMATIC ET 200SP Open Controller CPU1515SP PC minden verziója;
- SIMATIC ET 200SP Open Controller CPU1515SP PC2 minden verziója;
- SIMATIC S7-1200 CPU család V4.0 és minden korábbi verziója;
- SIMATIC S7-1500 CPU család minden verziója;
- SIMATIC S7-1500 szoftveres vezérlő minden verziója;
- SIMATIC S7-PLCSIM Advanced minden verziója.

A sérülékenységekkel kapcsolatban a gyártó kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységekről további részleteket a Siemes ProductCERT bejelentésében lehet olvasni: https://cert-portal.siemens.com/productcert/pdf/ssa-232418.pdf

Delta Electrics rendszerek sérülékenységei

kimiya, a 9SG biztonsági csoport tagja a ZDI-vel együttműködve két sérülékenységről osztott meg információkat a DHS CISA-val, ami a Delta Electrics DOPSoft nevű HMI-szerkesztő szoftverének 4.00.06.15-ös és korábbi verzióit érintik.

A gyártó a hibát a 4.00.06.47-es verzióban javította. A sérülékenységekről részleteket az ICS-CERT weboldalán lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-225-01

Sérülékenységek Johnson Controls rendszerekben

Egy harpocrates.ghost néven ismert biztonsági kutató két sérülékenységet jelentett a Johnson Controls-nak, amik a Metasys nevű rendszer 9.0-nál korábbi verzióit érintik.

A gyártó a hibákat a 9.0 és későbbi verziókban javította. A sérülékenységekről további információkat az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-227-01

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

Natnael Samson a ZDI-vel együttműködve egy sérülékenységet jelentett a DHS CISA-nak. A sérülékenység az Alpha Smart Loader minden, 4.2-nél korábbi verzióját érinti.

A gyártó a hibát az Alpha Smart Loader 4.2-es verziójában javította. A sérülékenységről bővebben az ICS-CERT weboldalán lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-227-02

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

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

Egy héttel ezelőtt, augusztus 9-én Nagy-Britannia egy jelentős részén voltak komolyabb áramkimaradások. A hírekben felvételeket lehetett látni a sötétbe borult metróállomásokon mobil telefonokkal világítva a kijáratok felé tartó utasokról és London mellett Nagy-Britannia távolabbi területeit is érintette az üzemzavar. Forrásaim szerint az incidensnek nem volt kiberbiztonsági oka, a The Energyst cikke alapján az RWE 740MW kapacitású Little Barford-i gázüzemű majd az Ørsted Hornsea melletti szélerűműve szakadt le a hálózatról, ami több lépésben végül az ismert áramkimaradásokhoz vezetett.

Az első reakciók (legalábbis a brit sajtó részéről) között megjelent a kiberbiztonsági kiváltó ok lehetősége, de az illetékesek ezt határozottan cáfolták. Minden esetre beszédes, hogy mostanra a laikus újságírók egyik gondolata is az egy komolyabb üzemzavar esetén, hogy vajon kibertámadás lehetett-e a háttérben - erről ír a (szintén brit) Cyber Security Intelligence oldal is.

Fontosnak tartom kiemelni, amit a múltban már többen, több incidens esetén is hangoztattak: korántsem minden üzemzavart okoznak kibertámadások és jó lenne óvakodni attól, hogy minden hasonló esetben azonnal hackereket kezdünk emlegetni. Az ICS biztonság témája sajnos úgy kezd egyre népszerűbb lenni, hogy közben a szakemberek és a valóban illetékes szervezetek felkészültsége a témában nem fejlődik kellőképpen. Inkább arra kéne koncentrálni és erőforrásokat fordítani, hogy ezeknél a szervezeteknél fejlesszük az ICS rendszerek és kapcsolódó eljárások illetve érintett emberek biztonsági szintjét.

Időközben tegnap este találtam egy posztot Joe Weiss-től a SANS ICS community weboldalán, ahol Joe éppen azt fejtegeti, hogy annak ellenére, hogy a mai villamosenergia-rendszerekben használt, igen összetett és bonyolult vezérlő rendszereket nagyon-nagyon kevesen látják át teljes mélységükben és ez azt is jelentheti, hogy egy alaposan felkészült támadó (ami - ezt már én teszem hozzá - szinte minden esetben valamilyen nemzetállami, többnyire titkosszolgálati hátterű csoportot jelent) képes lehet egy kibertámadást úgy felépíteni és kivitelezni, hogy az végül például mechanikus vagy emberi hibának tűnjön. Joe érvelése szerint legalábbis furcsa, hogy a Nagy-britanniai incidensnél szinte egyszerre következett be a szélerőmű és a gázüzemű erőmű kiesése, szerinte ez is mutathat abba az irányba, hogy alaposabban kell vizsgálni egy lehetséges kiberbiztonsági incidens nyomait az esetek hátterében.

Joe bejegyzése több más érdekes gondolatot is tartalmaz, regisztráció után itt érhető el.

Annyi mindenképp biztos, hogy a brit villamosenergia-szektort felügyelő hatóság (finoman fogalmazva) nem boldog, így biztosra lehet venni, hogy egy igen alapos vizsgálat fogja követni a múlt heti incidenst.

Update: Elérhető a NationalGrid (a brit átviteli rendszerirányító) előzetes jelentése az incidensről.

A Reuters cikke szerint számos, különböző ipari szektorokban tevékenykedő cég (többek között a Siemens-et, a Bayer-t, a BASF-et, a Henkelt, a Roche-t, a Sumitomo-t, a Shin-Etsu-t nevesítették) szenvedett el kibertámadásokat az utóbbi időben. A támadásokat vizsgáló szakértők a támadásokhoz a Winnti malware-t használták és bizonyos, feltételezések szerint kínai állami háttérrel rendelkező APT-csoportok állhatnak mögöttük.

Bár ezek a támadások minden jel szerint az érintett cégek adatainak ellopását célozhatták, felmerül a kérdés, hogy ha egyes államok támogatását bíró támadói csoportok ilyen félelmetes erőforrásokkal és hatékonysággal képesek az ipari kémkedésre és adatlopásra a saját gazdaságuk/iparuk fejlesztése érdekében, mikor jön el az a pont, amikor már nem csak az üzleti és technológiai titkokat akarják kibertámadásokkal megszerezni, hanem a konkurenciát hátrányos helyzetbe hozni vagy ellehetetleníteni?

Sérülékenységek Prima Systems rendszerekben

Gjoko Krstic, a Applied Risk munkatársa 9 sérülékenységet jelentett a DHS CISA-nak, amik a Prima FlexAir 2.3.38 és korábbi verzióit érintik.

A gyártó a hibát a 2.5.12-es verzióban javította. A sérülékenységekről további részleteket az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-211-02

Wind River VxWorks sérülékenységek

Gregory Vishnepolsky, Dor Zusman és Ben Seri, az Armis kutatói 11 különböző sérülékenységről osztottak meg részleteket a DHS CISA-val, amik VxWorks valósidejű operációs rendszer (Real Time Operating System, RTOS) alábbi verzióit érintik:

- Minden, jelenleg támogatással rendelkező VxWorks verzió (6.9.4.11, Vx7 SR540, Vx7 SR610);
- Régebbi, támogatással már nem rendelkező verziók 6.5-ig visszamenőleg;
- A támogatással már nem rendelkező Advanced Networking Technology (ANT) minden verziója.

Az alábbi termékeket és verziókat a most publikált sérülékenységek nem érintik:

- VxWorks 7 SR620 (a legújabb VxWorks verzió);
- VxWorks 5.3-tól VxWorks 6.4-ig;
- VxWorks Cert minden verziója;
- VxWorks 653 2.x és korábbi verziói;
- VxWorks 653 MCE 3.x Cert Edition és későbbi verziói.

A gyártó a még támogatással rendelkező, érintett verziókhoz javításokat és kockázatcsökkentő intézkedéseket jelentett be. A sérülékenységek több más gyártó (mostanáig a Rockwell Automation és a Xerox lettek megnevezve) egyes termékeit is érintik. Egyes források szerint az érintett rendszerek száma akár 200 millió is lehet világszerte. A sérülékenységekkel kapcsolatban bővebb információkat az ICS-CERT bejelentésében lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-211-01

Sérülékenységek LCDS rendszerekben

Francis Provencher (PRL) a ZDI-vel együttműködve két sérülékenységet azonosított a LAquis SCADA 4.3.1.71-es verziójában.

A gyártó a hibákat a 4.3.1.323-as verzióban javította. A sérülékenységekről részleteket az ICS-CERT weboldalán lehet elérni: https://www.us-cert.gov/ics/advisories/icsa-19-213-06

Rockwell Automation rendszerek sérülékenységei

kimiya, a 9SG biztonsági csoport tagja két sérülékenységet talált a Rockwell Automation Arena Simulation Software nevű termékének 16.00.00 és korábbi verzióiban.

A gyártó a hibákat a 16.00.01-es verzióban javította. A sérülékenységekről bővebb információkat az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-213-05

Sérülékenység 3S-Smart Software Solutions termékekben

JunYoung Park egy sérülékenységet azonosított a 3S-Smart Software Solutions CODESYS termékcsaládjának alábbi tagjaiban:

- CODESYS Control for BeagleBone;
- CODESYS Control for emPC-A/iMX6;
- CODESYS Control for IOT2000;
- CODESYS Control for Linux;
- CODESYS Control for PFC100;
- CODESYS Control for PFC200;
- CODESYS Control for Raspberry Pi;
- CODESYS Control RTE V3;
- CODESYS Control RTE V3 (for Beckhoff CX);
- CODESYS Control Win V3 (also part of the CODESYS Development System setup);
- CODESYS V3 Simulation Runtime (part of the CODESYS Development System);
- CODESYS Control V3 Runtime System Toolkit;
- CODESYS HMI V3.

A hibát a gyártó az érintett termékek legújabb, 3.5.16.0 verziójában fogja javítani, ami a tervek szerint 2020. februárban fog megjelenni. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT bejelentésében lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-213-04

3S-Smart Software Solutions CODESYS V3 sérülékenységek

A 3S-Smart Software Solutions két sérülékenységről osztott meg információkat a DHS CISA-val, amik az alábbi termékeiket érintik:

- CODESYS Control for BeagleBone;
- CODESYS Control for emPC-A/iMX6;
- CODESYS Control for IOT2000;
- CODESYS Control for Linux;
- CODESYS Control for PFC100;
- CODESYS Control for PFC200;
- CODESYS Control for Raspberry Pi;
- CODESYS Control V3 Runtime System Toolkit;
- CODESYS Gateway V3;
- CODESYS V3 Development System.

A gyártó a hibákat a v3.5.14.20-as és a v3.5.15.0 verziókban javította. A sérülékenységek részleteiről az ICS-CERT weboldalán lehet információkat találni: https://www.us-cert.gov/ics/advisories/icsa-19-213-03

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

kimiya, a 9SG biztonsági csapat tagja a ZDI-vel együttműködve egy sérülékenységet azonosított a Fuji Electric FRENIC Loader nevű termékének 3.5.0.0 és korábbi verzióiban.

A gyártó a hibát a legújabb verzióban javította. A sérülékenységről részletesebben az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-213-02

Sérülékenység Advantech rendszerekben

Mat Powell és a ZDI egy, az Advantech WebAccess HMI Designer 2.1.9.23-as és korábbi verzióit érintő sérülékenységről publikált információkat.

A hibát a gyártó a 2.1.9.31-es verzióban javította. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT weboldalán lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-213-01

Sérülékenységek Siemens SIPROTEC 5 hálózati kommunikációs modulokban

A Siemens ProductCERT a Wind River-rel, valamint Pierre Capillon-nal, Nicolas Iooss-szal és Jean-Baptiste Galet-vel, az ANSSI munkatársaival együttműködve 12 sérülékenységről hozott nyilvánosságra részleteket, amik a SIPROTEC 5 termékcsalád alábbi tagjait érintik:

- SIPROTEC 5 CP300 és CP100 plug-in kommunikációs modulok minden, V7.91-nél korábbi verziói;
- SIPROTEC 5 CP200 plug-in kommunikációs modulok minden verziója;
- SIPROTEC 5 CP300-as CPU-val szerelt változatainak minden verziója.

A gyártó az egyik sérülékenységhez bizonyos érintett eszközök esetében adott ki javítást, a többi esetben kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységről bővebben a Siemens ProductCERT publikációjában lehet olvasni: https://cert-portal.siemens.com/productcert/pdf/ssa-632562.pdf

A sérülékenységek negatív hatásainak csökkentése érdekében az ICS-CERT az alábbi kockázatcsökkentő intézkedések bevezetését javasolja:

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

A múltkori bejegyzésem, ami az IT/IT biztonsági és OT szakterületek közötti, finoman fogalmazva sem ideális viszonyokat boncolgatta, elég gyorsan vetett néhány hullámot, bizonyítva, hogy létező és komoly problémáról van szó.

Mivel a probléma felvetése szerintem csak egy (első) lépés az úton, megpróbálok adni néhány ötletet, hogyan lehetne javítani ezen a nem éppen jó helyzeten.

1. Kommunikáció (tudom, tudom, elég bullshit-nek fog tűnni, esélyes, hogy néhány kollégám ezért a bekezdésért meg akar majd dobálni, de bármennyire is közhelynek hangzik, innen kell indulni): Nem lehet megúszni azt, hogy az IT/IT biztonsági és OT szakterületek a nem létező vagy éppen csak érintőleges kapcsolatok helyett sokkal szorosabb szakmai együttműködést építsenek ki. Ebben beletartozik egymás feladatainak és napi kihívásainak, problémáinak valamilyen szintű ismerete is - személy szerint úgy gondolom, hogy kerüljön bármennyi időbe és energiában, mindenképp fontos, hogy a jobb szakmai együttműködés egy jobb személyes kapcsolatra épüljön, ezért pedig szükséges, hogy az IT/IT biztonsági és OT mérnökök időnként igenis üljenek le beszélgetni. Ha pedig ez a beszélgetés néha túlmutat a szakmai témákon, az sem baj.

2. Képzések: Elsősorban és leginkább azokra az alapozó képzésekre gondolok, amelyek keretében mind az OT, mind az IT (elsősorban IT biztonsági) mérnökök betekintést nyerhetnek az ICS biztonság világába (ilyenek pl. az Idaho National Labs és az ENCS - erről később fogok írni - képzései illetve a SANS ICS 410-es tanfolyama). Tudom, hogy ezeknek a tanfolyamoknak az ára meglehetősen magas, de fel kell tenni a kérdést az érintett szervezetek felelős vezetőinek: meg tudják egyáltalán becsülni (), hogy egy komolyabb ICS biztonsági incidens (mint például a Norsk Hydro vagy a TSMC elleni támadások) mekkora anyagi veszteséget eredményezhet a cégük számára? Ehhez hasonlítva még mindig soknak tűnik évente 1-2 ember számára fejenként 3000-5000 Eurót ilyen tanfolyamokra költeni (főleg, ha ezek az emberek utána a megszerzett tudást át is tudják adni a kollégáiknak)?

3. Információcsere: Részben a kommunikációhoz is tartozik, de tapasztalataim szerint jelenleg gyakorlatilag nulla információcsere van az OT és az IT biztonsági területek között. Ez pedig azt is jelenti, hogy még ha egy adott cél IT biztonsági szakterülete folytat is fenyegetés-elemzést és gyűjt információkat különböző forrásokból, ezek az információk szinte biztosan nem jutnak el az ICS rendszerek és eszközök üzemeltetéséért felelős szakemberekhez.

A fentiekben megfogalmazott feladatok/célok nyilván csak egy kis szeletét fedik le annak, amit tenni lehetne és kéne egy jobb IT-OT együttműködésért, de ha ezek mentén elkezd fejlődni egy szervezet, már az is hatalmas változásokat eredményezhet.

Sérülékenység Cisco ipari termékekben

A Cisco publikációja szerint egy sérülékenységet találtak az ipari hálózati eszközeik menedzsmentjéhez használható Industrial Network Director (IND) nevű rendszerük 1.7-nél korábbi verzióiban.

A hibát a gyártó az IND 1.7-es verziójában javította. A sérülékenységgel kapcsolatban további információk a Cisco publikációjában találhatóak.

Johnson Controls rendszerek sérülékenysége

Gjoko Kristic, a Zero Science Lab munkatársa egy sérülékenységet fedezett fel a Johnson Controls exacqVision server nevű megoldásának 9.6-os és 9.8-as verzióiban.

A gyártó a hibát a termék legújabb, 19.03-as verziójában javította. A sérülékenységről bővebben az ICS-CERT bejelentésében lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-199-01

Sérülékenységek Mitsubishi Electric rendszerekben

Az Applied Risk két sérülékenységről közölt információkat az amerikai Cyber Infrastructure Security Agency-vel (CISA). A sérülékenységek a Mitsubishi Electric FR Configurator2 rendszerének 1.16S és korábbi verzióit érintik.

A gyártó a hibát az 1.17T verzióban javította. A sérülékenységekről további információkat az ICS-CERT bejelentése tartalmaz: https://www.us-cert.gov/ics/advisories/icsa-19-204-01

Sérülékenység NREL EnergyPlus rendszerekben

Karn Ganeshen egy, az NREL EnergyPlus 8.6.0 és feltételezhetően korábbi verzióit érintő sérülékenységet jelentett a CISA-nak.

A gyártó a hibával kapcsolatban az érintett termék legújabb, v9.0.1-es verziójának használatát javasolja. A sérülékenységről részleteket az ICS-CERT weboldalán lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-204-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áltatások hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználó kezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (valamilyen szinten tűzálló páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

A hírek szerint csütörtökön ransomware-támadás érte a johannesburgi (a Dél-afrikai Köztársaság pénzügyi központjának számító város) áramszolgáltató informatikai rendszereit. Bár a különböző források szerint a támadás a cég egyes IT rendszereit érintette (többek között a telefonos ügyfélszolgálati valamint a munka és eszközkezelő rendszerekről esik szó) és nincs szó arról, hogy a villamosenergia-ellátásban közvetlenül érintett ICS rendszerekig ért volna a ransomware. Azonban a hírek szerint azok az ügyfelek, akik előre fizetnek a villamosáramért (jellemzően ezek a legszegényebb rétegek lehetnek ugyanúgy, mint Magyarországon), szintén érintettek, mert a feltöltőkártyás rendszer is érintett. Ráadásul mivel a déli féltekén most tél van, a hideg időjárás miatt előfordulhat, hogy a nagyobb rendszerterhelések következtében kialakuló meghibásodások áramkimaradásokhoz vezetnek, amiket a szolgáltató (a ransomware által titkosított rendszereik hiányában) a normálisnál jóval lassabban tud elhárítani.

Az incidensről jelenleg részleteket a Dark Reading és a Reuters cikkeiben olvashatóak.

A jelek szerint az idei év az ipari szereplők (és a különböző városi szolgáltatók és önkormányzati szervek) elleni ransomware-támadások éve lesz, elég csak a nemrég napvilágot látott floridai városok vagy éppen a Norsk Hydro elleni ransomware-támadásokra gondolni. A kérdés már csak az, mit tesznek azok, akiknek az a dolguk, hogy megelőzzék ezeket a támadásokat?

Nemrég egy közel 5 éves esetről olvastam, ami rávilágít arra, hogy az ICS kiberbiztonság világában is komoly kockázati tényezőt jelenthetnek a hamisított eszközök. A Yokogawa bejelentése szerint ismeretlenek Yokogawa logóval ellátott, EJA-110E sorozatú érzékelőket árulnak. Az érintett eszközöket számos szektorban használják, kereskedelmi, gyártástechnológiai és védelmi rendszerek mellett atomerőművek SCRAM (safety) rendszereiben is.

Bár a hamisításnak feltételezhetően tisztán pénzügyi okai lehetnek, nem szabad szó nélkül elmenni amellett a lehetőség mellett, hogy egy ilyen berendezésen keresztül mennyivel könnyebben lehet valótlan adatokat eljuttatni a felügyeleti rendszerekbe, ezáltal idézni elő egy komolyabb ICS biztonsági incidenst. Ráadásul mivel magát a szenzort kompromittálták a támadadók, ezért a hagyományos, host szintű vagy hálózatbiztonsági megoldások az ilyen támadások ellen nem vagy csak sokkal kisebb hatásfokkal tudnak védelmet nyújtani.

Ez a régi eset is rávilágít arra, hogy az ICS biztonság terén is kiemelten fontos az egyenszilárd biztonság kialakítása, ami magában kell, hogy foglalja a lvl1/lvl0 szinteken működő berendezések biztonsági kontrolljait. Mivel ezekhez az eszközökhöz általában már sem az IT biztonsági, sem az OT biztonsági mérnökök nem értenek, elkerülhetetlen, hogy a fent említett biztonsági szakemberek és a folyamatirányításért felelős OT mérnökök között nagyon szoros szakmai együttműködés létezzen, mert csak ez biztosíthatja, hogy a kialakításra kerül ICS biztonsági programnak nem lesznek vakfoltjai a Purdue-modell alacsonyabb szintjein működő berendezéseknél.