Az ipari folyamatirányítórendszerek esetén az utóbbi időszakban egyre inkább az elmélet, hogy a zero trust-alapú hálózati architektúra-tervezésnek igenis van létjogosultsága. De mi is az a zero trust biztonsági modell (amit időnként neveznek határvédelem nélküli biztonsági megközelítésnek is)? Ha egyetlen mondatban kéne összefoglalni, akkor talán arról szól, hogy feltételezzük, hogy a támadókat a határvédelmi megoldásaink nem voltak képesek megállítani és már a belső (IT) hálózatainkban is rendelkeznek hozzáféréssel egyes erőforrásainkhoz és ebből kiindulva építsünk olyan biztonsági rendszereket és kontrollokat, amik ilyen esetekben is biztosítják a szervezet kiberbiztonsági csapata számára a hatékony ellenlépések lehetőségét az incidensek megelőzése, észlelése és mielőbbi felszámolása érdekében. Kicsit bővebben, a zero trust kifejezést még 1994-ben, a Stirling-i egyetemen doktorandusz Stephen Paul Marsh alkotta meg, az első zero trust architektúrát pedig a Google építette fel 2009-ben. A zero trust ideje ezek ellenére igazán 2018-ra jött el, amikor a NIST és az NCCoE munkatársai elkészítették a NIST SP 800-207-es számú publikációját. A ZT architektúra-tervezés során kiemelt szerep jut a felhasználók és az IT eszközök authentikációjának, vagyis senki és semmi nem kommunikálhat egy ZT szerint tervezett hálózaton, akit és amit nem tudtunk megbízhatóan beazonosítani.
Figyelembe véve, hogy az ICS rendszerek jellemzően az egyes szervezetek számára a leginkább kritikus rendszerek közé tartoznak, nem tűnik túlzásnak azt mondani, hogy ha valahol, hát pont az ICS rendszerek esetén van értelme a ZT architektúra alkalmazásának. Van azonban néhány (nem is mindig kicsi) probléma. A ZT architektúráknak van néhány olyan alapelve, mint például a kommunikáció (és a tárolt adatok) titkosítása vagy például a tanúsítvány-alapú authentikációra való képesség. Azonban pont az ICS eszközök és rendszerek (különösen az egy-másfél-két évtizedes vagy még régebbi rendszer-komponensek) korántsem biztos, hogy képesek ezeknek a biztonsági megoldásoknak a használatára.
A fentiek ellenére azért van nem kevés olyan ötlet és intézkedés a ZT-ban, amiknek az alkalmazását meg lehet fontolni az ICS rendszerek esetén:
- Célszerű azonosítani az összes, az ICS rendszerhez kapcsolódó (kimenő, bejövő és az ICS rendszer elemei közötti belső) hálózati kommunikációt (ez egyébként sem haszontalan dolog, a CIS biztonsági kontrollok hardver- és szoftver-leltárja mellett minden rendszer esetén célszerűnek tartanám egy komplett hálózati kommunikáció-leltárt is elkészíteni);
- A minimálisan szükségesre kell szűkíteni az ICS rendszer elemeihez történő távoli hozzáférést (és ezeket is célszerűnek tartom minden esetben egy privilégizált felhasználó menedzsment rendszeren keresztül biztosítani);
- Természetesen minimalizálni kell a rendszerhez hozzáféréssel rendelkező felhasználók jogait a feladatvégzéshez szükséges szintre;
- Erős (egyes publikációk megfogalmazása szerint adathalász-támadásoknak ellenálló) authentikációs megoldásokat kell használni (praktikusan multifaktor authentikációt);
- Ahol a hálózati kommunikáció ezt lehetővé teszi, célszerű lehet egyirányú átjárókat (unidirectional gateway-eket) használni;
- A logikai biztonsági kontrollokat fizikai hozzáférési kontrollokkal történő kiegészítését célszerű megvalósítani (a holisztikus biztonsági megközelítés egyébként is jóval hatékonyabb lehet, hiszen nem egy olyan helyzet adódhat, amikor egy egyszerű fizikai kontroll sokkal nagyobb kockázatcsökkentést eredményezhet, mint egy bonyolult - és éppen ezért drága - logikai kontroll alkalmazásával lenne elérhető);
A ZT egy másik kulcsfontosságú komponense az átfogó (biztonsági) monitoring képesség, vagyis a ZT hálózat minél több komponenséből kell logokat gyűjteni egy jól konfigurált SIEM rendszerbe. Viszont ahhoz, hogy egy ICS rendszerből a logokat egy SIEM rendszerbe hatékonyan lehessen gyűjteni, nagyon jó folyamatirányítási (villamos-, gépész-, vegyész-, stb.) mérnöki és kiberbiztonsági szakemberek első osztályú együttműködésére van szükség, különben már az ICS alkalmazások naplóbejegyzéseinek feldolgozása is nagyon komoly kihívást jelenthet az érintett szervezeteknek. Ez pedig megint ugyanazt a (nehezen feloldható) problémát hozza elénk, hogy egy jó IT-OT-kiberbiztonsági együttműködés nélkül az ICS kiberbiztonsági erőfeszítések szinte biztosan kudarcra vannak ítélve. Márpedig jelenleg azt látom, hogy a technológiai fejlődés (úgy az új IT/IoT technológiák ICS implementációja, mint az új IT technológiák kockázataira adott válaszként megjelenő IT biztonsági eszközök és technikák) gyorsabban fejlődnek, mint ahogy az ICS kiberbiztonsági téma szereplői az együttműködés terén ezt le tudnák követni. Így pedig jelenleg nagyon is kérdésesnek érzem, hogy mennyire lehet hatékony a ZT az OT környezetekben. Az érintett ipari szervezetek számára talán az lehet a legjobb megközelítés, hogy a Purdue-modellt már megfelelően alkalmazó hálózataikban a ZT bevezetését az L4-nél kezdik és haladnak "lefelé" az ICS DMZ, L3, L2 útvonalon - és nagyjából ez lehet az a pont, amíg komolyabb fennakadások nélkül meg fognak tudni tenni.
