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

ICS Cyber Security blog

ICS Cyber Security blog

A Kaseya-incidens és annak tágabb összefüggései

2021. július 10. - icscybersec

Ismét mérföldkőhöz érkezett a blog, fennállása során először egynél több szerzője van a mai posztnak, a mai írást GéPé kollégával közösen követtük el.

Múlt héten pénteken a Miami székhelyű Kaseya VSA nevű felhős (Software-as-a-Service) megoldásán keresztül a REvil/Sodinokibi néven ismert, ransomware-ekkel operáló kiberbűnözői csoport több ezer, főként Nyugat-európai és amerikai vállalat rendszereit kompromittálta. Az érintett cégek között több Managed Service Provider (vagyis mások számára IT szolgáltatásokat biztosító) cég is megtalálható (az elérhető információk szerint a Kaseya SaaS-megoldását előszeretettel használják MSP-k), emiatt az érintett cégek pontos számát még most, egy héttel az incidens kirobbanása után sem könnyű még csak megbecsülni sem. 

Felmerülhet a kérdés, hogy mi köze van ennek az ICS rendszerekhez vagy úgy általában a fizikai folyamatokhoz? Nos, a támadás-sorozat egyik áldozata a svédországi Coop kiskerlánc, akiknek az üzleteikben (mintegy 500 szupermarketben) használt fizetési megoldásaik és önkiszolgáló kasszáik váltak használhatatlanná az incidens következtében - amikor pedig a lakossági élelmiszerellátásban fennakadásokat okoz egy ransomware-támadás, azt már (szerintem) tekinthetjük a kritikus infrastruktúra elleni támadásnak, még ha nem is bizonyítható, hogy ez lett volna a támadók kifejezett célja. Egy másik áldozat a szintén svéd államvasutak, szóval bár a közvetlen ICS érintettségről továbbra sincs információnk, ahogy azt a Colonial Pipeline incidens is megmutatta, nem csak a közvetlenül az ICS rendszereket érintő incidensek lehetnek elképzelhetetlenül káros hatással az általunk ismert civilizáció korábban megkérdőjelezhetetlen alapvetéseire (aki szerint ez erősen túlzó kijelentés, nézze csak meg azokat a felvételeket, amikor a Colonial Pipeline elleni ransomware-támadás utáni üzemanyaghiánytól félve egyes amerikai benzinkutaknál már nejlonzsákokba töltötték az üzemanyagot).

Több forrás szerint is a támadók a Kaseya egy 0-day sérülékenységét kihasználva indították el a mostani, tömeges fertőzéseket okozó kampányukat. Ezzel kapcsolatban az első érdekes kérdés, hogy vajon mennyire kell jól szervezettnek lennie egy szervezett bűnözői csoportnak, hogy egy ennyire összetett és jó koordinációs (már-már azt is mondhatnánk, jó projektmenedzseri) képességeket tudjanak felmutatni, ami ahhoz kell, hogy egy ilyen műveletet sikerre tudjanak vinni? Ilyet eddig csak APT-csoportoktól láttunk. Persze azt a lehetőséget sem szabad azonnal elvetnünk, hogy a 0-day és a szervezés mögött egy nemzetállami hátterű APT-csoport áll, a REvil/Sodinokibi csoport illetve a váltságdíj-követelés pedig csak a "front", a hihető tagadás álcája a némelyek által kiberháborúnak nevezett konfliktus-sorozat újabb állomásánál.

Ezzel az incidenssel viszont igazolódni látszik az a feltételezés, amiről néhány hete jelent meg poszt a blogon: még ha lesz is (akár bilaterális, akár globális) megállapodás arról, hogy milyen iparágakban, milyen szervezetek rendszereit nem szabad kibertámadásokkal zaklatni, egyes hatalmak könnyedén megtalálhatják a módot arra, hogy kiberbűnözői csoportok mögé bújva továbbra is támadásokat intézzenek akár a nemzeti kritikus infrastruktúrában megkerülhetetlen cégek rendszerei ellen. Mi fog történni akkor, ha ezek a cégek a mostanihoz hasonló, tömeges támadások kereszttüzében találják magukat? Képesek lesznek hatékonyan védekezni? Kapnak majd bármilyen támogatást az állami szervektől, különösen akkor, ha ezekhez az illetékes állami szervekhez órák vagy napok alatt több tucat vagy akár 100-200 hasonló segítségkérés fog befutni?

A SolarWinds/Orion után a Kaseya incidens megmutatta, hogy technológiailag nincs akadálya országos vagy akár több kontinensre kiterjedő és tömeges – azaz áldozatok százainak, vagy akár ezreinek működését megzavaró – támadások indításának. Nincs az az ország, amelynek illetékes szolgálatai és szakirányú vállalkozásai rövid időn belül képesek lennének egy ilyen masszív, tömeges támadás valamennyi áldozatának párhuzamos kezelésére, majd a biztonságos üzletmenet helyreállítására.

Márpedig amennyiben Kaseya VSA-felhasználói között véletlenül kritikus infrastruktúrák – de akár „csak” beszállítói, szolgáltatói – is szerepelnek, akkor az ő működési zavaruk előbb-utóbb a kritikus infrastruktúra működését is megakaszthatja. A kritikus infrastruktúrák összefüggéseinek egyik ismert ábrázolása szerint:

Ahogy a Colonial Pipeline incidens megmutatta, már egyetlen zsarolóvírus is elég volt az USA keleti parti üzemanyag ellátásának – és ezzel az üzemanyagfüggő ágazatoknak (pl. áruszállítás vagy légiközlekedés) – alapvető és több hetes megzavarásához. Az erőművek üzemanyagellátása a „megszokott” „csöves” helyett tartálykocsis szállítással volt fenntartható. Azaz bizonyos szempontból még az amerikai villamosenergia-rendszer beszállítói lánca is jelentős veszélyben forgott.

És gondoljunk bele: ez csak egyetlen céget érő egyetlen zsarolóvírus következménye volt.

Mi történne, ha egy SolarWinds/Kaseya-jellegű, de a kritikus infrastruktúrák szempontjából „fájóbban” célzott támadás történne?

Abban bízunk, hogy ez a gondolatsor illetékes hazai fejekbe is befészkeli magát…

Néhány szerintünk érdekesebb publikáció a Kaseya-incidensről az elmúlt egy hétből:

Kaseya helpdesk

TrendMicro

SecurityAffairs

TechCrunch

TheVerge

TheHackerNews

ICS sérülékenységek CCXCIV

Sérülékenységek Exacq Technologies, Panasonic, JTEKT, AVEVA, Claroty, Sensormatic Electronics, Johnson Controls, Delta Electronics, Mitsubishi Electric, Bachmann Electronic és ABB rendszerekben

XSS sérülékenységsk Exacq Technologies rendszerekben

Milan Kyselica és Roman Stevanak két XSS sérülékenységet jelentettek a Johnson Controls-nak az Exacq Technologies nevű leányvállalatuk alábbi termékeivel kapcsolatban:

- exacqVision Web Service 21.03 és korábbi verziói;
- exacqVision Enterprise Manager 20.12 és korábbi verziói.

A gyártó a hibákat az érintett terméekek újabb verzióiban javította. A sérülékenységekről további részleteket az ICS-CERT alábbi publikációiban lehet olvasni:

https://us-cert.cisa.gov/ics/advisories/icsa-21-180-01
https://us-cert.cisa.gov/ics/advisories/icsa-21-180-02

Panasonic rendszerek sérülékenysége

Michael Heinzl egy sérülékenységet jelentett a DHS CISA-nak, amit a Panasonic FPWIN Pro 7.5.1.1-es és korábbi verzióiban talált.

A gyártó a hibát a 7.5.2.0 verzióban javította. A sérülékenységgel kapcsolatos bővebb információkat az ICS-ERT bejelentése tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-21-180-03

Sérülékenység JTEKT PLC-kben

Chris Yang, a TXOne Networks munkatársa, a ZDI-vel együttműködve egy sérülékenységet jelentett a DHS CISA-nak, ami a JTEKT alábbi PLC-it érinti:

- PC10G-CPU;
- 2PORT-EFR;
- Plus CPU;
- Plus EX;
- Plus EX2;
- Plus EFR;
- Plus EFR2;
- Plus 2P-EFR;
- PC10P-DP;
- PC10P-DP-IO;
- Plus BUS-EX;
- Nano 10GX;
- Nano 2ET;
- PC10PE;
- PC10PE-16/16P;
- PC10E;
- FL/ET-T-V2H;
- PC10B;
- PC10B-P;
- Nano CPU;
- PC10P;
- PC10GE.

A gyártó a hibát javító újabb firmware-verziókat már elérhetővé tette. A sérülékenység részleteiről az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-180-04

AVEVA System Platform sérülékenységek

Sharon Brizinov, a Claroty munkatársa két sérülékenységről osztott meg információkat az AVEVA-val, amik a gyártó System Platform nevű termékének 2017-től 2020 R2 P01-el bezárólag minden verzióját érintik.

A gyártó a hibákat javító újabb verziót már elérhetővé tette illetve kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekkel kapcsolatos további információk az ICS-CERT publikációjában érhetőek el: https://us-cert.cisa.gov/ics/advisories/icsa-21-180-05

Claroty rendszerek sérülékenysége

Az Alphastrike Labs munkatársai egy sérülékenységet találtak a Claroty Secure Remote Access (SRA) Site 3.0-tól 3.2-ig terjedő verzióiban.

A gyártó a hibával kapcsolatban a 3.2.1-es verzióra történő frissítést javasolja. A sérülékenység részleteit az ICS-CERT bejelentése tartalmazza: https://us-cert.cisa.gov/ics/advisories/icsa-21-180-06

Sérülékenység Johnson Controls Faciliy Explorer rendszerekben

A Johnson Controls egy sérülékenységről közölt információkat a DHS CISA-val, amit a Faciliy Explorer SNC sorozatú Supervisory Controller-ek 11-es verziójában találtak.

A gyártó a hibát javító patch-et már elérhetővé tette. A sérülékenységről bővebben az ICS-CERT weboldalán lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-21-182-01

Sensormatic Electronics rendszerek sérülékenysége

A Johnson Controls, a Sensormatic Electronics anyavállalata egy sérülékenységet jelentett a DHS CISA-nak, amit a C-CURE 9000-esek minden, 2.80-asnál korábbi verzióját érinti.

A gyártó a hibával kapcsolatban a 2.80-as vagy újabb verzióra történő frissítést javasolja. A sérülékenységről további információkat az ICS-CERT publikációjában lehet találni: https://us-cert.cisa.gov/ics/advisories/icsa-21-182-02

Sérülékenység Delta Electronics DOPSoft szoftverekben

Natnael Samson, a ZDI-vel együttműködve két sérülékenységet jelentett a DHS CISA-nak, amiket a Delta Electronics DOPSoft nevű, a DOP-100-as HMI-okhoz használható szoftverének 4.0.10.17-es és korábbi verzióiban talált.

A gyártó a hibát javító újabb verziót már elérhetővé tette. A sérülékenység részleteit az ICS-CERT bejelentése tartalmazza: https://us-cert.cisa.gov/ics/advisories/icsa-21-182-03

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

Chizuru Toyama, a TXOne IoT/ICS Security Research Labs munkatársa egy sérülékenységet talált a Mitsubishi Electric alábbi rendszereiben és a ZDI-vel együttműködve jelentette a DHS CISA-nak:

Légkondícionáló rendszerek központi vezérlői:
- G-50A 2.50-estől 3.35-ig terjedő verziói;
- GB-50A 2.50-estől 3.35-ig terjedő verziói;
- AG-150A-A 3.20-as és korábbi verziói;
- AG-150A-J 3.20-as és korábbi verziói;
- GB-50ADA-A 3.20-as és korábbi verziói;
- GB-50ADA-J 3.20-as és korábbi verziói;
- EB-50GU-A 7.09-es és korábbi verziói;
- EB-50GU-J 7.09-es és korábbi verziói;
- AE-200A 7.93-as és korábbi verziói;
- AE-200E 7.93-as és korábbi verziói;
- AE-50A 7.93-as és korábbi verziói;
- AE-50E 7.93-as és korábbi verziói;
- EW-50A 7.93-as és korábbi verziói;
- EW-50E 7.93-as és korábbi verziói;
- TE-200A 7.93-as és korábbi verziói;
- TE-50A 7.93-as és korábbi verziói;
- TW-50A 7.93-as és korábbi verziói;
- CMS-RMD-J 1.30-as és korábbi verziói;
Légkondícionáló rendszerek bővítő vezérlői:
- PAC-YG50ECA 2.20-as és korábbi verziói.

A gyártó a hibákat javító újabb verziókat 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://us-cert.cisa.gov/ics/advisories/icsa-21-182-04

Mitsubishi Electric légkondícionálók sérülékenysége

Howard McGreehan, az Aon's Cyber Solutions munkatársa egy sérülékenységet jelentett a Mitsubishi Electric-nek, ami az alábbi termékeiket érinti:

Légkondícionáló rendszerek központi vezérlői:
- G-50A 3.35-ös és korábbi verziói;
- GB-50A 3.35-ös és korábbi verziói;
- GB-24A 9.11-es és korábbi verziói;
- AG-150A-A 3.20-as és korábbi verziói;
- AG-150A-J 3.20-as és korábbi verziói;
- GB-50ADA-A 3.20-as és korábbi verziói;
- GB-50ADA-J 3.20-as és korábbi verziói;
- EB-50GU-A 7.09-es és korábbi verziói;
- EB-50GU-J 7.09-es és korábbi verziói;
- AE-200A 7.93-as és korábbi verziói;
- AE-200E 7.93-as és korábbi verziói;
- AE-50A 7.93-as és korábbi verziói;
- AE-50E 7.93-as és korábbi verziói;
- EW-50A 7.93-as és korábbi verziói;
- EW-50E 7.93-as és korábbi verziói;
- TE-200A 7.93-as és korábbi verziói;
- TE-50A 7.93-as és korábbi verziói;
- TW-50A 7.93-as és korábbi verziói;
- CMS-RMD-J 1.30-as és korábbi verziói;
Légkondícionáló rendszerek bővítő vezérlői:
- PAC-YG50ECA 2.20-as és korábbi verziói;
Légkondícionáló rendszerek BM adapterei:
- BAC-HD150 2.21-es és korábbi verziói.

A gyártó a hibával kapcsolatos javítást tartalmazó újabb verziókat és kockázatcsökkentő intézkedésekre vonatkozó javaslatait már elérhetővé tette. A sérülékenység részleteit az ICS-CERT bejelentésében lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-21-182-05

Sérülékenység Bachmann Electronic rendszerekben

Az ICS-CERT bejelentése szerint egy, a Bachmann Electric termékeit érintő sérülékenységről hoztak nyilvánosságra részleteket. Érintett minden, M-Base operációs rendszert és middleware-t használó M1 hardveres vezérlő:

- MX207;
- MX213;
- MX220;
- MC206;
- MC212;
- MC220;
- MH230.

Érintettek továbbá az alábbi, már támogatásukat elvesztett modellek:

- MC205;
- MC210;
- MH212;
- ME203;
- CS200;
- MP213;
- MP226;
- MPC240;
- MPC265;
- MPC270;
- MPC293;
- MPE270;
- CPC210.

A gyártó a hibával kapcsolatban már elérhetővé tette a javítást tartalmazó új verziót (értelemszerűen csak a még támogatással rendelkező vezérlőkhöz). A sérülékenységekkel kapcsolatos további részleteket az ICS-CERT weboldalán lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-21-026-01-0

Sérülékenységek ABB rendszerekben

Az ABB publikációja szerint a Wibu CodeMeter licenc-szervert érintő sérülékenység megtalálhatóak az alábbi ABB termékekben:

- Automation Builder (AB) 2.4.1.1062 és korábbi verziói;
- Drive Application Builder (DAB) 1.1.1.631 és korábbi verziói;
- Virtual Drive 1.0.2.105 és korábbi verziói.

A hibákkal kapcsolatban a gyártó a Wibu CodeMeter V7.21a vagy későbbi verzióira történő frissítést javasolja. A sérülékenységről bővebben az ABB publikációjában lehet olvasni.

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.

Az ipari szervezetek egyre nagyobb hányada tapasztal kiberbiztonsági incidenseket

Fortinet, Mandiant és WhiteHat Security publikációk

A Fortinet idén év elején végzett, kifejezetten OT biztonsági felmérésének nemrég jelentek meg az eredményei.

A Fortinet összefoglalója szerint a válaszadó ipari szervezetek 90%-a tapasztalt kiberbiztonsági incidenseket 2020. során. Talán nem túl meglepő módon, a legtöbb incidens még mindig az adathalász-támadásokból ered és a különböző malware-ekhez kapcsolódó incidensek aránya is magas, még annak ellenére is, hogy a ransomware-támadásokat külön kategóriaként kezelték.

Tovább nőtt az IT-OT rendszerek és hálózatok összekapcsolása, immár az érintett szervezetek 70%-ánál megvalósul valamilyen szintű IT-OT konvergencia.

A felmérés részleteit a Fortinet weboldalán lehet megismerni.

Ezzel nagyjából párhuzamosan a FireEye-hoz tartozó Mandiant is publikált egy anyagot, amiben arról írnak, hogy az ICS rendszereket használó szervezeteket egyre inkább célba veszik az APT csoportoknál időnként kevésbé képzett kiberbűnözők is, akiknek nem feltétlenül az adott szervezeti fizikai folyamatirányításban használt rendszereinek (és ezen keresztül a fizikai folyamatok) megzavarása a célja, inkább csak a megtámadott cégektől kizsarolt pénz megszerzése a fontos számukra. Persze, ahogy a Colonial Pipeline és a JBS elleni ransomware-támadások esetében láttuk, akár még a célba vett szervezet működésének teljes leállásához is vezethet.

A Mandiant publikációja a témában itt érhető el.

A WhiteHat Security publikációjában azt emeli ki, hogy a közműszektorban működő cégek esetén egyre nő a sérülékenységi ablak (a sérülékenység publikálásától a javítás telepítéséig tartó időszak), ami jelenleg nagyjából 205 napra tehető. Ez a sérülékenységi ablak, illetve a növekedése egy nagyon fontos oka lehet annak, hogy mind több ipari szervezet tapasztal egyre súlyosabb ransomware- beszállítói lánc elleni és egyéb, alkalmazásokhoz köthető támadásokat.

ICS sérülékenységek CCXCIII

Sérülékenységek Advantech, CODESYS, FATEK és Philips rendszerekben

Advantech WebAccess sérülékenységek

Kimiya, a ZDI-vel együttműködve három sérülékenységről közölt információkat a DHS CISA-val, amiket az Advantech WebAccess HMI Designer 2.1.9.95-ös és korábbi verzióiban talált.

A gyártó jelenleg is dolgozik a hibák javításán. A sérülékenységekről bővebben az ICS-CERT publikációjában lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-173-01

Sérülékenységek CODESYS V2 web szerver sérülékenységek

Vyacheslav Moskvin, Sergey Fedonin és Anton Dorfman, a Positive Technologies munkatársai 6 sérülékenységet fedeztek fel a CODESYS alábbi termékeiben:

- CODESYS V2 web szerver standalone telepítései;
- a CODESYS V2 web szerver azon telepítései, amik a CODESYS runtime system 1.1.9.20-asnál korábbi verzióinak részeként működik.

A gyártó a hibát az 1.1.9.20-as verzióban javította. A sérülékenységek részleteiről az ICS-CERT bejelentéséből lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-21-173-02

CODESYS rendszerek sérülékenységei

Sergey Fedonin, Denis Goryushev és Anton Dorfman, a Positive Technologies munkatársai, illetve tőlük függetlenül Yossi Reuven, a SCADAfence munkatársa 3 sérülékenységet azonosítottak a CODESYS alábbi megoldásaiban:

- CODESYS Runtime Toolkit 32-bit v2.4.7.55-nél korábbi verziói;
- CODESYS PLCWinNT v2.4.7.55-nél korábbi verziói.

A hibákat a gyártó az érintett termékek újabb verzióiban javította. A sérülékenységekkel kapcsolatosan bővebb információkat az ICS-CERT weboldalán lehet találni: https://us-cert.cisa.gov/ics/advisories/icsa-21-173-03

Sérülékenység CODESYS V2 Runtime Toolkit rendszerekben

Sergey Fedonin és Ivan Kurnak, a Positive Technologies munkatársai egy sérülékenységet jelentettek a CODESYS-nek a V2 Runtime Toolkit nevű megoldásuk 32-bites kiadásának 2.4.7.55-ösnél korábbi verzióiban.

A gyártó a hibát a 2.4.7.55-ös verzióban javította. A sérülékenység részleteit az ICS-CERT publikációja tartalmazza: https://us-cert.cisa.gov/ics/advisories/icsa-21-173-04

FATEK WinProladder sérülékenységek

Michael Heinzl 3 sérülékenységet jelentett a DHS CISA-nak, amik a FATEK WinProladder nevű PLC-inek 3.30-as és korábbi verzióit érinti.

A gyártó jelenleg is dolgozik a hibák javításán. A sérülékenységekkel kapcsolatos bővebb információkat az ICS-CERT bejelenetésében lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-21-175-01

Sérülékenység Philips rendszerekben

A Philips egy sérülékenységről közölt információkat a DHS CISA-val, ami az Interoperability Solution XDS nevű rendszereük alábbi verzióit érinti:

- 2.5-től 3.11-ig terjedő verziók;
- 2018-1-től 2021-1-ig terjedő verziók.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről további részleteket az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsma-21-175-01

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.

Az orosz-amerikai elnöki csúcstalálkozó lehetséges hatásai a kritikus infrastruktúrák kiberbiztonságára

Az elmúlt két hétben a világpolitika kétségkívül legfontosabb és leginkább várt eseménye az orosz és amerikai elnökök svájci csúcstalálkozója volt. Ahogy előre lehetett sejteni, a megbeszélés csak egy lépés volt az utóbbi években nagyon megromlott amerikai-orosz kapcsolatok javítását célzó úton, a CyberScoop még előző szerdán megjelent cikke

https://www.cyberscoop.com/biden-putin-summit-russia-geneva/

alapján egy fontos megállapodás mégis született: Joe Biden felvetésére várhatóan tárgyalások fognak kezdődni abban a témában, hogy 16 kritikus infrastruktúra-szektor esetén a kibertámadásokat ne tekintsék lehetséges eszközöknek az államok közötti viták során.

A kezdeményezés nyilván jó, de én több okból is szkeptikus vagyok, hogy sikerül-e valódi eredményeket elérni ezen a téren.

1. A nemzetállami hátterű APT-csoportok által végrehajtott kibertámadások egyik legnagyobb előnye az adott állam számára a nagyon könnyű tagadhatóság, hiszen a támadók a legritkább esetben szoktak közvetlenül a saját szervezetük vagy országuk infrastruktúrájából támadásokat indítani, szinte mindig a célba vett ország vagy egy harmadik ország hálózatában kompromittált rendszerből indítják a támadásokat - ezért is olyan nehéz a támadók beazonosítása, az egyes támadói csoportokra jellemző attribútumok összeállítása és azokból történő következtetések levonása mára a threat intelligence-en belül is már-már külön tudományággá vált. Ez viszont azt is jelentheti, hogy míg az amerikai és orosz illetékesek hosszas tárgyalások után kidolgoznak valamilyen szabályrendszert, egyik vagy mindkét fél a kritikus infrastruktúrák elleni kibertámadások után a saját érintettségének letagadhatóságát kihasználva tovább folytatják ezeket az akciókat - vagyis lesz egy nagyon szép, nemzetközi szerződés, amit senki sem fog betartani.

2. Még ha ez a kétoldalú megállapodás meg is születik és a felek maradéktalanul be is tartják, akkor is van számos olyan további nemzetállam (Kína, Észak-Korean, Irán, Izrael és még sorolhatnánk), akik, ha nem tekintik az orosz és amerikai illetékesek által kidolgozott új szabályokat magukra kötelező érvényűnek, akkor nem lesz sokkal jobb helyzetben a kritikus infrastruktúrák kiberbiztonsága.

Félreértés ne essék, a kezdeményezés és hogy mindkét fél nyitottnak látszik egy ilyen szabályozásra, pozitív fejlemény, én azonban attól tartok, hogy egy ilyen megállapodás (még ha nem is csak bilaterális lesz, hanem pl. az ENSZ közgyűlése és a BT minden tagja ezt el is fogadja, mint a nemzetközi jog egyik modern sarokkövét) önmagában nem fogja megoldani az ICS kiberbiztonság sokasodó biztonsági kihívásaival küzdő kollégák mindennapos probémáit.

Kibertámadás érte a Dél-koreai Nukleáris Kutatóközpontot

Nemrég hozták nyilvánosságra, hogy kibertámadás érte a Dél-koreai Nukleáris Kutatóközpont (KAERI) rendszereit. A támadókat, (akiket természetesen ezúttal sem lehet minden kétséget kizárólag azonosítani) az incidens műszaki részleteinek ismeretében az Észak-koreai APT-csoportokhoz kapcsolhatónak tartják.

Felmerülhet a kérdés, hogy egy kutatóintézet elleni támadás miért érdemel külön posztot egy ICS biztonságra koncentráló blogon, de úgy gondolom, hogy nem igényel túl sok magyarázatot az, hogy az atomerőművek miért is az egyik (ha nem a) legkritikusabb komponensei az egyébként is a "legkritikusabb kritikus infrastruktúra" megnevezéssel is illetett villamosenergia-rendszernek.

Az első elemzések után napvilágot látott részletek alapján jelenleg úgy tűnik, hogy a támadók a korábban több gyártó (Juniper, Dell/SonicWall, Fortinet, Citrix) VPN-megoldásaiban talált sérülékenységeket kihasználva jutottak be a KAERI rendszereibe.

Az évek során számtalanszor írtam (és a kommentek között beszéltünk is) arról, hogy érthető módon az OT rendszerek és hálózatok esetében a feltárt (és publikált) sérülékenységek javítása nem a legfontosabb, de az OT hálózatokhoz Internet irányból hozzáféréseket biztosító IT rendszerek és komponensek esetén úgy gondolom, hogy még az átlagos nagyvállalati IT rendszerekénél is sokkal szigorúbb és gyorsabb(!) patch-menedzsment eljárásokat kéne alkalmazni.

ICS sérülékenységek CCXCII

Sérülékenységek Automation Direct, ThroughTek, Advantech és Softing rendszerekben

Sérülékenységek Automation Direct PLC-kben

Irfan Ahmed és Adeen Ayub, a Virginia Nemzetközösségi Egyetem és Hyunguk Yoo, a New Orleans-i Egyetem munkatársai 5 sérülékenységet jelentettek az Automation Direct-nek, amiket az alábbi termékeikben találtak:

- CLICK PLC CPU modulok C0-1x CPU-inak minden, v3.00-nál korábbi firmware-verziói.

A gyártó a hibákat a 3.00-ás firmware-verzióban javította. A sérülékenységekről további információkat az ICS-CERT publikációja tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-21-166-02

ThroughTek rendszerek sérülékenységei

A Nozomi Networks munkatársai egy sérülékenységet azonosítottak a ThroughTek P2P Software Development Kit alábbi verzióiban:

- 3.1.5 és korábbi verziók;
- nossl tag-gel rendelkező SDK verziók;
- azok a firmware-ek, amik nem használnak AuthKey-t az IOTC kapcsolatokhoz;
- azok a firmwarek-ek, amik az AVAPI modult DTLS nélkül használják;
- P2PTunnel-t vagy RDT modult használó firmware-ek.

A gyártó hibával kacsolatos ajánlásait és a sérülékenységgel kacsolatos további részleteket az ICS-CERT bejelentésében lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-21-166-01

Sérülékenységek Advantech WebAccess/SCADA rendszerekben

Chizuru Toyama, a TXOne IoT/ICS Security Research Labs munkatársa, a ZDI-vel együttműködve két sérülékenységet jelentett a DHS CISA-nak, amiket az Advantech WebAccess/SCADA 9.0.1 és korábbi verzióiban talált.

A gyártó jelenleg is dolgozik a hibákat javító újabb verzión. A sérülékenységekkel kapcsolatosan részletek az ICS-CERT weboldalán érhetőek el: https://us-cert.cisa.gov/ics/advisories/icsa-21-168-03

Softing SDK sérülékenység

Eran Jacob, az OTORIO munkatársa egy sérülékenységről tájékoztatta a DHS CISA-t, ami a Softing OPC UA C++ SDK 5.59-től 5.64-ig terjedő verzióit érinti.

A gyártó a hibát az 5.65-ös verzióban javította. A sérülékenység részleteiről az iCS-CERT publikációjában lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-168-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.

Kibertámadás érte egy kaliforniai vízmű ICS rendszereit

2021 nem az USA viziközmű cégeinek legjobb éveként fogja beírni magát a történelemkönyvekbe, már ami ezeknek a cégeknek az ICS rendszereit ért kibertámadásokat illeti. Február elején a floridai Oldsmar vízművének ICS rendszereit érte támadás, pénteken pedig egy kaliforniai viziközmű cég ICS rendszerei elleni, még januárban történt támadásról hoztak nyilvánosságra információkat.

Az eddig megismert részletek alapján nagyon úgy tűnik, hogy az Oldsmar-i esethez hasonlóan ebben az esetben is egy TeamView-er-elérést és egy, a cégnél már nem dolgozó korábbi munkatárs felhasználónevét és jelszavát használta fel a támadó. Szintén hasonló az eset az Oldsmar-i incidenshez abból a szempontból is, hogy a támadó ebben az esetben is módosította az ivóvízhez adagolt nátrium-hidroxid mennyiségét.

Lévén ez az incidens nagyon rövid idő alatt (gyakorlatilag 2-3 héten belül) a második (illetve kronológiailag ugye az első) volt az USA viziközmű vállalataival kapcsolatban, nagyon kíváncsi leszek, hogy az amerikai (szövetségi) döntéshozók mikor fognak valami NERC CIP-hez hasonló szabályozást hozni a viziközmű szektor cégeire vonatkozóan is.

ICS rendszereket támadó csoportok XIII

Kamacite

A Kamacite nevet a Dragos adta annak a csoportnak, ami feltételezéseik szerint kapcsolatba hozható (bizonyos szempontból átfedéseket mutat) a Sandworm néven elhíresült csoporttal, akiket többek között a 2015-ös és 2016-os ukrán villamosenergia-szektor elleni támadásokkal, valamint a Dél-koreai téli olimpiai játékok rendszerei és az USA-ban a Demokrata Párt 2016-os elnökválasztási kampánya és a DNC (a Demokrata Párt Nemzeti Kongresszusa) elleni támadásokkal.

A Dragos elemzése szerint a Kamacite néven hivatkozott csoport jó eséllyel egy több csoportból álló szervezet egyik része lehet és a szervezeten belül a célba vett ipari szervezetek rendszereiben történő kezdeti hozzáférések megszerzésére specializálódtak, főként adathalász és felhasználói adatok visszajátszása (credential replay) módszerek valamint egyedi malware-ek alkalmazásával, ezeket a hozzáféréseket pedig később átadják a szervezetükhöz tartozó más csoport(ok)nak, akik már kifejezetten az ICS rendszerek és az általuk felügyelt és irányított folyamatok megzavarásában érdekeltek.

A csoportról készített Dragos elemzés itt érhető el.

ICS sérülékenységek CCXCI

Sérülékenységek Siemens, Rockwell Automation, AGG Software, ZOLL és Schneider Electric rendszerekben

Siemens Simcenter Femap sérülékenységek

A ZDI két sérülékenységről osztott meg információkat a Siemens-szel, amiket a Simcenter Femap nevű termékük alábbi verzióiban találtak:

Simcenter Femap 2020.2 minden, V2020.2.MP3-nál korábbi verziója;
Simcenter Femap 2021.1 minden, V2021.1.MP3-nál korábbi verziója.

A gyártó a hibát az érintett termékek újabb verzióiban javította. A sérülékenységek részleteiről a Siemens ProductCERT publikációjában lehet olvasni.

NTP sérülékenységek Siemens SIMATIC NET rendszerekben

A Siemens ProductCERT bejelentése szerint korábban felfedezett NTP-sérülékenységek (szám szerint 15 sérülékenység) érintik a SIMATIC NET CP 443-1 OPC UA nevű termékük minden verzióját.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekkel kapcsolatban további információkat a Siemens ProductCERT bejelentésében lehet találni.

Sérülékenység Siemens rendszerekben

A ZDI segítségével a Siemens egy sérülékenységet azonosított az alábbi termékeikben:

- JT2Go minden, V13.1.0.3-nál korábbi verziói;
- Teamcenter Visualization minden, V13.1.0.3-nál korábbi verziói.

A gyártó a hibát a V13.1.0.3-as és későbbi verziókban javította. A sérülékenységről bővebben az Siemens ProductCERT weboldalán lehet olvasni.

Rockwell Automation FactoryTalk sérülékenység

A Rockwell Automation egy sérülékenységről tájékoztatta a DHS CISA-t, ami a FactoryTalk nevű platformjuk v6.11-es és korábbi verzióit érinti.

A gyártó a hibát a v6.20-as és későbbi verziókban javította és kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységgel kapcsolatos bővebb információk az ICS-CERT publikációjában érhetőek el: https://us-cert.cisa.gov/ics/advisories/icsa-21-161-01

Sérülékenységek AGG Web Server-ekben

Michael Heinzl két sérülékenységet jelentett a DHS CISA-nak, amit az AGG Software Web Server termékének v4.0.40.1014-es és korábbi verzióiban talált.

A gyártó a hibával kapcsolatban a 4.0.42 Build 512-re vagy későbbi verzióra történő frissítést javasolja. A sérülékenységekről további részleteket az ICS-CERT bejelentése tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-21-161-02

ZOLL defibrillátorok sérülékenységei

Egy névtelenségét őrző biztonsági kutató fél tucat sérülékenységről osztott meg információkat a DHS CISA-val, amiket a ZOLL Defibrillator Dashboard 2.2-esnél korábbi verzióiban talált.

A gyártó a hibákat a 2.2-es és újabb verziókban javította. A sérülékenységekről bővebben az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsma-21-161-01

Sérülékenység Schneider Electric Enerlin'X Com’X 510 eszközökben

Maxim Rupp egy sérülékenységet azonosított a Schneider Electric Enerlin’X Com’X eszközeinek V6.8.4-esnél korábbi verzióiban.

A gyártó a hibát a V6.8.4-es verzióban javította. A sérülékenységről bővebb információkat a Schneider Electric publikációja tartalmaz.

ISaGRAF sérülékenységek Schneider Electric IEC 61131-3 fejlesztő és tervező eszközökben

A Schneider Electric bejelentése szerint az alábbi termékeiket érintik a Rockwell Automation által publikált ISaGRAF sérülékenységek:

Easergy T300 V2.7.1 és korábbi verziói;
Easergy C5 1.0.x-nél korábbi verziói beágyazott ISaGRAF 5.2 és korábbi verziókkal;
MiCOM C264 D6.x-nél korábbi verziói beágyazott ISaGRAF 5.2 és korábbi verziókkal;
Minden, ISaGRAF 5.2 és korábbi verzióval telepített alábbi gateway-ek:
Windows:
− PACiS GTW 5.1
− PACiS GTW 5.2
− PACiS GTW 6.1
− PACiS GTW 6.3
− EPAS GTW 6.4
Linux:
− PACiS GTW 6.3
− EPAS GTW 6.4
- Saitel DP 11.06.21 és korábbi verziói;
- Saitel DR 11.06.12 és korábbi verziói;
- SCADAPack E 8.18.1 és korábbi firmware-verziói;
- SCADAPack Workbench 6.6.8 és korábbi verziói;
- SCD2200 10024-es és korábbi verziói;
- SAGE RTU
− C3414 CPU összes firmware-verziója;
− C3413 CPU összes firmware-verziója;
− C3412 CPU összes firmware-verziója.

A sérülékenységekkel kapcsolatos részleteket a Schneider Electric bejelentésében lehet találni.

Sérülékenységek Schneider Electric PowerLogic termékekben

Jacob Baines, a Dragos munkatársa 6 sérülékenységet talált, amik a Schneider Electric alábbi termékeit érintik:

- PowerLogic EGX100 minden verziója;
- PowerLogic EGX300 minden verziója;

A PowerLogic EGX100-as és EGX300-as termékek már elérték életciklusuk végét, így javítás sem várható a hibákkal kapcsolatban. A sérülékenységről bővebb információk a Schneider Electric weboldalán találhatóak.

Schneider Electric PowerLogic sérülékenységek

Ugyancsak Jacob Baines talált két sérülékenységet a PowerLogic termékcsalád alábbi tagjaiban:

- PM5560 V2.7.8-asnál korábbi verziói;
- PM5561 V10.7.3-nál korábbi verziói;
- PM5562 V2.5.4 és korábbi verziói;
- PM5563 2.7.8-nál korábbi verziói;
- PM8ECC minden verziója.

A gyártó a hibákat az érintett termékek újabb verzióiban javította (kivéve a PM5562 típusú berendezéseket, amikhez jelenleg is dolgoznak a javításon). A sérülékenységekkel kapcsolatban további információkat a Schneider Electric publikációja tartalmaz.

Siemens SIMATIC RFID olvasók sérülékenysége

A Siemens ProductCERT bejelentése szerint az alábbi termékeikben található hibát kihasználva össze lehet omlasztani az érintett berendezéseken futó OPC UA szolgáltatást:

- SIMATIC RF166C minden, V1.1-nél újabb és V1.3.2 korábbi verziója;
- SIMATIC RF185C minden, V1.1-nél újabb és V1.3.2 korábbi verziója;
- SIMATIC RF186C minden, V1.1-nél újabb és V1.3.2 korábbi verziója;
- SIMATIC RF186CI minden, V1.1-nél újabb és V1.3.2 korábbi verziója;
- SIMATIC RF188C minden, V1.1-nél újabb és V1.3.2 korábbi verziója;
- SIMATIC RF188CI minden, V1.1-nél újabb és V1.3.2 korábbi verziója;
- SIMATIC RF360R minden verziója>
- SIMATIC RF615R minden, V3.0-nál korábbi verziója;
- SIMATIC RF680R minden, V3.0-nál korábbi verziója;
- SIMATIC RF685R minden, V3.0-nál korábbi verziója.

A gyártó a hibát egyes érintett termékeinek V1.3.2-es verziójában javította. A sérülékenység részleteiről a Siemens ProductCERT bejelentéséből lehet tájékozódni.

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.

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