Niniejszy wpis jest rozwinięciem szerszego wątku związanego z identyfikacją i zarządzaniem podatnościami w środowisku produkcyjnym i sieci przemysłowym ICS/OT. Jest również drugim z całej serii zaplanowanych artykułów wyczerpujących wspomniane zagadnienia.

Tym samym zachęcam czytelników do zapoznania się z poprzednim artykułem (part 1) – tekstem wprowadzającym i traktującym o:

- istotności podatności - luk - vulnerabilities 
- zagrożeniach wynikających z zero days (0days)
- specyfiki środowiska ICS/OT w kontekście zarządzania ryzykiem organizacji

To czym są podatności zostało opisane w wyczerpujący sposób w treści artykułu, który jest dostępny pod powyższym linkiem.

W tym wpisie, będącym drugim z serii 3 zaplanowanych, opiszemy zasadnicze różnice pomiędzy zarządzaniem podatnościami w środowisku IT w stosunku do ICS/OT. Wprowadzimy czytelników w zagadnienia związane z Patch Management proces.

Patchować … Ale Jak i Kiedy?

Pierwszym i podstawowym punktem związanym z systemami automatyki przemysłowej ICS w stosunku do wszelkich zmian konfiguracji, aktualizacji i upgradów jest to, czy:

dana aktualizacja została sprawdzona – zwalidowana pod kątem kompatybilności całego systemu.

Wszystkie zalecenia i tzw. dobre praktyki

Inaczej rzecz ujmując, żadna zmiana w systemie produkcyjnym nie może zostać wprowadzona bez uprzedniego sprawdzenia kompatybilności sprzętowej – hardware jak i programowej – systemów współpracujących, oprogramowania typu SCADA, systemu raportowego czy konektorów danych (np. oprogramowania OPC UA). Bez uprzedniego sprawdzenia kompatybilności dla całego systemu i wszystkich jego komponentów!, narażamy organizacje na potencjalne straty z tytułu przestojów i awaryjnego zatrzymania linii technologicznej, systemu produkcji.

„Aktualizujemy i patchujemy wszystko”

Niejeden CISO, CSO, CIO …

Urządzeń pracującej linii technologicznej nie możemy w poddać procesom aktualizacji, tak zwyczajnie, z automatu i natychmiast po opublikowaniu danej poprawki. Wgranie łatki bezpieczeństwa lub aktualizacja aplikacji, systemu operacyjnego praktycznie zawsze wiąże się z koniecznością ponownego uruchomienia (ang.reboot) urządzenia. W efekcie końcowym nasza linii zostanie zatrzymana, produkcja stanie. Być może nawet zostaną zainicjowane procesy bezpiecznego awaryjnego wyłączenia kluczowych instalacji poprzez niezależne obwody bezpieczeństwa SIS (ang. Safety Instrumented System). Naprawdę, nikt nie chciałby wyzwolić procedury awaryjnego wyłączenia reaktora jądrowego w elektrowni atomowej …

Tymczasem, nagły i niezamierzony brak odczytu danych z pól pomiarowych i sterownika zarządzającego obiegiem wody chłodzącej w wyniku „przeładowania sterownika” przy aktualizacji firmware, wyzwolić może system bezpieczeństwa SIS i uruchomienie procedury i układ awaryjnego wyłączenia reaktora.

Film poniżej, będący tylko symulacją awarii oddaje stopień skomplikowania z jakimi mamy doczynienia w przypadku blokady kluczowych usług,  potencjalnej awarii. Potencjalnie, nieświadome podejście w przypadku patchowania urządzeń końcowych w środowisku ICS/OT może wywołać podobny scenariusz:

Więcej o Barierach i Wyzwaniach

Urządzenie i systemy niejednokrotnie pracują w trybie ciągłej pracy 24 x 7 z maksymalną dozwoloną wydajnością. Wynika to z potrzeby zapewnienia usługi, produktu w cyklu ciągłym lub z przyczyn ekonomicznych – utylizacji parku maszynowego w możliwie największym udziale (ROI, zwrot z inwestycji) i/lub wywiązania się z umów i kontraktów dostaw danego surowca, medium lub produktu.

Bardzo często to sam proces technologiczny determinuje konieczność zachowania ciągłości pracy maszynom, instalacjom technologicznym. Przykładem jest proces odlewania stali i „wielki piec” – instalacje, które nie mogą zatrzymać się w wyniku nieplanowanego przestoju. Inny przykład stanowi linia produkcji szkła. Podobnie, brak zachowania ciągłości procesu w odlewanych taflach szkła, parominutowy przestój kompletnie niszczy cały ciąg technologiczny. Ograniczeniem jest tutaj naturalny proces krystalizacji ciekłego szkła liczony w pojedynczych minutach. Przekraczając graniczną wartość, narażamy organizacje na bardzo poważne straty finansowe i kompletne zniszczenie linii produkcyjnej (szkło krystalizuje – zmienia stan skupienia z ciekłego w stały).

W procesach o wysokiej konsumpcji energii elektrycznej, ponowny rozruch całej instalacji i osiągnięcie parametrów procesowych jest bardzo kosztowne oraz czasochłonną operacją. Świetny przykład stanowią piece hutnicze, które wykorzystujące energię elektryczną do indukcyjnego mieszania stali lub w procesie normalizacji i obróbki stali jakościowych. W tych systemach bywają sytuacje, w których ciężko zaplanować aktualizację systemu operacyjnego komputera z wizualizacją SCADA, systemem zarządzania procesem produkcji.

Patch Management – Część Planu Zarządzania Zmianą

W związku z tym, konieczne staje się opracowanie planu i metodyki przeprowadzania aktualizacji i patchowania systemów produkcyjnych. Co więcej plan ten powinien uwzględniać dodatkowe aspekty przywrócenia kopii i pełnej funkcjonalności systemu na wypadek zaistniałych problemów.

Dokument ten uwzględniać powinien specyfikę środowiska produkcyjnego oraz efektywną i bezpieczną operację aktualizacji systemów. Efektywną z punktu widzenia czasu zatrzymania linii i maszyny, organizacji i sprawności działań całego zespołu. Bezpieczną przez pryzmat kompatybilności poprawki z całym systemem rozumianym zarówno jako hardware jak i warstwa aplikacji. Znaczenie słów efektywną oraz bezpieczną również należy rozumieć w kontekście różnic systemów OT/ICS vs IT, które dotychczas zostały zaznaczone. 

By dodatkowo podkreślić stopień skomplikowania, poniżej przykładowa infrastruktura zakładu produkcyjnego z systemem DCS: 

Na powyższym diagramie sieci zakładowej (Food&Beverage, Cement, wiele innych zbliżonych branż) możemy zidentyfikować:

• komputery przemysłowe/stacjonarne – OWS – Operatorskie: warstwa aplikacji klienta, wizualizacji, system operacyjny OS i inne narzędzia, oprogramowanie układowe – firmware (BIOS)
• komputery inżynierskie – EWS: warstwa aplikacji – środowisko programistyczne i narzędzi typu Studio5000, TIA Portal; oprogramowanie pomocnicze, system operacyjny OS i inne narzędzia, oprogramowanie układowe – firmware (BIOS)
• elementy aktywne infrastruktury typu switche L2&L3, routery oraz opcjonalnie zapory ogniowe: system operacyjny urządzeń, oprogramowanie układowe – firmware
• serwery aplikacyjne, bazy danych: przywołane aplikacje – wizualizacja, nadzór nad procesem produkcyjnym, wizualizacja, systemy operacyjne OS oraz oprogramowanie układowe – firmware
• warstwa automatyki przemysłowej ICS oraz urządzeń IIoT (ang. Industrial Internet of Things): sterowniki i kontrolery, panele HMI, elementy brzegowe (ang. edge compute), urządzenia nastawcze i regulacyjne (więcej na securot w treści: pętla sterowania). Systemy operacyjne OS oraz oprogramowanie układowe – firmware, aplikacje i narzędzia, bazy danych (Historian) i system OS klasy Windows.

Mamy więc cały szereg urządzeń zarówno IT jak i ICS, infrastruktury OT którym należy odpowiednio zarządzać – administrować, utrzymywać – zarządzać zmianą. Co w efekcie końcowym bezpośrednio przekłada się na bezpieczne użytkowanie i modyfikację ustawień. W tym aktualizację oprogramowania i wgrywanie poprawek – łatek bezpieczeństwa.

Patch Management dla ICS/OT wg. IEC 62443

Proces wgrywania łatek, sam w sobie nie jest nowy ani odkrywczy. Od dawna funkcjonują zalecenia i gotowe mapy lustrujące proces przeprowadzania aktualizacji od momentu wykrycia podatności/opracowania łatki do momentu jej użycia – implementacji. Warto przywołać w tym momencie darmowe opracowanie DHS National Cyber Security Division Control Systems Security Program, a w szczególności diagram: 

Zasadniczo, jest to jak najbardziej aktualny schemat dotyczący zarządzania ryzykiem przez pryzmat konieczności aktualizacji oprogramowania, patchowania. Adresuje bowiem aspekty związane z oceną ryzyka przez fakt istnienia oficjalnie zgłoszonych podatności:

• podjęcia działań dla krytycznych podatności – jednak przy uwzględnieniu konieczności zaplanowania tej akcji z Produkcją poprzez nadanie priorytetu
• zaplanowania akcji serwisowej dla systemów o małym ryzyku i małym znaczeniu.

Jedną z największych zalet standardu IEC 62443, jest określenie ról, doprecyzowanie zakresu i wymagań od strony użytkownika systemu. Tym samym standard 62443 określa obowiązki producenta, integratora systemów i dostawcy usług pod kątem zaleceń i wytycznych. Standard 62443 stanowi niemalże kompletne źródło informacji przy budowaniu programu bezpieczeństwa systemów ICS/OT. Zapraszamy do opracowania securot: iec-62443-isa-99 opisującego wskazany standard. Skoroszyt IEC 62443-2-3 jest bezpośrednim nawiązaniem do zagadnień związanych z „Patch Management Process” i rekomendujemy do zapoznania się z dokumentem. W sposób wyczerpujący opisuje wszystkie najważniejsze zagadnienia, przydziela odpowiedzialności.

By przybliżyć poruszane w nim aspekty, możemy zobrazować proces zarządzania łatkami ICS/OT w bardziej sformalizowany sposób łącząc zalecenia skoroszytu 62443-2-3 z dotychczas wspomnianymi aspektami. W ten sposób otrzymamy zaktualizowany i proszczony schemat:

Biznesowy Wymiar Patchowania

Proces patchowania stanowi stanowi część programu zarządzania zmianą (Change Management) i zarządzania ryzykiem organizacji. Stąd też zasadne staje się podejmowania decyzji o aktualizacji przez pryzmat kosztu – wartości czynności i prac, potencjalnej migracji lub konwersji systemu. Tak jak w całej istocie zarządzania ryzykiem uwzględnić musimy nakłady finansowe i zrównoważyć wydatki związane z danym ryzykiem:

Applying patches is a risk management decision. If the cost of applying patches is greater than the risk evaluated cost, then the patch may be delayed, especially if there are other security controls in place that mitigate the risk (such as disable or remove features).

IEC 62443 – 2 – 3 Patch management in the IACS environment

Przytoczone zdanie nabiera na znaczeniu w przypadku leciwych instalacji, maszyn i urządzeń, które wyposażone są w niewspierane już przez producenta oprogramowanie, aplikacje i systemy operacujne komputerów i urządzeń.

Cykl życia przemysłowych instalacji i maszyn z założenia był i dalej jest określony na lata jak nie na dziesiątki lat. Stąd też poszczególne układy i sekcje instalacji niekiedy wciąż oparte są na leciwych technologiach pochodzących z lat 80, 90. Niestety, często dostawcy z tamtego okresu już nie istnieją lub wsparcie produktowe zostało oficjalnie dawno wygaszone.  Niestety również, często koszty związane z modernizacją w oparciu o najnowsze serie produktowe wiążą się z poważnymi budżetami remontowymi. Wówczas warto zastosować inne mechanizmy bezpieczeństwa chroniące nasze legacy systems akceptując w pełni ryzyko związane z przestarzałą technologią. Czy jednak stanowią one poważne zagrożenie, odpowiedź da nam ocena ryzyka i krytyczności która stanowi część całego procesu Patch Management Plan i strategii zarządzania ryzykiem.