Cyberbezpieczeństwo 
wchodzi w nową erę

Fot.: Pixabay

Uwaga na backdoor attacks – cyberataki dokonywane poprzez wykorzystywanie luk w oprogramowaniu! Incydent w amerykańskiej firmie Juniper Networks z grudnia 2015 r. zmienił w wielu zakładach sposób postrzegania bezpieczeństwa przemysłowych urządzeń – odtąd stało się jasne, że hakerzy wykorzystują braki zabezpieczeń celowo zainstalowane w ich oprogramowaniu. Użytkownicy końcowi, integratorzy systemów oraz producenci sprzętu muszą zaakceptować tę nową rzeczywistość i odpowiednio się na nią przygotować. Jak? Postępując według podanych w artykule wskazówek dotyczących zapewnienia cyberbezpieczeństwa.

W yobraźmy sobie inżyniera oprogramowania, który próbuje skompletować główny blok kodu. Niestety, jego szef wycina z tego kodu dużą sekcję, zawierającą standardowe programy typu open source pobrane z Internetu. Zastąpienie usuniętych sekwencji znacznie wydłuży prace nad projektem. Inżynier biegnie więc do gabinetu szefa i błaga:

– Muszę wykorzystać to oprogramowanie w moim systemie!

– Nie możesz, bo to ryzykowne.

Inżynier kiwa głową. Spodziewał się takiej odpowiedzi.

– Przyznaję, że chodzi o oprogramowanie open source ściągnięte z Internetu, ale już z niego korzystaliśmy. Rozmawiałem z innymi inżynierami – na wszelki wypadek przejrzą linijka po linijce kod źródłowy i obiektowy.

Szef zerka na swój wiszący na ścianie certyfikat nagrody za lata pracy w pewnym tajemniczym miejscu.

– Nigdy nie możesz zagwarantować, czy w tym oprogramowaniu nie ma czegoś niebezpiecznego – odpowiada.

Opisana sytuacja mogłaby się zdarzyć naprawdę. Większość ludzi traktuje bowiem oprogramowanie jako coś, co wykonuje przede wszystkim powtarzalne, rutynowe zadania, łatwo zatem zaniedbać reakcję na czyhające niebezpieczeństwo.

Inżynierowie oprogramowania pisujący kody dla urządzeń i systemów przemysłowych starają się w wielu sytuacjach unikać ponownego „odkrywania Ameryki”. Jeśli więc ktoś stworzył już w przeszłości skuteczny kod realizujący określone zadanie, nie chcą pisać go znowu. Wolą zaoszczędzić czas przez ściąganie z Internetu darmowego oprogramowania i otwartych kodów źródłowych – albo kopiują istniejące kody ze swoich wcześniejszych produktów, które sprawdziły się w praktyce. W oparciu o takie właśnie działania naprędce sklecają jakieś oprogramowanie sterujące i ładują go do nowego urządzenia. Tak długo, jak działa ono zgodnie z oczekiwaniami, nikt nie musi wiedzieć i przejmować się tym, skąd pochodzi oprogramowanie.

Tego rodzaju praktyki stanowiły przez dłuższy czas niepisane założenie robocze, ale krajobraz w branży się zmienia. Świat cyberbezpieczeństwa staje się coraz bardziej zagmatwany, w miarę jak swoją obecność ujawniają w nim już nie tylko haktywiści i cyberprzestępcy, ale nawet państwa. Wysiłki hakerów odzwierciedlają szerokie spektrum poziomów umiejętności. Niektóre z nich są niezręczne i łatwe do wykrycia, ale inne bywają podstępne, wyrafinowane i trudne do zidentyfikowania dla zdecydowanej większości ekspertów, z wyjątkiem najlepszych policyjnych specjalistów od cyberprzestępczości.

Niewątpliwie inżynier oprogramowania ze scenki otwierającej ten artykuł, tworząc swój projekt, ma dobre chęci. Jednak to jego szef ma rację: w oprogramowaniu ściągniętym z Internetu może się czaić niebezpieczny kod. Czasami da się go odnaleźć i usunąć, ale zagrożenie może być naprawdę dobrze zakamuflowane.

Hasło brzmi „<<<%s(un=’%s’)=%u”

W grudniu 2015 r. serwis internetowy Ars Technica opublikował szokujący raport:

„17 grudnia 2015 r. firma Juniper Networks wydała nagłe wytyczne bezpieczeństwa na temat »nieautoryzowanego kodu«, odnalezionego w systemie operacyjnym (OS), wykorzystywanym przez niektóre swoje firewalle programowe NetScreen i sprzętowe SSG (Secure Service Gateway – bezpiecznej bramy sieciowej)”.

W raporcie podano, że opublikowano łatkę programową (patch) dla tego systemu operacyjnego (OS), zaś śledztwo policyjne wykazało, iż nieautoryzowany kod działał jak furtka do cyberataku na urządzenia pracujące pod tym systemem.

Dochodzenie pozwoliło odnaleźć hasło administratora użyte do obejścia normalnego uwierzytelnienia. Brzmiało ono: „<<<%s(un=’%s’)=%u”.

Wygląda to na bełkot, ale eksperci od zabezpieczeń informatycznych mogliby jednak uznać, że hasło zostało tak napisane, aby wyglądało na kod debugujący lub tekstowy wewnątrz pliku kodu źródłowego oprogramowania. To sugerowało dwie konkluzje:

1. Nieautoryzowana luka w oprogramowaniu została umieszczona w nim celowo.

2. Starannie ją zaprojektowano, aby uniknąć możliwości wykrycia.

Wygląda więc na to, że nadeszły czasy, w których wrażliwe na atak miejsca będą umyślnie wbudowywane w oprogramowanie, a następnie dokładnie ukrywane. Hakerzy, świadomi funkcji ukrytego kodu, mogą wykorzystać te zaplanowane słabości, kiedy tylko zechcą.

Rysunek wyjaśnia, kiedy łatać sieć pod kątem cyberbezpieczeństwa – zależnie od tego, czy
łatanie ma znaczenie praktyczne, i jaki jest stopień newralgiczności danej aplikacji lub sytuacji.

Co powinni zrobić użytkownicy końcowi?

Zweryfikować status łatki oprogramowania urządzenia. Oczywiście pierwszą rzeczą, jaką powinien zrobić każdy podmiot, jest weryfikacja wszystkich wrażliwych i potencjalnie wrażliwych na atak zainstalowanych urządzeń sieciowych. Należy rozpocząć od założenia, że cały posiadany w zakładzie sprzęt, niezależnie od producenta, jest w podobny sposób zagrożony cyberatakiem.

Wprowadzić łatki do wszystkich urządzeń sieciowych. Po wykonaniu weryfikacji trzeba zainstalować łatki w oprogramowaniu wszystkich posiadanych urządzeń. Chodzi bowiem o konieczność identyfikacji sprzętu znajdującego się w szczególnie newralgicznych obszarach (takich jak przemysłowe systemy sterowania) oraz odnalezienia urządzeń zbyt starych, aby je aktualizować.

Stworzyć macierz reagowania na ryzyko. Wyniki pierwszych dwóch etapów działań wygenerują informacje, które mogą pomóc w zdefiniowaniu możliwej powierzchni ataku. Taka macierz powinna zawierać dwie osie. Zostały one przedstawione na rysunku.

Na osi poziomej znajduje się stopień newralgiczności operacyjnej, który zmienia się od niskiego – dla przełączników sieciowych (switchów), znajdujących się w małych oddziałach organizacji, do wysokiego – dla kluczowych sieci przemysłowych, które muszą działać 24 godziny na dobę, przez siedem dni w tygodniu.

Na osi pionowej odzwierciedlono podatność i możliwość łatania (patchowania), która zmienia się od zerowej (brak możliwości ze względu na wiek sprzętu) do wysokiej (łatwej, osiągalnej dzięki współpracy z producentem urządzenia). Sprzęt realizujący kluczowe operacje, w którym nie można zainstalować łatki, powinien być wymieniony na nowszy.

Wykonanie takiej analizy pomoże każdej firmie być o jeden krok przed tymi, którzy, co nieuniknione, dokonają odtajnienia zabezpieczeń sprzętu sieciowego.

Opracować plan zmiany wrażliwych miejsc ataku. Macierz reagowania na ryzyko powinna stanowić wytyczne dla wszystkich działań mających na celu zaplanowanie wprowadzenia poprawek i łatania urządzeń sieciowych. Dysponując wszystkimi tymi informacjami, personel zajmujący się zabezpieczeniami może przygotować wykres typu burndown chart (graficzne przedstawienie pozostałych do wykonania w projekcie prac względem czasu) wraz z danymi procentowymi pokazującymi ryzyka generowane przez nowe wrażliwe na atak miejsca w urządzeniach sieciowych – gdy tylko się pojawiają. Macierz zapewnia także swego rodzaju dobry plan działania, gdy dojdzie do najgorszej sytuacji, czyli odkryte zostanie złośliwe oprogramowanie (malware), wykorzystujące luki typu zero-day (takie, o których nie wiedzą ani twórcy, ani użytkownicy oprogramowania użytkowego).

Zwiększyć monitoring sieci i jej konfiguracji. Jeśli jakiś podmiot używa sieciowego systemu bezpieczeństwa SNORT (dostępnego na zasadach wolnej licencji), może wykorzystać sygnatury IDS (Intrusion Detection System – systemu wykrywania włamań), które pomagają wykryć atak. Należy także w całym zakładzie przeprowadzić działania mające na celu uzyskanie kontroli nad konfiguracją wszystkich urządzeń sieciowych. Okresowe audyty bezpieczeństwa powinny nie tylko weryfikować konfigurację sprzętu sieciowego, ale także oceniać na żywo aktualną konfigurację sieci poprzez testowanie wzorców ruchu sieciowego.

Zadania dla integratorów systemów dostarczających sprzęt sieciowy

Weryfikacja statusu łatki oprogramowania urządzenia pochodzącej z laboratorium oprogramowania oraz wytycznych jej wdrożenia. Aby odzwierciedlać zmiany w konfiguracjach sprzętu sieciowego, integratorzy powinni łatać wszystkie systemy laboratoriów oprogramowania, a następnie aktualizować wytyczne wdrażania tych łatek.

Załatanie oprogramowania wszystkich urządzeń sieciowych. Integratorzy systemów powinni dokonać tego jak najszybciej, we współpracy ze swoimi klientami oraz użytkownikami końcowymi. Powinni także przeprowadzić szczere rozmowy z klientami, wyjaśniając im nową generację zagrożeń cyberatakami oraz podkreślając wagę przygotowania się na więcej operacji łatania i monitorowania, jakie będą niezbędne w dłuższej perspektywie czasowej. Porównanie grożącego niebezpieczeństwa do działania słynnego robaka Stuxnet nie będzie tu żadną przesadą.

Zaoferowanie klientom zwiększenia monitoringu urządzeń. Integratorzy powinni starannie informować klientów o nowych zagrożeniach oraz opracowywać rozwiązania służące zwiększaniu monitoringu zabezpieczeń i urządzeń sieciowych. To również dobry moment, by sugerować klientom rozważenie zakupu usług wyznaczających kontrolę nad konfiguracją sieci oraz wdrażanie łatania zabezpieczeń sieciowych.

Zadania dla producentów urządzeń (w tym sterowników i kontrolerów przemysłowych)

Weryfikacja statusu opracowania i wdrożenia łatki oprogramowania pochodzącej z laboratorium oprogramowania. Producent urządzeń powinien natychmiast łatać wszystkie systemy tworzenia oprogramowania i laboratoryjne. Procedury bezpieczeństwa należy aktualizować, aby odzwierciedlały zmiany w konfiguracjach sprzętu sieciowego. Trzeba też zaostrzyć kontrolę nad urządzeniami i oprogramowaniem migrującym do środowisk deweloperów.

Sprawdzenie architektury laboratorium oprogramowania i biura oprogramowania. Producenci urządzeń powinni mieć niemal obsesję na punkcie sposobów łączenia sieci deweloperów oprogramowania z innymi sieciami. Warto poświęcać wiele zasobów na identyfikowanie pojawiania się luk w oprogramowaniu swoich urządzeń. Firmy powinny też zapewniać swoich klientów, że będą inwestować w większą kontrolę konfiguracji tworzenia oprogramowania oraz ponownie analizować bezpieczeństwo swojej sieci deweloperskiej tak, aby poprawić jej audyty i monitoring.

Autor: Jeff Melrose jest głównym strategiem technologicznym ds. cyberbezpieczeństwa w firmie Yokogawa. Jego wiedzę i doświadczenie potwierdzają certyfikaty: CISSP-ISSEP (Information Systems Security Engineering Professional – ekspert od opracowywania zabezpieczeń systemów informatycznych) oraz GICSP (Global Industrial Cyber Security Professional – globalny ekspert od przemysłowego cyberbezpieczeństwa).