Otwarte i bezpieczne układy sterowania

 Zwiększenie otwartości i możliwości współpracy systemów sterowania z innymi systemami sprawiło, że stały się one bardziej podatne na złośliwe działania – zarówno wewnętrzne, jak i zewnętrzne. System sterowania może być otwarty, może współpracować z innymi systemami, ale to wymaga bardzo wnikliwego rozpatrzenia projektu, polityki ogólnozakładowej, procedur oraz dostępnych technologii. W ciągu ostatnich miesięcy coraz więcej mówi się na temat zwiększenia bezpieczeństwa sterowania i automatyki oraz zabezpieczenia ich… nie tylko przed ludźmi, którzy chcą coś sprzedać.

 Czy uczestniczycie Państwo w ogólnozakładowym planie bezpieczeństwa i czy zaadaptowaliście go odpowiednio do Waszego systemu sterowania? Aby uniknąć zjawiska określanego przez niektórych mianem „plug and plague” (angielska gra słów: plug and play – włączasz i używasz, plug and plague – włączasz, a tu klęska), trzeba podjąć następujące kroki:

1. Rozwiać mity utwierdzające w fałszywym poczuciu bezpieczeństwa. Typowe nieporozumienia: bezpieczeństwo to problem IT, a niedostępność urządzeń (PLC, DCS oraz wbudowanych czy innych układów sterowania) zapewnia bezpieczeństwo (większość włamań przeprowadzanych jest od środka). Inny fałszywy pogląd głosi, że firewall w zupełności wystarczy do ochrony („podróżujące” laptopy importują największą liczbę wirusów do systemów).

„Control Engineering pozostaje przy stanowisku, że należy czytelnikom pomagać unikać problemów"

2. Ocenić stopień bezpieczeństwa wynikający z analizy poszczególnych zagrożeń, łącznie z występującymi w systemach sterowania i automatyki, IT oraz innych. Należy oszacować poziom zagrożenia dla każdego ryzyka, przedstawić i zaproponować zabezpieczenia. Centrum każdego planu stanowią zasoby firmy, dalej – przesuwając się w kierunku na zewnątrz – mamy bezpieczeństwo systemu sterowania (i zdalny dostęp), bezpieczeństwo aplikacji, wykrywanie nieuprawnionych, zabezpieczenie przeciwwirusowe, firewall oraz odzyskiwanie utraconych w nagłych wypadkach archiwizowanych danych (backup recovery).

3. Określić zasady, zakomunikować je i przeprowadzać szkolenia w celu ich egzekwowania. Konsekwentne działania zniechęcają tych, którzy mieliby ochotę przysporzyć kłopotów; pomagają też uniknąć przypadkowego otwarcia systemu i narażenia go na atak.

4. Wdrożyć techniki wspomagające stosowane środki bezpieczeństwa. Pomocne są programy korekcyjne, tzw. łaty, i uaktualnienia. Na przykład Microsoft podaje, że jego program Windows Server 2003 automatycznie wyłącza wiele funkcji, ograniczając dostęp do sieci, gdy hasło nie zostanie wpisane, oraz redukując „obszar ataku” o 60%.

5. Przy każdej wprowadzanej zmianie rozważać kwestie bezpieczeństwa. Zmiany trzeba odpowiednio dokumentować i przeprowadzać stosowne szkolenia. Nie jest to wysiłek jednorazowy; trzeba oceniać, sprawdzać, dokonywać rewizji, szkolić – w dodatku robić to wszystko regularnie. Należy przyjąć, że kwestie bezpieczeństwa stanowią nieodłączną cześć każdej wprowadzanej zmiany. Podczas gdy media pełne są raportów o skutkach ataków, Control Engineering pozostaje przy stanowisku, że należy czytelnikom pomagać unikać problemów. Naprawdę wolałbym, żebyście Państwo potraktowali ten temat poważnie, zamiast pisać do nas później o przeżytych katastrofach.