Jeżeli nie wyciągamy wniosków z naszych błędów, niemal na pewno popełnimy je ponownie. W artykule prezentujemy przypadek, kiedy to zewnętrzny dział IT – nieświadomy harmonogramu pracy zakładu – doprowadził do wyłączenia całego procesu produkcji w firmie wartej miliardy dolarów.
|
Outsourcing firm odpowiedzialnych za bezpieczeństwo IT to powszechna praktyka, ponieważ niewiele przedsiębiorstw może sobie pozwolić na utrzymywanie armii specjalistów zajmujących się bezpieczeństwem danych, zatrudnianie bezpiecznego środowiska pracy czy ochrony przed atakami z zewnątrz. Czasami jednak skutki takiego rozwiązania mogą być opłakane. Historia z życia wzięta |
W pewnej fabryce, w zakresie obowiązków zewnętrznej firmy było wykonywanie regularnego skanowania wszystkich sieci teleinformatycznych i transmisji danych poziomu obiektowego w celu wykrycia niechronionych portów czy nielegalnych urządzeń. Niestety, outsourcowani pracownicy nie przekazywali pracownikom obsługi maszyn swojego planu testów, co owocowało „tajemniczym”, cotygodniowym wyłączaniem urządzeń na liniach produkcyjnych. Sterowniki PLC zatrzymywały się i wymagały restartu (a nawet ponownego załadowania programów), zaś wszystkie podłączone urządzenia do sterownika po prostu się resetowały. Najgorsze, że restarty urządzeń następowały w normalnych godzinach pracy, podczas gdy produkcja trwała na okrągło, 24 godziny na dobę. W dziale obsługi i organizacji produkcji sądzono, że jest to jakiś wewnętrzny problem na linii – jednak nie można było określić dokładnej przyczyny.
Ostatecznie na jednej z linii zauważono tuż przed wyłączeniem produkcji wzmożony ruch sieciowy (ang. flooding – przesył pakietów w krótkich odstępach czasu, prowadzący do spowolnienia przesyłu na łączu). Był to element sprawdzania zabezpieczeń przez zewnętrznych pracowników IT – symulowali oni w ten sposób atak na sieć (co oczywiście znajdowało się w zakresie ich obowiązków). Harmonogramu testów – jak twierdzą – nie podawali celowo, aby ewentualny „prawdziwy” intruz nie miał czasu na interwencję i wyłączenie z sieci swoich aktywnych urządzeń.
Brak stref DMZ
Niekiedy, w przypadku zamknięcia produkcji, powstaje sytuacja, w której sieci poziomu zarządzania i obsługi produkcji nie są wydzielone, tworząc wspólne środowisko infrastruktury sieciowej. Informacje przechodzą wówczas przez tzw. strefę zdemilitaryzowaną (DMZ – demilitarized zone) – sieć IT, która znajduje się pomiędzy sieciami korporacyjnymi oraz sieciami czasu rzeczywistego kontrolującymi proces (krytycznie ważnymi). Nie ma bezpośredniego połączenia przez DMZ, a cała komunikacja jest routowana przez serwery i bazy danych. Po każdej stronie DMZ znajduje się firewall, a czasami wykorzystuje się dodatkową, oddzielną domenę użytkownika. DMZ, firewalle oraz łączność pośrednia to najlepsze obecnie metody ochrony sieci tego typu.
W opisywanym przypadku uderzenie na sieć i wymuszenie ruchu wielokrotnie wyższego niż zazwyczaj po prostu „przytkało” sterowniki PLC i urządzenia do nich podłączone. Bufory odpowiedzialne za komunikację przepełniały się i doprowadzały do zatrzymania systemu. Na szczęście nie spowodowało to trwałego uszkodzenia urządzeń sieciowych i modułów podłączonych do sieci (hardware), a „jedynie” straty finansowe – choć nie da się ukryć, że rzędu dziesiątek tysięcy dolarów na minutę.
Urządzenia, sieci, wolna amerykanka
Ostatecznie dział IT wskazał, gdzie leży problem – nie istniała jednak żadna polityka firmy w tym zakresie, ani szczególne zasady podziału odpowiedzialności pomiędzy outsourcowane zespoły specjalistów IT a dział kontroli.
Dział IT był właścicielem sieci i switchy sieciowych, zaś dział kontrolowania procesu – właścicielem końcowych urządzeń. Sieć sterowania procesem sama w sobie nie była uznawana przez ludzi z IT za część systemów sterowania, natomiast pracownicy odpowiedzialni za sterowanie procesem tak właśnie ją traktowali. W gestii IT nie leżała naprawa urządzeń sieciowych obsługiwanych na tym poziomie.
Z opisywanej historii warto wyciągnąć następujące wnioski: korporacyjne reguły i zasady separacji sieci sterowania oraz sieci IT poprzez tzw. strefy DMZ są niezbędne, tak samo jak konieczność przeprowadzania regularnych testów i kontroli zabezpieczeń. Szczęściem w nieszczęściu, w tym przypadku wnioski wyciągnięto, zanim zdarzył się prawdziwy atak.
Dlatego właśnie warto tworzyć w firmach politykę lepszej ochrony systemów sterowania czasu rzeczywistego, a nie czekać na sytuację awaryjną.
Autor: Dennis Brandl jest prezesem firmy BR&L Consulting, specjalizującej się w branży IT.