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

Üzemeltetés kontra biztonság

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

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

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

Fejlesztés kontra biztonság

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

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

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

Joe Weiss ma megjelent blogposztjában részletesen áttekinti a december 23-i, nyugat-ukrajnai áramszünetet okozó kibertámadáshoz használt Blackenergy malware-ről eddig megtudott részleteket. Meglehetősen nyugtalanító megállapításai vannak azzal kapcsolatban, hogy a Blackenergy nyomait az USA villamosenergia-rendszereiben is több helyen beazonosították és felteszi a kérdést, hogy ha a decemberi ukrajnai támadás valójában üzenet volt a támadók részéről ("Látjátok, bármikor képesek vagyunk kiütni a kritikus rendszereiteket?"), akkor vajon kinek vagy kiknek szánták a figyelmeztetést?
 
 Amit egyelőre nem tudunk, az az, hogy pontosan hogyan okoztak áramkimaradást a támadók? A Blackenergy, a KillDisk és más malware-ek, amik az elmúlt években többek között a villamosenergia-rendszert vették célba (pl. a Havex.A) jellemzően információgyűjtésre és/vagy rombolásra specializálódtak, nem pedig arra, hogy módosítsák a kritikus infrastruktúrák működését. Felmerül a kérdés, hogy vajon a támadók már évek óta hozzáférnek a kritikus infrastruktúrákat vezérlő ICS rendszerekhez és az eltelt időt arra használták, hogy tanuljanak és tapasztalatokat szerezzenek a rendszerek működési sajátosságairól (ahogyan erről a tavalyi Hacktivity-n Marina Krotofil kiváló előadást tartott)?

A helyzet annyiban még rosszabb, hogy bár vannak olyan szabványok (többek között a NERC CIP, ezekről valamikor majd részletesebb áttekintést tervezek), amik pont a kritikus infrastruktúrák biztonságának fejlesztésére fókuszálnak, sajnos az ezeknek való megfelelés gyakorlatilag nem jelent semmit. Ahogy Joe is megemlíti a blogbejegyzésben, a tavaly októberi ICS Cyber Security konferencián volt egy előadás, ahol a Washington állami Nemzeti Gárda és a Snohomish Public Utility Department mutatta be azokat a tapasztalatokat, amiket a közösen végrehajtott penetration teszt során gyűjtöttek. Nos, NERC CIP-nek minden szempontból megfelelő közműszolgáltató rendszerébe a Nemzeti Gárda kiberbiztonsági szakemberei kevesebb, mint 30 perc alatt törtek be...

A jelek szerint szembe kell néznünk azzal a ténnyel, hogy a Stuxnet nyilvánosságra kerülése óta eltelt időben a kritikus infrastruktúrákat kiszolgáló informatikai rendszereket üzemeltetők és azok biztonságáért felelős emberek és szervezetek nem tudtak felnőni az új helyzet jelentette kihívásokhoz. Sem az USA-ban, sem Európában nem jól használták fel az eltelt több, mint 5 évet. Tartok tőle, hogy a jövőben több hasonló esetre lehet számítani, mielőtt a felelős (állami) döntéshozók végre érdemi lépéseket tennének a helyzet javítására.

A december 30-án napvilágot látott, ukrán villamosenergia-rendszer elleni kibertámadással kapcsolatos legújabb fejlemény, hogy Robert M. Lee, a SANS ICS biztonsági képzéseinek oktatója blogjában megjelent írása alapján a SANS szerzett egy mintát az ukrán áramszolgáltatók elleni támadáshoz használt malware-ből. Robert egy hosszabb blogposztban veszi sorra a tényeket, feltételezéseket és következtetéseket, illetve egy nagyon rövid, statikus elemzést is közread a malware-ről.

Az első vizsgálatok alapján a malware egy 32 bites Windows program és feltételezik, hogy egy komplex malware egyik modulja lehet. A SANS munkatársai a kapott minta elemzésébe több, különböző helyen dolgozó szakembert vontak be, így valószínű, hogy rövidesen részletes elemzések fognak megjelenni a témában.

További részletekért érdemes figyelemmel kísérni a SANS ICS blogját.

Ebben a posztban a ICS rendszerek biztonsági problémáinak általános áttekintését kezdem el. A tervek szerint ez egy több részes sorozat lesz - ebből is látható, hogy a ICS rendszerekkel bőven van probléma.

Protokollok biztonsági problémái

Ahogy a korábbi három posztban ismertetett, ICS rendszerekben használt protokolloknál lehet látni, ezek rendszerek gyakran évtizedekkel ezelőtt kidolgozott protokollokat használnak a mindennapi működésük során. Ezeknek a protokolloknak egy jelentős hányadát (elsősorban a ICS-specifikus protokollokat) jellemzően nem nyílt hálózatokon történő használatra tervezték, ezért ezek szinte soha nem tartalmaznak biztonsági funkciókat. Például a Modbus és a Modbus/TCP protokollok nem ismerik a felhasználónév/jelszó vagy bármilyen más authentikációs forma használatát a ICS szerver és a PLC/RTU közötti kommunikáció során, vagyis ha valaki kommunikálni tud egy Modbus szerverrel vagy klienssel és ismeri a megfelelő parancsokat, akkor irányítani is tudja az adott eszközt. Ez a legtöbb, hasonló korú ICS protokoll esetén sincs másként. Ez a probléma később még vissza fog térni néhányszor, nemzetközi ICS-biztonsági körökben a ICS rendszerek egyik fő ismérve, hogy nincs semmilyen authentikáció.

Jelszóproblémák

Ahogy a protokolloknál már érintettük, a ICS rendszerek egyik gyenge pontja az authentikáció (ami gyakran teljesen hiányzik a rendszerből), még akkor is, ha maga az authentikáció lehetőség adott. Nem ritka, hogy egyes (jellemzően távoli eszközökön, RTU-kon, PLC-ken) egy adott felhasználóhoz (akár root/adminisztrátor felhasználói fiókhoz is!) nincs jelszó beállítva, ha pedig van az adott fióknak jelszava, akkor az jellemzően könnyen kitalálható/törhető. Ha pedig ritka kivételként az üzemeltetők jó jelszót adtak meg, a legtöbb ICS rendszer esetén azt is pillanatok alatt meg lehet szerezni, hiszen ahogy a protokollokat tárgyaló korábbi részekből látni lehet, a ICS rendszerek elvétve használnak titkosított protokollokat, így az összes jelszó plain text formában utazik a hálózaton.

A ICS rendszerek életciklusa

Aki informatikai területen dolgozik (legyen akár üzemeltető, akár fejlesztő vagy bármilyen más terület szakértője), biztosan találkozott már az SDLC rövidítéssel, ami a szoftver-/rendszerfejlesztési életciklust jelöli. ICS rendszerek esetén az SDLC egy ciklusa sokkal nagyobb időtávot, gyakran évtizedeket ölel fel, szemben az általános informatikai gyakorlattal, ami napjainkra egyre gyorsuló ciklusokkal dolgozik (elég csak megnézni a népszerű böngészőprogramok vagy Linux-disztribúciók kiadási ütemét).
Egy ICS rendszer teljes életciklusa akár 20-30 év is lehet, ez azonban azt jelenti, hogy míg egy tervezési hibát egy átlagos szoftver vagy rendszer esetén a következő verzióban viszonylag gyorsan (akár napokon belül) lehet javítani. Ugyanez egy ICS rendszernél jobb esetben is hónapokat, rosszabb esetben akár éveket is igénybe vehet és eközben a rendszert napi szinten, gyakran 7/24-es üzemben kell használni olyan környezetben, ahol egy ismert hibát kihasználva a támadók jelentős anyagi károkat okozhatnak vagy akár emberéleteket veszélyeztethetnek.

Sajnálatos módon nagyon sokáig ez igaz volt a ICS rendszerek komponenseiben talált hibák javítására is. A Stuxnet előtt csak elvétve telepítették a ICS rendszerekre azokat az operációs rendszereket és adatbázisokat érintő hibajavításokat, amik minden más rendszer esetén az üzemeltetői rutin részeként kezelnek már több, mint egy évtizede. A Stuxnet okozta megrázkódtatás után egyes ICS rendzsereket fejlesztő cégek változtattak a korábbi hozzáállásukon és ma már készek (egy, más rendszerekéhez képes lassúnak és konzervatívnak tűnú) patch-menedzsment eljárást nyújtani a ICS üzemeltetőknek. Ennek ellenére mind a mai napig a ICS rendszerek rendszeres patch-elése nem elterjedt gyakorlat, volt olyan, ICS-rendszeren végzet penteszt, ahol 10 éves, javítatlan Solaris hibát találtak a biztonsági szakemberek.

A tegnapi napon számos szakmai híroldalon jelent meg az Ukrán Biztonsági Szolgálat (Security Service of Ukraine, SBU) által megfogalmazott vád, hogy a karácsony esti, egyes nyugat-ukrajnai területeket érintő áramkimaradásokat az orosz különleges szolgálatok által végrehajtott kibertámadások okozták.
 
Egyelőre nem lehet tudni, hogy az ukrán szolgálatok azon állítását, hogy az áramkimaradásokat egy kibertámadás okozta, alá lehet-e támasztani bizonyítékokkal, de vannak, akik összefüggést látnak a tavaly nyáron nyilvánosságra került, szintén orosz hacker-csoportoknak tulajdonított, európai energia-szektort célzó, Dragonfly néven ismertté vált kiberkémkedési eset és a mostani ukrajnai események között.

Update: Az ESET blogján megjelent cikk szerint az ukrán áramszolgáltatókat támadó malware egyértelműen a korábban többször látott Blackenergy malware-hez kapcsolható.

A tegnap posztban  említett SCADA Strangelove kutatócsapat tagjai a 32C3-on tartott előadásukban a vasúti közlekedésben használt ipari rendszerek biztonságával kapcsolatos vizsgálataik eredményeiről számoltak be.
 
A modern vasúti közlekedés számos ponton épít a digitális rendszerekre, sok más egyéb mellett ilyen rendszerek vezérlik a vonatok különböző funkcióit (sok egyéb mellett utastér jelzőberendezéseit, a vonatok irányító rendszereit és az utastájékoztató rendszert is). Számítógépekkel történik a vasúti pályán és az állomásokon használt biztosító berendezések (computer-based interlocking, CBI) vezérlése, a központi forgalomirányítás és a vasúti átjárók vezérlése, valamint a váltókat is ilyen rendszerek felügyelik és irányítják, de a mozdonyokról sem hiányzik a digitális technológia (egy modern mozdony, pl. egy Trax teljes újraindítása akár 5 percig is tarthat!).

A SCADA Strangelove kutatói az elmúlt három évben az ENISA-val és több, meg nem nevezett vasúttársasággal dolgoztak együtt a vasúti közlekedésben használt rendszerek biztonsági vizsgálata során és számos hibát fedeztek fel a biztosítóberendezésekben és vonatvezérlő rendszerekben. Tapasztalataik szerint ezekbe a rendszerekbe nem nehéz betörni, azonban a feladat az egyedi vasútautomatizálási rendszerek ismeretét és egy, a támadók rendelkezésére álló tesztkörnyezet meglétét igényli.

Bár a kutatók szerint a vasúti rendszerek publikusan nem elérhetőek, azért érdekes lenne látni egy statisztikát arról, hogy hány vasúti irányítórendszer van összekötve a vállalati hálózattal, aminek egyes elemei már elérhetőek az Internet irányából?

A C3-on elhangzott előadás prezentációja elérhető a Slideshare-en, további részletek pedig a különböző szakmai oldalak összefoglalóiban találhatóak.

A SCADA Strangelove egy független orosz biztonsági kutatókból álló csapat, akik ICS rendszerek és egyéb ipari környzetekben használt informatikai eszközök biztonságával foglalkozik. Az idei, 32. C3-ra (Chaos Communication Congress) időzítve december 27-én tették közzé a github-on egy listát 112 ICS rendszer/ipari eszköz gyári beégetett felhasználóneveivel és jelszavaival.

A listán 35 gyártó száznál is több terméke szerepel és a jelszavakat nézve az embernek az az érzése támad, mintha ezek a gyártók az évente publikált 20 legrosszabb jelszó listájáról választanák az eszközeikben a gyári felhasználók jelszavait.

Aki szeretne egy közelebbi pillantást vetni a gyűjteményre, itt találja a feltöltött fájlokat: https://github.com/scadastrangelove/SCADAPASS

Természetesen ha valaki talál olyan eszközt a sajátjai között, ami szerepel a listán, nagyon ajánlott minél előbb jelszót cserélni, ahol ez lehetséges - egyáltalán nem fogok meglepődni, ha a következő napokban-hetekben megszaporodnak azok a támadások kísérletek, ahol ezeket az adatokat próbálják meg majd felhasználni.

A nap másik komoly híre: nyugodj békében, Lemmy!

A mai napon egy új blogposzt-típust indítok útjára, más, ICS kiberbiztonsági témákkal foglalkozó blogokról fogok posztokat ajánlani. Az első ilyen az Unfettered blog, a sorszám oka pedig az, hogy várakozásaim szerint ezt a blogot még sokszor fogom hivatkozni.

Az Unfettered blog a www.controlglobal.com közösségen belül működő blogok egyike (a szerzők között többek között a magyar származású Lipták Béla is megtalálható), amit Joseph M. Weiss, az ICS kiberbiztonsági téma egyik legismertebb alakja ír. Joe, akit van szerencsém személyesen ismerni, lelkes kutatója az ICS biztonság kiberbiztonsági vonalának és elismert tagja az ICS biztonsági szakértők szűk körének.

Legújabb blogposztjában az amerikai Haditengerészeti Posztgraduális Iskola Belbiztonsági Központjának (Naval PostGraduate School Center for Homeland Defense and Security) újságjában megjelent cikkét vizsgálja és ad hangot annak a véleményének , hogy a cikkben olvasható megállapítások számos területen nem értékelik megfelelően az ICS rendszerek kiberbiztonsági incidenseinek (legyenek azok szándékos támadások vagy véletlen hibákból bekövetkező események) hatásait.

A teljes poszt, benne Joe saját adatainak és az NPS cikkének összehasonlítása itt olvasható.

A Siemens december 22-én jelentette az ICS-CERT felé, hogy a RuggedCom ROX-alapú eszközei közül a ROX I. firmware minden verziója és a ROX II. firmware-sorozat 2.9.0 előtti összes verziója több (a mostani bejelentés alapján 4), az NTP daemon-hoz kapcsolódó, távolról is kihasználható sérülékenységet tartalmaz.

Az első sérülékenységet kihasználva authentikáció nélkül lehet az eszközökön frissíteni az idő-beállításokat, a másik három sérülékenység pedig a bevitt adatok nem megfelelő ellenőrzéséből adódik.

A ROX II-alapú eszközökhöz a gyártó elérhetővé tette a hibákat javító új firmware-verziót. Azok számára, akik sérülékeny firmware-t használnak, több, a kockázatokat csökkentő intézkedést javasol a Siemens:

- A tűzfalakon javasolt blokkolni az ismeretlen forrásból származó NTP-csomagokat;
- NTP időszinkronizálást csak megbízható hálózaton javasolt alkalmazni;
- Javasolt az NTP funkciót kikapcsolni, ha nem létkérdés az alkalmazása;
- Javasolt az NTP konfigurációs fájlban beállítani a "noquery" flag-et a nem helyi eszközök esetén;
- Javasolt beállítani az NTP-authentikációt és az NTP konfigurációs fájlban beállítani a "notrust" flag-et a nem helyi eszközök esetén (ez utóbbit csak a ROX II-sorozatú eszközökön lehet megtenni).

Az ICS-CERT bejelentése teljes terjedelmében itt olvasható.

A mai posztban olyan, ICS rendszerekben is használt protkollokról lesz szó, amik széles körben ismertek. Ezeket a protokollokat a modern informatikai rendszerekben már többnyire nem használják, azonban a ICS rendszerben még mindig széles körben használatban vannak. Bár ezeket a protokollokat a legtöbb informatikus jól ismeri, a teljesség kedvéért röviden (itt-ott akár csak távirati stílusban) ezeket is áttekintem.

FTP

Az FTP (File Transfer Protocol) egy szabványos hálózati protokoll, amelyet TCP-alapú hálózatokban fájlok egyik számítógépről a másikra mozgatására szoktak használni.

Az FTP protokoll kliens-szerver architektúrára épül és elkülönülnek benne a kapcsolatvezérlő és adatkapcsolati funkciók. Az protokollban a felhasználóknak (klienseknek) egy clear-text authentikációs protokollal kell azonosítaniuk magunkat, de ha a szerver konfigurációja engedi, az anonim bejelentkezésre is van lehetőség. Az FTP protokoll biztonságosabb tételéhez, a felhasználói azonosítók és jelszavak, valamint a adattartalom titkosításához jellemzően SSL/TLS-t szoktak használni (az FTP-nek ezt a változatát ismerik FTPS-ként), illetve időnként SSH-t is, ekkor SFTP-ről beszélünk.

TFTP

A TFTP (Trivial File Transfer Protocol) egy egyszerű FTP protokoll, ami lehetővé teszi a kliensek számára, hogy fájlokat másoljanak fel és töltsenek szerverekről. A TFTP egyik elsődleges felhasználási formája a hálózatban kötött számítógépek LAN-ról történő boot-olásának biztosítása. A TFTP használatának egyik fő oka az egyszerű használat. A TFTP biztonsági szempontból gyenge protokollnak számít, az parancsok, adatok és a felhasználói authentikáció adatai is titkosítatlanul kerülnek továbbításra a hálózaton. Hiányoznak belőle azok a fejlett funkciók is, amik a jobb FTP protokollok sajátja. Mindezekkel együtt sok (főleg régebbi rendszerben és jellemzően régebbi (hálózati) eszközök firmware-jében még sok helyen ma is használatban van.

A TFTP-t először 1981-ben szabványosították, a protokoll jelenlegi specifikációját az RFC 1350-ben található.

rsh

Az rsh (remote shell) egy parancssori program, amivel shell parancsokat lehet végrehajtani a hálózaton található számítógépeken egy másik felhasználó nevében. A távoli rendszer, amihez az rsh csatlakozik, futtatja az rsh daemon-t (rshd). Az rsh daemon jellemzően az 514/tcp porton fut. Az rsh használata során a kiadott parancsok, valamint a felhasználói azonosítók és jelszavak titkosítatlanul kerülnek továbbításra a hálózaton.

Az rsh eredetileg a BSD Unix operációs rendszer 4.2-es verziójában jelent meg először, 1983-ban, együtt az rcp-vel, az rlogin csomagjában.

Az rsh-nak egyezik a neve egy másik gyakran használt UNIX paranccsal, a restricted shell-lel, ami először a PWB/UNIX-ban, a System V Release 4-ben jelent meg. A restricted shell általában a /usr/bin/rsh útvonalon található.

rlogin

Az rlogin egyszerre a szoftver és a szoftver által használt alkalmazás rétegbeli protokoll neve. Az authentikált felhasználók úgy tudnak dolgozni, mintha fizikailag is a távoli számítógép előtt ülnének. Az rlogin-t az RFC 1282 definiálták. Az rlogin az rlogind daemon-nal kommunikál a távoli számítógépen és a felhasználói authentikáció adatai ennél a protokollnál is clear text formában utaznak a hálózaton. Az rlogin hasonlít a telnet parancshoz, de ahhoz képest rendelkezik azzal hátránnyal, hogy nem testre szabható és csak Unix szerverekhez lehet csatlakozni vele.

rexec

Az rexec (remote execute) hasonló funkcionalitással rendelkezik, mint az rsh - más számítógépeken tesz lehetővé távoli parancsvégrehajtást.

telnet

A Telnet egy, az OSI modell együttműködési (session) rétegében működő protokoll, ami az Interneten és helyi hálózatokon biztosít kétirányú, interaktív, szöveges kommunikációs lehetőséget. A Telnet protokoll három fő alapelvre épül, az első a hálózati virtuális terminálok koncepciója, a második a "tárgyalásos lehetőségek" elve, a harmadik pedig a terminálok és folyamatok szimmetrikus nézete.

A Telnet mind a mai napig széles körben használt protokoll, azonban nem felel meg a modern biztonsági elvárásoknak.

A most bemutatott, általánosan használt protokollokon túl természetesen számos más protokollt is használnak ICS rendszerekben, ezzel a rövid bemutatással inkább azokra a protokollokra próbáltunk koncentrálni, amelyek gyakran előfordulnak és biztonsági szempontból komoly kihívást jelentenek.