Az ICS kiberbiztonság egyesek szerint két jelentős ok miatt más, mint az általános IT biztonság, az első az ipari rendszerek által használt egyedi protokollok, a második pedig a gyakran 15 évnél is régebbi végponti célrendszerek (PLC-k, RTU-k és egyéb ipari végponti berendezések) nagy számban történő alkalmazása.

Az ICS rendszerek kiberbiztonságának helyzetét részben az általuk használt kommunikációs protokollok biztonságának javításával lehet előre mozdítani, erről tartott nemrég egy webes előadást Erik Schweigert (Belden) és Joel Langill (SCADAhacker.com), ahol a DNP3 ICS protokoll biztonsági kérdéseivel foglalkoztak. Az előadás teljes terjedelmében itt érhető el (regisztrációt igényel): http://www.globalspec.com/events/eventdetails?eventid=1121&evtsrc=519Blog Bár a DNP3 protokoll használata Európában és Magyarországon nem jellemző, az előadás szerintem mégis érdekes és hasznos gondolatokat tartalmaz.

Az előadás fontosabb gondolatai az alábbiak:

A DNP3 (és a DNP3 helyett Európában meghatározó 104-es protokoll, IEC 60870-5-104) nagyon jó alacsony sávszélességgel rendelkező WAN hálózatokon történő kommunikáció stabil működésének biztosítására, emiatt széles körben használják a villamosenergia, kőolaj és földgáz szektorokban.

A DNP3 (hasonlóan a Modbus-hoz) tervezési okokból nem vizsgálja az egyes hálózati üzenetek legitimitását, vagyis egy alállomási eszközből érkező (a központi rendszer által nem kért) üzenettel könnyedén lehet üzemzavart előidézni. Ilyen volt a Marochy-Shire csatornarendszerben történt incidens, amikor egy hamis alállomási eszközről a felügyeleti rendszerbe érkezett üzenet hatására 1.000.000 liter szennyvíz került leeresztésre a rendszerből.

A beágyazott szoftvereket futtató eszközöket nem lehet host-alapú biztonsági eszközökkel megvédeni, általánosan kevés olyan  kontroll van, amit úgy lehet az ipari végponti berendezések biztonságának növelése érdekében alkalmazni, hogy az ne legyen hatással az eszköz alapvető funkcionalitására, teljesítményére és válaszidejére (elég csak a nemrég publikált Moxa sérülékenységre gondolni, amit a gyártó nem tud javítani egy egyébként még három évig támogatott eszközön, mert a patch forráskódja már nem fér el a rendszerben). Emiatt az ipari berendezések preventív műszaki kontrollját biztosító megoldásokat jellemzően az ipari hálózatok határvédelmében szokták alkalmazni.

Az ICS biztonság nem kizárólag a támadókról és a tevékenységük által jelentett fenyegetésekről szól, legalább ennyire fontos a megbízhatóság is (ahogy erről korábban már én is írtam). Az előadásban három olyan ICS incidenst mutatnak be, amiket nem malware-ek váltottak ki, de komoly üzemzavarokat okoztak az energiaszektorban és autógyártásban érdekelt cégeknél. Az előadásban külön kiemelik, hogy azokat a 15-25 éves ipari berendezéseket, amiket még jóval az Internet széleskörű elterjedése előtt terveztek és gyártottak, hogyan kell megvédeni a ma már mindennapos támadásoktól és az olyan hálózati forgalomtól, amit ezek az eszközök nem tudnak tolerálni.

Az előadásban egy nagyon jó animált hálózati diagramon bemutatják, hogy egy malware hogyan képes megkerülni egy erőművi ipari hálózatot védő tűzfalat és hogy egy hálózati eszköz meghibásodása hogyan idézheti elő PLC-k egy csoportjának kiesését. Ezek a példák igen jól bemutatják az ICS eszközök biztonságának kihívásait.

Az IEC 62443 (Zones and Conduits model) alapján bemutatják, hogyan kell hatékony mélységi védelmet kialakítani ICS rendszerek esetén. Ipari tűzfalak használatával a végponti berendezések kommunikációs csatornáira alapuló védelmét lehet megvalósítani, így biztosítva az automatizálási rendszerek védelmét malware és véletlen hálózati meghibásodások okozta incidensek ellen. Az előadásban azt is kiemelik, hogy az IEC 62443 általában egy meglehetősen nehezen értelmezhető koncepció az IT szakemberek számára, mert a vállalati IT-ban nincs megfelelője. Arról is beszél, hogyan lehet az IEC 62443-at Windows XP-t futtató PC-k és beágyazott operációs rendszerű eszközök biztonságának fokozására.

Az előadás utolsó nagyobb szekciója a hálózati csomagelemzésről szól és bemutatja azt is, hogy miben különbözik a protokoll-alapú DPI a mintaillesztéses DPI-től.

Az előadásban ezután még szó esik arról, hogy miért kell egyszerűnek lennie az ICS biztonsági megoldások ICS üzemeltetők (Operations Technology, OT) általi implementációjának (én inkább azon a véleményen vagyok, hogy az ICS biztonság megfelelő szintjének elérése érdekében a legjobb eredményt az hozza, ha az IT biztonsági és OT szakterületek folyamatos együttműködésére és információcseréjére építünk).