Nagyon régóta szemeztem már Dale Peterson ICS/OT biztonsági konferenciájával, az S4x-szel, de ilyen-olyan okok miatt mostanáig soha nem jutottam el rá. 2024-ben azonban már nem bíztam a véletlenre a dolgokat, így a jegyárusítás első pár napjában megvolt a jegyem és február 9-én útra kelhettem Floridába.
A korábbi évekkel ellentétben idén nem Miami South Beach-en, hanem Tampa városában rendezték meg az egyik legnagyobb múltra visszatekintő OT biztonsági konferenciát, de egyáltalán nem mondhatom, hogy bármilyen szempontból rossz lenne ez a helyszín (ennek ellenére már most lehet tudni, hogy jövőre megint - bár állítólag utoljára - Miami-ban lesz az S4x26).
Maga a rendezvény iszonyatosan profi, nagy rendezőgárda, mindenen és mindenhol látszik, hogy közel két évtizedes tapasztalat van Dale és csapata háta mögött. A konferencia belépőhöz járt egy szürke kapucnis pulcsi és Dale legújabb könyve (A year in OT security), ami egy 160 oldalas könyv és 12 fejezetben útmutatással szolgál bárkinek, aki szeretne az OT biztonság világába belépni vagy a tudását ebben a témában fejleszteni. Később, ha lesz időm végigolvasni, majd igyekszem erről a könyvről is írni egy rövidebb összefoglaló posztot.
Az S4x-nek évek óta van egy olyan nagyon szimpatikus vonása, hogy a konferencia minden előadását rögzítik és idővel a saját YouTube csatornájukon ezek a felvételek szabadon megtekinthetőek lesznek. Ha ez megtörténik azokkal az előadásokkal is, amiket én végignéztem, akkor az egyes bekezdések végére később frissítésként be fogom illeszteni az adott előadás YouTube-videójára mutató linket.
1. nap:
Tampában az S4x a korábbiakkal ellentétben három napos rendezvénnyé alakult, így a keddi volt az első érdemi napja a konferenciának. Erős felütésként az első előadás címe: Burning down cities. Annak fényében meg különösen, hogy éppen milyen hatalmas erdőtüzekkel küzdenek Los Angeles környékén. Brian Foster arról beszélt, hogy a különböző, IoT és IIoT megoldások az átlagos amerikai otthonokban hogyan válhatnak egy olyan tűzeset kiváltóivá, amivel az adott város tűzoltói már nem lennének képesek megbirkózni, egyszerűen csak a számosságukból adódóan (gyakorlatilag leDoSolva a város tűzoltó-kapacításait emberben vagy a tűzcsapok terén). Az igazán érdekes adat ebben az előadásban az volt, hogy mekkora a sérülékeny IoT és IIoT rendszerek aránya egyes nagyobb amerikai városokban (Los Angeles: ~23%, New York: 20%, Fort Worth, Texas: 18,8%).
A második előadást Jeffrey Macre, a Darktrace munkatársa tartotta, AI in OT and ICS security címmel. Az AI körül még mindig elég nagynak érzem a hype-ot, szerintem a technológia még nem képes arra, hogy az ICS/OT világban valódi értéket nyújtson, a generatív AI, ami még mindig a legnagyobb felhasználási területe az AI/ML modelleknek, kiberbiztonsági témában inkább a fenyegetések számát és súlyát növeli, mintsem a megoldás része lenne. Jeffrey előadása is részben alátámasztotta ezt a véleményemet, mert szerinte a felügyelet mellett használt AI/ML megoldások nem igazán alkalmasak új típusú vagy még ismeretlen támadások észlelésére vagy éppen a belső ember által végzett illegális vagy nem kívánt változtatások felfedezésére, ez a felhasználási mód (támadó-centrikus) igen nagy mértékben az AI/ML modell folyamatos tanítását igényli, vagyis elég magas az élőmunka-igénye.
Ezzel szemben a védekezés-fókuszú, nem felügyelt AI/ML használat képes lehet kiküszöbölni a fent említett hibák egy részét és az öntanulás miatt az élőmunka-igénye is kisebb lehet. Emellett azért szóba került olyan téma is (PLC kódok AI/ML-lel történő megíratása), ami egyrészt mutatja, hogy még mindig nagyon erősen tartja magát az AI = generatív AI gondolkodás, amit egyrészt roppant károsnak tartok, mert elveszi a fókuszt és a fejlesztési erőforrásokat az elemző illetve üzemeltetés-támogató AI/ML modellek fejlesztése elől, másrészt pedig ebben az esetben is felmerül a fejlesztők által AI/ML-lel megíratott program-részletek kapcsán már ismert probléma: hiába lehet "kiváltani" egy fejlesztés unalmasabb kódolási részeit, ha az AI által írt kódot később mégis embernek kell ellenőriznie, mert gyakran komoly minőségi problémák vannak az AI/ML által írt kódokkal. Ez már akkor is gond, amikor "csak" adatfeldolgozó kódot ír meg rosszul az AI, de mi fog történni, ha egy AI/ML által írt PLC kód hibái miatt safety incidensek történnek?
A harmadik előadás témája (Cyber Informed Engineering, előadó Andrew Ohrt) már régóta érdekelt, így nem lehetett kérdés, hogy ebben az idősávban ezt fogom megnézni/hallgatni. A CIE a mérnöki tervezési tevékenység evolúciójának következő természetes fázisa. A korábbi, kizárólag analóg mérnöki rendszerek ma már digitális tervezést, monitorozást, vezérlést jelent részben digitális, részben még analóg komponensekből álló rendszerek esetén.
A CIE-nek 12 alapszabálya van:
- Következmény-fókuszú;
- Mérnöki irányítású;
- Biztonságos információs architektúrára épül;
- Egyszerűsített tervek;
- Többszintű védelem;
- Aktív kiberbiztonsági védelem;
- Keresztfüggőségek kiértékelése;
- Digitális eszközök felismerése;
- Kiberbiztonsági beszállítói lánc ellenőrzés;
- Tervezett ellenállóképesség (rezilience);
- Mérnöki információ kontroll;
- Kiberbiztonsági kontroll;
A CIE-hez számos képességre van szükség, de ezek közül csak néhányat tudtam leírni (mérnöki tudás, üzemeltetői képességek, IT és OT kiberbiztonsági tudás). Andrew éhány alapvető kiindulási feltételezésről is beszélt:
- Minden digitális eszközünkről feltételeznünk kell, hogy sérülékenyek (ez szépen összecseng Mikko Hypponen régi mondásával: "If it is smart, it is vulnerable.");
- A támadók, akik a rendszereiket akarják kompromittálni, jól felkészültek és rendelkeznek a szükséges erőforrásokkal;
Néhány hasznos forrásanyag CIE témában:
CIE Quartery Webinar: What is Cyber-Informed Engineering?
A negyedik előadás, amit megnéztem, Justin Pascal-é (a Dragos munkatársáé volt), aki IT's impact on OT címmel arról beszélt, hogyan kell(ene) kezelni az ipari szervezetek rendszereit támadó zsarolóvírusokat. Az előadás egyik fő üzenete az volt, hogy a ransomware-ek egyre gyakoribb támadásai az ipari szervezetekre nézve ma már nem csak akkor jelent kritikus kockázatokat, ha a malware eléri az OT rendszereket, hanem akkor is, ha "csak" egyes fontosabb IT rendszerek működését lehetetlenítik el. Az első ilyen példa a NotPetya volt, de láttunk hasonlót a Norsk Hydro 201?-es incidensénél is, a Colonial Pipeline leállása is egyes fontosabb IT rendszerek (egy forrásom szerint a kereskedelmi rendszer) elvesztése miatt következett be. Az előadás lényegi témája az volt, hogyan lehet felmérni az IT rendszerek OT rendszerekre gyakorolt hatásait, ami alapján már pontosabban lehet tervezni, hogy mely IT rendszereket mennyire kell kritikusnak tekinteni a szervezet számára nélkülözhetetlen ipari-fizikai folyamatok esetén.
Az ötödik előadást ismét egy Dragos-os előadó, Logan Carpenter tartotta, aki az OT rendszerek sérülékenység-menedzsmentjének hogyanjáról és mikéntjéről beszélt. Elcsépelt frázis, hogy az OT-ban szinte semmilyen tevékenység nem tud ugyanúgy működni, mint az IT-ban, ez fokozottan igaz a sérülékenységek kezelésére is.
Logan először a CVSS sérülékenység-kategorizálási rendszer előnyeiről és hátrányairól beszélt. Hátrányból elmondása szerint több van... Az első, hogy a CVSS-t nem ICS/OT rendszerekre tervezték. Nagy mértékben szubjektív a pontozás (és ezáltal a sérülékenységek kategorizálása is) és túl sok sérülékenységet sorol a CVSS a kritikus kategóriába. Ezekkel szemben az előnye az, hogy jobb, mintha semmi sem lenne a sérülékenységek kategorizálására... Beszélt továbbá az SSVC (Stakeholder-Specific Vulnerability Categorization ) nevű másik sérülékenység-kategorizálási metodológiáról is, ami a Carnegi Melon Egyetem Szoftvermérnöki Intézetének és a DHS CISA munkatársainak közös projektjének eredményeként született és amiről a DHS CISA weboldalán lehet részletesebben olvasni: https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc
Végül pedig bemutatta a Now-Next-Never megközelítést (ami segít besorolni az egyes sérülékenységeket aszerint, hogy most - vagyis a lehető leggyorsabban -, az érintett ICS/OT rendszer következő ütemezett karbantartása során vagy soha nem fogja az érintett szervezet javítni az adott sérülékenységet) és az ehhez használható döntési fa-modelleket.
Ezután az előadás után beültem a Cisco Systems Prime room-jába (ezek a hazai konferenciákról, pl. ITBN-ről már ismert, kisebb termek, ahol max. 10-15 főnek tudnak bemutatni egyes, a rendezvényt szponzoráló cégek saját termékeket, szolgáltatásokat vagy azokhoz kapcsolódó ötleteket, módszereket). A Cisco előadása az OT SOC megvalósításáról szólt, erősen a cég által nemrég felvásárolt Splunk SIEM-et a középpontba helyezve. Alapvető újdonság ezen az előadáson és a kapcsolódó beszélgetésen számomra nem hangzott el.
A következő előadás, amire bementem egy technical deep dive-nak meghírdetett téma volt. Reid Wightman, a Dragos munkatársának az előadása már címével is figyelemfelkeltő volt: "Your IDS rules for ICS stink (and how to fix them)". A tartalom méltó volt a színpad nevéhez (technical deep dive), Snort és/vagy Suricata IDS-ekkel szerzett rutin nélkül elég gyorsan el lehetett veszíteni a fonalat, amire Reid a mondanivalóját felfűzte. A lényeg igazából az volt, hogy mennyire könnyen ki lehet kerülni a Snort/Suricata IDS-ek mintaillesztésre épülő riasztásai az egyes ipari protokollok esetén. A mély műszaki tartalom később sem hagyott alább, a Modbus/TCP protokollra épülő hálózati forgalmak Wireshark-ban történő elemzése központjában volt az előadás második felének. Viszont a bemutatott példákhoz tartozó tartalmak egy része elérhető Reid Github oldalán: https://github.com/reidmefirst/S4x25
A következő előadásban (Deep dive on low skilled threat actors) Ron Fabela az elmúlt évben történt, (főként) amerikai viziközmű szektorban működő kisebb cégek elleni, nagy port kavart kibertámadásokról beszélt. Olyan példákon keresztül, mint az iráni Cyber Av3ngers, az orosz RCAT/CARR, a feltételezhetően szintén orosz Z-pentest valamint a Usersec támadói csoportok által végrehajtott támadások, azt mutatta be, hogy ezeknek az incidenseknek az előidézéséhez a) nem kellett semmilyen szofisztikált sérülékenységet kihasználni és b) a későbbi vizsgálatok minden esetben azt bizonyíották, hogy ezek a támadások sokkal nagyobb hírverést kaptak, mint amekkora valós hatást gyakoroltak az érintett szervezetek fizikai folyamataira (ami minimális volt vagy éppen nulla).
Az ezt követő előadásan (A Severity Rating Scale For OT Security Incidents) Munish Valter-Puri az általa kidolgozott, OT biztonsági incidens-besorolási rendszert mutatta be.
Alapvető probléma, hogy jelenleg nincs jó és széleskörben ismert és elismert módszertan az OT rendszereket ért kiberbiztonsági incidensek súlyosságának mérésére. Ennek egyenes következménye, hogy amikor (sajnos egyre gyakrabban) egy újabb OT kiberbiztonsági incidensről érkeznek hírek, a sajtó gyakran sokkal komolyabbnak festi le az adott incidenst, mint amilyen az valójában volt. Munish ezt a fájóan hiányzó módszertant próbálja kidolgozni. Az előadás elején a különböző természeti katasztrófák (földrengés, szökőár, tűzvész, stb.) besorolási rendszerein keresztül mutatta be, milyen lehetőségek alapján történtek a hasonló besorolások más területeken, majd áttért az INfrastructure Cyber Incident scale (INCI) névre keresztelt módszertan bemutatására.
Az INCI három szempontból vizsgálja és pontozza az OT kiberbiztonsági incidenseket:
- Intensity - milyen mélységben tudta megzavarni a folyamatirányítást az incidens?
- Magnitude - az incidens hatása mennyire széleskörű?
- Duration - mennyi ideig tartott az incidens okozta zavar a folyamatirányításban?
Ezután Jim Miller előadása következett, Rating deployed OT firewalls címmel. Maga az előadás számomra érdekes volt, mert némileg hasonló munkát (is) végzek jelenleg és egyes tapasztalataim itt-ott visszaköszöntek Jim prezentációjában. Alapvetően a Layer3-Layer4 (IP címek és port/protokollok) szintjén vizsgálja a tűzfalszabályokat, a Next-Generation tűzfalak magasabb szintű (L7) funkciói inkább csak kiegészítésként jelentek meg a tűzfalszabályok minőségi vizsgálatában. Az én megítélésem szerint jól bemutatta az általános problémákat, bár tapasztalataim szerint a NGFW-k magasabb szintű (L7) funkcióit (pl. userID, Applicantion control, AV, stb.) az ipari hálózatokban jóval kevésbé lehet kihasználni, mint az IT hálózatok esetén.
2. nap
Keynote - Dale Peteson (S4x főszervező)
Dale 25 éve végez kockázatelemzéseket ipari szervezetek folyamatirányító rendszereivel kapcsolatban, de az első fél évtizedben szó szerint semmilyen változás nem történt, mert az auditokon feltárt hibák és hiányosságok priorizálását sem az auditor, sem az ügyfél nem végezte el. 2007-ben az egyik akkori ügyfele kérte, hogy segítsen ebben és ezután már elindultak pozitív változások az adott szervezet kockázatainak csökkentésében. A legfontosabb kiberbiztonsági kontrollok listája egyre csak nő (a DHS CISA egyik kiadványa 38, a 62443 51 különböző kontrollt sorol fel), ezek a nagy része a bekövetkezési valószínűség (likelihood) csökkentésére koncentrál és nem foglalkozik a következményekkel (consequences) - emiatt az érintett rendszerek kockázati egyensúlya megbillen.
Integrating Cybersecurity AI technology into OT - Ofir Arthin, NVIDIA
Ez az előadás nekem nem igazán illett az S4x-re, mert leginkább az NVIDIA saját AI-megoldásának a működéséről szólt, ahelyett, hogy a saját gyáraik termelésirányítási és egyéb OT rendszereikkel kapcsolatos felhasználásról mutatott volna be érdekesebb use-case-eket. Ez végül az utolsó 8-10 percben elkezdődött, de az arányokat én nem éreztem jónak - és akkor még nem is beszéltünk az olyan ötletekről, mint az AI-al végzett, üzem közbeni memória-forensics elemzések az OT rendszerekben, ami ugyan jól hangzik, de az én tapasztalataim szerint ezt sem a folyamatirányítási mérnökök, sem az OT vendorok nem fogják támogatni - ahhoz még nagyon sokat kell fejlődniük az OT vendor-folyamatoknak és gondolkodásnak, hogy erről akár csak ötlet szintjén is beszélni lehessen majd.
Fireside chat - Paul Griswold, volt Honeywell Chief Product Officer, Cybersecurity
Érdekes beszélgetés volt, olyan témákat érintve, mint például a DCS vendor oldaláról nézve hogyan látszik, az ügyfelek mennyit hajlandóak fizetni azért, hogy egy biztonságos(abb) DCS-t tudjanak használni (Paul szerint a DCS teljes árának kb. 10-15% lehet az a határ, amit az asset owner-ek még hajlandóak lehetnek kifizetni). Elhangzott, hogy a DCS vendorok nem cybersecurity vendorok, ami szerintem azért érdekes állítás, mert az én tapasztalataim szerint az OT vendorok egyre nagyobb része kínál OT cybersecurity megoldásokat is (pl. a Honeywell kb. 2 éve vette meg a SCADAFence nevű gyártót és most már csak ezt a megoldást kínálják, ha egy ügyfelük tőlük szeretne OT nw visibility megoldást venni).
Operating with Adversary Supplied Components - Emma Stuart, Idaho National Labs
Ez az előadás az amerikai villamosenergia-rendszer tároló- (akku-) kapacitásának (Bulk Electricity Storage System, BESS) nagy részét adó, kínai gyártású berendezések biztonsági kockázatairól szólt. Önmagában az, hogy az amerikai állami hivatalok az amerikai ICS/OT kiberbiztonsági szakma egy jelentős része és hosszú évek óta erősen gyanakvóan néz Kínára és az ott gyártott ipari berendezésekre, pl. transzformátorokra.
Emma Stuart előadása az általánosságoknál mélyebbre ment, beszélt a BESS elleni egyes lehetséges támadási módokról és azok lehetséges hatásairól, a kínai gyártású inverterek és akku-telepek sérülékenységeiről és a kínai beszállítói lánc okozta szervezeti kockázatokról is.
Ezeknek a kockázatoknak és kihívásoknak a megoldása egyáltalán nem könnyű. Tiltani, a kínai gyártású komponenseket eltávolítani/helyettesíteni nem mindig működő megoldás és elterelheti a figyelmet a jobb megoldásokról.
Nem leszünk képesek mindent megjavítani, de jócskán meg lehet nehezíteni azok dolgát, akik ezeket a sérülékenységeket ki akarják használni.
A hosszú távú siker záloga a public-private partnership és a megfelelő priorizálás lehet, ahol az iparági partnerekkel, tisztviselőkkel és alvállalkozókkal együttműködve lehet gyorsan telepíteni.
Identifying malware in factory program files - Mars Cheng, TXOne
Ez az előadás az itt kisebbségben lévő (vagy csak a hatodik érzékem jól működött és többre nem mentem be) termékbemutató előadások egyike volt. A szokásos módon a hagyományos antivírus/végpontvédelmi megoldások fals pozitív találatainak problémájával indított, majd áttért arra, hogy a Cyber Kill Chain és a MITRE ATT&CK használata csak a malware-detektálásban tud segíteni, a megelőzésben nem. Ezen a vonalon folytatódott az előadás, megelőzés-fókuszú (ami nyilván fontos, de ma már elég sokan tudjuk, hogy a megelőzés-észlelés-elhárítás hármas mindegyikével a saját helyiértékén kell foglalkozni), AI/ML-alapú működés.
Mars elmondása szerint viselkedési anomáliákat vizsgálnak, ami szintén nem számít ezen a téren újdonságnak (sőt, azt mondanám, hogy OT környezetben, figyelembe véve azok nagyon statikus és determinisztikus viselkedését, még jobban is működhet, mint az IT rendszerek esetén), de ahogy elmondta, az ő megoldásuknál nem számít, hogy az adott viselkedési anomália jó- vagy rosszindulatú -> ez viszont, AI/ML ide vagy oda, nekem azt mutatja, hogy egy ilyen megoldás használata még sokáig jelentős folyamatirányítási mérnöki tudást és részvételt igényelne a megoldás hatékony használatához.
Long conversation: OT and IT - convergence, integration and separation
Ez egy 90 perces program volt, más előadások miatt csak az első 30 percre tudtam bent maradni. Érdekes, számomra eddig ismeretlen forma, hogy 9 ember, 90 percen keresztül beszélget úgy, hogy egyszerre mindig csak ketten voltak a színpadon beszélgetni, majd 10 perc után az egyik résztvevőt váltotta egy új. Érdekesebb témák voltak:
- Jobb egyetlen, IT-t, OT-t és IoT-t lefedő cybersecurity statisztikát használni vagy hasznosabb több, specifikusabb statisztikával lefedni a különböző területeket?
- Elengedhetetlen a minél jobb szakmai kapcsolat az IT és OT szakemberek között, pl. az incidenskezelés enélkül alapjaiban válik lehetetlenné;
- Nincs olyan, hogy "csak IT-t vagy csak OT-t érintő incidens";
- Kiből lesz jobb OT security szakember? Folyamatirányítási mérnökből vagy IT biztonsági mérnökből?
Dynamic Edge Segmentation in Pharma - Mark Finch (GSK)
A gyógyszeripar gyártásautomatizálási és laboratóriumi rendszerei nagyon komplex környezetek, amiknél a biztonsági incidensek súlyos safety következményekkel járhatnak. A hálózatszegmentálást egy 6 fő mérföldkővel rendelkező idővonalon mutatták be:
1. Purdue modell-szerű kialakítás és fizikai elválasztás (airgap)
2. A Merck elleni 2017-es kibertámadás jelentősen megváltoztatta a teljes képet a projekt szempontjából
3. Átértékelve az ismert részleteket, úgy gondolták, hogy a tűzfalak és VLAN-ok nem hatékony eszközei a védekezésnek
4. Modern megoldásra volt (és van) szükségük, valami gyorsabbra és jobbra, mint amivel addig rendelkeztek
5. Modern architektúra szükséges a kiber-fizikai világ kihívásaira válaszul
6. Meg kell felelni a 62443-ban megfogalmazott zónák és adatutak leírásoknak
A hagyományos tűzfalszabályok helyett összetettebb, de véleményük szerint hatékonyabb policy-ket alkalmaznak, az új eszközökre dinamikus policy-k vonatkoznak.
PLC integrated security modul - Tamiki Kobayashi, Mitsubishi Electric
Az előadás a Mitsubishi Electric formabontó PLC fejlesztéséről szólt, amelynek során a Q- és R-sorozatú PLC-iket a Nozomi Networks Guardian nevű OT biztonsági termékével integrálták. Az előadást Tamiki Kobayashi tartotta, a Mitsubishi Electric Melsec PLC-inek korábbi fejlesztési vezetője tartotta, ennek megfelelően nagyon is deep-dive volt (hűen a színpad nevéhez, ahol az előadást tartották).
Az ilyenfajta PLC-biztonsági megoldás integrációt alapvetően háromféle módon lehet megoldani, külső eszközzel, dedikált CPU modullal és beágyazott intelligens modul használatával. A Mitsubishi Electric ez utóbbi megoldást választotta, aminek az egyik nagyon nagy előnye, hogy nincs hatással a PLC kontroll funkcióira.
Getting an installed base off the Internet - Anna Damon, Schneider Electric
Mit lehetett tanulni az elmúlt idők ICS/OT rendszereit ért kibertámadásokból (CyberAv3ngers és hasonló támadásokból)? Ezek a támadások (már az orosz-ukrán háború számos, ICS/OT rendszerét ért támadás és még inkább az izraeli-palesztin konfliktus azt mutatta, hogy számos támadás nem az APT-csoportokra jellemző kifinomult és újszerű módszerekkel érte el az ICS/OT rendszerek kompromittálását, hanem az alapvető ICS/OT biztonsági ajánlásokat - ne csatlakoztassunk folyamatirányító rendszereket publikus vagy bármilyen külső hálózatra - figyelmen kívül hagyva, elérhetőek voltak az Interneten). Ebből kiindulva a Schneider Electric munkatársai egy új kampányba kezdtek és elkezdték felmérni az Interneten elérhető termékeiket (ehhez a Shodan-t használták) az alábbi munkamódszert követve:
- Detection
- Identification
- Attribution
- Enrichment
- Contextualization
- Mitigation
Ez a projekt immár 3 éve fut a Schneider Electric-nél, ennek során 135.000 Interneten elérhető Schneider Electric ICS/OT eszközt/rendszert találtak. A feladatban az igazi kihívás az így felfedezett ICS/OT rendszerek üzemeltetőinek az azonosítása. Ehhez többféle megközelítést próbálnak alkalmazni, közvetlenül azonosítani a rendszer üzemeltetőjét illetve kormányügynökségeken keresztül jelezni az üzemeltetőnek, hogy miért nagyon rossz ötlet a felfedezett rendszereit ilyen módon elérhetővé tenni az Interneten.
3. nap
Fireside chat - Chistopher Anthony, Szingpúri kormány és Dale Peterson, S4x
Dale Szingapúrt egyfajta tesztlabornak tekinti a mérete és a modernsége miatt. Szóba került a CCoP (Cybersecurity Code of Practice), a szingapúri kiberbiztonsági ügynökség (CSA, Cybersecurity Agency), ami a szingapúri kiberbiztonsági törvény kritikus infrastruktúrákra vonatkozó szabályozásait tartalmazza (itt érhető el)
Személy szerint nekem nagyon tetszett a szingapúri CSA megközelítése, "szerelmes leveleket" küldenek azoknak a szervezeteknek, ahol kiberbiztonsági hiányosságokat vagy túlzottnak érzett kockázatokat éreznek: "Kedves XY szervezet! Tudjátok, hogy mi, a CSA-nál mennyire kedvelünk titeket és milyen nagyra tartjuk az általatok végzett munkát, azonban muszáj jeleznünk, hogy vannak bizonyos problémák az általatok üzemeltetett ICS/OT rendszerekkel..."
Kíváncsi lennék, itthon milyen következményei lennének (lennének-e egyáltalán), ha az NKI hasonlóan kedves, de határozott stílusban kommunikálna a hazai kritikus infrastruktúrák üzemeltetőivel?
Trust, reputation, data security and you - David Chamberlain, Orick
Az előadás témája a kibertámadások során gyakorolt kríziskommunikáció volt. Fel kell ismerni, hogy a cégekkel szembeni bizalom egy ugyanolyan céges vagyonelem, mint a termeléshez/szolgáltatáshoz használt eszközök. Szóba került, hogy mire van szüksége egy szervezetnek a bizalomépítéshez a kiberbiztonsági szakterület és a felsővezetés között? A ügyvezető- sés vezérigazgatók többsége szerint a vezetőknek (beleértve az IT és kiberbiztonsági vezetőket is) fontosabb jó üzletembernek lenni mint a saját szakterületén jó szakembernek.
Fireside chat - Tom Burke, OPC UA és Dale Peterson, S4x
Ugyan a beszélgetés az OPC UA-ra volt felépítve, de számos egyéb téma is előkerült, egyebek mellett a WonderWorld (az 1990-es években egyeduralkodó, PC-s ipari vizualizációs megoldás), a Rockwell és a 62443 is.
A beszélgetés második fele az OPC különböző alkalmazási területeiről (OPC DA, OPC HDA, OPC UA) szólt.
Assessing a cyber readiness at Florida - Ollie Gagnon, Idaho National Labs
Ez az előadás egy kifejezetten érdekes darab volt, azt mutatta be, hogyan építettek fel egy egész Floridát lefedő, kiberbiztonsági felkészültséget kiértékelő keretrendszert. Ez a megoldás nem csak a szövetségi állam szintjén, hanem akár az állam egyes megyéire és a megyék egyes településeire lebontva is meg lehet nézni a kiberbiztonsági felkészültségét.
Zones and conduits in the cloud - Dennis Hackney, Chevron
Egyre több folyamatirányító rendszer komponens kezd a felhőbe költözni (főleg, bár nem kizárólag az OT-DMZ-ből), az elsők ezek közül az IoT szenzorok felhős alkalmazásokban küldött adataival kezdődtek.
Az előadó bemutatott egy Cloud SCADA-modellt, ami meglehetősen felborítja a hagyományos, Purdue-modellt követő, SCADA-központű OT hálózati kialakítást, mert itt a SCADA rendszer teljes egésze a felhőben van, vagyis a Level4-Level5 fölött...
Ez pedig már előrevetíti, hogy az ISA/IEC 62443-as szabványban foglalt biztonsági szinteknek való megfelelés az SL-2/-3/-4 esetén komoly problémákkal kell szembenézniük azoknak, akik a felhőbe akarják költöztetni a SCADA/DCS rendszerüket és közben meg akarnak felelni a 62443-ban összegyűjtött követelményeknek.
Replacing likelihood with credibility in the risk equation - Andrew Ginter, Waterfall
Nem lehet ugyanazt a kockázatelemzési módszertant egy-az-egyben alkalmazni egy kicsi ipari szervezetre, mint egy földrajzilag nagy kiterjedésű rendszerre (pl. egy vasúti hálózat rendszereire). Azonban a törvények ezt nem mindig (különösen nem a nagyon nagy hatású eseteknél) engedik figyelembe venni.
A valószínűség (likelihood) egy véletlenszerű bekövetkezést feltételez, a kifinomult és leginkább veszélyes kibertámadások általában determinisztikusak, előre tervezettek és perzisztensek. Ráadásul a kiberbiztonsági incidensek a nagy hatású esetekben gyorsan fordulhatnak át safety incidensekké.
Power of collaboration to secure Critical Infrastructure - Seyd M. Belal, Hexagon
Váltani kell a silós megközelítésről az együttműködés felé, ez azonban gondolkodásbeli változásokat igényel. Az integráció alapvető fontosságú:
- egységes vizibilitásra,
- gyorsabb reagálási képességekre és
- a közösség által vezérelt információ-megosztásra lehet építeni ezt a fajta kritikus infrastruktúrák védelmének fejlesztését.
Nagyjából ennyit tudtam megnézni és jegyzetelni a három napos S4x előadásaiból. Ami ennek a konferenciának hatalmas előnye, hogy van egy saját YouTube csatornája, ahol az elkövetkező hetekben-hónapokban számos idei előadás felvételét elérhetővé fogják tenni a szervezők. Ha lesz időm ezeket a publikálásokat figyelemmel kísérni, akkor be fogom linkelni ezeket a felvételeket az egyes előadásokról írt rövid összefoglalókhoz. Szóval érdemes lehet néha visszanézni.