Az anomáliaészlelés egy hálózat megszokott viselkedését tanulja meg, és azt jelzi, ami ettől eltér. A mintaalapú észlelés ezzel szemben ismert támadások lenyomatát keresi a forgalomban. Az első módszer ismeretlen támadást is észrevehet, cserébe minden szokatlan, de ártalmatlan eseményre is megszólal. Az, hogy egy rendszer hasznos jelzéseket ad, vagy a kezelők néhány hét után már oda sem néznek, nagyrészt a bevezetés utáni munkán múlik.
Egy OT-környezetben a módszer jobban működik, mint a legtöbb irodai hálózatban.
Miért működik jól az anomáliaészlelés az üzemben
Egy irodai hálózat forgalmát emberek alakítják: ki melyik weboldalt nyitja meg, mikor indít videóhívást, melyik felhőszolgáltatásba tölt fel fájlt. Ebben a zajban nehéz megmondani, mi a szokatlan. Egy gyártósor hálózatán a forgalom nagy részét gépek generálják, rögzített program szerint. A HMI ugyanazokat a vezérlőket kérdezi le ugyanabban az ütemben, a historian ugyanazokat az adatpontokat gyűjti, a mérnöki munkaállomás pedig ritkán, egy szűk eszközkörhöz kapcsolódik. A kommunikáló partnerek köre szűk, a protokollok száma kevés, a konfiguráció évekig változatlan maradhat.
A NIST SP 800-82 Rev. 3 (2023) OT-biztonsági útmutatója is kiemeli, hogy az ipari hálózatok forgalma jellemzően statikusabb és kiszámíthatóbb az irodai hálózatokénál, ami kedvez a viselkedésalapú felügyeletnek, és a passzív megfigyelést ajánlja, amely nem küld csomagot a hálózatra. A forgalom másolatának begyűjtéséről, a port-tükrözésről és a hálózati TAP-ről a passzív OT-eszközleltárról szóló cikk ír részletesen. Az anomáliaészlelés jellemzően ugyanerre az érzékelőre épül, a leltáron túl a forgalom változását is figyeli.
Az OT-ban van egy másik ok is, amiért a mintaalapú észlelés önmagában kevés. Egy támadó a vezérlőt gyakran ugyanazokkal a parancsokkal manipulálja, amelyeket a mérnöki szoftver is használ: egy regiszter írása vagy egy programletöltés a protokoll szerint teljesen szabályos művelet. Ilyenkor a csomag tartalmában gyakran nincs ismert támadási lenyomat. Az viszont feltűnhet, hogy a parancs egy olyan gépről érkezik, amely korábban soha nem írt, vagy olyan időpontban, amikor nincs tervezett munka.
A módszer határa is ebből következik. Ha a támadó a megszokott mérnöki munkaállomást veszi át, és a szokásos időben, a szokásos parancsokkal dolgozik, a forgalom nem tér el az alapvonaltól. Az anomáliaészlelés ezért a szegmentáció, a végpontvédelem és a hozzáférés-kezelés mellé kerül, és egyiket sem váltja ki.
Az alapvonal: tanulási időszak és ami kimarad belőle
Az alapvonal a hálózat rögzített normál állapota. Egy tanulási időszak alatt az érzékelő összegyűjti, mi történik a hálózaton, és ebből építi fel a viszonyítási alapot. Rendszertől függően ez többféle adatot tartalmazhat:
- a látott eszközöket címmel, gyártóval és ahol kiolvasható, firmware-verzióval,
- a kapcsolatokat: melyik gép melyikkel, milyen protokollon és porton kommunikál,
- a protokollműveleteket: ki olvas, ki ír, ki tölt le programot, ki vált üzemmódot,
- az időbeli mintát: milyen gyakran érkeznek a lekérdezések, mikor van aktivitás,
- egyes rendszereknél a folyamatváltozók tartományát, például egy alapjel szokásos értékeit.
A tanulási időszak hossza az üzem ritmusától függ. Egy folyamatosan, egyféle terméket gyártó soron rövidebb idő is elég lehet, egy több műszakos, gyakran átálló üzemben hosszabb kell. A rövid tanulás sok ritka, de jogos eseményt kihagy, ezek később riasztásként térnek vissza.
Ami kimarad
Bármilyen hosszú a tanulás, néhány esemény kimarad belőle, mert ritkábban fordul elő:
- az éves nagyleállás és az utána következő újraindítás,
- a redundáns vezérlőre vagy szerverre való átváltás, amely jellemzően csak hibánál vagy tervezett átváltási próbánál történik meg,
- a vészhelyzeti eljárások, a kézi üzemmódra váltás,
- a mentésből való visszaállítás és a ritka kalibrációk.
Ezeket érdemes előre összegyűjteni az üzemeltetőkkel, és vagy leírni a kivételek közé, vagy tudatosan elfogadni, hogy első alkalommal riasztást okoznak.
A tanulás azt rögzíti, ami van
Az alapvonal a meglévő állapotot rögzíti, a rosszat is. Ha egy irodai gép régóta közvetlenül eléri a vezérlőt, vagy egy gépegység az üzemeltető tudta nélkül kifelé kommunikál, a tanulás ezt is normálisnak könyveli el. Ha a hálózaton már a tanulás idején jelen van egy támadó, az ő forgalma is bekerülhet. Ezért mielőtt a rendszer észlelő módba vált, az alapvonalat át kell nézni: minden kapcsolat vagy jóváhagyást kap, vagy javítandó tételként a feladatlistára kerül. Az átnézéshez jó keret az IEC 62443 zóna- és csatornamodellje: ami két zóna között halad át, annak a csatornára vonatkozó szabályokban kell szerepelnie.
Mi számít eltérésnek: új eszköz, új kapcsolat, új parancs
Az eltérések súlya nagyon különböző. Egy új olvasó kapcsolat egy historian és egy vezérlő között ritkán sürgős. Egy programletöltés egy olyan gépről, amely korábban soha nem kommunikált a vezérlővel, azonnali vizsgálatot érdemel. Az alábbi táblázat a gyakori típusokat és azt foglalja össze, mire utalhatnak.
| Eltérés | Mire utalhat | Első kérdés |
|---|---|---|
| Új eszköz (új MAC- vagy IP-cím) | Karbantartói laptop, cserealkatrész, új gépegység, illetéktelenül csatlakoztatott eszköz. | Volt-e erre munkalap vagy beszállítói látogatás? |
| Új kapcsolat két ismert eszköz között | Konfigurációváltozás, új adatgyűjtés, oldalirányú mozgás a hálózaton. | Szerepel-e a zónák közötti engedélyezett forgalomban? |
| Új protokoll vagy szolgáltatás | Távoli asztal, fájlmegosztás vagy távelérési szoftver ott, ahol csak ipari protokoll fut. | Ki telepítette, és miért ezen a szinten? |
| Írási művelet új forrásból | Regiszter- vagy alapjelmódosítás egy olyan gépről, amely eddig csak olvasott. | Ki ül a gép előtt, és tud-e a változtatásról a műszakvezető? |
| Programletöltés, üzemmódváltás, firmware-frissítés | Tervezett mérnöki munka vagy a vezérlő logikájának szándékos módosítása. | Van-e változtatási kérelem, és egyezik-e az időpont? |
| Megváltozott ütem vagy elnémult eszköz | Hálózati hiba, eszközleállás, az érzékelő lefedettségének kiesése. | A folyamat oldalán is látszik-e hiba? |
| Szokatlan folyamatérték | Hibás mérés, kézi beavatkozás, manipulált alapjel. | Mit mutat a HMI és a helyszíni műszer? |
A súlyozásnál két szempont számít. Az egyik a művelet jellege: ami a folyamatba beavatkozik (írás, programletöltés, leállítás), az többet nyom a latban, mint egy olvasás. A másik a célpont: egy biztonsági funkciót ellátó vezérlő vagy egy kritikus gépsor eszköze más kezelést kap, mint egy épületfelügyeleti érzékelő. A riasztási szinteket ezért az üzemi kritikussági besorolással együtt érdemes beállítani, a gyári alapértelmezés ezt nem ismeri.
Az elnémult eszköz külön eset. Lehet, hogy az eszköz leállt, de az is lehet, hogy egy kapcsolócsere után megszűnt a tükrözés, és az érzékelő egyszerűen nem lát semmit. A csend tehát az észlelőrendszer saját állapotáról is szól.
Hamis riasztások: karbantartás, átállás, idényjellegű üzem
A bevezetés utáni hetekben a riasztások jelentős része jellemzően tervezett üzemi munkából ered. Egy üzem sokat változik, csak ritkábban és kiszámíthatóbban, mint egy iroda. A tipikus zajforrások:
- Karbantartás. A beszállító szervizlaptopja új eszközként jelenik meg, programot tölt le, firmware-t frissít. Mindez jogos, és mindez pontosan az, amire a rendszernek riasztania kell, ha nincs mögötte munkalap.
- Átállás. Termékváltáskor új recept, más paraméterek és más lekérdezési minta kerül a vezérlőkre. Ha a tanulás csak egyféle termék gyártása alatt zajlott, minden átállás eltérésnek látszik.
- Idényjellegű üzem. Egy fűtési rendszer télen máshogy működik, mint nyáron, egy kampányszerűen termelő üzemben hónapokig áll egy gépsor. A tanulási időszak nem fedi le az egész évet, ezért az évszakváltás is riasztást okozhat.
- Hálózati változtatás. Címátszámozás, kapcsolócsere, új VLAN: a forgalom ugyanaz, de az érzékelő számára új kapcsolatoknak tűnik.
A zaj kezelésére több eszköz van, és érdemes őket ebben a sorrendben használni. Először a tervezett munkát kell előre jelezni: a karbantartási ablak és a változtatási kérelem eljusson a riasztásokat kezelőkhöz, és ahol a rendszer engedi, az ablakhoz kötött eszközök és műveletek ne riasszanak, vagy alacsonyabb szinten jelenjenek meg. Másodszor, ahol az üzemnek több jól elkülönülő működési módja van, mindegyikhez külön alapvonal vagy profil tartozhat. Harmadszor, ha egy kivétel elkerülhetetlen, kapjon lejárati dátumot és felelőst.
A hangolás célja egy olyan riasztásmennyiség, amelyet a kezelők minden egyes esetben valóban megnéznek. Ha a riasztások többsége tartósan zaj, kialakul a riasztási fáradtság: az érdemi jelzés is elsikkad a többi között, mert senki nem nyitja meg.
Ki dönt egy riasztásról: üzem és IT
Egy OT-riasztás értékeléséhez kétféle tudás kell. Az IT-biztonsági szakember tudja, hogyan néz ki egy oldalirányú mozgás vagy egy távelérési eszköz visszaélésszerű használata. Azt viszont csak az üzem tudja megmondani, hogy aznap éjjel volt-e tervezett programmódosítás, és hogy a megváltozott alapjel egy kezelő döntése volt-e. Ha a riasztás csak az egyik oldalhoz fut be, vagy túl sok téves vizsgálat indul, vagy a valódi eset marad értelmezés nélkül.
Működőképes rend akkor alakul ki, ha előre le van írva, ki mit csinál:
- Az első szűrés ellenőrzi, van-e az eseményhez munkalap, változtatási kérelem vagy bejelentett beszállítói munka.
- Ha nincs, a riasztás a folyamat gazdájához vagy a műszakvezetőhöz kerül, aki meg tudja mondani, ismert-e a tevékenység.
- A döntés három kimenetű: várt esemény (az alapvonal frissül), nem engedélyezett, de ártalmatlan esemény (az eljárást kell javítani, például a karbantartás bejelentését), vagy gyanús esemény (az incidenskezelési eljárás indul).
A beavatkozásnál az OT-környezet saját szabályai érvényesek. Egy kapcsolat automatikus blokkolása leállíthatja a gyártást, vagy megszakíthatja egy biztonsági funkció kommunikációját, ezért OT-ban az észlelőrendszer többnyire csak jelez, a beavatkozásról pedig az üzem dönt. Hogy melyik helyzetben szabad egy kapcsolatot bontani vagy egy gépet leválasztani, azt nem riasztás közben kell kitalálni. Ennek az incidenskezelési tervben a helye, az OT-ra vonatkozó szerepkörökkel és a műszakon kívüli elérhetőséggel együtt.
A szabályok és az alapvonal gondozása
Az alapvonal a bevezetés napjától kezdve avul. Új gépsor érkezik, vezérlőt cserélnek, a historian új adatpontokat gyűjt, egy cella új kapcsolót kap. Ha ezek a változások nem jutnak el az észlelőrendszerhez, két dolog történhet: a rendszer folyamatosan riaszt a már jóváhagyott forgalomra, vagy valaki széles kivétellel elnémítja, és onnan kezdve a terület vakfolttá válik.
A rendszeres gondozás feladatai:
- Az alapvonal frissítése a változások után. Egy beruházás vagy eszközcsere lezárásakor a várható új kapcsolatokat és eszközöket jóvá kell hagyni, és ezzel az alapvonal is frissül.
- Új eszközök felvétele a felügyeletbe. Egy új gépsor saját kapcsolón vagy cellában csak akkor látszik, ha az érzékelő oda is kap tükrözött forgalmat.
- A szoftver és a felismerési szabályok frissítése. Az érzékelő protokollelemzői és fenyegetésfelismerő szabályai frissítést igényelnek, és maga az észlelőrendszer is szoftver, amelynek sebezhetőségei lehetnek. A kezelőfelületét egy védett menedzsmentzónában érdemes tartani.
- A kivételek felülvizsgálata. A lejárt kivételeket törölni kell, a maradók indoklását és felelősét ellenőrizni.
- A lefedettség ellenőrzése. Minden megfigyelt pontról érkezik-e adat, és egyezik-e az eszközlista a leltárral.
Időnként érdemes a riasztásokat egészében is visszanézni. Mely szabályok szólnak meg folyamatosan, és melyek nem szóltak meg soha? Az előbbieknél hangolni kell, az utóbbiaknál azt érdemes ellenőrizni, hogy a szabály egyáltalán látja-e a forgalmat, amelyre írták. Egy rendszeres, például negyedéves áttekintés, amelyen az üzem és az IT együtt nézi át a riasztásokat, a változásokat és a nyitott tételeket, segít abban, hogy az alapvonal kövesse az üzemet, és a riasztások ne veszítsenek a hitelükből.
Kapcsolódó szolgáltatás: OT védelmi platform gondozása →
