Wpis jest kolejną 3-cią częścią seri artykułów poświęconych problematyce podatności (ang. vulnerabilities) w środowisku produkcyjnym. Skupimy się na aspektach visibility – widoczności kluczowych zasobów sieciowych OT oraz rozwiązań ICS.
Charakterystyka poprzednich części została przywołana poniżej. W treści tego wpisu skupimy się na obszarze monitorowania środowiska ICS/OT, zagadnieniach ciągłej analizy podatności i luk w naszych systemach i rozwiązaniach automatyki przemysłowej.
Co to są podatności…
W skrócie, podatność to pewna cecha urządzania, warstwy aplikacji/oprogramowania, która stwarza ryzyko wykorzystania przez osoby nieuprawnione celem:
- przejęcia kontroli nad danym urządzeniem, systemem siecią IT/OT,
- zmiany cech i własności zarówno samego produktu jak i procesu, działania,
- zmiany uprawnień i dostępu dla osób nieuprawnionych
- zablokowania usług celem zablokowania systemu przed dostępem uprawnionych użytkowników i usług.
Oczywiście, nie wyczerpaliśmy wszystkich możliwych scenariuszy i powodów ataków hakerskich. Infrastruktura ICS/OT jest również często wykorzystywana przy wymuszenia okupu. Ataki typu ransomware przybierają na sile z roku na rok (securot: RaaS, Raport Crowdstrike). Jednym z powodów takiego stanu rzeczy jest właśnie fakt braku wypracowanych procedur związanych z aktualizacją oprogramowania oraz zarządzania cyklem życia produktów (Life-Cycle).
Nie mniej jednak, celem wprowadzenia w tematykę podatności, kodów typu exploit, zero days, zachęcam do zapoznania się z wpisem:
Aktualizacja – patchowanie systemów ICS/OT
Drugi z serii artykuł, zwraca uwagę na konieczność wypracowania mechanizmów i procedur aktualizacji systemów produkcyjnych. Wskazuje podstawową różnicę pomiędzy systemami IT oraz produkcyjnymi OT.
Widoczność zasobów – visibility
W społeczności security jednym z kluczowych z punktu widzenia zarządzania ryzykiem organizacji jest sformułowanie:
„you cannot protect what you cannot see„
Specjaliści Security
I zasadniczo znajduje pełne uzasadnienie zarówno w środowisku IT jak … produkcyjnym ICS/OT.
Bo jak chronić obiekt nie znając jego charakterystyki, jego mocnych i słabych punktów. Jak dobierać systemy i narzędzia ochrony dla środowiska produkcyjnego stosujemy dokładnie tą samą analogie.
Nie ma bezpieczeństwa danego systemu ICS/OT bez poprzedzającej analizy, oceny ryzyka i zrozumienia jaki wpływ na całościowe bezpieczeństwo organizacji ma dany system/aplikacja.
Jeden gość IT z CISSP ale … certyfikowany też wg. IEC-62443
W ramach portalu securot.eu kładziemy szczególny nacisk na istotę opracowania spójnej polityki bezpieczeństwa organizacji. Spójnej z punktu widzenia biznesu i środowiska IT jak i produkcji – infrastruktury OT. Spójne przez pryzmat oceny całości systemów, rozwiązań i wzajemnych zależności. Tylko takie podejście pozwala budować warstwowe bezpieczeństwo (ang. defence-in-dept) i mechanizm wzajemnie uzupełniających się, systemów, technologii i ludzi – wiedzy eksperckiej.
Odnosząc powyższe sformułowanie do obszaru operacyjnego – produkcji dochodzimy do konkluzji, iż jednym z podstawowych aspektów budujących ICS/OT security jest wiedza o zasobach. Tylko i wyłącznie poprzez rozpoznanie i inwentaryzację poszczególnych zasobów sieciowych jesteśmy w stanie oszacować potencjalne ryzyko, ocenić wpływ poszczególnego zasobu na bezpieczeństwo operacyjne oraz organizacji. Bez tej elementarnej wiedzy, co do poszczególnych urządzeń, aplikacji i rozwiązań w poszczególnych obszarach naszej organizacji:
nie można w żadnym wypadku mówić o strategi, zarządzaniu ryzykiem. I w tym momencie dochodzimy do kolejnego punktu i zagadnienia jakim jest visibility.
Widoczność zasobów – visibility
Widoczność należy rozumieć w kontekście ciągłej analizy infrastruktury, danych, urządzeń i śledzenia ich zachowania (urządzeń). W myśl zasady, iż nic nie jest stałe, nasza infrastruktura w czasie ulega zmianom, modernizacjom a nasze urządzenia, punkty aktywne, zasoby sieciowe podlegają starzeniu. Ciągle przybywa nowych urządzeń IoT i połączeń, danych.
Nie inaczej jest w otoczeniu ICS/OT, w obszarze produkcji (Level 0-2 wg.Purdue Model). Tutaj bowiem, dynamikę zmian często definiują awarie, plany modernizacji i integracji systemów na potrzeby lepszej kontroli nad procesem.
Z drugiej jednak strony, istnieje szereg przestarzałych systemów wytwórczych, które bazują na wycofanych i niewspieranych już technologiach. Tutaj wszelka dynamika zmian jest raczej mała, by nie powiedzieć iż nikt ich nie dotyka. Często brakuje dokumentacji i samych narzędzi (oprogramowanie) i wiedzy. Sytuacja ta wpływa na ograniczenia co do zakupu nowych urządzeń, tworzy bariery technologiczne. i procesowych. Stąd też pełna modernizacja systemu sterowania, w pewnych przypadkach może osiągać koszty porównywalne z uruchomieniem nowej instalacji. Zagadnienie zarządzania Cykle Życia zostanie niebawem szczegółowo opisane w naszym wpisie. Dlatego, w cyklu bezpieczeństwa ogrywa bowiem jedną z kluczowych ról.
Jeżeli bezpieczeństwo infrastruktury zależy między innymi od urządzeń ją tworzących, spisu luk i podatności, analizy zachowania poszczególnych węzłów sieci, to wniosek jest radykalnie prosty. Potrzebujemy:
- narzędzi zapewniających wymienione funkcjonalności,
- zasobów ludzkich do obsługi tych narzędzi. Systematycznej obsługi, nie doraźnej. Bezpieczeństwo nie jest doraźne 🙂
Skupmy się na opisie, głębszej analizie potrzeb a więc i funkcjonalności systemu który pozwoli zarządzań ryzykiem z perspektywy urządzeń sieci industrialnej.
Asset inventory
Bez wątpienia widoczność urządzeń – visibility jest kluczowym aspektem. Dzięki tej funkcji, potrafimy odwzorować mapę urządzeń do poziomu adresu IP i MAC, zidentyfikować assety i odpowiednio sklasyfikować. Klasyfikacja pozwala na nadanie stopnia krytyczności wg. przyjętych standardów i oceny ryzyka w ogólnym ujęciu organizacji.
Skaner podatności
Przy odzwierciedleniu mapy urządzeń, topologi i wzajemnych zależności, zastosowanie odpowiednich mechanizmów powinno pozwolić na dokładne określenie konfiguracji urządzenia ICS/OT. By tak się stało, oprogramowanie monitorujące, powinno pozwolić na odpytanie danego zasobu co do jego charakterystyki i specyfikacji.
Jak zrobić to bezpiecznie z perspektywy procesu produkcyjnego celem zachowania ciągłości produkcji i niezmienności procesu ?
Real Time Monitoring
Moduł analizujący w czasie rzeczywistym dane, pakiety przesyłane są pomiędzy poszczególnymi węzłami sieci i urządzeniami końcowymi (ang.End Points). Punkt teoretycznie łatwy do spełnienia, jednak nie do końca w tradycyjnym ujęciu systemów i rozwiązań klasy IDS (ang. Intrusion Detection System, typu: QRadar, Splunk, Cisco Stealthwatch i inne).
Kluczem do analizy komunikacji i jej zrozumienia jest języka a więc protokoł. W tym zakresie stworzono już tony publikacji, porównań i szkoleń, które lustrują szereg rozwiązań i standardów w obszarze komunikacji ICS/OT. Musimy sobie szczerze powiedzieć, iż o ile w dzisiejszych czasach mówimy o standaryzacji na poziomie warstwy fizycznej w oparciu o Ethernet, jak i model OSI, tak sięgając wiele lat temu to kwestia ta nie była tak oczywista i ukierunkowana na jeden wspólny standard. W efekcie końcowym, szereg instalacji i rozwiązań z ostatnich 10-15+ lat wstecz, bazuje na różnych standardach, wariacjach i rozwiązaniach. Co więcej, sprawa komplikuje się jeżeli uwzględniamy ilość producentów automatyki przemysłowej. Pozostaję daleki od sformułowania, iż co producent to nowy standard i opracowany protokół, lecz pewnym podsumowaniem niech pozostanie grafika poniżej:
Typowymi przykładami, a zarazem najczęściej spotykanymi w środowisku ICS/OT, są rozwiązania bazujące na Modbus RTU/TCP, Profibus/Profinet i inne jak Devicenet, Bacnet. Aczkolwiek, widać też że wiele zależy od specyfiki instalacji, maszyny i rozwiązania.
System monitoringu sieci i urządzeń, winien wspierać szereg dedykowanych przemysłowych rozwiązań wielu producentów zarówno oprzętu OT/ICS oraz rozwiązań serwerowych i punktów aktywnych typu switch L2, L3, komputerów przemysłowych i stacji operatorskich HMI, laptopów i PC’s służb technicznych.
Mało który ze znanych dostawców oprogramowania klasy IDS stosowanych na warstwach enterprise / biznes IT zapewnia takie możliwości. Dlatego, następna cześć serii artykułów poświęconych ICS/OT vulnerabilities, opisywać będzie szczegółowo dostępne rozwiązania i systemy klasy IDS lecz dedykowane systemom ICS/OT.
Analiza – alarmy i zdarzenia security
Podsumowaniem lub zwieńczeniem powyższych punktów staje się wygenerowanie informacji do użytkownika systemu SIEM (ang. Security Information and Event Management) lub we wspomnianym uprzednio oprogramowaniu klasy IDS. Coś jest nie tak! Sytuacją tą wyzwolić powinno zarówno nieautoryzowane działanie osób trzecich, zachowanie wzbudzające podejrzenie (np. błędne logowanie), naruszenie pewnych zasad, polityk w odniesieniu do samych użytkowników, ich uprawień jak i urządzeń.
Świetnym przykładem jest sytuacji, w której dotychczas nie używany port 445/TCP dla protokołu SMB zostaje zainicjowany. Czy naprawdę taka sytuacja powinna mieć miejsce ?
Inna sytuacją, wywołującą conajmniej dalszą analizę, jest pojawienie się nowego urządzenia/assetu z adresem IP. Czy należy śledzić akcje tego użytkownika, jeżeli zaczyna on skanować sieć przy użyciu narzędzi i poleceń nmap ? Odpowiedź wydaje się oczywista.
Co z komunikacja outbound do adresów IP o dziwnej lokalizacji, conajmniej niepewnym nazewnictwie jakie zwraca serwer DNS ? Czy moja stacja operatorska OWS (ang. Operator WorkStations) naprawdę musi nawiązywać sesję zewnętrzną, i to w dodatku z chińskim adresem IP ?
Sytuacje tego typu powinny być natychmiast raportowane i dalej po nadaniu odpowiedniego priorytetu rozwiązane, przy ostatecznym określeniu jako OK lub NOK.
Jak monitorować ICS/OT
Jedno nie podlega wątpliwości – na pewno w sposób ciągły. Niestety ale doskonałym i kolejnych przykładem jest zdarzenie jakie miało miejsce na przestrzeni ostatnich dni gdy powstawał niniejszy artykuł:
A hack targeting a US drinking water facility just outside Tampa, Florida increased the levels of sodium hydroxide more than a hundred-fold.
Źródło: https://www.chemistryworld.com/
Ten przykład lustruje, iż zaniedbania w obszarze bezpieczeństwa mogą mieć rażące skutki na życie ludzkie.
W kolejnym artykule z serii o podatnościach i zarządzaniu nimi przyjrzymy się serii oprogramowania klasy IDS dedykowanego do środowiska ICS/OT. Z dotychczasowego opracowania tych zagadnień, wynika wniosek iż przy różnorodności dostawców automatyki przemysłowej oraz złożoności tych systemów produkcyjnych, nie ma miejsca na szablonowe rozwiązania.
