Podstawy bezpiecznej architektury ICS¶
Pierwotne źródło tekstu
Utworem pierwotnym w stosunku do niniejszego tekstu jest rozdział „Wprowadzenie do bezpieczeństwa przemysłowych systemów sterowania (ICS/OT)” autorstwa Marcina Dudka, pochodzący z książki „Wprowadzenie do bezpieczeństwa IT”. Pierwotny tekst został udostępniony dzięki uprzejmości Securitum Wydawnictwo.
Segmentacja¶
W latach 90. XX wieku powstał model architektury Purdue opisujący, jak powinien wyglądać zakład przemysłowy z perspektywy podziału logicznego i uproszczenia zarządzania. Mimo że nie uwzględniał on kompletnie aspektów bezpieczeństwa, do tej pory jego fragmenty i terminologia tam użyta są wykorzystywane. Dla nas najbardziej istotne jest zrozumienie, co inne osoby mają na myśli, mówiąc o tzw. poziomach. W każdej organizacji będzie to wyglądało inaczej, ale w uogólnieniu przyjął się następujący podział architektury na poziomy funkcjonalne:
- Poziom 5: sieć i usługi korporacyjne – Active Directory, poczta, systemy HR, obieg dokumentów itd.
- Poziom 4: sieć lokalna i planowanie produkcji – lokalna sieć biura, systemy do planowania zapotrzebowania na materiały (MRP), systemy planowania zasobów (ERP), systemy utrzymania ruchu (CMMS) itd.
- Poziom 3,5: IT/OT DMZ – wydzielony DMZ pomiędzy IT a OT/ICS na potrzeby wymiany danych i zdalnego dostępu: replika historiana tylko do odczytu, serwery przesiadkowe, serwery plików itd.
- Poziom 3: systemy wsparcia i nadzoru produkcji – w przypadku rozproszonej działalności centralne systemy nadrzędne (np. serwery SCADA), stacje operatorskie, historian, stacje przesiadkowe, systemy inwentaryzacji urządzeń, serwery logów, konsole AV, serwery czasu itd.
- Poziom 2: lokalny nadzór – panele HMI, serwery SCADA/DCS, stacja inżynierska (EWS) itd.
- Poziom 1: lokalne sterowanie – sterowniki PLC, zdalne terminale RTU, przekaźniki programowalne, systemy SIS; często ściśle powiązane z poziomem 0.
- Poziom 0: urządzenia polowe – czujniki i urządzenia wykonawcze, konwertery protokołów, serwery portów szeregowych, moduły komunikacyjne; często ściśle powiązane z poziomem 1.
Systemy SIS
Systemy bezpieczeństwa SIS powinny być umieszczone w dedykowanych odizolowanych podsieciach. Są one kluczowe dla zapewnienia bezpieczeństwa procesu w przypadku awarii.
Poziomy funkcjonalne stały się bazą dla definiowania m.in. propozycji bezpiecznej architektury, opisanej w normie IEC 62443, czy zaproponowanej przez SANS. Dostawcy oprogramowania i sprzętu dla przemysłu również prezentują referencyjne architektury z wykorzystaniem ich rozwiązań.
Referencyjny podział stref zaproponowany przez SANS, uwzględniający rozproszony charakter procesu
Referencyjna architektura zaproponowana przez Rockwell Automation
Referencyjna architektura zaproponowana przez Siemensa
Kluczowe jest, aby przy definiowaniu reguł dostępu do zasobów nie opierać się wyłącznie na poziomach funkcjonalnych, a w znacznym stopniu na analizie krytyczności systemów i potrzeb komunikacji między poszczególnymi komponentami. Może się zdarzyć tak, że stacja przesiadkowa z poziomu 3 będzie komunikowała się bezpośrednio ze sterownikiem PLC na poziomie 1, aby umożliwić jego zdalną konfigurację. Historian z poziomu 3 może potrzebować zbierania danych z poziomów: 2, 1 i nawet 0, a następnie wysyłać je do poziomu 4. Co więcej, w nadchodzących latach możemy spodziewać się coraz większej liczby przypadków urządzeń z poziomu 0, np. czujników, komunikujących się z Internetem w celu przesłania danych do chmury, czyli ery tzw. Industrial Internet of Things (IIoT).
Strategie segmentacji¶
Strategii na dokonanie segmentacji jest wiele. Można np. zastosować podejście proponowane przez standard IEC 62443, czyli podział infrastruktury na strefy i kanały, a następnie określać wymogi bezpieczeństwa, albo mniej znane podejście rekomendowane przez Międzynarodową Agencję Energii Atomowej (IAEA) – oceny krytyczności systemów, podziału ich na strefy i przypisania do odpowiednich poziomów bezpieczeństwa.
Rekomendowana przez IAEA metodyka podziału systemów na strefy i poziomy bezpieczeństwa.
Zdecydowanie warto też zapoznać się z rozdziałem OT Cybersecurity Architecture kultowego dokumentu NIST 800-82 Rev.3, który pozostaje jednym z najważniejszych dokumentów opisujących bezpieczeństwo architektury systemów przemysłowych.
Komunikacja OT z sieciami zewnętrznymi¶
Z analizy wniosków z ataków można wysunąć tezę, że kluczowy z perspektywy bezpieczeństwa jest styk systemów sieci przemysłowej (poziomy 0–3) z sieciami zewnętrznymi. Jest to zdecydowanie najczęstszy wektor ataku, a jako przykłady można podać:
- współdzieloną domenę (Active Directory) i przejęcie jej przez atakującego po stronie biznesowej,
- zainfekowany komputer zewnętrznego wykonawcy,
- historian z interfejsami w sieciach IT i OT,
- zdalny dostęp przez modem GSM wpięty bezpośrednio do urządzenia na poziomie 1,
- system zarządzania infrastrukturą sieciową OT dostępny z sieci IT,
- … i wiele więcej.
Dobre praktyki: bezpieczna komunikacja OT z sieciami zewnętrznymi
Wszystkie połączenia z sieciami zewnętrznymi (a za takie uważany jest też WAN) powinny być realizowane w następujący sposób:
- komunikacja przez strefy DMZ wydzielone za pomocą zapór sieciowych z dobrze opisanym i maksymalnie ograniczonym dozwolonym ruchem;
- dostęp zdalny powinien być realizowany wyłącznie z wykorzystaniem VPN-a z dwuskładnikowym uwierzytelnianiem, preferencyjnie w postaci fizycznego tokena;
- w przypadku zdalnych czynności konfiguracyjnych zalecane jest wykorzystanie stacji przesiadkowych, z dostępem ograniczonym tylko do minimalnego zasobu, na których dostępne będzie zainstalowane wymagane oprogramowanie.
Więcej na ten temat można przeczytać np. w rekomendacjach CISA i SANS.
Bezpieczny zdalny dostęp wg rekomendacji SANS
Najważniejsze punkty architektury¶
Nie da się stworzyć jednej uniwersalnej architektury dla każdego zakładu przemysłowego. Różnią się one od siebie znacząco, zarówno w zakresie używanych systemów, ich możliwości i potrzeb, jak i zagrożeń. Mimo to można wydzielić pewne punkty wspólne. Poniżej zebrano listę najważniejszych aspektów, o których należy pamiętać przy projektowaniu, a także przy audytowaniu architektury ICS/OT.
Dobre praktyki: projektowanie i audytowanie architektury ICS/OT
- Konieczna jest segmentacja zgodnie z opisem w poprzednich podrozdziałach, ale musi ona zacząć się od inwentaryzacji. Nie da się zabezpieczyć sieci, nie wiedząc, co się w niej znajduje.
- Bezpośredni dostęp z poziomów 4–5 oraz z sieci zewnętrznych do poziomów 0–3 powinien być domyślnie zabroniony.
- Dostęp do Internetu z poziomów 0–3 powinien być zabroniony. Dozwolone są wyjątki po odpowiedniej analizie ryzyk i potrzeb. Przykładem, gdzie takie połączenie ze strefy 0 może być dozwolone, jest wykorzystanie IIoT.
- Wewnętrzna sieć WAN powinna być traktowana podobnie jak Internet i połączenia z nią powinny przechodzić przez dedykowany DMZ.
- Zapory sieciowe powinny mieć zawsze jako domyślną regułę blokującą wszystko. Wszystkie reguły zezwalające na ruch muszą być jak najbardziej precyzyjne i dobrze udokumentowane.
- Systemy odpowiedzialne za bezpieczeństwo procesu, takie jak SIS czy ESD, powinny być odizolowane, preferencyjnie z użyciem diody jednokierunkowej.
- Jeśli wymagany jest dostęp do danych z sieci OT, konieczne jest wydzielenie strefy DMZ. Obowiązującą tu zasadą powinno być założenie, że strefa o mniejszym poziomie zaufania nigdy nie inicjuje komunikacji, tj. dozwolone jest połączenie OT→DMZ, ale zabronione DMZ→OT. Oczywiście nie zawsze będzie to możliwe do wdrożenia w tak prosty sposób.
- Na potrzeby pracy biurowej (np. poczta firmowa) przez personel mający dostęp do systemów przemysłowych powinny zostać wykorzystane wyłącznie dedykowane stacje robocze w podsieci traktowanej jako poziom 5.
- Dostęp zdalny powinien być realizowany wyłącznie z wykorzystaniem VPN-a z dwuskładnikowym uwierzytelnianiem (najlepiej fizycznym tokenem), niezależnym od kontrolera domeny.
- Dostęp zdalny powinien być realizowany przez dedykowane stacje przesiadkowe z niezbędnym oprogramowaniem i dostępami ograniczonymi do minimum. Sesje zdalne powinny być nagrywane.
- Kontroler domeny wykorzystywany w OT lub służący jako uwierzytelniający do sieci OT nie powinien być w żaden sposób powiązany z IT (wliczając w to drzewa, lasy czy repliki domen).
- Wykorzystanie wspólnego rozwiązania dla wirtualizacji serwerów IT i OT, choć często stosowane, jest bardzo ryzykowne i powinno być traktowane jako poważny wektor ataku z sieci IT, w szczególności przy założeniu przejęcia kontroli nad hipervisorem.
- Centralne konsole do zarządzania urządzeniami sieciowymi, antywirusami czy systemy SIEM mają szerokie dostępy i mogą być również wektorem ataku. Powinny one znajdować się w osobnym segmencie sieci.
- Warto projektować sieć przemysłową tak, żeby kluczowe systemy mogły nadal działać po całkowitym odcięciu od sieci IT i mniej istotnej infrastruktury.
- Wiele ataków da się zatrzymać i wykryć przez odpowiednie utwardzenie (ang. hardening) stacji roboczych i serwerów z wykorzystaniem listy dozwolonych aplikacji, przez funkcje takie jak: Software Restriction Policies (SRP), AppLocker czy WDAC. Niestety w wypadku istniejących systemów nie zawsze jest to możliwe, np. z powodów gwarancyjnych.
- Systemy, które mają poważne podatności, a nie mogą być zaktualizowane albo nie mogą spełnić wymogów bezpieczeństwa, np. z powodów gwarancyjnych, powinny zostać wydzielone do osobnego segmentu sieci.
- Cała komunikacja na styku sieci OT z innymi segmentami powinna być logowana i monitorowana. Równie ważne jest zbieranie i analiza logów ze stacji roboczych i serwerów, np. ze stacji inżynierskich, serwerów SCADA czy historiana. Monitorowanie sieci głębiej i analiza protokołów przemysłowych – na poziomie 0–2 – też są ważne, ale jeśli organizacja jest dopiero na początku drogi do bezpiecznej infrastruktury, powinna postawić priorytet na monitorowanie styków sieci.