EASM — jak zarządzać zewnętrzną powierzchnią ataku
External Attack Surface Management wykrywa nieznane domeny, IP, chmurę i usługi. Budujemy proces discovery, ownership i usuwania ryzyka.
- AUTOR
- Karol Rapacz / Pentester (OSCP, PNPT)
- PUBLIKACJA
- 7 lipca 2026
- CZAS CZYTANIA
- 10 min czytania
- TEMAT
- Zarządzanie ryzykiem
External Attack Surface Management (EASM) to ciągłe wykrywanie i kontrola zasobów, które atakujący widzi z internetu. Obejmuje domeny, subdomeny, adresy IP, certyfikaty, chmurę, aplikacje, API i przejęte lub zapomniane usługi.
Skan jednego znanego zakresu nie wystarczy. Najgroźniejszy bywa system, którego nie ma w CMDB: stary panel dostawcy, testowa subdomena, storage po migracji albo serwer utworzony kartą firmową.
Discovery zaczyna się od wielu nasion
Zbieraj oficjalne domeny, ASN, zakresy IP, organizacje chmurowe, certyfikaty, rekordy DNS, repozytoria i nazwy marek. Następnie rozwijaj relacje: SAN w certyfikacie, wspólny nameserver, historyczny DNS, podobny favicon i identyfikatory analityczne.
Automatyczne powiązanie jest hipotezą, nie dowodem własności. Hosting współdzielony i dostawcy SaaS tworzą false positives. Zasób musi zostać potwierdzony przez właściciela technicznego lub dane organizacyjne.
Inventory potrzebuje ownera i cyklu życia
Dla każdego aktywa zapisuj:
- właściciela biznesowego i technicznego;
- środowisko oraz krytyczność;
- dane i funkcję;
- dostawcę oraz umowę;
- publiczne protokoły i technologie;
- datę ostatniego potwierdzenia;
- plan utrzymania albo wyłączenia.
Status „nieznany” jest wynikiem wymagającym obsługi, nie miejscem do wiecznego przechowywania rekordu.
Co priorytetyzować
Nie każda otwarta usługa jest podatnością. Najwyższy priorytet mają:
- panele administracyjne i zdalny dostęp;
- aktywnie wykorzystywane CVE;
- domyślne lub wygasłe poświadczenia;
- przejęcie subdomeny i osierocone rekordy DNS;
- publiczny storage z danymi;
- API bez właściciela i uwierzytelnienia;
- niewspierane oprogramowanie;
- wyciek sekretów oraz repozytoriów.
Połącz ekspozycję z kontekstem znanym z zarządzania podatnościami: exploitability, wartość zasobu, kontrolki i konsekwencje.
EASM to proces zamykania, nie dashboard
Każde znalezisko musi trafić do właściciela, mieć termin i ślad weryfikacji. Naprawą może być aktualizacja, ograniczenie sieci, przejęcie DNS, migracja, formalne zaakceptowanie albo całkowite usunięcie usługi.
Po zamknięciu wykonaj ponowny pomiar z zewnątrz. Ticket „wykonano” nie dowodzi, że port, domena lub bucket przestały być dostępne.
Integracja ze zmianami
Najlepszy EASM nie tylko skanuje cyklicznie. Otrzymuje zdarzenia z rejestracji domen, cloud organization, CI/CD i CMDB. Alarmuje, gdy pojawia się nowy certyfikat, publiczny endpoint albo zmiana dostawcy DNS.
Zdefiniuj procedurę szybkiego wyłączenia zasobu bez właściciela, ale uwzględnij ryzyko przerwania legalnej usługi. Dowody własności i kontakt awaryjny są obowiązkowe.
Checklista wdrożenia EASM
- Zdefiniuj organizacyjne nasiona i marki.
- Odkrywaj domeny, IP, certyfikaty, chmurę i SaaS.
- Potwierdzaj własność i usuwaj false positives.
- Przypisuj ownera, krytyczność i cykl życia.
- Priorytetyzuj ryzyko, nie samą liczbę portów.
- Integruj ticketing, CMDB i vulnerability management.
- Weryfikuj naprawę z internetu.
- Mierz czas od pojawienia się zasobu do identyfikacji i kontroli.
EASM uzupełnia OSINT organizacji, ale jego rezultatem ma być mniejsza powierzchnia ataku, nie większa lista aktywów.
Walidacja odkrytego zasobu
Wynik skanera jest hipotezą, dopóki nie potwierdzisz własności. Łącz DNS, certyfikaty, dane chmurowe, repozytoria i CMDB, a przy niepewności kontaktuj właściciela domeny lub usługi. Nie wykonuj inwazyjnego testu zasobu, którego zakres i zgoda nie są jasne. Rekord powinien zawierać właściciela biznesowego, środowisko, dane, dostawcę oraz datę ostatniej weryfikacji.
Najważniejszą metryką nie jest liczba znalezionych hostów, lecz czas od ekspozycji do przypisania i zamknięcia ryzyka. Monitoruj nowe subdomeny, certyfikaty, porty administracyjne, przejęte rekordy DNS i wygasłe usługi. Zamknięcie zgłoszenia potwierdź z perspektywy Internetu, bo zmiana w panelu chmurowym nie zawsze usuwa publiczną ścieżkę.
Proces usuwania musi rozróżniać zasób potrzebny, nieznany i porzucony. Nie wyłączaj automatycznie systemu tylko dlatego, że nie występuje w CMDB; może obsługiwać klienta lub integrację dostawcy. Najpierw ogranicz ekspozycję, zachowaj dowody i eskaluj do właściciela domeny, konta chmurowego lub centrum kosztowego.
Źródła: NIST CSF 2.0, CISA CDM, NIST SP 800-53 Rev. 5.
