Audyty bezpieczeństwa IT i testy penetracyjne

Nikt nigdy tego nie sprawdził

Aplikacja działa od lat, więc wygląda na bezpieczną. Brak incydentu nie jest dowodem odporności, tylko brakiem informacji.

Klient albo przetarg wymaga raportu

Duży kontrahent pyta o testy bezpieczeństwa i certyfikaty. Bez dokumentu rozmowa się kończy, nawet gdy technicznie jest dobrze.

Skaner wypluł 400 alertów

Połowa to fałszywe alarmy, a wśród reszty nie widać, co jest naprawdę groźne. Bez weryfikacji ręcznej ta lista blokuje pracę zespołu.

Aplikację pisał ktoś, kogo już nie ma

Nie wiadomo, gdzie są klucze, jak działa logowanie i co robi ten jeden endpoint. Audyt kodu odpowiada na te pytania szybciej niż lektura.

Dane osobowe leżą w miejscach, o których nie wiecie

Kopie baz na dyskach, logi z pełnymi danymi, eksporty w arkuszach. Zwykle znajduje się to przy pierwszym przeglądzie, nie przy kontroli.

Testy penetracyjne

Kontrolowana symulacja realnych ataków na aplikację i infrastrukturę, w zakresie ustalonym na piśmie. Sprawdzam nie tylko podatności, ale też skuteczność obrony, która już u Was jest.

Analiza podatności

Systematyczny przegląd systemów pod kątem znanych podatności i błędnych konfiguracji, z ręcznym odsianiem fałszywych alarmów i klasyfikacją według realnego ryzyka.

Audyt kodu źródłowego

Analiza statyczna i dynamiczna kodu: błędy bezpieczeństwa, obsługa danych wrażliwych, zarządzanie sekretami i uprawnieniami. Wychwytuje to, czego test z zewnątrz nie zobaczy.

Audyt zgodności

Ocena zgodności z RODO, ISO 27001, PCI DSS i wewnętrznymi politykami, z listą braków w dokumentacji i procesach oraz przygotowaniem do certyfikacji.

94%

firm doświadczyło incydentu bezpieczeństwa w ciągu ostatnich dwóch lat. Dane branżowe, nie moje, ale zgodne z tym, co widzę w praktyce.

4.35M

euro to średni koszt naruszenia ochrony danych w Unii Europejskiej. Audyt jest tanią pozycją w porównaniu z tą kwotą.

287

dni to średni czas wykrycia naruszenia. Właśnie dlatego pytam o logi i monitoring, a nie tylko o podatności.

ZAKRES I ZGODA

Ustalamy, co jest w zakresie, czego nie ruszam i w jakim okresie testuję. Zgoda jest na piśmie, bo bez niej takie testy są po prostu nielegalne.

ROZPOZNANIE

Inwentaryzacja tego, co faktycznie jest wystawione: usługi, domeny, panele, integracje. Ten etap regularnie znajduje systemy, o których firma zapomniała.

MODELOWANIE ZAGROŻEŃ

Co w tej firmie jest najcenniejsze i jak realnie ktoś by po to poszedł. Bez tego kroku audyt sprawdza wszystko po równo, a to marnuje budżet.

TESTY

Analiza podatności i kontrolowane próby ich wykorzystania, według OWASP i PTES. Wszystko w ustalonym zakresie, z dziennikiem prac.

OCENA WPŁYWU

Każde znalezisko oceniam pod kątem tego, co realnie oznacza dla Waszej firmy, a nie tylko według skali punktowej. To decyduje o kolejności naprawy.

RAPORT

Dwie warstwy: streszczenie dla zarządu i część techniczna z odtworzeniem krok po kroku oraz konkretną rekomendacją naprawy.

OMÓWIENIE

Spotkanie z zespołem, na którym tłumaczę wyniki i odpowiadam na pytania. Raport, którego nikt nie rozumie, nie poprawia bezpieczeństwa.

RETEST

Po Waszych naprawach sprawdzam, czy faktycznie zadziałały. Bez tego kroku nie wiadomo, czy poprawka zamknęła lukę, czy tylko ją przesunęła.

Przegląd startowy

Szybka ocena stanu bezpieczeństwa jednej aplikacji lub jednego środowiska, z listą najpilniejszych rzeczy do naprawy. Dobry pierwszy krok.

Pełny audyt

Testy penetracyjne aplikacji i infrastruktury wraz z audytem kodu, według OWASP i PTES. Zakres najczęściej wybierany przed rozmową z dużym klientem.

Zgodność i opieka

Przygotowanie do certyfikacji oraz stała opieka: cykliczne przeglądy, monitoring podatności i reagowanie, gdy pojawi się nowa.

Czy testy mogą zepsuć nasz system?

Ryzyko istnieje i dlatego się nim zarządza, a nie udaje, że go nie ma. Zakres i okno czasowe ustalamy na piśmie, testy obciążeniowe i próby, które mogą wpłynąć na dostępność, robimy tylko na Wasze wyraźne życzenie, najlepiej na środowisku testowym. Przez cały czas macie kontakt do mnie i możecie przerwać prace jednym telefonem.

Potrzebujecie dostępu do naszego kodu?

Zależy od zakresu. Testy z zewnątrz nie wymagają kodu, ale znajdują mniej, bo widzą tylko to, co widzi atakujący bez wiedzy o środku. Audyt kodu wymaga dostępu do repozytorium, zwykle w formie konta z prawem do odczytu na czas prac. Dane i kod usuwam po zakończeniu, co jest zapisane w umowie.

Czym audyt różni się od skanu podatności?

Skan to narzędzie i jego wynik to lista hipotez, w dużej części fałszywych. Audyt to praca człowieka: sprawdzam, czy podatność da się wykorzystać, jaki miałaby realny skutek w Waszej firmie i co konkretnie zrobić, żeby ją zamknąć. Dostajecie listę, którą można wykonać, a nie 400 alertów do przejrzenia.

Co dostajemy na koniec?

Raport w dwóch warstwach: streszczenie dla zarządu, zrozumiałe bez wiedzy technicznej, i część techniczną z odtworzeniem każdej podatności krok po kroku oraz konkretną rekomendacją. Do tego spotkanie z omówieniem i retest po naprawach. Taki raport przechodzi też w rozmowach z dużym klientem, który pyta o testy bezpieczeństwa.

Naprawiacie też znalezione błędy?

Mogę i często tak się dzieje, ale mówię wprost, że audyt i naprawa u jednego wykonawcy to konflikt interesów, bo audytor ocenia własną pracę. Uczciwe rozwiązanie: naprawy robi Wasz zespół albo osobny wykonawca, a ja weryfikuję skuteczność w retestcie. Jeśli zespołu nie macie, wykonuję naprawy, a retest zleca się komuś innemu.

Jak często powtarzać audyt?

Raz w roku dla systemu, który zmienia się umiarkowanie, oraz po każdej większej zmianie: nowy moduł płatności, nowa integracja, migracja na inną infrastrukturę. Przy aplikacji rozwijanej co tydzień lepiej działa stała opieka z krótkimi przeglądami niż jeden duży audyt raz na dwa lata, bo połowa kodu w tym czasie jest już inna.

Testujecie tylko po zgodzie właściciela?

Tak i nie ma tu wyjątków. Testy bezpieczeństwa bez pisemnej zgody właściciela systemu są przestępstwem, niezależnie od dobrych intencji. Jeśli aplikacja stoi u zewnętrznego dostawcy albo w chmurze, potrzebna jest zgoda także po jego stronie, o czym pamiętam w harmonogramie, bo czasem trwa to dłużej niż same testy.

DevOps i infrastruktura

Naprawa tego, co audyt znalazł w konfiguracji, wdrożeniach i monitoringu.

Bezpieczny dostęp VPN

Panele i systemy schowane za jednym, kontrolowanym wejściem.

Szkolenia dla zespołu

Warsztat z bezpiecznego kodowania i rozpoznawania ataków na ludzi.

Audyty bezpieczeństwa IT i testy penetracyjne | Mateusz Ulewicz

SPRAWDZAM TO,

Testy penetracyjne, analiza podatności i audyt kodu według OWASP oraz PTES, zawsze w zakresie ustalonym na piśmie. Zamiast surowego raportu ze skanera dostajecie listę rzeczy do naprawy w kolejności ryzyka i retest po poprawkach.

SZEŚĆ POWODÓW,

Prawie nikt nie zamawia audytu z ciekawości. Zwykle jest konkretny powód: wymóg klienta, zmiana w zespole albo poczucie, że nikt tego nigdy nie sprawdził.

Zakres

Można je łączyć i zwykle tak się robi. Testy z zewnątrz pokazują, co widzi atakujący, a audyt kodu to, czego z zewnątrz nie widać.

Liczby

Poniższe dane pochodzą z badań branżowych, nie z moich projektów. Podaję je, bo dobrze pokazują proporcję między kosztem audytu a kosztem incydentu.

W standardzie

Pierwsze dwa punkty są nienegocjowalne. Testy bez pisemnej zgody i bez ustalonego okna czasowego nie są usługą, tylko przestępstwem.

Warianty

Wycena zależy od liczby systemów i tego, czy potrzebny jest dostęp do kodu. Zakres ustalamy na krótkiej rozmowie, przed jakąkolwiek pracą.

Metodyki i narzędzia

Narzędzia są tylko narzędziami. Wartość audytu bierze się z tego, co człowiek zrobi z ich wynikiem, dlatego każde znalezisko przechodzi weryfikację ręczną.

NAPISZ, CO MA BYĆ

Wystarczy adres aplikacji albo krótki opis systemu i informacja, czy audyt jest potrzebny na czyjeś wymaganie. Odpowiem, jaki zakres ma sens, ile to potrwa i czego będę potrzebował od Waszej strony.