Bezpieczeństwo dostępu zdalnego do środowisk OT – część I

FBI, Secret Service investigating cyberattack on Florida water treatment plant – TechRepublic

SCADA and IoT Security: What is Broken, & Can it Be Fixed? | BeyondTrust

Analizując ten przypadek doszedłem do wniosku, że chciałbym podzielić się doświadczeniami jakie zdobyliśmy podczas wdrożeń systemów zdalnego dostępu. Szczególnie, że od kilku miesięcy obserwujemy znaczny wzrost liczby projektów w tym obszarze, co oznacza że temat zapewnienia bezpiecznego dostępu zdalnego dla kontraktorów w obiektach przemysłowych, zaczyna być istotny.

W zasadzie, we wszystkich przypadkach, z którymi mieliśmy do czynienia najistotniejszymi czynnikami powodującymi, że klienci w ogóle poszukiwali rozwiązań do zdalnego dostępu do środowiska OT były kwestie bezpieczeństwa. Możliwość nagrywania sesji, zapewnienia poufności haseł przy jednoczesnym utrzymaniu wysokiej wydajności pracy kontraktorów były kluczowe podczas omawiania przypadków użycia. Oczywiście, podniesienie bezpieczeństwa dostępu zdalnego jest obszernym zagadnieniem i powinno uwzględniać szereg różnych czynników. Zatem na początek chciałbym skupić się na pytaniu – „Jak powinien działać system dostępu zdalnego, żeby dostęp ten był możliwie najbezpieczniejszy?”.

Zazwyczaj, filarami bezpiecznego dostępu zdalnego są: architektura systemu, precyzyjnie regulowane uprawnienia (tzw. least privilege) oraz logowanie zdarzeń, nagrywanie sesji i możliwość przeprowadzenia audytu.

Architektura systemu

Najpierw zajmę się architekturą systemu dostępu zdalnego. W tym zakresie niemal zawsze klienci decydują się na systemy implementowane w modelu on-premise, głównie ze względu na potrzebę pełnej kontroli ruchu sieciowego oraz przechowywania logów i nagrań sesji. Bardzo często istotne również są kwestie formalne ulokowania usługi w obszarze geograficznym UE, a nie wszyscy dostawcy usług chmurowych są w stanie zapewnić, że usługa zawsze jest świadczona w ten sposób. Zatem, jeśli całość systemu znajduje się w środowisku klienta, dział IT ma pełną kontrolę nad ruchem sieciowym, czasem retencji i miejscem składowania logów i nagrań.

Co do samego systemu, zauważyłem że klienci bardzo cenią sobie rozwiązania oparte o tzw. appliance, czyli system fabrycznie przygotowany do działania (out-of-the-box) i zabezpieczony (hardening) przez producenta w formie albo fizycznego serwera, albo – co bardziej praktyczne – obrazu maszyny wirtualnej. Naturalnie, całość ruchu sieciowego związanego z działaniem systemu i nawiązywaniem sesji musi być szyfrowana (zazwyczaj wykorzystywany jest w tym celu TLS). Dla zminimalizowania powierzchni ataku, wszystkie zbędne usługi powinny być wyłączone, a do działania samego systemu powinien być wykorzystywany minimalny zestaw portów – najlepiej jeden.

Istotnym i powszechnie wykorzystywanym elementem architektury przy opisywanych projektach, są serwery proxy. Wynika to z faktu, że zazwyczaj urządzenia w infrastrukturze OT są osadzone w sieciach wyizolowanych, bez dostępu do sieci zewnętrznej czy do innych podsieci w organizacji. Zastosowanie serwerów proxy z jednej strony umożliwia wykonanie połączenia do sieci wyizolowanej, a z drugiej – dodaje kolejną warstwę zabezpieczeń, ponieważ nawiązanie połączenia w ten sposób wymaga od użytkownika posiadania odpowiednich uprawnień. Dodatkową zaletą pracy w tym trybie jest kontrola nad ruchem sieciowym. Możliwe jest wskazanie tylko tych urządzeń wewnątrz sieci wyizolowanej, które mogą łączyć się przez proxy, a sam ruch z proxy jest kierowany wyłącznie do wspomnianego wcześniej appliance, będącego trzonem systemu zdalnego dostępu.

Pojawia się jeszcze pytanie, gdzie powinien być umieszczony sam appliance? W tym przypadku bywają stosowane są różne scenariusze. Czasem preferowane jest zestawienie klasycznego tunelu VPN między kontraktorem, a wydzieloną podsiecią w infrastrukturze klienta. Czasem, ze względu na uproszczenie procesów, np. uniknięcia angażowania działu sieciowego w przypadku uruchamiania dostępu dla nowego kontraktora, preferowana jest konfiguracja, która działa bez potrzeby stosowania tuneli VPN. Optymalnie, gdy system może obsłużyć jednocześnie obydwa warianty.

Przykładowy model architektoniczny przedstawiony jest na rycinie poniżej.

Bezpieczeństwo procesu dostępu do zasobów

Po implementacji systemu dostępu zdalnego przychodzi czas na zadanie pytania „Kto i w jaki sposób będzie mógł nawiązywać sesje do zasobów wewnątrz organizacji?”. W tym przypadku, zawsze pierwszym krokiem będzie zdefiniowanie procesu logowania kontraktora do systemu zdalnego dostępu. Konto użytkownika, którego będzie używał kontraktor najczęściej jest kontem domenowym, choć niektórzy klienci preferują utrzymywanie kont lokalnych systemu dostępowego. Obydwa warianty mają swoje zalety, zatem ważne jest, by można było w łatwy sposób je zaimplementować. W zakresie samego bezpieczeństwa logowania do systemu dostępowego, standardem jest zabezpieczenie tego procesu drugim składnikiem uwierzytelniania (2FA/MFA). Jeśli klient nie ma własnych narzędzi, żeby taki proces uruchomić, sugerujemy rozważenie takiego systemu. Nie tylko w kontekście omawianego zagadnienia, ale z perspektywy ochrony dostępu w całej infrastrukturze. Ewentualnie, możliwe jest wykorzystanie jednego z dostępnych na rynku serwisów generujących jednorazowe kody, np. Microsoft Authenticator, czy Google Authenticator. Zatem kontraktor, żeby zalogować się do systemu zdalnego dostępu musi podać swoje poświadczenia (login i hasło), a następnie zatwierdzić proces uwierzytelniania wpisując kod wysłany na jego numer telefonu lub potwierdzić dostęp w dedykowanej aplikacji. Po skutecznym zalogowaniu kontraktor widzi tylko te urządzenia, do których powinien móc nawiązywać połączenia i na których będzie mógł wykonywać ograniczony zestaw akcji. Tym zagadnieniem zajmę się w drugiej części publikacji.

Żeby operować przykładem dla takiego procesu, załóżmy że kontraktor musi wykonać prace na jednym z systemów. Naturalnie, pojawia się szereg pytań. Czy kontraktor powinien móc wykonać takie połączenie w dowolnym dniu o dowolnej godzinie? Czy dostęp powinien być dodatkowo zatwierdzany? Kto powinien zostać poinformowany o rozpoczęciu i zakończeniu sesji? Są to pytania bezpośrednio związane z wewnętrznymi procesami akceptacji i monitorowania sesji realizowanych przez zewnętrznych dostawców. W wariancie najbardziej bezpiecznym mogą zostać nałożone wszystkie powyższe restrykcje. Kontraktor będzie mógł wykonywać sesję tylko w ustalonych oknach serwisowych, a przed rozpoczęciem sesji będzie konieczne uzyskanie zgody. Oczywiście mechanika i implementacja takiego zachowania muszą być obsługiwane w systemie dostępu zdalnego. Kontraktor musi mieć możliwość złożenia w prosty sposób wniosku dostępowego, który następnie jest dystrybuowany, zazwyczaj do grupy osób wewnątrz organizacji odpowiedzialnych za określony zasób i określonego kontraktora. Jeśli zatwierdzenia nie ma, to po prostu sesja nie będzie mogła się odbyć. Natomiast jeśli wniosek zostanie zatwierdzony, kontraktor może rozpocząć pracę w wyznaczonym oknie serwisowym, a w momencie uruchomienia sesji, odpowiednie osoby zostaną o tym fakcie powiadomione, np. audytor, który chce uczestniczyć w pracach i je nadzorować.

Poniżej został zobrazowany schemat wnioskowania i nawiązywania sesji zdalnej.