Security Operations Center dla obszaru OT – to nieco inna bajka niż ICT

Budując usługę Security Operations Center, która ma objąć swoim zakresem obszar technologii operacyjnej (operational technology, OT) powinniśmy pamiętać, że możemy ją oprzeć o sprawdzony model SOC dla technologii informacyjnej (ICT), uwzględniając przy tym specyfikę i wymagania obszaru OT.

Podstawową różnicą pomiędzy obszarem ICT oraz OT jest cel ich utrzymania. W najprostszym ujęciu obszar ICT zapewnia dostarczenie technologii informacyjnej zaś OT koncentruje się na maszynach. W tym pierwszym przetwarza się dane w ramach określonych procesów cyfrowych. Drugi zarządza procesami fizycznymi i powiązanymi z nimi urządzeniami. Kolokwialnie – obszar IT można sprowadzić do biura, obszar OT do fabryki. Różnica gołym okiem jest znacząca.

Do podstawowych zadań Security Operations Center należy między innymi monitorowanie zasobów, reakcja na incydent bezpieczeństwa, identyfikacja hostów w sieci i śledzenie zmian czy ciągłe doskonalenie mechanizmów bezpieczeństwa. Realizacja tych zadań następuje w obrębie triady SOC – personelu ludzkiego, procesów oraz technologii. SOC wymaga danych wejściowych, które dostarczają informacji dot. pracy poszczególnych, monitorowanych komponentów.

Security Operations Center może być, a niekiedy wręcz powinno być zapewniane zarówno w obszarze ICT jak i w OT. Skuteczny SOC dla obszaru OT musi jednak uwzględniać jego specyfikę i wrażliwość technologiczną. W sieciach OT nie mamy takich możliwości operacyjnych jak w części ICT. W OT mamy zupełnie inne kompetencje, urządzenia czy metody ich komunikacji. Jak zatem podejść do budowy SOC OT?

‘Ludzie nieco inaczej’ – zespół SOC, który ma zapewnić skuteczną reakcję na wystąpienie incydentu bezpieczeństwa musi go przede wszystkim zrozumieć. Profil kompetencyjny operatorów poszczególnych linii powinien uwzględniać znajomość zagadnień procesów technologicznych,  automatyki przemysłowej czy protokołów komunikacyjnych. Istotne jest również zrozumienie działania poszczególnych elementów linii produkcyjnych, zwłaszcza w kontekście ich zależności. Przykładowo operator analizując incydent powinien mieć umieć określić wpływ pozyskanego podczas analizy artefaktu na daną część procesu technologicznego.

‘Procesy nieco inaczej’ – mając na uwadze priorytetowy dla obszaru OT atrybut bezpieczeństwa, którym jest dostępność (w OT bezkompromisowym priorytetem jest ciągłość działania) należy zapewnić skuteczne procesy komunikacyjnego oraz eskalacyjne. Podstawowym sposobem na poprawę sprawności reakcji na incydent jest określenie odpowiedzialności za wsparcie działań operacyjnych usług Security Operations Center na inżynierów OT. Bez wzajemnego zrozumienia i dobrej komunikacji przetwarzanie incydentów bezpieczeństwa będzie bardzo utrudnione lub czasem wręcz niemożliwe. Realizacja procesów takich jak zarządzanie podatnościami czy threat intelligence w OT przebiega zupełnie inaczej.

‘Technologia nieco inaczej’ – w technologii operacyjnej na najniższych poziomach (poziom zerowy do poziomu drugiego modelu PERA) pracujemy z sensorami (L0), sterownikami (L0), siłownikami (L0), robotami (L0), kontrolerami (L1) czy stacjami operatorskimi (L2). W tym obszarze najczęściej nie powinniśmy pozwolić sobie na wyrafinowane, proaktywne narzędzia bezpieczeństwa lokowane bezpośrednio na urządzeniach (np. oprogramowanie agentowe czy proaktywne systemy IPS). Powyżej (poziom trzeci do poziomu piątego) spotkamy już infrastrukturę podobną do tej, znanej z obszaru ICT (np. serwery aplikacyjne, bazy danych, stacje robocze, sieć z logiką biznesową). Ten obszar, z zachowaniem szczególnej ostrożności możemy starać się uzbrajać w systemy protekcji, przy czym model zabezpieczeń dla sieci OT jest różny od tego, co znamy z sieci ICT.

I wreszcie ‘nieco inny biznes’ – produkcja energii elektrycznej, sterowanie ruchem kolejowym czy wytwarzanie charakteryzują się innymi celami, technologiami, procesami produkcyjnymi, specjalizacjami czy wręcz branżami. Podobnie, jak w przypadku świadczenia usługi SOC dla przedsięwzięć opartych o ICT, i w tym przypadku znajomość biznesu jest bardzo istotna. Pamiętajmy że atakujący stosują taktyki, techniki i procedury zależnie od swojego celu, przez co wykrycie zaawansowanych ataków bez znajomości otoczenia wewnętrznego i zewnętrznego nie będzie możliwe.

SOC w OT – jak zacząć?

  1. Inwentaryzacja wszystkich aktywów – podobnie jak w obszarze ICT, również w OT usługa Security Operations Center musi znać wszystkie aktywa oraz powiązania pomiędzy nimi. W obszarze OT bywa to kłopotliwe, zwłaszcza gdy przyjęta architektura sieci czy też procesy utrzymaniowe nie przeszły odpowiedniej transformacji technologicznej; transformacja sama w sobie jest też sporym wyzwaniem, bo OT po prostu musi działać. Komfortową sytuacją są stosunkowo nowe, kilkuletnie i dobrze udokumentowane wdrożenia infrastruktury. W takim przypadku wystarczy przeprowadzić analizę architektury oraz odpowiednio zagregować dane.
  2. Modelowanie wektorów ataków – podobnie jak w przypadku ICT, z tym że wektory ataków są inne. Analiza powinna również uwzględniać casy, które z poziomu sieci ICT mogą wpływać na sieć OT i na odwrót. Kluczowe jest przeanalizowanie otoczenia oraz znajomość ‘biznesu’. Popierając powyższe wiedzą dot. taktyk, technik i procedur grup przestępczych można uzyskać wiedzę dot. potencjalnych ataków jak i informacje dot. źródeł danych (i sposobów ich integracji), które należy objąć monitorowaniem bezpieczeństwa.
  3. Definicja i integracja źródeł danych – o tyle, o ile w ICT możemy korzystać z agentowych źródeł, o tyle w obszarze OT jest to utrudnione lub wręcz niemożliwe. Budując architekturę źródeł danych warto oprzeć się o model PERA (Purdue Enterprise Reference Architecture), który definiuje poziomy integracji (od zerowego do czwartego). Systemy lokowane na poziomie trzecim i czwartym mogą, po wcześniejszej analizie być objęte monitorowaniem agentowym. Systemu poniżej poziomu trzeciego powinniśmy traktować wyjątkowo, nie zmieniając bezpośredniej konfiguracji rozwiązania. Tu przychodzą nam na pomoc dedykowane rozwiązania do monitorowania i detekcji zagrożeń w sieciach OT. Rozwiązania takie jak CheckPoint Asset and Anomaly Detection (AAD), Indegy Industrial Cyber Security Platform, Scada Shield czy SCADVANCE potrafią interpretować protokoły OT oraz wykrywać potencjalne incydenty bezpieczeństwa, korzystając przy tym ze znanych taktyk przestępców oraz zaawansowanej analizy statystycznej. Przed wdrożeniem rozwiązania tej klasy pamiętajmy jednak o modelowaniu wektorów ataków. Tylko w taki sposób będziemy mogli zapewnić optymalne wdrożenie oraz właściwie identyfikować incydenty bezpieczeństwa, nie tworząc przy tym list false – positive.
  4. Opracowanie play books – opracowując play books dla obszaru OT musimy mieć świadomość zapewnienia nieprzerwalności realizowanego procesu biznesowego. Tu nie możemy pozwolić sobie na odłączenie hosta od sieci do celów wykonania przeglądu konfiguracji, o ile naprawdę nie jest to ostateczność. Co więcej, nawet odłączając podejrzaną maszynę czy sterownik od sieci działanie to musimy wykonać w taki sposób, aby nie doszło do przerwy. Zbawieniem jest tu repozytorium konfiguracji i stock. Na ratunek przychodzą też rozwiązania typu TAP (np. Gigamon) lub SPAN port a także analizator pakietów.
  5. Dobrze zaplanowany proces incydent response – obszar OT, ze względu na często spotykaną wrażliwość technologiczną wymaga dużo bardziej dokładnego podejścia do wyjaśniania incydentów bezpieczeństwa. Dodatkowo duża część przedsiębiorstw, które utrzymują infrastrukturę OT, objęta jest wymaganiami prawnymi dot. cyberbezpieczeństwa czyli tzw. cyberustawą. Planując proces incydent response pamiętajmy zwłaszcza o złożoności infrastruktury OT oraz idących za nią niezliczonych ról, które zapewniają jej utrzymanie i doskonalenie.