Bezpieczeństwo aplikacji i audyty
Bezpieczeństwo aplikacji rzadko przegrywa na wyrafinowanym ataku. Znacznie częściej przegrywa na kluczu zostawionym w repozytorium, na bibliotece, której nikt nie aktualizował od dwóch lat, i na tym, że zwykły użytkownik po podmianie jednego identyfikatora w adresie widzi dane cudzej firmy.
Sprawdzamy właśnie takie rzeczy - te, które realnie się zdarzają i realnie kończą wyciekiem. Efektem audytu jest lista uporządkowana według rzeczywistego ryzyka, z opisem, jak każdą pozycję naprawić, a nie stustronicowy wydruk ze skanera automatycznego.
Co sprawdzamy podczas audytu
Zaczynamy od uwierzytelniania i uprawnień, bo tam znajduje się najwięcej poważnych błędów. Sprawdzamy sposób logowania, cykl życia sesji i tokenów, zasady dotyczące haseł oraz to, czy każde żądanie do serwera weryfikuje uprawnienia niezależnie od tego, co pokazuje interfejs. Ukrycie przycisku nie jest zabezpieczeniem.
Następnie dane: co jest zbierane, gdzie przechowywane, jak długo i kto ma do tego dostęp. Weryfikujemy szyfrowanie w spoczynku i w tranzycie, sposób przechowywania haseł, dostęp do kopii zapasowych oraz to, czy dane produkcyjne nie krążą po środowiskach testowych, co zdarza się zaskakująco często.
Trzeci obszar to warstwa aplikacyjna: obsługa danych wprowadzanych przez użytkownika, wstrzyknięcia do zapytań, przesyłanie plików, nagłówki bezpieczeństwa, konfiguracja domen uprawnionych do odpytywania API i ochrona przed zautomatyzowanym nadużyciem formularzy.
Czwarty to łańcuch dostaw i infrastruktura: przegląd zależności pod kątem znanych podatności, sekrety w kodzie i historii repozytorium, uprawnienia w chmurze, otwarte porty, konfiguracja magazynów plików oraz to, co dzieje się z uprawnieniami po odejściu pracownika.
- Uwierzytelnianie, sesje i kontrola uprawnień
- Przechowywanie i szyfrowanie danych osobowych
- Typowe podatności warstwy aplikacyjnej
- Zależności, sekrety i konfiguracja chmury
- Kopie zapasowe i procedura odtworzenia
Jak wygląda raport
Każde znalezisko opisujemy w ten sam sposób: na czym polega, jak je odtworzyliśmy, co może się wydarzyć, jeśli zostanie wykorzystane, i jak konkretnie je usunąć. Priorytet wynika z połączenia dotkliwości skutków z łatwością wykorzystania, więc na górze listy trafia to, co jest jednocześnie groźne i proste do zrobienia.
Raport dzielimy na dwie części. Streszczenie dla osób decyzyjnych mieści się na jednej stronie i odpowiada na pytanie, czym trzeba się zająć w tym miesiącu. Część techniczna zawiera szczegóły, fragmenty kodu i propozycje poprawek dla zespołu, który będzie je wprowadzał.
Po naprawie wracamy i sprawdzamy poprawki. Audyt bez ponownej weryfikacji zbyt często kończy się przekonaniem, że problem został rozwiązany, podczas gdy poprawka zamknęła jedną ścieżkę i zostawiła otwartą drugą.
Bezpieczeństwo w trakcie budowy, nie po niej
W projektach, które prowadzimy od początku, przeglądy bezpieczeństwa są częścią zwykłej pracy. Automatyczne sprawdzanie zależności działa przy każdej zmianie w kodzie, sekrety trzymamy w menedżerze, a nie w plikach konfiguracyjnych, i domyślnie zakładamy najwęższy zestaw uprawnień, rozszerzając go dopiero wtedy, gdy coś faktycznie tego wymaga.
Ten sposób pracy jest wielokrotnie tańszy od naprawiania. Poprawka wprowadzona w tygodniu, w którym powstał kod, to kilkanaście minut. Ta sama poprawka po dwóch latach, gdy na wadliwym założeniu opiera się połowa systemu, potrafi kosztować tygodnie.
Dane osobowe i obowiązki formalne
Przy okazji audytu porządkujemy kwestie związane z danymi osobowymi: jakie kategorie danych przetwarzasz, na jakiej podstawie, jak długo je trzymasz i czy potrafisz zrealizować żądanie usunięcia bez ręcznego przeszukiwania bazy. Nie zastępujemy prawnika, ale wskazujemy miejsca, w których technika nie pozwala spełnić deklaracji z polityki prywatności.
Sprawdzamy również, czy istnieje możliwość odtworzenia przebiegu zdarzeń. Przy incydencie liczy się to, czy da się ustalić, do jakich danych i kiedy uzyskano dostęp - bez dzienników zdarzeń każda odpowiedź na to pytanie jest domysłem.
Dla kogo to robimy
Najczęściej dla firm, które przetwarzają dane swoich klientów i doszły do etapu, na którym ktoś zaczął o to pytać: kontrahent przed podpisaniem umowy, ubezpieczyciel albo własny zarząd. Pracujemy też z zespołami przed dużym uruchomieniem, gdy warto sprawdzić system, zanim zobaczy go kilka tysięcy osób naraz.
Działamy z Rybnika, obsługujemy klientów ze Śląska i całej Polski, a sam audyt prowadzimy zdalnie - do pracy potrzebujemy dostępu do kodu i środowiska testowego, a nie obecności w biurze.
Najczęściej zadawane pytania
Ile trwa audyt bezpieczeństwa?
To zależy od liczby ról i integracji, dlatego zakres i termin ustalamy indywidualnie po wstępnym przejrzeniu aplikacji. Ponowna weryfikacja po naprawach jest zawsze wyraźnie krótsza od pierwszego audytu i wyceniamy ją osobno.
Czy audyt zakłóci pracę systemu produkcyjnego?
Nie, ponieważ pracujemy na środowisku testowym z kopią struktury danych. Jeżeli konieczne jest sprawdzenie czegoś na produkcji, ustalamy wcześniej zakres, termin i sposób wycofania zmian.
Czym to się różni od testów penetracyjnych?
Test penetracyjny sprawdza, czy da się włamać z zewnątrz, przy ograniczonej wiedzy o systemie. Nasz audyt prowadzimy z dostępem do kodu, co pozwala znaleźć również błędy niewidoczne z zewnątrz, na przykład niepoprawną kontrolę uprawnień między kontami.
Co, jeśli znajdziecie coś poważnego?
Zgłaszamy to natychmiast, nie czekając na koniec audytu i publikację raportu. Przy krytycznym znalezisku pomagamy przygotować poprawkę tego samego dnia.
Czy pomagacie wdrożyć poprawki?
Tak. Możemy przekazać raport Twojemu zespołowi i odpowiadać na pytania albo wprowadzić poprawki samodzielnie i przekazać je do zatwierdzenia.
Jak często powtarzać audyt?
Pełny audyt raz w roku wystarcza większości firm, pod warunkiem że pomiędzy nimi działa automatyczne sprawdzanie zależności przy każdej zmianie w kodzie. Termin warto przyspieszyć po większej przebudowie systemu, po dodaniu nowej integracji przetwarzającej dane osobowe albo po zmianie w zespole, która przemeblowała uprawnienia.
Czy dostanę dokument dla kontrahenta lub ubezpieczyciela?
Tak. Poza raportem technicznym przygotowujemy krótkie podsumowanie opisujące zakres przeglądu, zastosowaną metodę i stan po wprowadzeniu poprawek. Jest to dokument, który zwykle wystarcza w rozmowie z klientem korporacyjnym pytającym o bezpieczeństwo przed podpisaniem umowy.
Porozmawiajmy o Twoim projekcie
Opisz nam swój projekt, a wrócimy do Ciebie z wyceną i orientacyjnym terminem. Każdy projekt wyceniamy indywidualnie, bo koszt i czas zależą od zakresu. Wstępna rozmowa jest bezpłatna i do niczego nie zobowiązuje.