Fib.Code
Skan podatności powie Państwu, że coś jest nieaktualne. Test penetracyjny pokaże, co z tego wynika: czy przez tę jedną niezałataną usługę można wyjść do sieci wewnętrznej, sięgnąć po dane kadrowe i wyjść niezauważonym. Różnica jest zasadnicza, a coraz częściej wymagana wprost - ustawa o KSC oczekuje weryfikacji skuteczności środków zarządzania ryzykiem, rozporządzenie DORA wprowadza dla znaczących podmiotów finansowych zaawansowane testy TLPT, a norma ISO/IEC 27001 wymaga zarządzania podatnościami technicznymi i testowania zabezpieczeń. Każdy test prowadzimy wyłącznie na podstawie pisemnego zakresu i zasad prowadzenia działań uzgodnionych przed rozpoczęciem. To nie formalność - to warunek, który odróżnia test bezpieczeństwa od incydentu.
Przed wdrożeniem produkcyjnym nowej aplikacji, systemu lub integracji
Cyklicznie, gdy wymaga tego ustawa o KSC, DORA, ISO 27001 lub umowa z klientem
Po istotnej zmianie architektury, migracji do chmury lub przejęciu spółki
Gdy klient korporacyjny lub ubezpieczyciel żąda dowodu odporności systemów
Po incydencie - żeby sprawdzić, czy naprawiono przyczynę, a nie tylko objaw
Zakres dobieramy do rzeczywistego ryzyka, nie do cennika - czasem wystarczy jedna aplikacja, czasem potrzebna jest pełna symulacja ataku.
Zakres i zasady prowadzenia działań - ustalamy na piśmie, co wchodzi w zakres, czego nie wolno ruszać, w jakich godzinach pracujemy, kto po Państwa stronie jest osobą kontaktową i jak przerywamy test, gdyby coś poszło nie tak. Bez tego dokumentu nie zaczynamy.
Rozpoznanie - zbieramy informacje o powierzchni ataku - z perspektywy napastnika, który nie ma dostępu do Państwa dokumentacji. Ten etap regularnie ujawnia zasoby, o których organizacja zapomniała: stare środowiska testowe, zapomniane subdomeny, usługi wystawione przez pomyłkę.
Testowanie - prowadzimy działania według PTES, NIST SP 800-115 i wytycznych OWASP, łącząc narzędzia automatyczne z pracą ręczną. Automat znajduje znane podatności, człowiek znajduje błędy logiki biznesowej - a to one bywają najkosztowniejsze.
Weryfikacja i eskalacja - każde znalezisko potwierdzamy praktycznie, żeby wykluczyć fałszywe alarmy, i sprawdzamy, jak daleko można zajść. Podatność, przez którą da się przejąć konto administratora domeny, to zupełnie inna sprawa niż ta sama podatność w odizolowanym systemie.
Raport - otrzymują Państwo dwa dokumenty: część wykonawczą dla zarządu - bez żargonu, z oceną ryzyka biznesowego, oraz część techniczną dla zespołu - z krokami odtworzenia, dowodami i konkretną rekomendacją naprawy. Znaleziska mapujemy na CVSS, CWE i macierz MITRE ATT&CK.
Retest - Po wdrożeniu poprawek wracamy i sprawdzamy, czy podatności rzeczywiście zniknęły. Retest podstawowego zakresu jest częścią usługi - raport bez potwierdzenia naprawy to tylko lista problemów, a nie ich rozwiązanie.
Skan to zautomatyzowane porównanie wersji oprogramowania z bazą znanych podatności - wykonuje się w godziny i generuje długą listę, w której sporo pozycji okazuje się fałszywymi alarmami. Test penetracyjny to praca człowieka, który tę listę weryfikuje, łączy pojedyncze słabości w łańcuch ataku i sprawdza, dokąd faktycznie prowadzi. Skan odpowiada na pytanie „co jest nieaktualne”, test - na pytanie „co da się z tym zrobić”. Obie rzeczy są potrzebne, ale tylko druga pokazuje realne ryzyko.
Ryzyko istnieje i nie będziemy go ukrywać - dlatego zarządzamy nim, zamiast udawać, że go nie ma. W zasadach prowadzenia działań ustalamy okno czasowe, listę systemów wyłączonych z testów oraz działania zakazane, na przykład ataki odmowy usługi. Przy środowiskach OT i systemach medycznych stosujemy podejście zachowawcze, często ograniczając się do testów pasywnych albo pracy na środowisku odwzorowującym produkcję. Utrzymujemy stały kontakt z Państwa zespołem i przerywamy działania natychmiast na sygnał.
Pojedyncza aplikacja webowa to zwykle od pięciu do dziesięciu dni roboczych, infrastruktura średniej wielkości - od dziesięciu do piętnastu, pełna operacja red team - od czterech do sześciu tygodni. Raport przekazujemy w ciągu tygodnia od zakończenia testów, a znaleziska krytyczne zgłaszamy natychmiast po potwierdzeniu, bez czekania na koniec prac. Nie ma powodu, by Państwo dowiadywali się o krytycznej podatności dopiero z dokumentu.
Pisemna zgoda właściciela systemów - i to nie jest kwestia uprzejmości, lecz podstawa prawna całego przedsięwzięcia. Jeśli infrastruktura znajduje się u dostawcy chmurowego lub hostingowego, część działań wymaga jego zgody albo zgłoszenia; pomagamy przejść tę procedurę. Ustalamy również zasady postępowania z danymi, na jakie możemy natrafić podczas testu, oraz sposób ich bezpiecznego usunięcia po zakończeniu prac. Wszystko to zapisujemy w umowie i zasadach prowadzenia działań przed rozpoczęciem.
Jest istotnym elementem dowodowym, ale sam w sobie nie wystarcza. Ustawa o KSC oczekuje systemu zarządzania ryzykiem, którego weryfikacja skuteczności - a więc również testowanie - jest jednym ze składników. Norma ISO/IEC 27001 wymaga zarządzania podatnościami technicznymi oraz testowania zabezpieczeń, przy czym audytor pyta nie tylko o raport, lecz także o to, co się z jego ustaleniami stało. Dlatego raport zawsze kończymy planem naprawczym z priorytetami, a przy retestach dokumentujemy zamknięcie znalezisk.