Egyre több olyan szándékos támadást észlelnek, amelyek ipari irányító rendszereket (ICS) céloznak meg, mivel ezek sebezhetők lehetnek a kibertámadásokkal szemben. A jelenlegi legjobb gyakorlat a kiberbiztonság terén az, hogy egy összetett vállalati védelmi „buborékot” építenek az ICS célpont köré, miközben igyekeznek a rendszert teljesen elszigetelni. Ez magában foglalhatja a demilitarizált zónák létrehozását az üzleti hálózat és az ipari hálózat között, a hordozható eszközök használatának tilalmát az ipari hálózaton, a biztonsági javítások rendszeres telepítésének biztosítását, a személyzet átvizsgálását és képzését, a rendszerek tervezési szabályainak betartását, az adatok korlátozását, a hálózat szegmentálását és a javítási politikákat. Azonban semmilyen eljárás, képzés és technológia nem pótolhatja az ICS alapvető hibáit.

A javítások például nagyon fontosak, de nagyon drágák is, és további kockázatokat hordoznak az ICS esetében, mivel hatással lehetnek egy kritikus folyamat teljesítményére. Az ilyen gyengeségek mindig olyan sebezhetőségekhez vezetnek, amelyeket a támadók kihasználhatnak, hacsak nem javítják az ICS alapvető biztonságát.

1Illusztráció: iStock

Példátlan mennyiségű biztonsági sebezhetőség derült ki az ICS rendszerekben, de vannak jól bevált stratégiák, amelyek alkalmazhatók a biztonsági sebezhetőségek felderítésére és enyhítésére, valamint az alapvető biztonság javítására. Például az injekciós támadások megelőzése érdekében az ICS rendszereknek érvényesíteniük kell minden bemeneti adatot, amelyet kapnak. A hálózaton keresztül történő adatlopás megakadályozása érdekében az adatokat titkosítani lehet. Annak biztosítása érdekében, hogy a konfigurációkat ne lehessen megbízhatatlan forrásokból letölteni, felhasználói és eszköz-hitelesítést lehet bevezetni. Az ICS rendszerek más biztonsági gyengeségeinek felderítésére teszteléseket lehet végezni, mint például a forráskód statikus elemzése, a fuzz tesztelés és a bináris kód elemzése.

Miért fontos az ICS rendszerek tanúsítása?

A nem tanúsított termékek képességei általánosak, és csak véletlenszerű jogsértésekkel vagy nem célzott támadási módszerekkel, például a szociális mérnökséggel szemben képesek védeni. Az ICS és a felhőalapú megelőző karbantartó eszközök közötti biztonságos interfészek interoperábilis biztonsági megközelítéseket igényelnek, ami nem lehetséges nem tanúsított termékekkel. Az ICS modulok hamisítása elterjedt, és olyan fejlett, hogy nehéz megkülönböztetni a hamis és az eredeti termékeket. Bár a hamisítást elsősorban pénzügyi nyereség céljából használják, a rosszindulatú szereplők ezt a módszert támadási vektorként használják a hamis termék firmware-jébe ágyazott rosszindulatú programok révén. A jövő útja olyan rendszerek tervezése, amelyek mélyen beágyazott belső védelmi mechanizmusokkal rendelkeznek, amit csak tanúsított termékek biztosítanak. Például a belső hardver és firmware hitelesítés erős titkosítással azonnal felismeri és elutasítja a kifinomult hamisítványokat, kiküszöbölve ezt az erős kiber-támadási vektort. A tanúsított termékek megőrzik hitelességüket, mivel könnyű észlelni a jogosulatlan változtatásokat a komponensek firmware-jében és/vagy szoftverében, megnehezítve a jogosulatlan változtatások végrehajtását.

Titkosítás az ICS-ben

A titkosítást két alapvető módon lehet használni az ICS rendszerekben. Az első az üzenetek és a rendszeradatok tartalmának elrejtése. A titkosítás második alkalmazási módja a hitelesítés, azaz a firmware frissítés a megfelelő forrásból származik-e? Megváltoztatták-e? Az ICS modul valódi hardver-e? Az új felhasználói logika a vezérlő számára engedélyezett forrásból származik-e? Ez a beállítási pont változása egy engedélyezett forrásból származik-e? A titkosítás nemcsak egyértelmű választ ad ezekre és más kérdésekre, hanem ami még fontosabb, biztosítja, hogy az üzenetek, a kódbeli változtatások és a kezelői műveletek, amelyek nem felelnek meg a hitelesítésnek, elutasításra kerüljenek. A titkosítás jelentősen megnehezíti az ICS elleni kiber-támadásokat.

Az ICS tanúsítása három elemet tartalmaz:

  • Kommunikációs robusztussági tesztelés (CRT): A CRT vizsgálja az ICS képességét arra, hogy megfelelően fenntartsa az alapvető szolgáltatásokat, miközben normális és hibás hálózati protokoll forgalomnak van kitéve normál és rendkívül magas forgalmi terhelés mellett (flooding állapot). Ezek a tesztek konkrét teszteket tartalmaznak az ismert hálózati támadásokkal szembeni sebezhetőségre vonatkozóan.
  • Funkcionális biztonsági értékelés (FSA): Az FSA az ICS biztonsági képességeit vizsgálja, elismerve, hogy bizonyos esetekben a biztonsági funkciók más összetevőknek is el lehetnek osztva az egész rendszeren belül.
  • Szoftverfejlesztési biztonsági értékelés (SDSA): Az SDSA az ICS fejlesztésének folyamatát vizsgálja.

ISA/IEC 62443 és a biztonsági szint követelmények

Az ISA/IEC 62443-3-2 szabvány előírja, hogy az üzemet biztonsági zónákra kell bontani, amelyek csatornákon keresztül kapcsolódnak egymáshoz. Ezután a biztonsági kockázatértékelési folyamat segítségével különböző biztonsági szinteket rendelnek a különböző zónákhoz és csatornákhoz az alapján, hogy milyen következményekkel járna, ha egy támadás célkitűzése megvalósulna azon a zónán belül. A biztonsági szintek (1-től 4-ig) függvényében különböző intézkedéscsomagokra van szükség, amelyek kumulatívak és minden szinttel növekednek. Bár a biztonsági szint képessége a zónákra és a csatornákra vonatkozik, az adott zónán belül lévő ICS-nek is rendelkeznie kell a biztonsági szint képesség tanúsítvánnyal.

SL1 előírja a képességeket az alkatrészek véletlenszerű vagy alkalmi hozzáférés, visszaélés vagy manipuláció elleni védelmére. Nem minden terméknek kell tanúsítvánnyal rendelkeznie egy zónában – például az általános termék képességek fedezhetik a nem szándékos támadásokat, és ezért használhatók az SL 1 zónákban.
SL2 zónákban szükségesek a tanúsított termékek, amelyek további biztonsági funkciókat biztosítanak, például olyan eszközök, amelyek képesek egyedileg megkülönböztetni az emberi és nem emberi felhasználókat, hitelesíteni magukat a rendszerhez, amelybe integrálódtak, lezárni az inaktív kommunikációs csatornákat, amelyek potenciális támadási felületként szolgálhatnak, és ellenőrizni a kommunikáció forrását az adott alkatrészhez. Ezek mind hozzájárulnak a hálózati támadási források korlátozásához. Ez azt jelenti, hogy egy SL2 szintre tanúsított ICS több kiberbiztonsági követelménynek felel meg, és magasabb szintű védelmet nyújt, mint egy SL1 szintű.

ISASecure tanúsítás

Az ISASecure program egy tanúsítási rendszer, amely a polcról leemelhető automatizálási és irányítórendszereket tanúsítja az ISA/IEC 62443 sorozatú szabványok szerint. A termékértékeléseket egy globális hálózatban működő, ISO/IEC 17065 akkreditált ISASecure tanúsító szervezetek végzik. Az ISASecure tanúsítási előírásait kiegyensúlyozott tagság dolgozza ki, beleértve a végfelhasználókat, beszállítókat, eszközszállítókat, felhőszolgáltatókat és automatizálási szállítókat.

Az ISASecure-t 2007-ben alapították, és a következő tanúsítási rendszereket kínálja:

Következtetés

Az ICS rendszerek korlátozzák a lehetőséget, hogy az operátorok szoftverváltoztatásokat hajtsanak végre vagy biztonsági szoftvert adjanak hozzá a telepítés után. Ez korlátozza az ellenintézkedések végrehajtásának lehetőségét, és bizonyos esetekben sebezhetővé teszi őket a támadásokkal szemben. Ezért alapvető fontosságú, hogy az ICS gyártásától kezdve beépítsük a biztonságot. Az olyan klasszikus ellenintézkedések, mint a titkosítás, hitelesítés, integritás-ellenőrzés, behatolás-megelőzés és biztonságos frissítési lehetőségek beépítése jelentős biztonsági javulásokat eredményezhet.

Nemzetközi szabványok, például az ISA/IEC 62443 és a bevált megfelelőségi értékelési programok, mint az ISASecure, biztosítják a biztonságos fejlesztési életciklus és a biztonsági képességek követelményeit, amelyek beépített biztonság támogatására alkalmazhatók. Az ISA/IEC 62443 releváns részeire vonatkozó független tanúsítás bizalmat adhat az ICS alapvető biztonságában.