fałszywy alarm

Fałszywy alarm (false positive) to sytuacja, w której narzędzie bezpieczeństwa uznaje nieszkodliwą aktywność lub treść za złośliwą. NIST definiuje go jako przypadek, w którym narzędzie bezpieczeństwa błędnie klasyfikuje nieszkodliwą treść jako złośliwą, a w kontekście testów bezpieczeństwa jako alert błędnie wskazujący na obecność podatności ^[1]. Polski słownik NSC 7298 używa nazwy „wynik fałszywie dodatni” i opisuje go jako alarm, który nieprawidłowo wskazuje na występowanie złośliwego działania ^[3]. Przeciwieństwem jest wynik fałszywie ujemny, czyli atak, którego system nie zauważył ^[2].

Jak powstaje

Każdy system wykrywania porównuje obserwowane zdarzenia z jakimś wzorcem: sygnaturą znanego ataku, profilem normalnego ruchu albo regułą. Wytyczne NIST dla systemów IDS i IPS stwierdzają, że żadna z tych technologii nie wykrywa w pełni dokładnie: wszystkie generują zarówno fałszywe alarmy, jak i wyniki fałszywie ujemne ^[2]. Nie da się wyeliminować obu rodzajów błędów naraz; zwykle zmniejszenie jednego zwiększa drugi ^[2].

Źródłem błędu bywa metoda wykrywania. NIST zauważa, że produkty oparte na wykrywaniu anomalii często dają wiele fałszywych alarmów, bo nieszkodliwa aktywność potrafi mocno odbiegać od wyuczonego profilu, zwłaszcza w zmiennych środowiskach ^[2]. Przykładem jest comiesięczny transfer dużych plików, którego system nie widział w okresie uczenia ^[2]. Różnice między podejściami opisuje hasło wykrywanie sygnaturowe i heurystyczne.

Drogę jednego alertu od zdarzenia do decyzji pokazuje schemat poniżej.

RYS. 1Od zdarzenia do werdyktu

Rodzaje wyników

Wynik detekcji opisuje się w dwóch wymiarach: czy system zgłosił alarm i czy zdarzenie było naprawdę złośliwe. Daje to cztery przypadki.

Dla bezpieczeństwa groźniejszy jest wynik fałszywie ujemny, bo atak przechodzi niezauważony. Fałszywe alarmy kosztują jednak czas. NIST pisze, że wiele organizacji świadomie ogranicza wyniki fałszywie ujemne kosztem większej liczby fałszywych alarmów, co wymaga dodatkowych zasobów na odróżnienie ich od prawdziwych zdarzeń ^[2].

Znaczenie ma też to, jak rzadkie jest zjawisko, którego szukamy. Serwis sekurak.pl podał przykład, oparty według autora na własnych badaniach: detektor treści generowanych przez AI o czułości 90% i swoistości 95%, użyty na 10 000 plików, z których 5% jest syntetycznych, da około 450 trafień i około 475 fałszywych alarmów ^[8]. Ponad połowa alarmów będzie więc błędna, choć detektor na papierze wygląda na dokładny.

W WordPressie

Na stronach WordPress fałszywe alarmy pojawiają się głównie w trzech miejscach.

Zapora aplikacyjna. WAF blokuje żądania podobne do ataków, a nietypowa, lecz poprawna wtyczka potrafi wysyłać parametry łudząco podobne do ładunku XSS (Cross-Site Scripting) czy wstrzyknięcia SQL. Dokumentacja reguł OWASP CRS opisuje to wprost: wyższy poziom paranoi utrudnia atakującemu pozostanie niewykrytym, ale kosztem większej liczby fałszywych alarmów ^[4]. Poziom 1 oznacza bazowe bezpieczeństwo przy minimalnej potrzebie strojenia, a ustawienie wysokiego poziomu w trybie blokowania bez strojenia dokumentacja nazywa bardzo ryzykownym ^[4].

Skanery plików. skaner złośliwego oprogramowania (malware scanner) i monitorowanie integralności plików zgłaszają zmienione lub podejrzane pliki. Alert oznacza, że plik różni się od wzorca albo pasuje do sygnatury, a nie że na pewno jest złośliwy. Zanim plik zostanie uznany za webshell, trzeba go porównać z oryginalnym pakietem wtyczki lub motywu w tej samej wersji.

Listy zagrożeń. Strona może trafić na czarną listę przeglądarek. Google w pomocy do raportu problemów z bezpieczeństwem przewiduje osobną ścieżkę dla sytuacji, w której właściciel uważa, że Safe Browsing sklasyfikował stronę błędnie ^[5]. Po usunięciu rzeczywistego problemu przegląd trwa od kilku dni do kilku tygodni ^[5].

Skutki

Pojedynczy fałszywy alarm jest drobnym kosztem. Seria takich alarmów prowadzi do zmęczenia alertami (alert fatigue): zespół przestaje czytać powiadomienia albo wyłącza regułę, która kiedyś wykryłaby prawdziwy atak. W przypadku zapory blokującej fałszywy alarm oznacza też realną szkodę dla użytkownika, na przykład odrzucony formularz zamówienia. Dokumentacja OWASP CRS ostrzega, że źle dostrojony, zbyt agresywny zestaw reguł może skończyć się złym doświadczeniem użytkowników albo całkowitym wyłączeniem ochrony ^[4].

Jak ograniczać

• Strojenie. NIST nazywa zmianę konfiguracji systemu wykrywania w celu poprawy dokładności strojeniem (tuning) i zaznacza, że większość takich systemów wymaga go choć w pewnym zakresie ^[2]. Przykładowe narzędzia to progi, czyli wartości oddzielające zachowanie normalne od nienormalnego ^[2].
• Wyjątki zamiast wyłączania. OWASP CRS zaleca pisanie wykluczeń reguł, które wyłączają regułę całkowicie albo tylko dla wybranych parametrów lub adresów, dzięki czemu reszta zestawu pozostaje nienaruszona ^[4].
• Listy dozwolonych. Znane, nieszkodliwe źródła można wpisać na białą listę (allowlist). CERT Polska opisał, że przy wykrywaniu botnetów z algorytmem generowania domen (DGA) nieszkodliwe źródła szumu, np. przeglądarka Chrome, mogą powodować fałszywe alarmy, więc system potrzebuje mechanizmów filtrujących, takich jak whitelista ^[6].
• Weryfikacja przed eskalacją. Alert przechodzi triaż (triage), zanim uruchomi reagowanie na incydent. W SOC (Security Operations Center) służą temu reguły korelacji w SIEM (Security Information and Event Management) i kontekst z innych źródeł.

Historia i przykłady

Problem jest znany od początku systemów wykrywania włamań. Wytyczne NIST SP 800-94 z lutego 2007 roku omawiają go jako cechę wspólną wszystkich technologii IDPS ^[2]. CERT Polska w 2015 roku wskazywał fałszywe alarmy jako przeszkodę w wykrywaniu botnetów na podstawie odpowiedzi DNS o nieistniejących domenach ^[6].

Ten sam problem dotyczy automatycznego wyszukiwania błędów. W opisie autonomicznego procesu fuzzingu nadzorowanego przez model językowy, opublikowanym w maju 2026 roku, CERT Polska wyjaśnia, że awarie uznane za nieosiągalne są oznaczane w bazie i pomijane w dalszych krokach ^[7]. Bez tego filtra moduły tworzące raporty, priorytety i propozycje poprawek zajmowałyby się usterkami programów testowych zamiast prawdziwymi błędami ^[7].