Az aktív (scanner-ekkel végzett) biztonsági tesztelés mind a mai napig az egyik legnagyobb kockázatnak tekintett biztonsági tevékenység az OT világban. Nem véletlenül. Még a Purdue-modell magasabb szintjein (L2, L3) működő rendszerek esetén sem lehet garantálni, hogy egy biztonsági tesztelő (scannelő) megoldás használata nem zavarja meg a SCADA/DCS rendszerek működését (volt "szerencsém" ilyet tapasztalni, egyszer megfigyelőként, egyszer azonban aktív elkövetőjeként egy Loss-of-View eseménynek - pedig tényleg minden lehetséges és elvárható előkészítést és előzetes egyeztetést az üzemeltető és felhasználó mérnökökkel megtettem, mégis egy közepes méretű probléma lett egy sima port scan-ből).
Persze ma már nem csak aktív eszközökkel lehet információkat gyűjteni az OT rendszerek komponenseiről, hanem a már több, mint egy tucatnyi OT hálózatmonitorozó megoldás használatával passzív módon (pl. a hálózati forgalom SPAN porton vagy TAP-en keresztül kicsatolt másolatának vizsgálatával) vagy ugyanezeknek a megoldásoknak egy bár aktív (a DCS/SCADA szerverekre, operátori/mérnöki munkaállomásokra, hálózati OT hálózati eszközökre service userrel történő bejelentkezést igénylő), de a biztonsági scanner-megoldásokénál mégis sokkal kevésbé kockázatos - bár a legtöbb OT vendor ettől függetlenül továbbra is mereven elzárkózik az ilyen, bejelentkezést igénylő vizsgálatoktól, ami gyakorlatilag egyet jelent azzal, hogy maximum a rendszer tulajdonosának saját felelősségére lehet ilyen biztonsági vizsgálatokat végezni. Ezt pedig (idestova lassan 13 éves OT biztonsági tapasztalataim alapján) nagyjából soha, senki nem fogja felvállalni a vendor írásos hozzájárulása nélkül.
Az idei S4x konferencián Raphael Arakelian erről a témáról (egészen pontosan a PLC-k) biztonsági scanneléséről tartott előadást, ami egy kifejezett érdekes volt és néhány hónapja már elérhető az előadás teljes felvétele is: https://www.youtube.com/watch?v=yqhn4xPwbfQ&ab_channel=S4Events
Raphael megközelítése mellett mostanában támadt egy újabb ötletem a SCADA/DCS rendszerek elterjedt megoldásoknál sokkal durvább (akár behatolás-tesztelésig terjedő) biztonsági vizsgálataira vonatkozóan. A legtöbb OT vendor ma már kiterjedt biztonsági szolgáltatásokat kínál, gyakran Managed Security Services-ként cimkézve a szolgáltatásukat (ezek többnyire az IT rendszereknél már megszokott biztonsági tevékenységeket takarják, jellemzően patch-elés, AV/végpontvédelmi megoldás telepítése és rendszeres frissítése OT rendszerekhez dedikált AV-menedzsment szerverrel, loggyűjtés és elemzés, OT hálózatbiztonsági monitoring, mentés-visszaállítás, stb.). A mentés-visszaállítási tevékenységnél szeretek rákérdezni arra, hogy milyen gyakorisággal történik meg a mentések visszaállíthatóságának tesztelése. Sajnos láttam már arra is példát, hogy egy mentésről csak az adatvesztéssel járó (üzemeltetési) incidens után derült ki, hogy bár a jelek szerint rendszeresen sikeres volt a mentés elkészítése, nem lehet belőle helyreállítani a szervezet számára igen fontos adatokat, szóval jöhetett az adat-helyreállító cég. Ha pedig az OT vendor által kínált mentés-visszatöltés szolgáltatásnak valóban része az OT rendszer mentésének rendszeres (pl. évenkénti) visszatöltés-tesztelése (nyilván nem egy élesben üzemelő SCADA/DCS környezetben, hanem egy biztonságos, labor környezetben, amit a tesztek végén törölnek), akkor a visszatöltési tesztek után, de még a teszt/labor-környezet felszámolása előtt bármilyen üzembiztonsági kockázat nélkül lehet sérülékenység vizsgálatokat vagy behatolás-teszteket végezni a mentésből helyreállított folyamatirányító rendszeren.
