Testy bezpieczeństwa aplikacji: minimalny zestaw działań dla zarządów

Bezpieczeństwo aplikacji trafia na posiedzenia zarządu zwykle w jednym z dwóch momentów: przy audycie i po incydencie. W obu przypadkach rozmowa jest trudna, bo toczy się pod presją i w języku, którego zarząd nie używa na co dzień. Pada pytanie o to, czy jesteśmy bezpieczni, a odpowiedź brzmi „to zależy”, co nikogo nie uspokaja i nie prowadzi do żadnej decyzji.

Zarząd nie musi rozumieć technik ataku. Musi wiedzieć, jakie mechanizmy kontrolne w firmie działają, kto za nie odpowiada i po czym poznamy, że przestały działać. Poniżej dziesięć elementów, które w naszej praktyce audytowej tworzą sensowne minimum, uporządkowanych od tych, które dają najwięcej przy najmniejszym nakładzie.

Dlaczego to temat dla zarządu, a nie tylko dla działu technicznego

Trzy powody wystarczą. Pierwszy to odpowiedzialność: przy naruszeniu ochrony danych osobowych rozliczana jest organizacja, nie zespół, który wdrożył podatną wersję. Drugi to pieniądze: decyzje o budżecie na kontrolę bezpieczeństwa zapadają poza działem technicznym, więc bez zrozumienia zarządu pozostają na liście życzeń. Trzeci to czas reakcji, który zależy od tego, czy ktoś ma prawo zatrzymać wydanie albo odłączyć usługę bez konsultacji.

Warto też zauważyć, że najczęstsze przyczyny incydentów są od lat te same i doskonale opisane. OWASP publikuje zestawienie dziesięciu najpoważniejszych kategorii ryzyk w aplikacjach webowych, a w wydaniu z 2021 roku pierwsze miejsce zajęła kontrola dostępu, przed błędami kryptograficznymi i wstrzyknięciami. To nie są egzotyczne ataki, tylko rzeczy, które da się systematycznie sprawdzać.

Dziesięć elementów minimum

Cztery elementy, które dają najwięcej na starcie

Mapa ryzyk i trzy scenariusze. Zanim kupicie jakiekolwiek narzędzie, warto ustalić, co konkretnie chcecie chronić. Wyciek danych klientów, przejęcie konta administratora i zatrzymanie sprzedaży to trzy różne zagrożenia, wymagające trzech różnych mechanizmów. Bez tego ustalenia budżet rozłoży się równomiernie tam, gdzie akurat było najłatwiej coś wdrożyć.

Kontrola zależności. Większość kodu w typowej aplikacji pochodzi z bibliotek zewnętrznych, a podatności w nich są publicznie znane i katalogowane. Agencja CISA prowadzi katalog podatności potwierdzonych jako wykorzystywane w rzeczywistych atakach i to jest praktyczna lista priorytetów: jeśli coś z niej dotyczy Waszego stosu technologicznego, nie ma o czym dyskutować.

Testy uprawnień jako osobna kategoria. To najczęściej pomijany obszar i jednocześnie ten, w którym błędy są najdotkliwsze, bo prowadzą wprost do dostępu do cudzych danych. Regresja funkcjonalna ich nie wykryje, bo sprawdza, czy uprawniony użytkownik może wykonać operację, a nie czy nieuprawniony nie może.

Ćwiczenie incydentu. Sam plan reagowania jest dokumentem, a dokument nie odbiera telefonu o drugiej w nocy. Publikacja NIST poświęcona obsłudze incydentów bezpieczeństwa komputerowego opisuje cykl obejmujący przygotowanie, wykrywanie i analizę, ograniczanie i usuwanie skutków oraz działania po incydencie. Element „przygotowanie” obejmuje ćwiczenia i to jest jedyna część, którą da się sprawdzić przed prawdziwym zdarzeniem.

Pozostałe sześć elementów i po co są w tej tabeli

Analiza statyczna kodu. Narzędzie przeglądające kod źródłowy w poszukiwaniu znanych wzorców błędów, włączone w proces budowania. Sensowne pod jednym warunkiem: próg musi być ustawiony tak, żeby zespół realnie reagował na wyniki. Bramka zgłaszająca kilkaset ostrzeżeń przy każdej zmianie zostanie po tygodniu obejściem, a nie kontrolą, i będzie gorsza niż jej brak, bo da fałszywe poczucie pokrycia.

Testy dynamiczne działającej aplikacji. Skan systemu w takiej postaci, w jakiej widzi go osoba z zewnątrz. Wartość pojawia się dopiero przy regularności: raz w roku przed audytem jest formalnością, raz na wydanie albo raz w miesiącu na środowisku zbliżonym do produkcyjnego zaczyna wychodzić na to, po co powstał.

Sekrety i konfiguracja. Klucze, hasła i tokeny nie mają prawa być w repozytorium, a środowiska muszą być rozdzielone tak, żeby dane produkcyjne nie trafiały do testowych. Wbrew pozorom to najczęstsze znalezisko przy pierwszym przeglądzie i zwykle najprostsze do naprawienia, choć naprawa oznacza rotację wszystkiego, co wyciekło do historii zmian.

Monitorowanie i czas wykrycia. Pytanie brzmi nie „czy mamy logi”, tylko „czy ktoś patrzy i po jakim czasie zareaguje”. Miara jest prosta: ile godzin minęło między pierwszym sygnałem w systemie a pierwszą reakcją człowieka. Jeśli tej liczby nikt nie zna, to znaczy, że sygnał nie dociera do nikogo.

Jeden przegląd dla zarządu. Kilka liczb i jedno zdanie o kierunku, publikowane w stałym rytmie: liczba otwartych podatności o wysokiej istotności, najstarsza z nich, czas wykrycia i data ostatniego ćwiczenia. To wystarczy, żeby zarząd widział trend, a nie tylko incydenty.

Wymagania wobec dostawców. Integracja z zewnętrznym systemem oznacza, że część Waszego ryzyka leży poza Waszą kontrolą. Minimum to zapis w umowie o obowiązku zgłoszenia incydentu w określonym czasie oraz o możliwości weryfikacji zabezpieczeń. Bez tego dowiecie się o problemie u dostawcy wtedy, co Wasi klienci.

Jak wdrożyć to bez programu na rok

Największym błędem jest ogłoszenie rocznego programu bezpieczeństwa z harmonogramem i komitetem sterującym. Taki program konsumuje kwartał na ustalenia, a przez ten czas nie zmienia się nic w kodzie ani w konfiguracji. Skuteczniejsza jest kolejność odwrotna: najpierw dwie rzeczy, które da się włączyć w dwa tygodnie, potem reszta.

Praktyczny plan na pierwszy kwartał wygląda tak. Tydzień pierwszy i drugi: kontrola zależności włączona w proces budowania, z progiem obejmującym wyłącznie podatności o wysokiej istotności, żeby zespół nie utonął w ostrzeżeniach. Tydzień trzeci i czwarty: przegląd repozytoriów pod kątem sekretów i rotacja tego, co znajdziecie. Drugi miesiąc: mapa ryzyk i trzy scenariusze, ustalone wspólnie z biznesem, nie tylko z działem technicznym. Trzeci miesiąc: pierwsze ćwiczenie incydentu i pierwszy jednostronicowy przegląd dla zarządu.

Po takim kwartale macie coś, czego nie da żaden dokument: wiedzę o tym, gdzie faktycznie stoicie, i cztery działające mechanizmy zamiast dziesięciu planowanych. Reszta z tabeli dokłada się przez kolejne miesiące, w kolejności wynikającej z mapy ryzyk, a nie z tego, co akurat jest modne na konferencjach.

Warto też uczciwie powiedzieć, czego to minimum nie daje: nie zastępuje testów penetracyjnych ani niezależnego audytu. Daje natomiast stan, w którym taki audyt ma sens, bo nie skończy się listą oczywistości znanych zespołowi od dawna.

Rola zespołu jakości w tym układzie

W wielu organizacjach bezpieczeństwo jest formalnie poza QA, a praktycznie to właśnie testerzy jako pierwsi widzą sygnały: identyfikator w adresie, który da się podmienić, komunikat błędu ujawniający strukturę bazy, formularz przyjmujący dane bez ograniczeń. Problem polega na tym, że te obserwacje nie mają gdzie trafić, bo w kategoriach zgłoszeń nie ma dla nich miejsca.

Najtańsza zmiana, jaką można wprowadzić, to osobna kategoria zgłoszeń dla obserwacji dotyczących bezpieczeństwa i jedna osoba, która je przegląda co tydzień. Nie wymaga to nowych narzędzi ani nowych etatów, a zamienia rozproszone spostrzeżenia w listę, którą da się priorytetyzować. W kilku projektach, w których to wprowadziliśmy, pierwszy przegląd przyniósł więcej znalezisk niż zaplanowany na kwartał później skan automatyczny.

Druga zmiana dotyczy języka. Zgłoszenie „można podmienić identyfikator w adresie” brzmi jak ciekawostka techniczna. To samo zgłoszenie opisane jako „użytkownik może zobaczyć dane innego klienta” trafia na inną listę priorytetów, choć dotyczy dokładnie tej samej linii kodu. Warto tego uczyć zespół, bo od tego zależy, czy problem zostanie naprawiony w tym tygodniu, czy za pół roku.

Co mówić klientom i regulatorowi, zanim będzie trzeba

Osobna warstwa tego tematu dotyczy komunikacji. Przy naruszeniu ochrony danych osobowych obowiązują terminy i obowiązki informacyjne, a decyzja o tym, czy i kogo powiadomić, zapada zwykle w pierwszych godzinach, przy niepełnych informacjach. Zespół techniczny nie powinien podejmować jej sam, a zarząd nie powinien poznawać reguł dopiero wtedy, gdy zegar już tyka.

Najtańsze zabezpieczenie to ustalenie z góry trzech rzeczy: kto decyduje o powiadomieniu, kto rozmawia z klientami i jakie informacje muszą być zebrane, żeby ta decyzja miała podstawy. To jedna strona, przygotowana raz, sprawdzona przy ćwiczeniu incydentu. Firmy, które ją mają, przechodzą przez pierwsze godziny znacznie spokojniej, niezależnie od skali samego zdarzenia, bo nie tracą czasu na ustalanie ról.

Powiązane na Strefie QA

• Najczęstsze dziury bezpieczeństwa, które QA widzi, a nikt nie słucha
• Ile kosztuje luka bezpieczeństwa, której nikt nie szukał
• Trzy rodzaje ryzyka, których nikt nie uwzględnia w planie testów

Źródła:

• OWASP Top 10, zestawienie najpoważniejszych kategorii ryzyk w aplikacjach webowych
• OWASP ASVS, standard wymagań weryfikacji bezpieczeństwa aplikacji
• OWASP, zarządzanie sekretami: praktyki i najczęstsze błędy
• NIST SP 800 61 rev. 2, Computer Security Incident Handling Guide
• CISA, katalog podatności potwierdzonych jako wykorzystywane w atakach
• Testy bezpieczeństwa, Quality Island