Cyberataki stały się codziennością. To co jeszcze kilka lat temu wydawało się nam wyłącznie fikcją znaną z filmów akcji, dziś nikogo już nie dziwi. Codziennie słyszymy o kolejnym ataku, wycieku danych czy nawet całkowitym paraliżu przedsiębiorstwa. Widzimy, że celem ataków są zarówno giganci tacy jak Maersk czy British Airway, jak również drobne firmy i jednostki Państwowe takie jak np. Urząd Gminy Lututów, Politechnika Warszawska czy KNF.

Wraz z nadejściem ery gospodarki 4.0 przedsiębiorstwa coraz bardziej się digitalizują, a co za tym idzie systemy IT, którymi się posługują pełnią coraz większą rolę w sprawnym zarządzaniu firmą. Dlatego czasowa niedostępność tych systemów może wiązać się z paraliżem organizacji, jak miało to miejsce w ataku na jedną z hut stali w Niemczech. Hakerzy wyłączyli w niej jeden z pieców, co w rezultacie doprowadziło do wielomilionowych strat spowodowanych fizycznymi uszkodzeniami infrastruktury huty. W skrajnych przypadkach ataki mogą również doprowadzić do poważnego uszczerbku na zdrowiu a nawet śmierci. Tak głośny ostatnimi czasy przypadek ataku na szpital w Düsseldorfie jest tego dowodem. W efekcie cyberataku zablokowany został system szpitalny, przez co nie było możliwym przyjęcie pacjentki w ciężkim stanie, która zmarła w drodze do innego szpitala.

Należy też wziąć pod uwagę to, że wiele system IT jest w ciągłym rozwoju, aby na bieżąco dostosowywać się do zmieniających wymagań rynkowych. Idealnym tego przykładem jest przeniesienie wielu usług do Internetu po nastaniu pandemii. Digitalizacja ta z reguły odbywa się w błyskawicznym tempie, a wtedy łatwo o wypuszczenie systemów z błędami w zabezpieczeniach oprogramowania tzw. podatnościami, na które czyhają hackerzy.

Jak w takim razie zabezpieczyć systemy zarówno te, które zostały już napisane jak również te, które są w fazie ciągłego rozwoju i jednocześnie muszą być dostępne do użytku?

System nie będący w fazie rozwoju

Jeżeli kupowaliście kiedyś mieszkanie nie ważne czy nowe czy używane i sami nie znacie się na budowlance, to zapewne korzystaliście z pomocy fachowca. Jego zadaniem było zweryfikowanie czy wasze wymarzone M zostało wybudowane zgodnie ze sztuką. Taki ekspert sprawdza m.in to czy ściany trzymają pion, czy nie ma mostków termicznych albo czy w mieszkaniu nie występują uszkodzenia mechaniczne będące efektem braku uwagi robotników budowlanych.

W przypadku systemów IT ich właściciel również bardzo często nie zna się na tworzeniu oprogramowania, a tym bardziej na kwestiach bezpieczeństwa. Dlatego, analogicznie do sytuacji kupna mieszkania, w kwestii weryfikacji bezpieczeństwa systemów IT również należy skorzystać z pomocy eksperta, tzw. pentestera. Wykonuje on, jak sama nazwa wskazuje, Testy Penetracyjne aplikacji, czyli audyty bezpieczeństwa oparte najczęściej na standardach takich jak OSSTMM, ISO 2700x, czy najpopularniejszy OWASP czyli Open Web Application Security Project i zdefiniowanych przez niego list najczęstszych luk bezpieczeństwa systemów IT (OWASP Top 10) oraz aplikacji mobilnych (OWASP Top 10 Mobile).

Jak wygląda taki test bezpieczeństwa?

Jest to, podobnie jak w przypadku ataku hakerów, szturm na testowany system. Jednak tutaj podobieństwa się kończą. Atak ten przede wszystkim wykonywany jest w porozumieniu z właścicielem systemu, dzięki czemu może zostać zaplanowany w sposób, który nie zakłóci poprawnego działania organizacji. Ponadto podczas prawdziwego ataku hakerowi wystarczy znalezienie jednej podatności, która pozwoli mu przełamać zabezpieczenia i ma na to nieograniczony czas. Zadaniem pentestera jest znalezienie jak największej ilości podatności, idealnie wszystkich, i musi to zrealizować w określonym czasie. Dlatego pentesterzy często korzystają z przewagi, jaką jest możliwość wglądu w kod źródłowy oprogramowania. Testy takie nazywane są wtedy whitebox i w odróżnieniu od ataków bez dostępu do kodu źródłowego (tzw. blackbox), są o wiele dokładniejsze.

W rezultacie audytu przygotowany zostaje raport, w którym wyszczególnione zostaną wszystkie wykryte podatności. Zawiera on również informacje dla programistów informujące o tym, jak dane podatności należy naprawić.

Po “załataniu” wszystkich luk bezpieczeństwa rekomendowanym jest również przeprowadzenie audytu weryfikacyjnego, który sprawdzi czy wdrożono wszystkie rekomendacje opisane w raporcie.

Czy po audycie bezpieczeństwa system jest już bezpieczny ?

Należy pamiętać, że zadaniem audytu bezpieczeństwa jest zmniejszenie ryzyka związanego z cyberatakiem. Całkowita ochrona bardzo często jest niemożliwa. Jedną z przyczyn jest to, że współczesne systemy IT nigdy nie są tworzone od podstaw. Wykorzystują gotowe silniki oraz biblioteki bazujące na otwartym kodzie, tzw. OpenSource. Biblioteki te mogą być wykorzystywane zarówno w części serwerowej tzw. backend (np. Spring czy Laravel), części webowej, tzw. frontend (AngularJS, React czy Vue.js) a także w aplikacjach mobilnych (np. Flutter, React Native). Rozwiązania te używane są po to, żeby ułatwić pracę programistom i w rezultacie przyspieszyć proces rozwoju oprogramowania oraz obniżyć koszty jego produkcji. Takich bibliotek wykorzystanych w projekcie IT może być bardzo dużo, od kilkudziesięciu do nawet kilkuset. Dlatego ich ręczna weryfikacja jest niemożliwa. Z reguły odpowiedzialność za bezpieczeństwo konkretnych bibliotek spada na ich twórców. Dostarczają oni najczęściej nowe wersje bibliotek zawierające łatki bezpieczeństwa, tzw. patche. Łatki, z kolei, są często odpowiedzią na pojawiające się w publicznych bazach podatności informacje o tym, że w danej bibliotece wykryto nową “dziurę”. Jedną z najpopularniejszych baz tego typu jest CVE (Common Vulnerabilities and Exposures), z której możemy się dowiedzieć czy biblioteki z których korzystamy są bezpieczne czy nie. Jest to istotna informacja dla nas, ale należy pamiętać że z racji, że jest to informacja publiczna, wiedzą o niej również hackerzy. Dlatego koniecznym jest aktualizacja bibliotek z podatnościami na ich nowsze wersje, a jeśli takowe nie istnieją to zamiana na biblioteki alternatywne. Oczywiście ręczna weryfikacja wszystkich wykorzystywanych w systemie bibliotek byłaby zadaniem karkołomnym. Dlatego do tego celu wykorzystywane są specjalne skanery podatności, które w sposób automatyczny sprawdzają nie tylko to, czy biblioteka wykorzystywana przez system posiada podatności w bazach takich jak CVE, ale również zweryfikują czy nasz system IT spełnia podstawowe reguły bezpieczeństwa OWASP.

A co z systemami będącymi w fazie ciągłego rozwoju?

Kwestia aktualizacji bibliotek nie jest jednak tak poważnym zagadnieniem, jak konieczność weryfikacji zmian w naszym systemie. Często jest tak, że aby dopasować się do ciągle zmieniających się potrzeb rynkowych, musimy modyfikować i rozszerzać nasz system na bieżąco. W dobie wszechobecnej transformacji cyfrowej tzw. Digital Transformation jest to zjawisko coraz częstsze, a wręcz ośmielę się powiedzieć “typowe” dla współczesnych produktów IT.

Jak w takim przypadku zapewnić bezpieczeństwo takiego systemu? Oczywistą odpowiedzią, jaka się nasuwa, jest przeprowadzenie audytu bezpieczeństwa. Tylko kiedy taki test penetracyjny systemu powinien zostać przeprowadzony ? Ponownie odpowiedź nasuwa się sama, że za każdym razem jak upubliczniana jest nowa wersja systemu, ponieważ każda nowa zmiana niesie ryzyko wprowadzenia również luk bezpieczeństwa. Jednakże ciągłe wykonywanie testów bezpieczeństwa może znacząco podrożyć koszty jego wytworzenia oraz znacznie spowolnić Time-To-Market nowych wersji produktu. Czy jest w takim razie inne rozwiązanie ?

Ciągły monitoring na ratunek

Rozwiązaniem jest wprowadzenie mechanizmu ciągłego monitoringu pentesterskiego. Jak to działa? Żeby to wyjaśnić należy zrozumieć jak wygląda proces wytwarzania oprogramowania. Programiści piszą kod źródłowy programu na swoich komputerach i laptopach. Następnie wgrywają go do tzw. repozytorium kodu, najczęściej jest to Git. Po wgraniu do repozytorium kodu specjalne serwery budujące tzw. Servery CI/CD (Continuous Integration/Continuous Delivery) wykonują kompilację kodu źródłowego. W trakcie kompilacji język programowania zrozumiały dla programisty zostaje zamieniony na binarny kod maszynowy rozumiany przez komputer. Po zakończeniu tej fazy, wykonywane są na pliku binarnym testy automatyczne weryfikujące, czy nowe funkcjonalności nie zdestabilizowały tych wcześniej już istniejących. Jeśli wszystko zakończy się sukcesem, plik jest wgrywany na właściwy serwer, na którym program zostanie uruchomiony.

Jeśli w ramach procesu rozwoju oprogramowania wykonywane są automatyczne testy weryfikujące stabilność kodu, to czy mogą istnieć również automatyczne testy weryfikujące jego bezpieczeństwo ? Właśnie tym jest ciągły monitoring pentesterski. Polega on na wpięciu skanera podatności w proces CI/CD tak, aby przy każdym wypuszczeniu nowej wersji oprogramowania można było również weryfikować bezpieczeństwo tworzonego produktu oraz wykorzystywanych przez niego bibliotek OpenSource. I podobnie jak w przypadku testów automatycznych, tak w przypadku ciągłego monitoringu, wymagana może być aktualizacja konfiguracji takiego skanera w odpowiedzi na nowe funkcjonalności oraz modyfikacje monitorowanego systemu. Aktualizacja takiej konfiguracji nie wymaga jednakże takich nakładów jak przeprowadzenie całościowego audytu bezpieczeństwa. Należy jednak pamiętać, że ciągły monitoring, pomimo że jest procesem w którym pentester aktualizuje konfigurację skanera, nadal opiera się wyłącznie na skanach automatycznych, dlatego szczególnie dla krytycznych systemów w ramach ciągłego monitoringu pentesterskiego rekomendowane byłyby okresowe całościowe audyty bezpieczeństwa co 6, 12 lub 24 miesiące w zależności od stopnia krytyczności owych systemów.