Bezpieczeństwo cybernetyczne organizacji zależy od odpowiednich polityk bezpieczeństwa, świadomości i edukacji użytkowników (pracowników) oraz jakości stosowanych narzędzi ochronnych. Na to wszystko musi nakładać się systematyczna kontrola stanu zabezpieczeń sieci, infrastruktury i aplikacji. Niezwykle cennej wiedzy w tym zakresie dostarczają testy penetracyjne. 

Aby przekonać się, jak złożonym problemem jest cyberbezpieczeństwo infrastruktury korporacyjnej, wystarczy rozłożyć ją na warstwy. Ochrony wymagają sieć, aplikacje, dane, sprzęt i urządzenia końcowe użytkowników – co nabrało szczególnego znaczenia w warunkach pracy zdalnej; wszystko spięte klamrą fizycznego zabezpieczenia zasobów przed nieuprawnionym dostępem.

Każdy z wymienionych elementów jest ważny i nie może być pomijany w politykach bezpieczeństwa. Jednak to właśnie jakość wytwarzanego bądź używanego w organizacji kodu – z uwagi na znaczne przyśpieszenie cyklu rozwojowego aplikacji i w efekcie, częstsze wdrożenia nowych wersji oprogramowania – nakazuje przyjrzeć się ze szczególną uwagą warstwie aplikacyjnej.

Środowisko aplikacyjne – podstawowe elementy

• komponenty sieciowe (sieć wewnętrzna pozwalająca na komunikację elementów infrastruktury),
• hardware – zasoby sprzętowe,
• wirtualizacja i storage,
• system operacyjny,
• middleware, na którym bezpośrednio jest uruchamiana aplikacja,
• komponenty aplikacyjne – kod, bazy danych, API realizujące określone procesy, udostępniające dane czy komunikujące się z innymi komponentami,
• firewall, Web Application Firewall.

Ochrona aplikacji – najważniejsze narzędzia i procesy 

• analiza statyczna (Static Application Security Testing) – skanowanie kodu aplikacji przed kompilacją,
• analiza dynamiczna (Dynamic Application Security Testing) – dynamiczna analiza kodu aplikacji uruchomionej w środowisku testowym lub akceptacyjnym,
• testy penetracyjne – symulowane cyberataki na infrastrukturę IT, przeprowadzane celem wykrycia jej słabych punktów,
• skanowanie podatności – wykrywanie znanych, zidentyfikowanych wcześniej błędów,
• State Compliance Monitoring – weryfikacja zgodności konfiguracji komponentów aplikacji z wytycznymi branżowymi lub regulacyjnymi.

Procesy SAST i DAST dają dużą wartości z punktu widzenia bezpieczeństwa ale jednocześnie są mocno obciążające pod względem analizy wyników (przykładowo, narzędzia SAST produkują dużo alertów false positive, gdzie zgłaszane podatności i niezgodności w kodzie nie zawsze są prawdziwe). W praktyce stosuję dwa podejścia, w zależności od poziomu doświadczenia interesariusza. W pierwszym wykwalifikowany zespół security wykonuje usługę (pentest), analizuje wyniki i dostarcza klientowi raport; drugi, bardziej zaawansowany, obejmuje szkolenie programistów, by mogli samodzielnie przeprowadzać analizy. Do tego mogą przydać się programy w rodzaju „Security Champion”, pozwalające wyłuskać z zespołów developerskich osoby o odpowiednich kompetencjach.

Łukasz Miedziński, dyrektor obszaru Cyber, ING Tech Poland

Bezpieczeństwo aplikacji – co, gdzie i kiedy

Typowy cykl życia oprogramowania obejmuje cztery główne fazy: prace projektowo-rozwojowe, tworzenie i kompilacja kodu, wdrożenie i produkcja/utrzymanie. Wątki cyberbezpieczeństwa powinny być wplecione w proces od samego początku i obecne przez cały czas, dlatego na każdym z etapów zaleca się stosowanie wymienionych wcześniej narzędzi – pojedynczo lub w połączeniu z innymi.

• prace projektowo-rozwojowe – SAST; zintegrowanie narzędzi skanujących z aplikacjami używanymi przez programistów (w trakcie tworzenia kodu developer może szybko dostać informację o podatnościach),
• tworzenie i kompilacja kodu – połączona analiza statyczna i dynamiczna,
• faza wdrożeniowa – w środowisku akceptacyjnym warto zaaplikować większość procesów bezpieczeństwa, w tym ponownie DAST, pełny manualny pentest, skanowanie podatności i test compliance,
• produkcja/utrzymanie – pentesty w połączeniu z regularnym skanowaniem podatności i weryfikacją compliance.

Metodyki testów penetracyjnych

Istnieje kilka metodyk pentestów, różniących się zakresem, złożonością i szczegółowością. 

• WhiteBox – najszersza pod względem zakresu. Test wykonywany jest przy pełnej wiedzy o aplikacji, tester dysponuje całą dokumentacją, ma wiedzę o architekturze, komponentach,  przepływach danych i interakcjach z użytkownikiem. Zaletą podejścia jest dokładność – testy obejmują zarówno aspekty techniczne, jak i procesowe, minusem – czasochłonność.
• BlackBox – symulacja cyberataku przeprowadzonego z zewnątrz; tester przeprowadza operację bez wiedzy o aplikacji, a samo badanie obejmuje m.in. gromadzenie informacji o celu ataku. Plusem metodyki jest odwzorowanie rzeczywistych scenariuszy ataku. Z drugiej strony natura testu uniemożliwia wykrycie wszystkich luk lub podatności, ponadto niektóre elementy środowiska pozostaną niesprawdzone.
• GreyBox – metodyka łącząca elementy dwóch poprzednich. Tester przeprowadza badanie dysponując niepełną wiedzą o celu ataku i częściową autoryzacją (dostępem) do zasobów. 

Dzięki pełnemu wglądowi do aplikacji, przewidzianemu w ramach testu WhiteBox, tester może opracować szczegółowy plan naprawczy dla organizacji, w tym wskazanie wadliwych elementów i wyprowadzenie podatności. Jednak nie każda organizacja jest na tyle dojrzała, by wytwarzać obszerne dokumentacje, dlatego w tym podejściu trzeba angażować programistów czy inżynierów do współpracy w ramach testu.

BlackBox to dobry początek dla firmy, która nigdy nie przeprowadzała pentestów, bo pokazuje, jak wyglądamy z zewnątrz. Można go zrealizować szybko i wyłapać najprostsze podatności, ale nie identyfikuje wszystkich błędów na poziomie całego stacku technologicznego a tylko te, do których tester uzyska dostęp.

Odpowiedni balans i efektywność z punktu widzenia testowania aplikacji zapewnia GreyBox.

Łukasz Miedziński, dyrektor obszaru Cyber, ING Tech Poland

W ramach testów penetracyjnych aplikacji najlepiej sprawdza się metodyka GreyBox, z przydzielonymi testerom rolami (użytkownik „read only”, zwykły oraz administrator) – taki test należy wykonać w środowisku akceptacyjnym, gdyż procedura może wpłynąć na integralność danych. 

Chcąc zrobić pentest w środowisku akceptacyjnym musimy upewnić się, że jest ono tożsame z produkcyjnym – aby uniknąć sytuacji, że do testów idzie jedna wersja aplikacji, a do produkcji – inna. 

Test aplikacji powinien być powiązany z testem infrastruktury (BlackBox przeprowadzone w środowisku produkcyjnym) – aplikacja udostępnia swoje serwisy na komponentach serwera, więc sprawdzenia wymaga, czy nie pozwalają one na nieautoryzowane operacje.

W wypadku testów penetracyjnych infrastruktury podejście BlackBox zapewnia najlepszy balans efektywności, czasochłonności i kosztu, gdyż można w ten sposób zidentyfikować tzw. low hanging fruits, stosunkowo łatwe do znalezienia luki (przy założeniu, że w organizacji działają narzędzia lub procesy regularnego skanowania podatności i testów compliance). Aktualizacja technologii czy systemów wymaga już przeprowadzenia testu WhiteBox celem sprawdzenia poprawności konfiguracji.

Wszystkie podatności o ważności zaklasyfikowanej jako krytyczna i wysoka powinny być zgłaszane niezwłocznie właścicielowi aplikacji jako incydenty bezpieczeństwa jeszcze podczas wykonywania testu, żeby uruchomić proces Security Incydent Management i nie narażać organizacji na długotrwałe wystawienie na atak.

Łukasz Miedziński, dyrektor obszaru Cyber, ING Tech Poland

Częstotliwość testów

Kluczowe znaczenie dla utrzymania wysokiego poziomu bezpieczeństwa ma regularny monitoring zabezpieczeń. Infrastrukturę – o ile nie zachodzą w niej częste zmiany, na przykład wymiana lub modernizacja komponentów – wystarczy testować raz do roku. Testy podatnościowe (Vulnerability Scanning czy Compliance Testing) powinny być wykonywane regularnie i częściej, raz w tygodniu lub miesiącu, w zależności od tego, jaki jest poziom dojrzałości organizacji.

Jeżeli mamy komponenty krytyczne, które mogą wpływać na bezpieczeństwo innych elementów, np. aplikacji, warto przeprowadzić analizę ryzyka, czy takie komponenty nie powinny być testowane częściej. Moje minimum to co najmniej dwa testy w roku dla aplikacji krytycznych. Przy zmianach w aplikacjach, w ramach projektu czy kolejnego sprintu również należy wykonać test.

Łukasz Miedziński, dyrektor obszaru Cyber, ING Tech Poland

Pentester może ocenić wpływ techniczny wykrytych podatności, a jego ocena powinna być niepodważalna. Nie jest on jednak w stanie ocenić ryzyka biznesowego i tego, jaki wpływ mają podatności na biznes firmy. Organizacja po otrzymaniu raportu powinna przeprowadzić proces oszacowania ryzyka i ocenić realne znaczenie podatności w kontekście bezpieczeństwa swoich operacji. A także ustalić aplikacje krytyczne, priorytetowe, bo nie wszystkimi lukami można zająć się jednocześnie.

Każdorazowo testom powinien towarzyszyć regularny follow-up, czyli przeprowadzone po upływie pewnego czasu sprawdzenie, w jaki sposób organizacja poradziła sobie z usunięciem luk i podatności wykrytych w trakcie pentestu.