Cyber Threat Intelligence: praktyczny cykl programu CTI
Cyber Threat Intelligence zamienia dane o zagrożeniach w decyzje. Poznaj wymagania, źródła, analizę, dystrybucję i mierniki skutecznego programu CTI.
- AUTOR
- Karol Rapacz / Pentester (OSCP, PNPT)
- PUBLIKACJA
- 6 lipca 2026
- CZAS CZYTANIA
- 10 min czytania
- TEMAT
- Threat Intelligence
Cyber Threat Intelligence (CTI) to wiedza o zagrożeniach przygotowana pod konkretną decyzję. Lista adresów IP nie jest jeszcze intelligence. Wartość pojawia się wtedy, gdy zespół wie, kogo informacja dotyczy, jakie ma znaczenie i co należy zrobić.
NIST SP 800-150 opisuje bezpieczną wymianę informacji o zagrożeniach. Operacyjnie program CTI warto prowadzić jako powtarzalny cykl: wymagania, zbieranie, przetwarzanie, analiza, dystrybucja i informacja zwrotna.
Zacznij od wymagań
Priority Intelligence Requirements powinny wynikać z profilu firmy. Operator płatności może pytać o grupy atakujące API i tożsamość, producent o szpiegostwo oraz łańcuch dostaw, a szpital o ransomware i przerwy dostępności.
Dobre wymaganie jest ograniczone, ma odbiorcę i horyzont czasu. „Co robią hakerzy?” nie spełnia tych warunków. „Które techniki uzyskania początkowego dostępu obserwujemy u grup atakujących europejskie firmy logistyczne w tym kwartale?” już tak.
Źródła i przetwarzanie
Łącz dane wewnętrzne — alerty EDR, e-mail, IAM, DNS, podatności i incydenty — z raportami CERT, CISA, dostawców oraz społeczności. Oceń wiarygodność źródła oddzielnie od prawdopodobieństwa informacji.
Normalizuj czas, domeny, adresy i identyfikatory. Usuwaj duplikaty oraz oznaczaj datę obserwacji. Stary IOC bez kontekstu może generować koszty, a domena używana przez współdzieloną chmurę może prowadzić do blokady legalnego ruchu.
Analiza: od IOC do zachowania
IOC są nietrwałe. Trwalszą wartość dają techniki i procedury opisane w MITRE ATT&CK. Mapuj hipotezy do telemetrii: jakie zdarzenie potwierdzi użycie techniki, gdzie powinno zostać zarejestrowane i czego dziś nie widzimy.
Wniosek powinien zawierać poziom pewności, dowody, alternatywne wyjaśnienia i ograniczenia. Oddzielaj fakt od oceny analitycznej.
Dystrybucja dla różnych odbiorców
SOC potrzebuje reguł detekcji i priorytetów. Vulnerability Management — listy technologii oraz znanego wykorzystania. Zarząd — scenariuszy biznesowych, trendów i decyzji inwestycyjnych. Jeden raport nie obsłuży wszystkich.
CTI powinno zasilać modelowanie zagrożeń i testy purple team, a wnioski z detekcji powinny wracać do analityków.
Mierniki, które pokazują rezultat
Mierz czas od uzyskania informacji do wdrożenia detekcji, odsetek raportów prowadzących do decyzji, pokrycie kluczowych technik telemetrią oraz trafność ostrzeżeń. Liczba pobranych feedów jest kosztem, nie rezultatem.
Regularnie pytaj odbiorców, czy materiał zmienił priorytet, kontrolę lub reakcję. Wymagania, które nie wspierają żadnej decyzji, należy zamknąć albo przeformułować.
Minimalny cykl CTI
- Ustal odbiorców i wymagania.
- Wybierz źródła adekwatne do pytań.
- Normalizuj, deduplikuj i oceniaj dane.
- Analizuj zachowania, kontekst i alternatywy.
- Dostarczaj materiał w formie użytecznej dla odbiorcy.
- Zbieraj feedback i mierz decyzje.
- Aktualizuj wymagania po zmianie zagrożeń.
Skuteczny CTI nie próbuje wiedzieć wszystkiego. Skraca drogę od wiarygodnego sygnału do lepszej decyzji obronnej.
Od informacji do decyzji
Dobry produkt CTI odpowiada na wcześniej uzgodnione pytanie. Dla SOC może to być lista zachowań do wykrycia; dla zespołu podatności — technologie najczęściej wykorzystywane w danym sektorze; dla zarządu — zmiana ryzyka dla konkretnej usługi. Sam feed IOC szybko traci wartość bez kontekstu czasu, źródła, pewności i obserwowanego zachowania.
Każdą ocenę oznacz poziomem zaufania i oddziel fakt od analitycznego wniosku. Informację zwrotną mierz działaniem: nową regułą, zmianą priorytetu łatki, ćwiczeniem lub decyzją architektoniczną. ATT&CK pomaga opisać zachowanie, lecz mapowanie techniki nie dowodzi atrybucji sprawcy.
Źródło oceniaj pod kątem dostępu do danych, historii poprawności, motywacji i niezależności. Dwa serwisy powtarzające ten sam komunikat nie są dwoma niezależnymi potwierdzeniami. W produkcie zachowuj datę obserwacji i datę publikacji, bo stary IOC może być poprawny historycznie, lecz bezużyteczny do blokowania dzisiaj.
Źródła: NIST SP 800-150, MITRE ATT&CK, CISA — Information Sharing.