Automatyka budynkowa to często luka w cyberbezpieczeństwie

Moment, w którym „Pan Bezpiecznik” miał rację

To był stresujący moment — bo ostatnią rzeczą, jakiej się chce, jest opóźnienie podpisania protokołu odbioru z powodu zastrzeżeń działu IT i cyberbezpieczeństwa. Ale też moment pouczający, bo on miał rację.

Czasy, w których żyjemy, są wariackie. Nie trzeba już rozmachu Ethana Hunta, żeby wyobrazić sobie, że podłączenie się do kabelka przy klimakonwektorze i szukanie dziur w zabezpieczeniach sieci może mieć sens.

Modbus/TCP ma trzydzieści lat i nie zna szyfrowania

Automatyka budynkowa została pod tym względem daleko z tyłu za światem IT. Modbus/TCP — jeden z najpopularniejszych protokołów — ma około trzydziestu lat i z założenia nie przewiduje ani uwierzytelniania, ani szyfrowania. Powstał do zamkniętej, zaufanej sieci przemysłowej, a nie do świata, w którym każdy segment sieci trzeba traktować jako potencjalnie wrogi.

Dopóki taki protokół pozostaje w użyciu, trzeba go traktować jak lukę w zabezpieczeniach — niezależnie od tego, jak dobrze działa od strony sterowania.

Separacja to standard, ale sama nie wystarcza

Odseparowanie galwaniczne sieci automatyki od sieci klienta to już standard — raczej nikomu nie przyjdzie do głowy routować takiego ruchu po firmowym LAN-ie. To jednak nie zamyka tematu. W obrębie samego segmentu automatyki nieszyfrowany protokół nadal pozostaje słabym punktem.

Dlatego właściwym podejściem jest konwersja Modbus do czegoś bezpieczniejszego jak najbliżej urządzenia — tak, aby wrażliwy, nieszyfrowany ruch obejmował możliwie najkrótszy odcinek.

Koszt policzalny wobec ryzyka

Takie podejście podnosi trochę koszt inwestycji. Ale to koszt policzalny — i nieporównywalnie niższy niż koszt incydentu, który wyląduje na głównych stronach portali informacyjnych.

Bezpieczeństwo automatyki budynkowej nie jest dodatkiem doklejanym po wdrożeniu. To element, który albo zaprojektowano od początku, albo trzeba będzie kosztownie nadrabiać — zwykle wtedy, gdy zapyta o to audytor klienta.