triaż
| Po angielsku | triage |
|---|---|
| Którą formą pisać | obie formy Obie formy są w obiegu. Przy pierwszym wystąpieniu pisz „polski termin (english term)”, dalej sam polski. |
| Inne formy | wstępna ocena alertów · klasyfikacja i priorytetyzacja alertów (ujęcie ustawowe) |
| Kategoria | SOC, wywiad o zagrożeniach i reagowanie |
Triaż (triage) to wstępna ocena napływających alertów i zgłoszeń, która rozstrzyga, czy doszło do incydentu, jak jest poważny i jak pilnie trzeba na niego odpowiedzieć. NIST opisuje ten krok jako wstępny przegląd nowego zgłoszenia w celu potwierdzenia, że incydent wystąpił, a następnie oszacowanie jego wagi i potrzebnej pilności reakcji [1]. FIRST w ramach usług zespołów CSIRT określa cel triażu jako skategoryzowanie, nadanie priorytetu i wstępną ocenę incydentu [3].
Jak działa
Triaż jest pierwszym etapem reagowania na incydenty po wykryciu. Na wejściu są alerty z systemów wykrywania, zgłoszenia użytkowników i informacje od osób trzecich. NIST zaleca, by organizacja miała kanały do przyjmowania zgłoszeń z zewnątrz i traktowała je poważnie [1]. Na wyjściu każdy sygnał ma jedną z decyzji: zamknięty jako fałszywy alarm (false positive), przekazany dalej z priorytetem albo odłożony do obserwacji.
FIRST opisuje ten etap w usłudze analizy zdarzeń. Potencjalne incydenty trzeba poddać triażowi i każdy zakwalifikować jako incydent (true positive) albo fałszywy alarm [3]. Rejestrowanie tych kwalifikacji pozwala wskazać reguły wykrywania, źródła danych albo procesy o słabej jakości [3].
Typowy przebieg w SOC (Security Operations Center) pokazuje schemat poniżej.
W polskich opisach struktury SOC triaż jest zadaniem pierwszej linii. Przykładowo rola „SOC L1 (Analityk dyżurny)” obejmuje obsługę alertów, eskalację i „pierwszy triage” [6]. Szybkość tej pracy zależy od jakości samego alertu. Kapitan Hack zwraca uwagę, że jeśli do oceny, czy działanie jest złośliwe, potrzebne są jakieś dane, alert musi je zawierać albo wskazywać, gdzie je znaleźć [5]. Dobry alert zawiera kontekst zagrożenia, techniki MITRE ATT&CK, dane wzbogacające i odwołanie do playbooka [5].
Kryteria priorytetu
NIST podkreśla, że z powodu ograniczonych zasobów incydentów nie należy obsługiwać w kolejności zgłoszeń [1]. Triaż, priorytety i eskalacja powinny opierać się na zestawie czynników oceny ryzyka [1]. Jako przykłady podaje krytyczność zasobu, wpływ funkcjonalny, wpływ na dane, etap obserwowanej aktywności, charakterystykę sprawcy i możliwość odtworzenia [1].
Wcześniejsza wersja przewodnika proponowała skalę wpływu funkcjonalnego, którą nadal często się stosuje.
| Kategoria | Wpływ na organizację |
|---|---|
| brak | może świadczyć wszystkie usługi wszystkim użytkownikom [2] |
| niski | świadczy wszystkie kluczowe usługi, ale mniej wydajnie [2] |
| średni | utraciła kluczową usługę dla części użytkowników [2] |
| wysoki | nie może świadczyć części kluczowych usług nikomu [2] |
Ten sam dokument osobno ocenia wpływ na informacje. Jedną z kategorii jest dostęp do danych osobowych albo ich wyprowadzenie [2]. Taki wynik triażu powinien uruchomić ocenę, czy doszło do naruszenia ochrony danych osobowych.
W polskim prawie słowo „triaż” nie pada. Ustawa o krajowym systemie cyberbezpieczeństwa definiuje jednak obsługę incydentu jako czynności umożliwiające wykrywanie, rejestrowanie, analizowanie, klasyfikowanie, priorytetyzację, podejmowanie działań naprawczych i ograniczenie skutków incydentu [4]. Klasyfikowanie i priorytetyzacja to właśnie treść triażu.
Odmiany
Słowo „triaż” opisuje tę samą czynność w kilku miejscach procesu bezpieczeństwa.
- Triaż alertów w SOC: oddzielenie prawdziwych incydentów od fałszywych alarmów, zwykle na podstawie danych z SIEM (Security Information and Event Management).
- Triaż incydentów w zespole CSIRT: kategoryzacja według typu, na przykład wyciek danych, ransomware, przejęcie konta, odmowa usługi, i nadanie kolejności [1].
- Triaż zgłoszeń podatności: ocena, czy zgłoszony błąd jest prawdziwy i jak groźny, typowa dla skoordynowanego ujawniania podatności (coordinated vulnerability disclosure).
- Triaż awarii w testach automatycznych. CERT Polska opisuje system fuzzingu, który w fazie podstawowego triażu normalizuje ślad błędu, sprawdza duplikaty i grupuje awarie o tej samej przyczynie [7].
W WordPressie
Właściciel strony WordPress rzadko ma własny SOC, ale triaż wykonuje za każdym razem, gdy dostaje powiadomienie. Wtyczka bezpieczeństwa wysyła informacje o zablokowanych logowaniach, zmienionych plikach i nowych wersjach z łatkami. Większość z nich to szum. Seria zablokowanych prób przy działającym limicie prób logowania zwykle nie wymaga działania. Zmiana pliku rdzenia wykryta przez monitorowanie integralności plików poza oknem aktualizacji wymaga pilnej analizy, bo może być wskaźnikiem kompromitacji (IoC).
Triaż zgłoszeń dotyczy też samego ekosystemu. WordPress prosi, by podatności rdzenia zgłaszać poufnie zespołowi bezpieczeństwa, a podatności wtyczek autorowi i zespołowi wtyczek [8]. Zespół bezpieczeństwa WordPressa liczy ponad 50 zaufanych ekspertów [8]. Każde takie zgłoszenie, na przykład o podatności we wtyczce, przechodzi ocenę prawdziwości i wagi, zanim powstanie łatka.
Jak robić to dobrze
- Spisać kryteria priorytetu z góry, zamiast ustalać je przy każdym alercie [1].
- Dołączać do alertów kontekst i przykłady prawdziwych oraz fałszywych trafień [5].
- Rejestrować decyzje triażu i na ich podstawie poprawiać reguły wykrywania [3].
- Ograniczać liczbę alertów o niskiej wartości. Nadmiar prowadzi do zmęczenia alertami (alert fatigue) i przeoczeń.
- Po triażu przekazać incydent do opanowania incydentu według ustalonej ścieżki eskalacji [1].
Historia i przykłady
Druga wersja przewodnika NIST SP 800-61 ukazała się w sierpniu 2012 roku [2]. Nazywała ustalanie priorytetów obsługi incydentu być może najważniejszym punktem decyzyjnym całego procesu [2]. 3 kwietnia 2025 roku NIST wycofał tę wersję i w całości zastąpił ją rewizją 3, zbudowaną jako profil ram CSF 2.0 [2]. W rewizji 3 triaż ma własny element: „Incident reports are triaged and validated” (RS.MA-02), a kategoryzacja i priorytetyzacja – element RS.MA-03 [1].
Przypisy
8- [1] NIST SP 800-61r3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management · NIST
- [2] NIST SP 800-61r2: Computer Security Incident Handling Guide (wycofana) · NIST
- [3] CSIRT Services Framework v2.1 · FIRST
- [4] Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. 2018 poz. 1560) · Dziennik Ustaw
- [5] Jak powinien być skonstruowany poprawny alert bezpieczeństwa? · Kapitan Hack
- [6] Mapowanie NIS2 w praktyce: jak Wazuh i Zabbix pokrywają wymagania art. 21 · Sekurak
- [7] Autonomiczny proces fuzzingu pod nadzorem LLM · CERT Polska
- [8] Security · WordPress.org
Hasła w tym artykule
17- reagowanie na incydenty
- fałszywy alarm
- SOC (Security Operations Center)
- MITRE ATT&CK
- playbook
- naruszenie ochrony danych osobowych
- SIEM (Security Information and Event Management)
- CSIRT
- ransomware
- skoordynowane ujawnianie podatności
- wtyczka bezpieczeństwa
- limit prób logowania
- monitorowanie integralności plików
- wskaźnik kompromitacji (IoC)
- podatność we wtyczce
- zmęczenie alertami
- opanowanie incydentu