Az alábbiakban szeretnék reagálni a Csinos Tamás, a Clico Hungary Kft. képviselőjének 2023 novemberi, NIS2 és OT kiberbiztonság témájú előadására. Az előadást az IT-OT konvergencia folyamatokra károsnak tartom, mert tartalma pontatlanságoktól, illetve néhány esetben szakmai hibától terhes, az előadás stílusa pedig nem méltó az IT szakma jeles képviselőjéhez.

Az IT és az OT viszonyrendszere problémás. Áthatja az évtizedek óta felgyűlt feszültség, amelyet a szakmai ellentétek mellett pont a hasonló kommunikációs anomáliák gerjesztenek. Az IT-OT konvergencia nem csak a technológiáról szól, hanem a két terület szakembereinek hatékony együttműködéséről, amely nélkül a technológiai konvergencia sem fog tudni létrejönni és fennmaradni.

Az OT szakterület és az OT kiberbiztonság a hazai környezetben óriási lemaradással küzd. Becslésem szerint kb. 20 vagy 25 évvel vagyunk elmaradva az IT kiberbiztonságtól. Ha kiberbiztonsági oldalról nézzük, gyengék vagyunk és erőtlenek. Küzdünk az évtizedes és megörökölt problémákkal, a büdzsé nélküliséggel, a folyamatos üzem kényszereivel és küzdünk a szakemberhiánnyal. Gyengék és erőtlenek vagyunk, elesettek és talán gyámoltalanok. A NIS2 vagy az egyéb kiberbiztonsági megfelelőségek alapjaiban rengetik meg terepi világunkat.

A most megkritizált (jobb későn, mint soha!) előadással kapcsolatban gondolom és hiszem, hogy ez nem szándékos volt és nem rosszindulat motiválta. Remélem, hogy a túlterhelés rovására írható, az előadás heve, az IT szemüveges csőlátás, az év végi fáradtság vagy bármi egyéb más méltányolható mentőkörülmény hatása belejátszott az eredménybe.

Azonban ezt nem lehet ennyiben hagyni.

Nagyon kevesen vagyunk, akik az OT kiberbiztonságával foglalkoznak hazánkban. Megfeszített erővel próbáljuk evangelizálni és edukálni a szervezeteket, az előadás pedig ezt a tevékenységet rombolja. Bizonyos tekintetben azonban pont az előadás hívja fel a figyelmet arra (és ezt edukációs célra igyekszem most felhasználni), hogy mindaz, amit arról beszélünk, hogy nem lehet és nem szabad IT-s szemüvegen keresztül nézni az OT-t, illetve az IT-ban megszokott eljárásokat adaptálás nélkül rákényszeríteni az OT-ra – az IGAZ.

Megpróbálom hát az előadásból kiemelni azokat a pontatlanságokat, amelyek megmutatják, hogy miért van szükség OT kiberbiztonsági szakemberekre és hogy ezeket a szakembereket az OT-nak kell kinevelnie, vagy átképeznie az IT oldalról. Megpróbálom (csaknem) szó szerint idézni azokat a gondolatokat, amelyekkel nem hogy nem értek egyet, de károsnak, pontatlannak – és néhol kifejezetten sértőnek tartok.

„A hatóság kijelölheti ezen cégek beszállítóit is”

 Az SZTFH nem jelöli ki a beszállítókat, hanem a NIS2 által érintett szervezet azonosítja a beszállítóit és szerződésben elvárja bizonyos biztonsági követelmények teljesítését.

„0.-dik pillanat január 1, van másfél hónapunk”

A megfelelőséget 2024. október 18-tól kell az érintett szervezeteknek biztosítania, azt megelőzően nem érvényesek az elvárások. 2024. január 1-től június 30-ig kell bejelentkezni a szervezeteknek, de a felügyeleti díj csak októberben lesz esedékes.

„2025-től lehet azt hiszem büntetni”

A büntethetőség (és a hatósági ellenőrzések) elvi kezdődátuma 2024. október 18, amikortól elvileg a követelményeknek meg kell felelni.

„Ezeket a szervezeteket a hatóság kiértesíti”

A Hatóság nem fogja a NIS2 által érintett szervezeteket kiértesíteni. A szervezeteknek kell felismerni, hogy érintettek, és 2024. június 30-ig be kell jelentkezniük.

„Nem azt mondjuk, hogy kritikus infrastruktúra, hanem azt, hogy kockázatos és kiemelten kockázatos iparágak”

Nem a kritikus infrastruktúra helyett mondjuk, a kettő ugyanis nem ugyanaz! A NIS2 nem a kritikus infrastruktúrákat váltja, azok létfontosságú rendszerelem néven továbbra is jelen lesznek, a NIS2 ettől teljesen független.

„A törvény legfőbb üzenete, hogy képesnek kell lennünk incidenst riportolni. Ez a lényeg, hogy ha támadás ér, akkor legalább észrevegyük. Nem előztük meg, az egy dolog, nem hárítjuk el az egy dolog, de észre kell tudnunk venni, mert ha nem vesszük észre, akkor dádá lesz. Alapvetően ez az üzenet.”

A NIS2 alapján van a hatóság felé incidens jelentési kötelezettség, de a NIS2 alapvető üzenete az, hogy gondoskodjon a szervezet a (kiber)biztonságáról, előzzék meg, észleljék, hárítsák el és természetesen az észlelést követően jelentsék az incidenst!

„Az összes gyártói tevékenységre vonatkozik a NIS2”

Nem, erre megvan a katalógizált tevékenységi kör, például a játék és ruházati termék gyártásra sem vonatkozik.

„…a MES néven emlegeti a szakma, gyakorlatilag a gyártás ERP-je, semmi extra nincsen benne…”

Analógiát tekintve a Manufacturing Execution System (MES) mint Termelésirányítási Rendszer NEM olyan, mint az ERP - legalábbis a hozzáfűzött „semmi extra” kitétellel együtt. Inkább hasonlónak lehet mondani, de csak részfunkcióját tekintve. Annyi „extra” van benne ugyanis, hogy a MES rendszerek vezérlési, irányítási vagy szabályozási tevékenységet is végezhetnek (kiépítéstől függően), azaz visszahathatnak a terepi és terepközeli eszközökre, PLC-kre, DCS-re, illetve a folyamatokra. A MES ugyanis (kiépítéstől függően) vezérelhet, irányíthat vagy szabályozhat folyamatokat (illetőleg a felügyelet a MES alapján valósíthat meg vezérlést), ezzel pedig kiberfizikai eszközzé válik, amelyet a hazai NIS2 implementációban is alkalmazott NIST SP 800-82 ajánlás és az IEC 62443 szabvány is nagyon erősen megkülönbözteti az IT-tól. Jogosan, hiszen bármi, ami vezérel, irányít vagy szabályoz, az a fizikai világra hat ki, hatást gyakorol és változást indukál a fizikai környezetben, ez pedig hatással lehet az emberi életre és egészségre, a környezet biztonságára és a berendezések épségére.

Itt egyben szeretnék rámutatni arra, hogy az IT kiberbiztonságban megszokott bizalmasság, sértetlenség, rendelkezésre állás szent hármasa sem értelmezhető a MES rendszerre, mint ahogy az OT-ban általánosságban sem alkalmazható. Az OT-ban ugyanis az üzembiztonság, megbízhatóság, rendelkezésre állás, sértetlenség és bizalmasság a sorrend. Ez a sorrend kőbe van vésve és mindenek felett áll. Ez az előbbiekben bemutatott kiberfizikai létezésből fakad, azaz például a MES esetében is az üzembiztonság a legfontosabb, mivel visszahat(hat) a fizikai környezetre.

Összefoglalva, a MES és az ERP között annyi „extra” különbség biztosan van, hogy nemigen lehet olyan ERP rendszert felmutatni, amely (bizonyos szerencsétlen körülmények között) meg tud ölni, vagy kárt tesz a környezetben vagy a berendezésben.

„…Advanced Process Controll, ezzel vezéreljük ezt meg azt. Inkább hálózatos vonatkozásai vannak. Közlekedtetünk üzeneteket mindenféle hálózatokon, általában most már IP fölött, mert minden digitalizálódik...”

Egyrészt tegyünk különbséget vezérlés, irányítás és szabályozás között, mert ezek lehet az IT-ban szinonimaként vannak kezelve, de az OT-ban nem ugyanazt jelentik. Az APC kategorikusan nem azonos a terepi vezérléssel, szabályozással, hanem annak egy fejletteb, magas szintű rendszerekkel megvalósított struktúrája és többféle algoritmusból álló koncepciója, amelyet jellemzően a fejlett DCS rendszerekben implementálnak. Ide tartoznak például a feedforward, a következtetéses szabályzás, illetve a matematikai modelleken alapuló előrejelzések és az adaptív beavatkozás algoritmusai. Alkalmazását nézve Ilyen példa lehet a kívánt termék összetétel változásra és a bemenő anyagok tulajdonságaira reagáló modell bázisú szabályzás, amely a szabályzókörök PID paramétereit állítja. Az eredeti mondat tehát tárgyi tévedés, hiszen a kommunikáció csak az APC inputjait és outputjait hivatott eljuttatni a terepi eszközök és a kontrolt adó vezérlőelemek részére, de az APC lényege egészen más, hívhatjuk modellnek, koncepciónak, algoritmusnak, struktúrának – de üzenet közlekedtetésnek „mindenféle hálózaton” - nem.

De ha már itt tartunk, nem minden „vezérlés” megy IP felett. Üzembiztonsági (és történelmi) okokból az ilyen „beavatkozók” esetében nagyon sok helyen használnak direkt huzalozást és reléket, vagy 4-20mA-t. Pont azért szeretjük az analóg vezérlést (és a 4-20mA-t), mert „korlátlan” távolságig vihető és vezérelhető vagy szabályozható vele a motor, a szelep, az adagoló, vagy bármilyen más berendezés. (A korlátlant direkt idézőjelbe tettem, a világban sok minden korlátlan, de sajnos a fizika nem az. A jelátviteli módok általában az architektúrához és a feladathoz igazítottak.) Egyébként a digitalizált OT rendszerben egyedül az áramerősség az, ami nem hazudhat. Nemzetközi szinten erre készültek a Level-0 alapú OT kibervédelemi rendszerek (például SEGA, Mission Secure), ahol a szignált vizsgálva VALIDÁLJÁK azt, amit digitális/kiber oldalról látni lehet – pontosan azért, mert a digitális az hazudhat és mást mutathat, mint ami a fizikai világban van, a szignál viszont nem tud hazudni. (Az más kérdés, hogy mikor érünk el itthon erre a szintre, ahol például a Clico által is forgalmazott kiváló Forescout – illetve a hasonló termékek – implementációja is nagyon nehézkes, hiszen nagyon sok helyen az iparban nincsenek menedzselhető switchek a terepen, csak a felsőbb zónarétegekben – vagy még ott sem).

A Process Controllról tehát annyit összefoglalnék, hogy korántsem digitális minden, sőt, ahol kritikus az üzembiztonság, ott messzire kerülik az IP-t. Gondoljunk csak a safety világra, az OT (üzem)biztonsági berendezéseire, gyakran ott sem IP-n megy a vezérlés. Sőt, a hazai vonatkozásban – nyilván szektortól és szervezettől függően – a vezérlések jelentős része egyáltalán nem IP alapú (éljen az Örökkévaló Profibus és MODBUS RTU), hiszen sok esetben 20-30 éves berendezésekről van szó. Óriási hiba tehát a kontrollt (és az APC-t) mindenféle üzenetek hálózaton (akár IP, akár nem) való közlekedtetésének definiálni, ennél ez sokkal, de sokkal bonyolultabb kérdés, amelyet az automatizációs és folyamatmérnökök hosszú évekig tanulnak.

„Data HISTORIAN, ez is egy nagyon jó kifejezés, ez egy tök mezitlábas rohadék adatbázis, semmi extra nincsen benne, de ugye az OT-s csavók szeretik ezt elfedni ezeket a dolgokat, és nem azt mondjuk, hogy ugye van egy SQL adatbázis, ahol gyűjtjük az információkat, hanem azt mondjuk, hogy van nekünk egy Data Historianunk, ez mennyivel fennköltebbnek hangzik”

Nem tudok ennek azzal a részével mit kezdeni, miszerint az OT-s csávók szeretik elfedni a dolgokat. Ez valami téves, demisztifikatív célú kijelentés lehet az előadó részéről.

Az OT-ban a historikus adatgyűjtő eszköz neve HISTORIAN. Ez a terminológia. Hasonló lehet ez az IT biztonságban alkalmazott adatszivárgás-védelmi (Data Leak Prevention – DLP) megoldáshoz, amely az elnevezéséhez képest ugye nemigen tudja a szándékos adatszivárgást megakadályozni, dehát ez a terminológia, ezt használjuk és szerintem ez sem fennkölt.

A Data vagy Process Historian nem egy újhullámos elnevezés. Az 1980-as évek közepe óta így hívják a funkcionalitást, csak akkor még VAX/VMS környezetekben futottak ezek a rendszerek. Azóta is így hívják a gyártók, GE Historian, AVEVA Process Historian, stb. Abban igaza van az előadónak, hogy ennek az alapja egy adatbázis (SQL vagy ma már valamilyen noSQL), azonban a funkcionalitását nagyon pongyola erre a szintre degradálni.

A Historian nem „csak” egy mezitlábas, rohadék adatbázis. A Historian a process manufacturing, azaz a folyamatgyártás egyik legfontosabb berendezése (ne menjünk most bele a diszkrét, kötegelt, folyamat(os) és hibrid gyártási folyamatokba, bár természetesen nagyon szignifikáns, rendszert és eljárásokat meghatározó különbségek vannak). Kicsit olyan ez, mintha egy SOC/SIEM rendszert degradálnánk le mezitlábas, rohadék adatbázisra – pusztán azért, mert a tárolásra adatbázis struktúrát használ, vagy a korábban említett adatszivárgás-védelmi megoldásra jelentenénk ki, hogy mezitlábas, rohadék adatbázis.

Mindamellett, hogy természetesen a Historian valós idejű és idősoros adattárolást tesz lehetővé, a legfontosabb funkciója a valós idejű adatelemzés, amely lehetőséget biztosít a folyamatok valós idejű nyomon követésére, így például a devianciák észlelésére és azonnali lereagálására. Deviancia alatt lehet érteni a műveletek, események és eredmények devianciáját, ugyanakkor talán legalább ilyen fontos, hogy azoknak az eszköz, rendszer vagy folyamatdevianciáknak az észlelését is lehetővé teszi, amelyek konkrétan veszélyt jelenthetnek az emberi életre és testi egészségre, a környezet biztonságára és a berendezések épségére. A Historian üzembiztonsági eszközként is funkcionál(hat), a működési rendellenességeket fedi fel, olyan rendellenességeket, amelyek (nem tervezett/kényszer) karbantartáshoz vezetnek vagy akár üzembiztonsági eseményt (incidenst) fognak előidézni – esetleg már elő is idéztek, csak még nem eszkalálódtak.

A működési rendellenességek kiszűrése mellett működésoptimalizáló funkciója is van, amely viszont megint csak azt jelenti, hogy a Historian belenyúlhat a vezérlésbe – ha az adatelemzés alapján erre termelési vagy üzembiztonsági okokból szükség van (pontosabban azért jobb, ha a Historian alapján más komponens végez ilyen beavatkozásokat).  Az idősoros és hiteles adatbázis egyébként (ha mégis adatbázis funkcióról beszélünk) pont az az eszköz, amely nélkül bizonyos szektorok működésképtelenné vállhatnak. Nem azért, mert az adatbázis nélkül nem működnek a berendezések, hanem azért, mert a hiteles adatbázis nélkül nem működhetnek a berendezések. Ilyen például a gyógyszergyártás, de lehetne még sorolni. Tudnának működni, azonban a jogszabályi megfelelőség követelményei miatt az auditálható, jogilag hiteles, bizonyító képességgel bíró adatbázis hiányában a gyártás nem validálható és ebben az esetben a késztermékek – pl. gyógyszerek – sem validálhatóak és nem kerülhetnek forgalomba (akár meg kell őket semmisíteni).

Összefoglalva, a Historian funkcionalitása (a kiépítéstől függően) messze túlmutat a „mezitlábas, rohadék adatbázison”, de természetesen az nem tagadható, hogy van benne adatbázis és adattárolás, de ennyi erővel ez bármire ráfogható és ezzel gyakorlatilag degradálódik a funkcionalitás és szerep. Az „OT-s csávók” nem fedik el ezeket a dolgokat – mert értenek hozzá, és nem tartják fennköltnek az eszköz elnevezését – mert ez a neve.   

Amikor azt mondjuk, hogy SCADA rendszer, akkor gyakorlatilag most az új terminológia erre, hogy Operational Technology, OT rendszerekről beszélünk.

Az igaz, hogy ha SCADA-ról beszélünk, akkor OT rendszerről beszélünk, de nem azért, mert a SCADA új terminológiája az Operational Technology.

Az Operational Technology esetében többféle meghatározás létezik, ezek részint korszak- és kényszerszülte, részint pedig már sztenderdé vált megfogalmazások. A leginkább kényszerszülte megfogalmazás az, hogy „minden OT, amivel az IT nem akar foglalkozni”. Természetesen nem ez került kanonizálásra, hanem a NIST megfogalmazása – amely a NIST SP 800 82 miatt a hazai NIS2 implementációjában (mint kiberfizikai rendszer) is megjelenik: „Programozható rendszerek vagy eszközök, amelyek kölcsönhatásba lépnek a fizikai környezettel, vagy más, a fizikai környezettel kölcsönhatásba lépő eszközöket kezelnek. Az eszközök, folyamatok és események megfigyelésével és/vagy vezérlésével érzékelik a fizikai környezetet, vagy közvetlenül változást idéznek elő a fizikai környezetben.”

Ez alapján az OT-hoz tartoznak olyan eszközök és rendszerek is, amelyeket nem gondolnánk elsőre annak, például a kamerarendszerek, tűzjelzők, riasztók, beléptetők, hűtés-fűtés-ventillálás (HVAC) rendszerek és az egyéb épület automatikák. Látható, hogy a SCADA ennek egy nagyon pici része, mint ahogy a SCADA mellett (ha már rendszereket nézünk) ott vannak a DCS és PCS/PACS rendszerek is.

„Az alján ugyanúgy Windows meg Linux comuting egységekről beszélünk. A PLC-n is 99%-ban valamilyen Linux/Unix kód fut. Nem egy egyedi operációs rendszer.”

A régebbi PLC-k esetében az állítás biztosan nem igaz. Vannak aztán újabb PLC-k, amelyekben valamilyen „UNIX-like”, de speciális igényekre és működésre szabott, valósidejű (RTOS) operációs rendszer működik, de hogy ez ugyanaz a UNIX/Linux lenne, az ismét nem igaz. Ott van az Allen Bradley Microware OS9 rendszere, amely még Motorola CPU-ra készült a 80-as években, már akkor erősen modularizált és valósidejű kivitelben. Ott van a VxWorks, amely 1987-ben jelent meg és amelynek megbízhatóságáról csak annyit, hogy a Curiosity Mars rover landolását a VxWorks vezényelte, mindemellett természetesen az Allen Bradley, Omron, az Emerson és a Yokogava is használja a DCS kontrollerekben és PLC eszközökben. Vannak olyan gyártók is, akik saját operációs rendszert fejlesztenek, például több Siemens PLC-n is teljesen saját fejlesztésű beágyazott rendszer fut. Ahol valamilyen UNIX-like jellegű RTOS működik, ott az ős (esetleg) közös volt, de ez ugyanúgy igaz minden korábbi Windows-ra, hogy az csak egy színes DOS, vagy bármely Linuxra, hogy az meg egy csicsás MULTICS/UNICS – vagy BSD (révén, hogy az első Linux 1999-ben jelent meg). Többnyire egyedi megoldásokról és operációs rendszerekről beszélünk. Vannak természetesen köztes megoldások, mint például a Beckhoff, ahol valóban erősebben megjelenik a jól ismert Windows (vagy a Twincat/BSD), de szűklátókörűség az ilyen általánosítás és egyszerűen nem igaz.

Az IT-OT konvergencia bármennyire is a területek közeledéséről szól, nem azt jelenti, hogy az IT és az OT összeolvad. Sokkal inkább arról van szó, hogy az IT és az OT közösen hoznak létre új paradigmákat és közös technológiai megoldásokat, amelyeket valamilyen módon közösen működtetnek és tartanak fenn.

Az IT és OT eszközök közötti igazi különbséget nem a felhasznált technológia, hanem a technológia felhasználásának célja, módja, illetve az azt meghatározó elvárások, megfelelőségek és preferenciák jelentik és ezek eltérnek az IT-tól, az eltérések pedig visszahatnak az operációs rendszerekre.

„A kommunikációk az egyes komponensek között ugyanúgy egy nyamvadt SSH-n mennek, ahogy az IT rendszerekben. Ezzel sincs alapvetően semmilyen különbség.”

Az OT-ban rengeteg protokoll van, nem akarom ezeket mind felsorolni, de azért álljon itt jó pár ipari protokoll a teljesség igénye nélkül: S7Comm, S7CommPlus, MODBUS, PCCC, BACNet, DNP3, ROC, DeltaV, HART(IP), iFix, Goose, Ethercat, FoxboroTalk/Eng, stb.

Sajnos a régi (szép?) időben minden gyártó saját protokollt fejlesztett ki, ennek örökségét a mai napig hordozzunk a vállunkon. A soktucatnyi ipari protokoll mellett egy OT hálózatban természetesen jelen vannak az IT-ból jól ismert protokollok is, azonban az biztos, hogy az OT komponensek (pl. PLC, DCS kontroller, szenzorok, motorok, IO-k, stb) között nincsen SSH kommunikáció.

Részint azért, mert a legtöbb ipari protokoll (valamilyen, még nem TCPIP verzióban) már akkor létezett, amikor az SSH még nem, például a MODBUS 1979-ben született, míg az SSH 1995-ben. Kis érdekesség, hogy a MODBUS 1999-ben már TCPIP-re is fel lett készítve, pont akkor, amikor az OpenSSH megjelent, azonban addigra a MODBUS már régen nagykorú volt.  Vagy beszélhetünk a DNP3-ról, amely 1990-ben jött létre, vagy az 1987-es BACnet-ről, és még sorolhatnám.

A másik, hogy sajnos az OT terepközeli eszközei – az IT-hoz képest – meglehetősen csekély erőforrással rendelkeznek, amelyeket inkább a működés egyéb területein hasznosítanak – és nem fordítanak túl nagy hangsúlyt (és erőforrást) a kriptográfiára. Ezt az örökséget a mai napig görgetjük magunk előtt, és azt kell mondanom, ha esetleg egy eszköz még képes is valamilyen titkosított protokoll kommunikációra, jellemzően akkor is inkább a nem titkosított változatát használják. Nem feltétlenül csak az erőforrások miatt, de ilyen ok lehet például az interoperabilitás kérdése: amikor egy rendszerben együtt kell működnie egy 30, egy 20, egy 10 és mondjuk egy 2 éves eszköznek, akkor a mindenség eredője valószínűleg az 1979-es vagy az 1999-es MODBUS lesz. Bizonyos tehát, hogy SSH-t nem használnak a komponensek közötti kommunikációra.

„Ugyanúgy kitettek ugyanazoknak az IT fenyegetéseknek”

Véleményem szerint ez eléggé pontatlan megfogalmazás, de valahol azért hordoz igazságot is, csak nem feltétlenül úgy, ahogy azt az előadó sugalmazza az előadásában.

A régebbi OT eszközökre bizonyosan nem igaz, azoknak megvan a saját és jellemzően a régmúltból örökölt sérülékenysége, amelyek ugyan visszavezethetőek az IT-ban is ismert régi sérülékenységekhez (titkosítás hiánya, hitelesítés hiánya, visszajátszás elleni védelem hiánya, stb), nyilván az 1970-es években szó nem volt arról, hogy ezeket az eszközöket összekapcsolják, hálózatba szervezik, illetve hálózatok és felhők felett átívelő kommunikációt kell folytatniuk.

Ezeket a sérülékenységeket az IT is hordozta ettől az időszaktól kezdve, azonban ott megvoltak azok a kényszerítő körülmények, amelyek miatt ezek a sérülékenységek kikoptak belőlük. Igen, kikoptak. Őszintén mondom, hogy ezek a sérülékenységek a mai modern IT környezetben legfeljebb szándékosan, vagy fatális véletlenek sorozata miatt létezhetnek, ha ma (sőt 5 éve, 8 éve) egy IT fejlesztő olyan alkalmazást vagy eszközt készít, amelyben ezek a sérülékenységek fixen megvannak, azt rövid úton alkalmatlannak nyilvánítják. Ellentétben az OT-val, ahol ha ma csinálnak egy eszközt, amelyben ezek a sérülékenységek megtalálhatóak – ellenben az eszköz üzembiztosan és megbízhatóan működik-, fel sem merül, hogy alkalmatlannak nyilvánítják – mivel az OT számára az üzembiztonság és megbízhatóság a fontos. Szóval ebből a szempontból nézve az OT ilyen fenyegetései a modern IT-ban már nem lelhetőek fel.

A modernizációs törekvések az OT-val kiberbiztonsági szempontból nem tettek jót. A modern OT-s eszközökben sajnos megjelentek azok a sérülékenységek is, amelyekről az előadó beszél, az IT-ból jól ismert és aktív sérülékenységek. Amikor egy PLC eszközön webszerver fut, ott megjelennek a különféle webes támadások, illetve természetesen ugyanez igaz a modern PLC-k hasonló, IT-jellegű szolgáltatásaira. Van erre egy jó kifejezés, a „bifrons” – ami kétarcú démont jelent, vagy a Janus-arcú eszköz, amelyben jelen vannak az OT régmúltból hozott és örökölt sérülékenységei, illetve már a konvergencia keserű gyümölcsei is megteremnek rajta: a modern IT által beemelt sérülékenységek.

Összefoglalva, az OT egyes sérülékenységei az IT-ban már nem ismertek, legfeljebb rémmesékként léteznek – nekünk pedig ez a mindennapunk. És igen, valóban megjelentek ezek mellé a IT modern sérülékenységei is, csak hogy jó és szép legyen minden.

„A tetején a menedzsment rendszereknél az adatgyűjtésnél ugyanolyan teljesen szabványos IT technológiákat használunk, mint amilyeneket az IT-ban.”

Bárcsak igaza lenne az előadónak. Bárcsak. De nincsen. Az örökség itt is nyomja a vállunkat. A gyártók által fejlesztett saját és zárt protokollok miatt az OT-ban az adatgyűjtés sem feltétlenül ilyen egyszerű, a zárt protokollvilág miatt nagyon sok esetben akár többféle adatgyűjtőről (és az IT-ban nem ismert protokollokról) is beszélhetünk. Persze, lehetne mesélni olyan adatgyűjtőről, ami UDP-n broadcastolja adatokat a teljes hálózatban, amelyet innentől minden eszköz megkap, legfeljebb, ha nincsen megjelenítő kliens rajta, akkor nem tud vele mit kezdeni. De számos adatgyűjtő nem is „dobozos” termék, hanem a speciális, egyedi építésű berendezések, protokollok és funkciók miatt arra az egy rendszerre írta meg valaki 20 éve – és használják a mai napig. Erre a káoszra azért születtek olyan szabványos megoldások is, mint az OPC (UA), vagy a PROFISafe, amelyeket nemigen hiszem, hogy az IT-ban bárki is használna.

„..annak ellenére, hogy általában azt mondjuk, hogy ezek airgeppelt rendszerek, ezekhez nem lehet hozzáférni, ez nekünk teljesen le van szeparálva, meg nagyon sok mindent hallunk az igazi OT-s arcoktól, hogy ők miért sérthetetlenek.”

Nem tudom pontosan milyen OT-s arcokra gondolhat az előadó. Az automatizációs mérnökökre? A folyamatmérnökökre? A tervezőmérnökre? A főmérnökre? A PLC programozókra? A karbantartókra? Az elektrikusokra? Az operátorokra? A safety mérnökökre? A kazángépészre? A blokkgépészre? A TMK-ra? Ugyanis ezeknek a rétegeknek egyike sem kiberbiztonsági vagy IT szakember. Sőt, őszintén szólva ők a kiberbiztonsággal legfeljebb az IT által szervezett biztonságtudatossági oktatásokon találkozhatnak, amelyek nem terjednek ki a technológiai rendszerekre. Komolyan, a felsorolt szerepkörök jó részének fogalma sincsen arról, hogy a kiberbiztonság egyáltalán jelen van (vagy jelen kellene, hogy legyen) a vezénylőkben, reléterekben, kapcsolószekrényekben, gépsorokban, eszközökben és folyamatokban. Ha megkérdezünk egy „igazi OT-s arcot”, hogy sorolja fel az OT rendszereit, a legvalószínűbb, hogy magától fel sem merül benne, hogy IT-jellegű berendezések, alkalmazások, szoftverek is bele tartoznak: neki ugyanis az IT és nem OT. Neki a SCADA alatt futó Windows nem OT.  Nem ért hozzá és nem foglalkozik vele, így annak kiberbiztonságával vagy kitettségével nem is lehet tisztában. Ha egy „igazi OT-s arc” sérthetetlenségről beszél a biztonság vonatkozásában, akkor általában safety-ről beszél és üzembiztonságról.

Aki egyébként kiber vonatkozásban ilyet mondhatna, az az OT infrastruktúra mérnök vagy OT infrastruktúra üzemeltetető, de ő biztosan nem mond ilyet, mivel itthon ez a réteg – egyenlőre – nemigen létezik. Mondhatna ilyet még esetleg az OT kiberbiztonsági szakember, de hazai vonatkozásból mind a tizennégyet ismerem és tuti egyik se mond ilyet.

De akkor mégis, honnan származhat ilyen kijelentés? Mert tény, hamis biztonságérzet az van. Ezt nem lehet letagadni. Igen, elismerem, vannak ilyen hangok is. Ezzel én magam is találkoztam már. Viszont érdemes feltárni, hogy ha mondják, miért mondják?

Mert így tudják.

A forrás első sorban nem az OT-ban keresendő, ők legfeljebb másodkézből mondják. Ugyanis egy PLC programozó, egy karbantartó, egy elektrikus vagy egy folyamatmérnök – nem ért a kiberbiztonsághoz. Nem ő csinált tűzfalat és nem is ő üzemelteti. Ezért nyilvánvaló, hogy nem ő választja el az OT-t az IT-tól. Jellemzően az IT szegregálja az OT-t, hogy az ott található kaotikusnak tűnő mindenség ne fenyegesse az IT tisztább és sterilebb világát. „Megvédik” az IT-t és az „elválasztással” az OT felé hamis biztonságérzetet közvetítenek. Mert az „elválasztás” igazából nem tud megvalósulni, az OT-nak és az OT-val kommunikálni kell. Az „elválasztás” önmagában nem is elég, nem véletlenül jött létre a biztonságos OT hálózati referenciamodell, a több szeparációt és funkcionális partícionálást tartalmazó Purdue-modell. Itt megint fel lehet tenni a kérdést, hogy vajon ki képes a szervezetben egy több szintes szeparált és partícionált hálózatot kialakítani? Mert az elektrikus, kazángépész, TMK, automatizációs mérnök, folyamatmérnök, PLC programozó – nem. Nem az ő feladatuk.

Ahonnan még ilyen hamis biztonságérzet közvetítődhet, az fizikai és vagyonvédelmi oldal, amelynek ugye többek között az a feladata, hogy megakadályozza a jogosulatlan fizikai hozzáféréseket a szervezet infrastruktúrájához, beleértve természetesen a technológiai környezeteket is. Ha esetleg az OT oldal bármely szerepkörétől azt halljuk, hogy „ide úgy sem tud bejönni senki”, az nem logikai, hanem a fizikai biztonságra vonatkozik. Véleményem szerint sok esetben a szervezet (nem az OT, vagy nem csak az OT) meglehetősen túlbecsüli a megvalósított fizikai kontrollok védelmi hatékonyságát. Természetesen a menedzsmentről sem szabad megfeledkezni, amely a fizikai és logikai szegregáció szakralitását magába szívva elkönyvelheti, hogy az OT „sérthetetlen”.  

De legyen tényleg igaza az előadónak, biztosan akad olyan „igazi OT-s arc” is, aki azt gondolja és mondja, hogy sebezhetetlen. Miben más ő attól az IT/office felhasználótól, aki – a kockázatokat nem ismerve bízik a szervezet kibervédelmi tevékenységeiben – és ugyanezt gondolja? Mindig és mindenhol az ember a leggyengébb láncszem. A felhasználókat oktatni és képezni kell. Az oktatás (és nem kioktatás) a leghatékonyabb és legolcsóbb védelmi intézkedés.

„Az OT-ban ott vannak ezek a ködösített dumák, amik ugyanúgy IT technológiákat használnak…”

Erre a pontra nem is szakmailag akarok reagálni, az IT-OT konvergenciával kapcsolatban már kifejtettem a véleményemet.

Azonban szeretném megkérdezni az előadótól, milyen ködösítésre gondol? Esetleg arra, hogy azt mondjuk, az IT és az OT jelentősen eltér egymástól? Mert ha igen, akkor nem ködösítés: az IT és az OT eltér egymástól. Ha esetleg eddig ez nem tiszta az előadónak, javaslom, hogy legalább a SeConSys „Villamosenergetikai ipari felügyeleti rendszerek kiberbiztonsági kézikönyve” 16. sz. mellékletét olvassa el, vagy az általam írt „Az IT és az OT viszonyrendszere, a konvergencia humán és adminisztratív aspektusai” tanulmányt, ezek pont erről szólnak.

Véleményem szerint az OT nem ködösít semmit. Az, hogy az IT nem érti meg a preferenciáinkat – nem ködösítés, hanem kommunikációs probléma, amelyen láthatóan dolgoznunk kell még.

„Nekünk vannak olyan tanácsadó penteszter barátaink, akik foglalkoznak ilyen jellegű cégek auditálásával, és azt kell mondjuk, hogy az esetek 99%-ban a kapunál bedobunk egy IP csomagot, az ki tud kötni az alumínium öntő gépnél, ha ügyesek vagyunk.”

Remélem, hogy tényleg csak a manufacturing-ről állítja ezt az előadó, mert például ugye az erőművek is OT környezetek, ezért ha igaza van, nem tudom, hogy az NKI mivel töltötte az elmúlt éveket. De ha igaza van, akkor az előadó kérdezze meg az NKI-tól, az Ő hangja mélyebb.

De hogy azért legyen szakmai is a válaszomban, valószínűleg vannak ilyen és olyan rendszerek is. Például vannak olyan erőművek – többtízezer IO pontos irányítástechnikával – ahol nincsen terepi kiberfenyegetettség, mivel 30 éves rendszereket használnak és egyáltalán nincs az irányítástechnikában Ethernet meg IP. Sőt, ebből a szempontból gyártócégek is vannak, ahol PLC-s gyártógépeknél sincsen kiberfenyegetés, mert minden gép egy zárt, autonóm egység és nem kommunikál sehová, nincsenek is összekapcsolva. Nyilván vannak sajnos teljesen másképpen szervezett hálózatok és rendszerek is, de ennyi erővel ugyanez az IT-ról is elmondható lehetne.

„Odamegy a technikus és betölti az új kódot konkrétan a radiátorszelepet tekergető motorba, hogy lesz az menedzselve, amikor jön egy firmware upgrade?”

Kicsit bakafántos, de értem a kérdést és meg is válaszolom: sehogy. Azért, mert jön egy firmware upgrade, miért kellene frissíteni?

Az OT egyértelműen nem frissítéspárti. Ennek az az oka, hogy üzembiztonsági szempontból minden frissítés rendkívül kockázatos, nem lehet tudni, hogyan fog viselkedni az eszköz, vagy hogyan működik a frissített eszközön a program.

Az OT nem IT.

Nekünk (többnyire és általánosságban) nincsenek tesztkörnyezeteink, gondolom az csak nyilvánvaló, hogy erőművi turbinából vagy kazánból, kohóból, esetleg gyártósorból nem tartunk raktáron tartalék rendszereket. Mi általában nem tudunk tesztelni, ezért, ha lehet, akkor nem frissítünk. A frissítés sok rendszernél járhat egyébként is plusz tevékenységgel, mivel ugye csak leálláskor lehet, ezért az indítás előtt sokszor végig kell mennie a rendszernek egy komolyabb ellenőrzésen. Sőt, beszélhetünk a validált rendszerekről, ahol egy frissítés revalidációval járhat, amely több hónapos és rendkívül költséges játék. Szóval, ha jön a firmware upgrade, akkor általában – ha csak nincsen kényszerítő funkcionális igény vagy hibajavítás, nem történik semmi. (Persze azért megvannak erre a megoldások, a frissítéseket tesztelje ki a gép- vagy rendszergyártó/szállító/integrátor, és ha nem okoz üzembiztonsági problémát akkor jöjjön és telepítse és végezze el a szükséges ellenőrzéseket. Ha több azonos gép vagy gépsor van, az egyiket ki lehet jelölni „teszt”-nek a frissítés előtt – bár ezzel a megoldással sokan vitatkoznának, révén az sem jó ha csak egy sor vagy cella kiesik a frissítés hibája miatt).

„Valamilyen távoli hozzáféréssel kellene ezeket a menedzsmenteket megtenni”

Nem, még csak véletlenül sem. Firmware frissítést – és általánosságban frissítést – jellemzően tilos távolról csinálni. A jobb OT eszközök ezt konkrétan nem is engedik, sajnos azonban egyre több eszközben jelent meg ilyen távoli lehetőség, amelyet viszont legalább nem ajánlott használni. Kicsit parasztos, de én nem szégyenlem. A frissítéskor az eszköz valamilyen szerviz portjához lokálisan csatlakozva történik a frissítés, vagy kártyáról, esetleg a nagyobb DCS rendszerekben a DCS központi alkalmazás intézi az egészet, viszont ebben az esetben sem távolról. Általánosságban tehát tilos (vagy ellenjavalt), azonban néha nem elkerülhető. Viszont ebben az esetben szigorúan kontrolláltan és helyi szinten felügyeletet és beavatkozást biztosító személyzet jelenléte mellett történik az ilyen távoli beavatkozás, azaz előre lejelentetten, karbantartási ablakban és helyi közreműködéssel és ellenőrzéssel kísérve tud megvalósulni.

Ó persze, ott vannak a Windows munkaállomások vagy szerverek. De mint mondtam, az OT (hibás) szemszögéből ezek nem is OT eszközök. Gondolhatnánk, hogy ezeket aztán már lehetne frissíteni orrvérzésig – akár távolról is. Hát nem. A gyártók és szállítók egy adott szoftverkörnyezettel adják át a rendszereket. A különféle üzembehelyezési tesztek az átadott hardver-szoftver konfigurációhoz kötődnek, azaz a gyártók és szállítók az átadott állapotú rendszerre vállalnak garanciát és támogatást. A frissítés megváltoztatja a szoftveres konfigurációt és állapotot (integritást), ezzel veszélyezteti a létfontosságú szerződéses kereteket. A Windows esetében a frissítés az üzembiztonságot és a megbízhatóságot is veszélyeztetheti. Halvány sejtelmünk sincsen arról, hogy egy frissítés hogyan fog hatni az alkalmazás rétegre, és nem fog-e olyan hibát előidézni, amely a megváltozott szoftverkörnyezetre vezethető vissza. Még egyszer: az OT-nak jellemzően nincsen tesztkörnyezete.

„Ezeket úgy adják el, hogy a gyártó cégek, nagy német meg japán iparvállalatok úgy adják el, hogy ahhoz senki más nem nyúlhat hozzá csak ők…Magyarul veszek egy komplett gyártórendszert és lehetőséget adok Ló Bélának, hogy bármikor belépjen a gyártórendszerembe és ott mindenféle upgradet futtasson”

Igen, azt leszámítva, hogy Ló Béla nem fog upgradet csinálni, pláne nem bármikor.

A leírt állapot a bármikori upgradet leszámítva létező, jellemzően a nagy gyártók a kompletten leszállított vagy az általuk épített rendszerek esetében sokszor kiemelt jogosultságokat se adnak át az ügyfélnek, teljesen ismeretlen struktúrában működik a rendszer.

Az ilyen rendszereket az ügyfél, mint (tulajdonos) felhasználó kezeli, a rendszer felügyelete, analízise, (bizonyos) hibabehatárolása és a többi feladat a berendezés gyártó/szállító tevékenysége. De ez nem jelenti azt, hogy bármikor bármit csinálhat, ennek szerződéses korlátai vannak, amelyet mindkét fél maximálisan betart – se a medve, se a turbina nem játék. Erre megvannak az OT kialakult eljárásai, például néha még (lekapcsolt) ISDN vonalak élnek a régebbi technológiák felé a gyártóktól. Persze a modernebb környezetben ezt a távelérést is a gyártó alakítja ki, sok esetben azt sem lehet tudni, hogy mikor jönnek be, mivel perzisztens a site-to-site VPN kapcsolat (igen, a tűzfalat is a gyártó/szállító vagy az integrátor hozza, a VPN kapcsolatot is ő állítja be).

„Hogyan tudom azt biztosan, hogy aki belép karbantartani az az akit mondtak, milyen jogosultsággal tudom odaengedni, hogyan tudom a jogosultságokat kiosztani vagy visszavonni”

A fenti példa esetén sehogyan. Ilyen esetben az OT-nak semmi köze hozzá, ez a berendezés gyártó/szállító vagy integrátor tevékenysége, ezt nem műszakilag, hanem szerződéses keretek között szükséges kezelni (felelősség és kockázathárítás, supply chain, stb). Mivel nincsenek kiemelt privilégiumok a felhasználói oldalon, így semmilyen hasonló tevékenységet nem is tud az OT megtenni. Tudom én, hogy ez furcsa és riasztó az IT-nak, de az erőművi környezetek jó része így működik. A gyártás és termelés területen is lehet ugyanezzel találkozni, sokszor a gyári OT-s kollégáknak semmilyen kiemelt hozzáférése és jogosultsága nincs az ilyen rendszerekhez.

„A scan behozhat késleltetéseket, ami miatt egy nagy precizitású gyártási folyamat elkezd késleltetődni, ezt nem nagyon tudjuk megtenni, de van erre felkészült rendszer, ami tudja, hogyan lehet puhán szkennelni”

A vezérlések nagy része valósidejű. Például a PLC esetén van egy belső órajel, amely alapján végigmegy a vezérlési cikluson. Ha ez nem sikerül, ott van a watchdog timer, ami figyeli, hogy túllépi-e a ciklusidőt, és ha túllépi, akkor a ciklus megszakad és megáll, mert nem tudja tartani a ciklusidőt. Persze, végül is valahol az is „késleltetés”, hogy megállt az eszköz vagy a rendszer.

A terepközeli eszközök jó része (főleg a régebbi eszközök) rendkívül rosszul tűrik a klasszikus sérülékenységvizsgálatok során alkalmazott szkennelést. Lehet akármennyire is kicsi és puha, bizony nekünk az fájdalmas. Nem csak azért, mert túlterhelődhetnek, azt még csak-csak ki lehet(ne) csillapítani kellő próbálkozások után (bár addigra már megdöglöttek vagy elmentek stop-ba, és imádkozhatunk, hogy vissza lehessen őket hozni egyáltalán), viszont ott van még az a probléma is, hogy egyszerűen a kapott adatforgalmat nem értik és elkezdnek makrancosan viselkedni, finom és misztikus hibákat beleszőve a folyamatokba. Sőt, előfordul, hogy nem is a vizsgálat időablakában jelentkeznek a misztikus hibák, hanem a későbbi élesüzem alatt. Nem véletlen, hogy sok OT környezetben még leállási ablakban is tilos az aktív sérülékenységvizsgálat. Pont ezért jelentek meg a passzív sérülékenységvizsgáló eszközök, mint például a Clico által is forgalmazott remek Forescout, vagy a Nozomi, Claroty, OTORIO, Industrial Defender és egyéb kiváló megoldások.

Zárszó

Maroknyi kolléga elhivatottan küszködik azon, hogy hidat verjen az IT és OT közötti szakadék felett. Ennek természetesen nagyon sok edukatív oszlopa van, például meg kell próbálnunk az OT-val megértetni, hogy az IT nem ellenség, hanem jóbarát és együtt, közösen építjük fel a jövőt.

Az előadás a szakmai pontatlanságok mellett véleményem szerint bicskanyitogató stílusú, és nem szolgálja a konvergencia érdekeit. A ködösítő, fennkölt, elfedő, „igazi OT-s arcok” (a mezitlábas, rohadék adatbázisaikkal) nem szeretik, hogy ha ilyen stílusban beszélnek róluk. Szerintem pontosan az ilyen kinyilatkoztatások miatt nem sikerül közelebb hoznunk egymáshoz az IT-t és az OT-t.

Nem széthúzásra és ellenségeskedésre van szükség, hanem összefogásra. Erre számos jó példa van itthon is, talán a legjobb példa a már említett SeConSys kiberbiztonsági összefogás, amely ugyan jelenleg csak a villamosiparra terjesztette ki hatását, de példaértékű lehet más szektoroknak – és az IT szakembereknek. 

Az OT nem IT.

Más eszközökkel és másképpen működünk. Különbözünk és ezt az IT-nak tiszteletben kell tartania. A kiberbiztonságért és a konvergenciáért azonban együtt kell dolgoznunk és nem egymás ellen. Szabályzatokkal és technológiával. Tanulással és tudással. Szavakkal és előadással.

De nem ezzel az előadással.