Ma egy izgalmas cikket hoztam, David Formby a LinkedIn-en publikált még tavaly nyáron egy cikket, amiben a cikk megjelenése előtt néhány héttel történt Crowdstrike-frissítéses incidens kapcsán arról ír, hogyan tudná elképzelni a beágyazott ICS eszközökben (gyakorlatilag kontrollerekben) használt végpontvédelmi megoldások (Endpoint Detection and Response, EDR) megvalósítását.

David alapvetően arról ír, hogy a nagy automatizálási rendszerek (és kontrollerek) gyártóinak (Rockwell, Siemens, Schneider, Honeywell, Emerson, stb.) ugyanazt a megközelítést kéne alkalmazniuk, mint az Apple-nek a conzumer elektronikai piacon (az Apple, a Microsoft-tal ellentétben az EDR-gyártóknak nem biztosít kernel-szintű jogosultságot a végpontvédelmi megoldások számára, hanem egy Apple által fejlesztett és elérhetővé tett API-n keresztül kommunikálhatnak a biztonsági szoftverek az MacOS-sel). David szerint, mivel az automatizálási rendszerek gyártói ugyanolyan, teljeskörű kontrollal rendelkeznek a vezérlők hardvere és az azon futó szoftver felett, ezért képesek lennének hasonló, API-n keresztül történő biztonsági szoftver-hozzáférést biztosítani. Ez mindenképp paradigma-váltást jelentene, hiszen jelenleg semmilyen a Purdue-modell első szintjén (L1-en) működő berendezés esetén nem jellemző a biztonsági szoftverek telepítésének és használatának a támogatása (én legalább is még nem találkoztam olyan ICS vendor-ral, aki ilyen változtatást támogatottnak nyilvánított volna).

A kérdés csak az: valóban szüksége lenne a szakmának egy (vagy több) L1 eszközökön futtatható végpontvédelmi megoldásra? Vagy elég lenne a meglévő kontrollokat minél jobban és következetesebben használni és ezzel már meg lehetne előzni az L1 eszközök szintjén a kártékony kódok megjelenését?