Każdy układ automatyzacji ma przynajmniej jedną stację operatorską ze sprzętem komputerowym, choć na ogół ma ich więcej. W dużych układach, gdzie zwykle mamy do czynienia z siecią transmisyjną, wiążącą całość układu w system, poza komputerami w operatorniach, występują też na obiekcie programowalne sterowniki oraz coraz popularniejsze interfejsy użytkownika (HMI) z bezpośrednim dostępem do systemu automatyki. Poza tym możemy mieć także do czynienia z wbudowaną (osadzoną) w urządzeniach technologicznych inteligencją, czyli układem mikroprocesorowym. Każda taka stacja robocza musi być wyposażona w pewną liczbę programów, najczęściej o modułowej strukturze ze specjalizowanymi sekwencjami, instrukcjami, procedurami obliczeniowymi, protokołami czy kodami.To znana wszystkim oczywistość.
Ten wysoki i stale rosnący poziom złożoności systemów automatyki i zarządzania stanowi olbrzymie wyzwanie z punktu widzenia potrzeby wprowadzania zmian do programów, ale też z punktu widzenia konieczności zapewnienia bezpieczeństwa dla systemu, czyli ustrzeżenia się przed wprowadzeniem zmian niedopracowanych lub nieupoważnionych. Zaostrza ten problem fakt, że coraz więcej elementów sprzętu jak i programów użytkowych pochodzi od różnych producentów.Także coraz szersze opieranie się na rozległych sieciach transmisyjnych włącznie z Internetem nie tylko powiększa niebezpieczeństwo zakłócania pracy, ale też otwiera system automatyki i system zarządzania całym przedsiębiorstwem na celowe ataki z zewnątrz.
Do niedawna opatentowane protokoły oraz odizolowane sieci czy ich fragmenty zapewniały wystarczający poziom zabezpieczenia przed zagrożeniami zewnętrznymi. Jednakże obecnie wielu dostawców rezygnuje z opatentowanych mechanizmów komunikacyjnych na rzecz obniżenia kosztów izwiększenia niezawodności. Podobnie coraz więcej rozwiązań z zakresu zarządzania zasobami przechodzi na stacje robocze oparte na PC lub na inne systemy otwarte. Przejście na standardowe protokoły i systemy operacyjne sprawia, że tak zbudowane nowoczesne systemy są bardziej podatne na zagrożenia niewłaściwie wprowadzanymi zmianami oraz na ataki z zewnątrz.
Rodzaj zmian wprowadzanych w oprogramowaniu systemu automatyki :
|
Autoryzowanie |
Zmiany aktywowane natychmiast |
Zmiany aktywowane z opóźnieniem |
|
Zastosowanie odpowiedniego sposobu autoryzacji: |
|
|
|
Obchodzenie autoryzacji: |
|
|
Źródło: Control Engineering na bazie danych pochodzących od firmy MDT Software
Obszary ryzyka
Ryzyko wewnętrzne może mieć wiele przyczyn. Przyjrzyjmy się kilku z nich.
Pierwszą przyczyną zagrożenia pochodzącego z wewnątrz to sytuacja, w której ktoś zmienia parametr systemu w sposób nieprawidłowy, powodując uszkodzenie poprawnie wykonywanej instrukcji, algorytmu czy kodu. Systematyczne szkolenia pracowników oraz zwyczaj sporządzania zapasowych kopii danych są tu pomocne, ale mogą być niewystarczające. Nawet najlepiej wyszkolony personel popełnia błędy, zaś systemy automatycznego sporządzania zapasowych kopii danych skupiają się zazwyczaj na danych serwera i rzadko, kiedy archiwizują logikę urządzeń opatentowanych. Rola podsystemu kontroli wprowadzania zmian polega w tym przypadku na utrzymaniu w pamięci i udostępnieniu w każdej chwili wcześniej sprawdzonych i udokumentowanych wersji programu.
Druga przyczyna zagrożeń wewnętrznych to brak procedur aprobowania wprowadzanej zmiany, jak też weryfikacji wprowadzonych do systemu zmian. Problem ten staje się poważniejszy wtedy, gdy pozwala się podwykonawcom na samodzielne dokonywanie zmian lub też kiedy w wyniku liczbowej redukcji personelu obniża się sumę doświadczenia i zmniejsza zdolności do wykonania szczegółowych i trafnych ekspertyz w swoim zakładzie.
Przy takim zagrożeniu podsystem kontroli wprowadzania zmian powinien być uzupełniony instrukcjami aprobowania oraz na okresowym sprawdzaniu już wprowadzonych zmian oraz ich skutków.
Trzecia, chyba najbardziej rzucająca się w oczy, przyczyna, to rozczarowani pracownicy, którzy mają złą wolę, a przy tym dogłębną znajomość systemów automatycznej regulacji i posiadają otwarty dostęp do nich. Chociaż sposób zaprojektowania systemów i zastosowane w nich zabezpieczenia mogą ochronić przed większością zdarzeń o katastroficznym charakterze, to jednak stosunkowo łatwo jest wprowadzić do oprogramowania zmiany, które spowodują zatrzymanie działania systemu automatyki. Tego typu zagrożenia mają zazwyczaj specyficzny charakter: ktoś posiadający złe zamiary, dokonuje modyfikacji programu w taki sposób, aby program wykonał niepożądane czy nawet szkodliwe działanie w przyszłości, a nie natychmiast po wprowadzaniu zmiany.
Dla takich zagrożeń sposób działania podsystemu kontroli wprowadzania zmian musi przewidywać wykrywanie i usuwanie szkodliwej zmiany (kodu, procedury) w okresie pomiędzy jej wprowadzeniem a momentem aktywacji. Powinien dać możliwość wykrycia uszkodzenia fragmentu oprogramowania, ostrzec obsługujący personel i zapobiec powstaniu niepożądanego zdarzenia.
Wiele ostatnio napisano na temat zagrożeń zewnętrznych, jakie stanowią osoby o złych intencjach. Celem zapewnienia bezpieczeństwa najważniejszych systemów kluczowym działaniem jest ograniczanie dostępu, poprzez właściwe zastosowanie ścian ogniowych czy tak zwanych stref demilitaryzacji ? oddzielny komputer lub specjalna podsieć, zlokalizowane pomiędzy zabezpieczaną w ten sposób siecią wewnętrzną a przyłączem do sieci zewnętrznej). Jednakże opisane powyżej działania nie ujawniają faktu wprowadzenia zmiany do oprogramowania systemów automatyki. Aby to osiągnąć i podnieść poziom bezpieczeństwa systemu, konieczne jest, aby podsystem kontroli wprowadzania zmian porównywał aktualnie wykonywane sekwencje programu z kopiami programu odniesienia (wcześniejszej, przetestowanej i bezbłędnej wersji).
Innym wyzwaniem w wykrywaniu zmian w zautomatyzowanych urządzeniach jest sposób zaprojektowania tych urządzeń. W wielu przypadkach pozwala się na bezpośrednie połączenie urządzenia z procesorem, na przykład sterownikiem PLC, obchodząc zabezpieczenia sieciowe i procedurę atestacji. Aby wykrywać na czas te niepożądane zmiany, konieczne jest częste ich poszukiwanie. Automatyzacja tego procesu jest zdecydowanie bardziej precyzyjnym i skutecznym sposobem osiągnięcia celu, niż okresowe, pobieżne przeglądy. ce
Joe J. Colletti Jr. jest prezesem firmy MDT Software.
www.mdtsoft.com.