Egy viszonylag régi, de annál alaposabb cikket találtam a 2017-es, Szaúd-arábiai olajfinomító elleni kibertámadásról, ami később Triton/TriSIS néven vált ismertté.

A cikk alaposan bemutatja a megtámadott szaúdi olajcéget, a támadással gyanúsított iráni APT csoportot, a később felfedezett orosz kapcsolatot és a Dragos által feltárt, más célpontok ellen indított Triton/TriSIS támadásokat is.

Bár a cikkben sok új információt nem lehet olvasni, én korábban még nem találkoztam hasonlóan alapos írással, ami ezt az incidenst foglalná össze, ezért mindenképp hasznosnak tartom és érdemesnek egy olvasásra.

Sérülékenységek Honeywell MAXPRO rendszerekben

Joachim Kerschbaumer két sérülékenységet talált a Honeywell alábbi, videómenedzsmentre használt rendszereiben:

- HNMSWVMS VMS560 Build 595 T2-Patch-nél korábbi verziói;
- HNMSWVMSLT VMS560 Build 595 T2-Patch-nél korábbi verziói;
- MAXPRO NVR XE NVR 5.6 Build 595 T2-Patch-nél korábbi verziói;
- MAXPRO NVR SE NVR 5.6 Build 595 T2-Patch-nél korábbi verziói;
- MAXPRO NVR PE NVR 5.6 Build 595 T2-Patch-nél korábbi verziói;
- MPNVRSWXX NVR 5.6 Build 595 T2-Patch-nél korábbi verziói.

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

Sérülékenységek GE orvostechnikai eszközökben

Elad Luz, a CyberMDX munkatársa 6 sérülékenységről közölt információkat a DHS CISA-val, amik a GE alábbi orvostechnikai rendszereit érintik:

- ApexPro Telemetry Server 4.2 és korábbi verziói;
- CARESCAPE Telemetry Server 4.2 és korábbi verziói;
- Clinical Information Center (CIC) 4.X és 5.X verziói;
- CARESCAPE Telemetry Server 4.3-as verziója (a CVE-2020-6962 és CVE-2020-6961 sérülékenységek érintik);
- CARESCAPE Central Station (CSCS) 1.X verziói;
- CARESCAPE Central Station (CSCS) 2.X verziói (a CVE-2020-6962 és CVE-2020-6964 sérülékenységek érintik);
- B450 2.X verziói (a CVE-2020-6962 és CVE-2020-6965 sérülékenységek érintik);
- B650 1.X verziói (a CVE-2020-6962 és CVE-2020-6965 sérülékenységek érintik);
- B650 2.X verziói (a CVE-2020-6962 és CVE-2020-6965 sérülékenységek érintik);
- B850 1.X verziói (a CVE-2020-6962 és CVE-2020-6965 sérülékenységek érintik);
- B850 2.X verziói (a CVE-2020-6962 és CVE-2020-6965 sérülékenységek érintik).

A sérülékenységekkel kapcsolatban a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja, a hibákat javító újabb verziókról jelenleg nincs elérhető információ. A sérülékenységekről bővebb információk az ICS-CERT bejelentésében találhatóak: https://www.us-cert.gov/ics/advisories/icsma-20-023-01

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.

Az IT kontra OT téma a 2018 elején megrendezett S4 konferencia óta az egyik népszerű vitája az ICS biztonsági közösségnek, én is többször írtam erről a blogon és a visszajelzések szerint ez az egyik leginkább érdekes téma.

Még novemberben Joe Slowik, a Dragos egyik veterán elemzője (aki, mint oly sokan az amerikai ICS bizotnsági közösségből, hosszabb időt töltött el a fegyveres erők - Joe esetében az amerikai haditengerészet - kötelékében) írt egy hosszabb blogbejegyzést a témában.

Ebben az írásban Joe (akivel október végén volt lehetőségem röviden személyesen is beszélgetni) a tőle megszokott stílusban, az elmúlt évek fontosabb ICS biztonsági incidensein (Industroyer/CrashOverride, Triton/TRISIS és a 2015-ös ukrán incidens) keresztül mutatja be, hogy szerinte miért rossz megközelítés, ha valaki választani akar az IT és az OT között, amikor az ICS biztonsági kihívások kezelésének módját keresi.

Kíváncsi vagyok, a hazai színtéren ki és mikor fog végre előrelépni és a hazai szakmai körök elé tárni a véleményét a témában? Én ugyan szívesen leírom a véleményemet erről (is), de úgy, hogy alig érkezik visszajelzés, vitáról nehéz beszélni. Pedig a vita jó (lenne), mert új gondolatokat, ötleteket szülhet, amiből mind profitálhatnánk.

Sérülékenység GE PACSystems RX3i termékekben

Jin Kyung Lee és Yeop Chang of NSR (National Security Research Institute) munkatársai egy sérülékenységet találtak a GE PACSystem alábbi termékeiben és verzióiban:

- CPE100: minden, R9.85-ösnél korábbi verzió;
- CPE115: minden, R9.85-ösnél korábbi verzió;
- CPE302: minden, R9.90-nél korábbi verzió;
- CPE305: minden, R9.90-nél korábbi verzió;
- CPE310: minden, R9.90-nél korábbi verzió;
- CRU320: (a termék elérte életciklusa végét, a gyártó javasolja a CPE330-asra történő váltást);
- CPE330: minden, R9.90-nél korábbi verzió;
- CPE400: minden, R9.90-nél korábbi verzió;
- CPL410: minden, R9.90-nél korábbi verzió.

A hibával kapcsolatban a gyártó a legújabb elérhető firmware-verziókra történő frissítést javasolja. 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-014-01

Siemens SINEMA szerverek sérülékenysége

Antonin Rahon, az Agilicom munkatársa egy sérülékenységet fedezett fel a Siemens SINEMA Server nevű hálózatmenedzsment megoldásának minden, 14.0 SP2 Update 1-nél korábbi verziójában.

A gyártó a hibát javító új verziót már elérhetővé tette. A sérülékenységgel kapcsolatban további részleteket a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet találni.

Sérülékenység Siemens SCALANCE X hálózati eszközökben

Maxim Rupp egy sérülékenységet azonosított a Siemens SCALANCE X ipari switcheinek alábbi változataiban:

- SCALANCE X-200RNA termékcsalád minden verziója;
- SCALANCE X-300 termékcsalád (beleértve a SIPLUS NET változatokat is) minden, 4.1.3-nál korábbi verziója;
- SCALANCE X-408 minden, 4.1.3-nál korábbi verziója.

A gyártó a hibával kapcsolatban a SCALANCE X-200RNA termékcsalád tagjait használó ügyfeleinek kockázatcsökkentő intézkedések alkalmazását, az X-300-as és X-408-as termékcsaládok tagjaihoz pedig firmware-frissítés telepítését javasolja. A sérülékenységről bővebb információk a Siemens ProductCERT és az ICS-CERT weboldalain érhetőek el.

Siemens SINAMICS PERFECT HARMONY sérülékenység

A Siemens egy sérülékenységet jelentett a DHS CISA-nak, ami az alábbi feszültségszabályozó termékeiket érinti:

A SINAMICS PERFECT HARMONY GH180 típusú berendezések MLFB 6SR32-vel, MLFB 6SR4-gyel és MLFB 6SR5-tel kezdődő sorozatainak (utóbbinak az A30-as opcióval és 12 colos vagy nagyobb HMI-vel szerelt változatai) minden verziója, valamint az MLFB 6SR325-tel kezdődő sorozatának nagy rendelkezésre állást (HA) biztosító változatainak minden verziója.

A gyártó a hibához kapcsolódóan kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenység részleteiről a Siemens ProductCERT és az ICS-CERT publikációiban lehet olvasni.

Siemens TIA Portal sérülékenység

William Knowles, az Applied Risk munkatársa egy sérülékenységet talált a Siemens TIA Portal alábbi verzióiban:

- TIA Portal v14 minden verziója;
- TIA Portal v15 minden, v15.1 Upd 4-nél korábbi verziója;
- TIA Portal v16 minden verziója.

A gyártó a hibát a V15.1 Upd 4 verzióban javította és kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről bővebben a Siemens ProductCERT és az ICS-CERT bejelentéseiből lehet tájékozódni.

OSISoft PI Vision sérülékenységek

Az OSISoft négy sérülékenységet fedezett fel és jelentett a DHS CISA-nak, amik az alábbi termékeiket érintik:

- PI Vision 2019-nél korábbi összes verziója;
- PI Vision 2017 R2 és PI Vision 2017 R2 SP1;

A gyártó a hibákat a PI Vision 2019-es verziójában javította. A sérülékenységekkel kapcsolatban további részleteket az ICS-CERT weboldalán lehet elérni: https://www.us-cert.gov/ics/advisories/icsa-20-014-06

Sérülékenység Schneider Electric Modicon PLC-kben

Younes Dragoni, a Nozomi Networks munkatársa három sérülékenységet azonosított a Schneider Electric alábbi termékeiben:

- Modicon M580 minden, v2.80-nál korábbi firmware-verzió;
- Modicon M340 minden, v3.01-nél korábbi firmware-verzió;
- Modicon Premium minden, v3.20-nál korábbi firmware-verzió;
- Modicon Quantum minden, v3.60-nál korábbi firmware-verzió; (a háromból két sérülékenység csak a v3.52-nél korábbi verziókat érintik).

A gyártó a hibákat javító firmware-verziókat már elérhetővé tette a weboldalán. A sérülékenységekről részletek az ICS-CERT bejelentésében találhatóak: https://www.us-cert.gov/ics/advisories/icsa-20-016-01

Schneider Electric MSX Configurator sérülékenység

Yongjun Liu, az nsfocus munkatársa egy sérülékenységet jelentett a Schneider Electric-nek, ami az MSX Configurator V1.0.8.1-nél korábbi verzióit érinti.

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

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.

Január 6-án Joe Weiss az Unfettered blogon egy hosszabb posztban foglalta össze az ICS biztonság elmúlt két évtizedével kapcsolatos gondolatait. Ennek olvasása közben merült fel bennem a gondolat, hogy melyik megközelítésnek milyen előnyei és hátrányai lehet az ICS biztonság fejlesztése során?

Nem titok (hiszen én is többször írtam erről), hogy (főként az USA-ba) meglehetősen heves vita zajlik arról, hogy az ICS biztonság fejlesztése során hova kell, hova célszerű helyezni a hangsúlyt. Vannak, akik az OT hálózatok és rendszerek biztonságát tekintik elsődlegesen védendőnek és vannak mások (elsősorban, de nem kizárólag Joe), akik szerint az OT hálózatok mellett (időként helyett) a hangsúlyt főként az automatizálási eszközök biztonságára kellene helyezni és erősen helytelenítik, hogy ebben a kérdésben az elmúlt két évtizedben nem igazán történt előre lépés.

Az én személyes véleményem a témában az, hogy az OT hálózatok és eszközök biztonságának javítására több okból is célszerű jelentős erőforrásokat fordítani. Egyrészt ezek a rendszerek/hálózatok sokkal jobban hasonlítanak a hagyományos, nagyvállalati IT rendszerekre, így (bizonyos egyedi jellemzőket szem előtt tartva) sok IT biztonsági megoldás kisebb-nagyobb változtatásokkal használható az OT rendszerekben és hálózatokban is. Ezzel szemben az automatizálási eszközök, bár sok esetben az IT-ban megszokott komponensekhez többé vagy kevésbé hasonló komponensekből épülnek fel, mégsem egyszerű a hagyományos IT biztonsági megoldások implementálása (pl. a szűkre szabott erőforrások nem teszik lehetővé végpontvédelmi megoldás telepítését, stb.).

A másik ok pedig az, hogy ha az eddig nyilvánosságra került incidenseket vizsgáljuk, akkor elég jól lehet látni, hogy a legnagyobb kockázatokat jelentő, szándékos támadások a legtöbb esetben az Internetről érkezve, az IT és OT rendszeken keresztül jutott el az automatizálási eszközök (level1/level0 eszközök) szintjére és okozott kárt ezekben az eszközökben vagy az általuk vezérelt folyamatokban. Még a Stuxnet is, ami mind a mai napig az egyik legkinomultabb ICS rendszerek elleni támadásként van nyilvántartva, az OT hálózat irányából jutott el a fizikai folyamatokat közvetlenül irányító berendezésekig.

Ezzel nyilván nem azt mondom, hogy Joe Weiss téved, sőt. Biztos, hogy Joe-nak is igaza van és a level1/level0 eszközök biztonságán is dolgozni kell, de azt is gondolom, hogy ez egy jóval lassabb folyamat lesz, időnk pedig nem igazán van, tehát mindent meg kell tennünk a ma ismert civilizációnk alapjait képező rendszerek megvédése érdekében. Ezen az úton szerintem a leggyorsabban a legnagyobb javulást az ipari szervezetek IT és OT rendszereinek és hálózatainak védelmét fokozva érhetjük el, közben pedig az IT, IT biztonsági és OT szakemberek közötti együttműködés javításával meg kell teremtenünk a level1/level0 eszközök biztonsági szintjének javításához a lehetőségeket.

Ami engem igazán érdekelne, hogy mi a véleménye erről a témáról a hazai szakmának?

A MITRE által összeállított és karbantartott ATT&CK keretrendszer az elmúlt években kvázi szabvánnyá vált a kiberbiztonsági szektorban a támadók viselkedésének és tevékenységeinek osztályozásában, ennek a tudásbázisnak az ICS rendzserekre szabott változatát adták ki a hét első napjaiban.

A tudásbázis központi eleme egy mátrix, ami az ismert, ICS rendszerek elleni támadások során használt TTP-kből (Tools, Technics, Procedures) építkezik és tartalmaz egy kategorizálást is a különböző ICS eszközökre vonatkozóan.

Az ATT&CK for Industrial Control Systems szabadon elérhető a MITRE weboldalán.

Ahogy látom, az ICS biztonsági szakma meglehetősen lelkesen vette tudomásul az új ATT&CK verziót, számos IT és/vagy ICS biztonsági oldalon írtak róla és a Dragos január 14-én egy webinart is rendez, közösen a MITRE egyik munkatársával.

Azzal, hogy az elmúlt egy hétben megint a világ egyik legfontosabb témájává vált az amerikai-iráni viszony és feszültség, engem is megkerestek azzal a kérdéssel, hogy ennek lehet-e hatása a kritikus infrastruktúrák illetve más ICS rendszerek kiberbiztonságára. Ahogy a hírekben olvasható volt, többen számítottak arra, hogy Szulejmáni tábornok halálát az irániak nem (vagy nem csak) fizikai támadásokkal próbálják majd megbosszulni, hanem a kibertérben is támadásokat indítanak egyes amerikai kritikus infrastruktúra elemek ellen. Olyannyira komoly fenyegetésként kezelték/kezelik ezt a lehetőséget, hogy konkrétan tudok olyan európai közműszolgáltatóról, ahol ennek nyomán magasabb szintre emelték a készenlétet.

Mivel sok időm erre a posztra sajnos nincs, ezért csak két dologra térnék ki részletesebben:

1. Az iráni bosszúhadjárat gyakorlatilag már az Irakban található, amerikai haderő által is használt légibázisok elleni rakétatámadások előtt megindult, de amerikai kormányzati szervek (pl. a Federal Depository Library Program) weboldalai ellen indított deface-támadások valószínűleg inkább írhatóak az iráni hazafias hackerek számlájára, mint az iráni hátterű APT-csoportokéra (amikből szintén akad néhány, pl. a Magnallium/APT33).

Az ilyen támadások véleményem szerint, bár nyilván problémát jelentenek, egy ország szempontjából nem minősülnek komoly támadásnak, inkább arra jók, hogy a másik oldal (ebben az esetben Irán) fel tudjon mutatni valamilyen gyors és kockázatmentes választ, ami javítja a morált és minimálisan megfelel a tömegek feltüzelt bosszúvágyának).

2. A kritikus infrastruktúrák/ICS rendszerek elleni támadások szerintem nem valószínű, hogy (ha egyáltalán lesznek) az elkövetkező napokban fognak bekövetkezni. Egy ICS rendszer elleni támadás (az eddig tapasztalatok alapján) minden esetben hosszú hónapok előkészítő munkáját igénylik (emlékeztetőül, az ICS Cyber Kill Chain két fázisa külön-külön is több hetes, hónapos műveleteket jelenthetnek), ezért én két forgatókönyvet tudok elképzelni. Az első szerint az iráni APT-csoportok már hosszabb ideje hozzáféréseket szereztek egyes amerikai kritikus infrastruktúrák rendszereihez és ezeket felhasználva nagyon gyorsan képesek megszervezni és kivitelezni az ICS rendszerek (és/vagy az általuk vezérelt fizikai folyamatok) elleni támadásokat. A második forgatókönyv pedig az, hogy most kezdik el célzottan felderíteni az általuk fontosnak tartott és támadni kívánt rendszereket, ebben az esetben azonban hónapok vagy akár évek múlva számíthatunk komolyabb zavarokat okozó eseményekre. Én személy szerint inkább ez utóbbira számítok.

Ahogy Magyarországon, úgy az USA-ban is sok helyen cikkeztek a témáról a sajtóban, a SecurityWeek cikkében nyolc szakértő (a CyberX, a Dragos, a Nozomi Networks, a CrowdStrike, a Claroty, a Synopsys CyRC és a Lastline munkatársait) véleményét foglalja össze.

Sérülékenység Moxa berendezésekben

Dove Chiu, Philippe Lin, Charles Perine, Marco Balduzzi, Ryan Flores és Rainer Vosseler, a TrendMicro munkatársai egy Command Injection sérülékenységet fedeztek fel a Moxa MGate 5105-MB-EIP sorozatú eszközeinek 4.1-es és korábbi firmware-verzióiban.

A gyártó a hibát javító új firmware-verziót már elérhetővé tette. A sérülékenység részleteiről a Moxa weboldalán lehet olvasni.

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 elmúlt időszakban többször is felmerült körülöttem a kérdés, hogy az IT és az ICS biztonság helyileg hova kéne, hogy tartozzon egy adott (ipari) szervezeten belül, ezért úgy határoztam, hogy egy posztban összefoglalom az ezzel a kérdéssel kapcsolatos gondolataimat, épp csak annyira, hogy elkezdődhessen egy diskurzus a témáról.

Kezdjük talán az IT biztonsági szakterülettel. Amennyire én látom, jellemzően két megközelítés létezik a szakmában azzal kapcsolatban, hogy az IT biztonsági szakemberek szervezetileg hova tartoznak. Az első szerint az IT vezető irányításával dolgoznak, ezek a szervezetek az IT biztonságot is főként az IT egy területeként fogják fel (mint az adatközponti üzemeltetést, alkalmazásfejlesztést vagy a felhasználók támogatását). Amennyire én ezt átlátom a saját tapasztalataim szerint, az ilyen szervezetekben az IT biztonság esetén a fő hangsúly a különböző biztonsági rendszerek (tűzfalak, spamszűrők, végpontvédelmi megoldások, stb.) üzemeltetésén van és az operatív feladatok jellemzően kisebb fontossággal léteznek. Ez (bár szerintem helytelen) nem annyira meglepő, hiszen az IT vezetők az esetek döntő többségében üzemeltetői és/vagy fejlesztői múlttal és tapasztalatokkal rendelkeznek, a biztonsági műveleti feladatok tőlük kicsit távolabb állnak. A másik megközelítés szerint az IT biztonsági szakterület a biztonsági vezetőhöz tartozik (együtt a fizikai, szervezeti/humán biztonsági és egyéb biztonsági témákkal). Az ilyen esetek talán még összetettebbek, mert az esetek döntő többségében a biztonsági vezetőnek fizikai biztonsági tapasztalatai vannak (jellemzően valamilyen rendvédelmi vagy katonai múlttal rendelkező emberek), viszont a logikai biztonság témáját általában kevésbé ismerik. Ilyen esetekben a műveleti feladatok erősebbek lehetnek, viszont az IT biztonsági rendszerek üzemeltetési kérdései nagyobb kihívásokat jelenthetnek és az IT üzemeltetőkkel történő együttműködés is komolyabb kihívásokat jelenthet.

Az ICS biztonság, mint szakterület a fentiekhez hasonlóan többnyire kétféle megvalósításban szokott létezni - legalábbis amennyire én ezt látom a szakmán belül. Az egyik szerint az ICS biztonságnak az IT biztonsághoz kell tartoznia (akik emellett érvelnek, többnyire az IT rendszerek és komponensek OT-n belüli térhódításával érvelnek), a másik szerint pedig az ICS biztonságnak az IT biztonsággal párhuzamosan kell léteznie, de az OT szakterületen belül, hiszen az ICS biztonság megfelelő minőségben történő megvalósításához és működtetéséhez elengedhetetlen az OT minél alaposabb ismerete.

Az én véleményem az, hogy ezek a megközelítések még mindig a régi, hierarchikus szervezeti felépítésekben gyökereznek, ami megakadályozza azt, hogy az ICS (és az IT) biztonság egy olyan szolgáltatása legyen az adott szervezetnek, ami átfogóan képes kezelni bármilyen irányból (legyen az fizikai, humán, IT vagy OT) irányból érkező fenyegetést. Kiemelten fontosnak tartom, hogy a különböző ipari szervezetek minél előbb számoljanak le a silós működési modellel a biztonság területén és kezdjenek megvalósítani egyfajta mátrix-szerű működést ebben a témában. Ehhez elsősorban megint a kommunikációra kell helyezni a hangsúlyt és komoly erőfeszítéseket kell tenni a többi szakterület kihívásainak és prioritásainak megismerésére.

Ki mit gondol erről a témáról?

A Chaos Computer Club évenként megrendezett konferenciájáról az elmúlt években többször is írtam már a blogon.

Az idén is megrendezett konferencián (sorrendben immár a 36-on, vagyis a 36c3-on) a Kaspersky Lab munkatársai tartottak előadást a nemrég publikált (én pedig itt írtam róla röviden), erőművi turbinavezérlésre használt Siemens SPPA-T3000 rendszerek sérülékenységéről.

Az előadás diái PDF-formátumban itt található.

Szerk: Időközben a SCADA Strangelove oldalán megjelent az előadás felvétele is néhány egyéb apróság (pl. dissector az SPPA-T3000 alkalmazás szerver kommunikációhoz) társaságában.