Sérülékenység 3S Codesys rendszerekben

Carl Hurd, a Cisco Talos munkatársa egy sérülékenységet fedezett fel a 3S (3S-Smart Software Solutions Gmbh) Codesys Runtime szoftveres PLC-inek 3.5.14.30-as verziójában.

A hibával kapcsolatban egyelőre nincs információ javításról. A sérülékenység részleteit a Talos bejelentésében érhetőek el: https://talosintelligence.com/vulnerability_reports/TALOS-2020-1003

Fazecast rendszerek sérülékenysége

Ryan Wincey, a Securifera munkatársa a ZDI-vel együttműködve egy sérülékenységet azonosított a Fazecast jSerialComm nevű, Java-alapú, platformfüggetlen soros kommunikációs megoldásának 2.2.2-es és korábbi verzióiban. A publikáció szerint a sérülékenység a Schneider Electric EcoStruxure IT Gateway-ek 1.5.x, 1.6.x és 1.7.x verzióit is érinti.

A hibát a Fazecast a jSerialComm 2.2.3-aa és újabb, a Schneider Electric az EcoStruxure IT Gateway 1.8.1-es és újabb verzióiban 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/ICSA2012601

Sérülékenységek SAE IT-systems RTU-kban

Murat Aydemir of Biznet Bilisim A.S. munkatársa két sérülékenységet jelentett a DHS CISA-nak, amik a SAE IT-systems FW-50 RTU-i közül az 5. sorozat, CPU-5B típusú CPU második verziójával szerelt, 6-os CPLD verzióját érintik.

A hibákkal kapcsolatban a gyártó kockázatcsökkentő intézkedésekre (RTU webszerverének letiltása, CPU kártya cseréje) tett javaslatokat. A sérülékenységek részletei az ICS-CERT weboldalán találhatóak: https://www.us-cert.gov/ics/advisories/ICSA2012602

Advantech WebAccess sérülékenységek

Natnael Samson és egy Z0mb1E néven ismert biztonsági kutató a ZDI-vel együttműködve 8 sérülékenységről hoztak nyilvánosságra részleteket. A sérülékenységek az Advantech WebAccess alábbi verzióit érinti:

- WebAccess Node 8.4.4 és korábbi verziói;
- WebAccess Node 9.0.0 verzió.

A gyártó a hibákat a 8.4.4.P0320844 és 9.0.0.P0320900 patch-ekben javította. A sérülékenységekről további információkat az ICS-CERT bejelentésében lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-20-128-01

Schneider Electric Pro-face GP-Pro sérülékenység

Kirill Kruglov, a Kaspersky Lab munkatársa egy sérülékenységet talált a Schneider Electric GP-Pro EX V1.00-tól V4.09.100-ig terjedő verzióban.

A gyártó a hibát a GP-Pro EX V4.09.120-as verzióban javította. A sérülékenységről részleteket a Schneider Electric publikációja tartalmaz.

Sérülékenység Schneider Electric Vijeo rendszerekben

Jie Chen, az NSFOCUS munkatársa egy sérülékenységet azonosított, ami a Schneider Electric Vijeo alábbi verzióit érinti:

- Vijeo Designer Basic V1.1 HotFix 16 és korábbi verziók;
- Vijeo Designer V6.2 SP9 és korábbi verziói.

A gyártó a hibát a Vijeo Designer Basic V1.1 HotFix 17-ben javította és a Vijeo Designer következő javítócsomagjában fogja javítani. A sérülékenység részleteiről a Schneider Electric bejelentésében lehet olvasni.

Schneider Electric U.motion szerverek és érintőpanelek sérülékenységei

Rgod és Zhu Jiaqi két sérülékenységet találtak a Schneider Electric alábbi termékeiben:

- MTN6501-0001 – U.Motion – KNX Server minden verziója;
- MTN6501-0002 – U.Motion – KNX Server Plus minden verziója;
- MTN6260-0410 – U.Motion KNX server Plus, Touch 10 minden verziója;
- MTN6260-0415 – U.Motion KNX server Plus, Touch 15 minden verziója;
- MTN6260-0310 – U.Motion KNX Client Touch 10 minden verziója;
- MTN6260-0315 – U.Motion KNX Client Touch 15 minden verziója.

A hibákat a gyártó az érintett termékek 1.4.2-es verziójában javította. A sérülékenységek részleteit a Schneider Electric weboldalán lehet megtalálni.

Sérülékenységek Siemens villamosenergia mérő berendezésekben

A Siemens ProductCERT bejelentése szerint 10 sérülékenységet találtak a kis- és nagyfeszültségű villamos mérőberendezéseikben található Wind River VxWorks valós idejű operációs rendszerében. A sérülékenység az alábbi berendezéseket érinti:

- Siemens Power Meters Series 9410 V2.2.1-nél korábbi összes verziója;
- Siemens Power Meters Series 9810 minden verziója.

A gyártó a hibákat a 9410-es sorozat esetén a V2.2.1-es verzióban javította, a 9810-es sorozatot használó ügyfeleinek kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekről bővebben a Siemens ProductCERT publikációjában lehet olvasni.

Eaton rendszerek sérülékenységei

Sivathmican Sivakumaran, a Trend Micro ZDI munkatársa két sérülékenységet talált az Eaton Intelligent Power Manager v1.67 és korábbi verzióiban.

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

Sérülékenységek OSISoft rendszerekben

William Knowles, az Applied Risk munkatársa az OSISoft-tal közösen 10 sérülékenységet azonosított a gyártó alábbi rendszereiben:

- A PI Asset Framework (AF) kliens 2018 SP3 Patch 1, 2.10.7.283 és korábbi verzióit használó alkalmazások;
- A PI Software Development Kit 2018 SP1, 1.4.7.602 és korábbi verzióit használó alkalmazások;
- PI API for Windows Integrated Security 2.0.2.5 és korábbi verziói;
- PI API 1.6.8.26 és korábbi verziói;
- PI Buffer Subsystem 4.8.0.18 és korábbi verziói;
- PI Connector for BACnet 1.2.0.6 és korábbi verziói;
- PI Connector for CygNet 1.4.0.17 és korábbi verziói;
- PI Connector for DC Systems RTscada 1.2.0.42 és korábbi verziói;
- PI Connector for Ethernet/IP 1.1.0.10 és korábbi verziói;
- PI Connector for HART-IP 1.3.0.1 és korábbi verziói;
- PI Connector for Ping 1.0.0.54 és korábbi verziói;
- PI Connector for Wonderware Historian 1.5.0.88 és korábbi verziói;
- PI Connector Relay 2.5.19.0 és korábbi verziói;
- PI Data Archive 2018 SP3, 3.4.430.460 és korábbi verziói;
- PI Data Collection Manager 2.5.19.0 és korábbi verziói;
- PI Integrator for Business Analytics 2018 R2 SP1, 2.2.0.183 és korábbi verziói;
- PI Interface Configuration Utility (ICU) 1.5.0.7 és korábbi verziói;
- PI to OCS 1.1.36.0 és korábbi verziói;
- PI Data Archive 2018 és 2018 SP2.
- PI Data Archive 2018 SP2 és korábbi verziói;
- PI Vision 2019 és korábbi verziói;
- PI Manual Logger 2017 R2 Patch 1 és korábbi verziói;
- RtReports Version 4.1 és korábbi verziói;
- PI Vision 2019 és korábbi verziói;

A gyártó a hibákkal kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről bővebb információkat az ICS-CERT weboldalán találhatóak: https://www.us-cert.gov/ics/advisories/icsa-20-133-02

Opto 22 SoftPAC sérülékenységek

Mashav Sapir, a Claroty munkatársa 5 sérülékenységet talált az Opto 22 SoftPAC Project 9.6 és korábbi verzióiban.

A gyártó a hibát a 10.3-as verzióban javította. A sérülékenységek részleteit az ICS-CERT weboldalán lehet megtalálni: https://www.us-cert.gov/ics/advisories/icsa-20-135-01

Sérülékenység Emerson WirelessHART Gateway-ekben

Az Emerson egy sérülékenységet talált a WirelessHART Gateway termékcsaládjának alábbi tagjaiban:

- Wireless 1410 Gateway 4.6.43-tól 4.7.84-ig terjedő verziói;
- Wireless 1420 Gateway 4.6.43-tól 4.7.84-ig terjedő verziói;
- Wireless 1552WU Gateway 4.6.43-tól 4.7.84-ig terjedő verziói.

A gyártó a hibát a hibát javító új firmware-verziót már elérhetővé tette. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT publikációja tartalmaz: https://www.us-cert.gov/ics/advisories/icsa-20-135-02

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.

Hírszerzési információk alapján a The Washington Post arról számolt be, hogy Irán állhat az izraeli viziközmű cégek ellen végrehajtott kibertámadások mögött, amikről május elején én is írtam, és amik során egyes hírek szerint a PLC-kig is eljutottak a támadók. Szokás szerint izraeli hivatalos források nem kommentálták a híreket, iráni illetékesek pedig tagadnak, de nem kell hozzá túl bátornak lenni, hogy feltételezhessük, Irán és izrael között csak súlyosbodni fognak a hasonló konfliktusok. Sajnos ebből esélyesen a hazai rendszerek és számítógépek sem fognak kimaradni - a mostani források szerint az izraeli viziközmű vállalatok elleni támadásokhoz Észak-amerikai és európai számítógépeket használtak a támadók, hogy elfedjék valódi kilétüket. A kérdés már csak az: mit teszünk mi, itt, Magyarországon, hogy képesek legyünk megvédeni a saját (IT és OT) rendszereinket?

Tegnap megjelent hírek szerint kibertámadás érte az Elexon nevű a brit villamosenergia-piac működtetéséért felelős cég IT rendszereit. Az Elexon saját publikációi ugyan kifejezetten szűkszavúak, de a sorok között olvasva én valamilyen ransomware-támadásra tippelnék.

Bár a villamosenergia-piaci folyamatoknak általában nincs közvetlen kapcsolata ICS rendszerekhez vagy eszközökhöz, a megújuló energiatermelés egyre nagyobb részaránya mellett a villamosenergia-piac egyre fontosabbá válik a szektorban. Egyes vélemények szerint a piaci folyamatok már-már fontosabbak a villamosenergia-ipari cégek számára, mint maga az üzemirányítás - ez ugyan elég furcsán hangozhat, azt is figyelembe kell venni, hogy a villamosenergia-ipari cégek számára a piaci tevékenységük biztosítja a jövedelmezőséget és ez hatalmas összegeket jelent. Így talán nem is olyan meglepő az a várakozásom, hogy a jövőben bizony szaporodni fognak a piacműködtetéshez használt rendszerek és azzal foglalkozó cégek elleni kibertámadások, hiszen ez a szektornak az a része, ami a különböző kiberbűnözői csoportok számára is vonzó lehet.

Sérülékenységek LAquis SCADA rendszerekben

Natnael Samson a ZDI-vel együttműködve két sérülékenységről közölt információkat a DHS CISA-val, amik az LCDS LAquis SCADA rendszerének 4.3.1-es és korábbi verzióit érintik.

A gyártó a hibákat a legújabb verzióban javította. A sérülékenység részleteiről az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-20-119-01

Moxa NPort sérülékenység

A Moxa bejelentése szerint Maayan Fishelov, a SCADAfence munkatársa egy sérülékenységet talált az NPort 5100A sorozatú eszközeik 1.5-ös és korábbi firmware-verzióiban.

A gyártó a legújabb firmware-verzióban javította. A sérülékenységgel kapcsolatban bővebb információkat a Moxa bejelentése tartalmaz.

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.

Múlt héten kedden jelent meg a hír a CyberScoop weboldalán, hogy ransomware-támadás érte a tajvani állami energiavállalat, a CPC Corp. rendszereit. A CPC a tajvani olaj- és cseppfolyósított (LNG) gáz-szektor egyik nagoyn fontos szereplője.

A hírek szerint az incidens nem érintette a CPC ICS rendszereit.

Két nappal később, múlt héten csütörtökön jelent meg az első hír, ami szerint támadók bejutottak a Stadler (itthon is meglehetősen ismert - na nem az akasztói vállalkozó, hanem a svájci vasúti járműgyártó vállalat) rendszereibe és a közlemény szerint nagy mennyiségű adatot loptak el.

A jelenleg rendelkezésre álló információk alapján a támadók célja az adatlopás és zsarolás lehetett, egyelőre nincsenek olyan jelek, amik alapján feltételezhetnénk, hogy a Stadler termelésirányításban használt rendszerei vagy a különböző vonatokban és villamosokban használt vezérlőrendszereket érintette volna az incidens.

Az esetről mostanra több IT biztonsági portál is beszámolt.

Május 1-jén (a reakciókat figyelve némileg a szakmai közösséget is meglepő módon) a Fehéz Ház oldalán megjelent egy új elnöki rendelet, ami az USA villamosenergia-rendszerének biztonságával kapcsolatban tartalmaz rendelkezéseket.

Az elmúlt egy hétben még viszonylag kevés reakció jelent meg, de amikkel én találkoztam, azok pozitívként értékelik ezt az új fejleményt.

Az elnöki rendelet többek között megtiltja az USA villamosenergia-hálózatában a külföldi forrásból származó, nagyfeszültségű villamosenergia-berendezések (pl. transzformátorok, védelmek, RTU-k, stb., vagyis mindazoknak az ICS berendezéseknek, amiknek a biztonságáról beszélni szoktunk) beszerzését és üzemeltetését, amelyek esetében külföldi ország vagy állampolgár érdekeltséggel rendelkezik és ez az ügylet veszélyeztetné az USA nemzetbiztonsági érdekeit. Ha ezt a rendelkezést abból a szempontból nézzük, hogy az utóbbi években egyre nagyobb fenyegetést jelent a kritikus infrastruktúrák (köztük a villamosenergia-rendszert üzemeltető szervezetekre is, de nem csak rájuk nézve) a beszállítói láncok elleni kibertámadások, akkor még könnyebb megérteni, hogy miért fontos (és nagyon időszerű) ez az elnöki rendelet.

Várhatóan az elnöki rendelet nyomán megindul több régóta várt (és az ICS biztonsági közösség által régóta szorgalmazott) folyamat, mint például párbeszéd a szabályozók, az ellenőrzéseket végző hatóságok, a gyártók és az üzemeltetők között. Ugyancsak várható, hogy az elnöki rendelet változásokat fog eredményezni az USA villamosenergia-rendszerében működő cégek életét és működését szabályozó NERC CIP követelményrendszerben is.

A Fehér Ház weboldalán elérhető elnöki rendelet a következő hónapokban és években még számos fejleménynél lesz hivatkozási alap és én személy szerint úgy gondolom, hogy az USA ismét tett egy olyan lépést a helyes irányba, amit az európai országok előbb vagy utóbb valamilyen formában követni fognak. Csak remélni tudom, hogy a magyar jogalkotók és felügyeleti szervek minél előbb felismerik, hogy ez a helyes irány és a magyar környezet sajátosságait szem előtt tartva születik egy nagyon hasonló magyar jogszabály.

Kicsit több, mint egy hete hozta nyilvánosságra az izraeli kormány, hogy kibertámadás-sorozat érte az ország több viziközmű-vállalatát. Bár a hivatalos kommunikáció és az arra épülő első cikkek szerint a támadók nem fértek hozzá a folyamatirányító rendszerekhez, később új információk láttak napvilágot, ezek már arról szóltak, hogy a támadók alaposan ismerték a megtámadott cégek által használt PLC-ket és képesek voltak olyan változtatásokat végezni a PLC-ken, amik később érvényesnek bizonyultak, vagyis egészen pontos ismereteik voltak a kompromittált ICS eszközökkel kapcsolatban.

Az incidenssel kapcsolatban megjelent Radiflow blogposzt feltételezhető, hogy a támadókat valaki a helyszínen is segíthette, ami rögtön érthetőbbé teszi, hogyan juthattak a támadók ilyen mélyre a megtámadott viziközmű vállalat rendszereiben - még akkor is, ha az izraeli kormány első publikációjában arról is írnak, hogy a viziközmű cégeknek mielőbb gondoskodniuk kell az ICS rendszereik Internet-kapcsolatainak megszüntetéséről. Ez ugye nagyjából az első tanács bármilyen ICS kiberbiztonsági kérdés merül fel.

A Dragos által Parisite-nak nevezett csoport az elemzések szerint 2017 óta aktív és célpontjai közé egyaránt tartoznak Észak-amerikai, Közel-keleti, európai és ausztrál, különböző ipari területeken (légiközlekedés, olaj- és gázszektor, közműszektor) működő szervezetek.

A csoport eszköztárába elsősorban széles körben használt VPN-megoldások ismert sérülékenységei mellett különböző szabadon elérhető eszközökből (pl. Masscan, dsniff) áll.

A jelenleg rendelkezésre álló információk szerint a PARISITE csoport tevékenysége jelenleg nem célozza ICS rendszerek működésének megzavarását vagy ellehetetlenítését, sokkal inkább a Magnallium/APT33 neveken ismert csoport számára végez felderítési és hozzáférés-előkészítési feladatokat.

A Parisite-ról jelenleg egyedül a Dragos weboldalán lehet információkat találni.

Sérülékenység Inductive Automation rendszerekben

Sharon Brizinov és Mashav Sapir, a Claroty munkatársai egy sérülékenységet találtak az Inductive Automation Ignition 8 Gateway termékének 8.0.10-esnél korábbi verzióiban.

A gyártó a hibát a 8.0.10-es verzióban javította és kockázatcsökkentő intézkedések alkalmazását is javasolja. A sérülékenységről bővebb információk az ICS-CERT publikációjában találhatóak: https://www.us-cert.gov/ics/advisories/icsa-20-112-01

Sierra Wireless termékek sérülékenységei

Egy 2019-ben, Carl Hurd és Jared Rittle, a Cisco Talos laborjának munkatársai által felfedezett sérülékenységekről megjelent bejelentéshez adott ki frissítést az ICS-CERT. Az új információk alapján az érintett AirLink eszközök listája bővült az LS300, GX400, GX440 és ES440-es modellek összes, 4.4.9-esnél korábbi verziójával.

A bejelentés frissítése a hibát javító újabb verziókról is új információkat adott ki. A sérülékenységgel kapcsolatos új információk az ICS-CERT bejelentésében érhetőek el: https://www.us-cert.gov/ics/advisories/ICSA-19-122-03

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

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

A Cisco Talos kutatói egy (általuk PoetRAT névre keresztelt), Python-alapú trójait terjesztő támadói csoportot azonosítottak. A PoetRAT a célba vett rendszerbe történő bejuttatása után egyebek mellett képes információkat kinyerni a kompromittált rendszerből, fájlokat tud le és feltölteni, módosításokat tud végezni a rendszerleíró adatbázisban és operációs rendszer parancsokat is ki tud adni.

A PoetRAT malware-t jellemzően Microsoft Word fájlokba rejtett dropperekkel terjesztik, ez év februárjában olyan, hamisított dokumentumokban is feltűnt, amik az indiai védelmi minisztérium egyik kutatás-fejlesztési cégének logóját viselték - ennek ellenére a Talos kutató nem találtak bizonyítékot arra, hogy a PoetRAT malware-rel indiai célpontok ellen is bevetették volna.

Ami az ICS rendszerek világát illeti, a Talos elemzői szerint a PoetRAT mögött álló támadók kifejezett érdeklődést tanúsítanak a villamosenergia-szektor egyes azeri (különösképpen a szélerőművi turbinák vezérlésben használt) ICS rendszerek iránt.

A PoetRAT-ról és a támadókról további részleteket a Talos elemzésében lehet olvasni.