Strukturalny przepływ pracy na rzecz przekształcania wywiadu o cyberzagrożeniach w obliczalne wzorce wykrywania

Podsumowanie

Przedstawiamy protokół konwertujący wskaźniki kompromitacyjne z raportów wywiadu cyberzagrożeń, takich jak ścieżki plików, klucze rejestru i wskaźniki wiersza poleceń, na zweryfikowane wyrażenia regularne dla zasad wykrywania w systemach SIEM (Security Information and Event Management), z wykorzystaniem ekstrakcji zespołowej z dużymi modelami językowymi (LLMs) i etykietowaniem składników przy użyciu grafów.

Streszczenie

Centrum Operacji Bezpieczeństwa (SOC) rutynowo przekształca raporty dotyczące wywiadu o cyberzagrożeniach (CTI) w operacyjną zawartość wykrywania. Trwałym wąskim gardłem w tym przepływie pracy jest przekładanie wyodrębnionych wskaźników kompromitacyjnych (IOC), szczególnie ścieżek plików, kluczy rejestru i ciągów wiersza poleceń, w wdrażalne wyrażenia regularne (regex), nadające się do osadzania w zasadach korelacji zarządzania informacjami i wydarzeniami bezpieczeństwa (SIEM). Chociaż poprzednie prace poprawiły automatyczne wyodrębnianie wskaźników kompromitacyjnych (IOC), przekształcanie wyodrębnionych ciągów w zweryfikowane wzorce regex nadal jest w dużej mierze ręczne, wymaga specjalistycznej wiedzy i jest podatne na błędy. Celem tego protokołu jest zapewnienie standaryzowanej, powtarzalnej procedury przekładu IOC na regex. Przepływ pracy składa się z pięciu etapów: (1) analizowanie heterogenicznych raportów CTI w ujednoliconą reprezentację Markdown; (2) wyodrębnianie IOC za pomocą wielu dużych modeli językowych (LLM) z głosowaniem konsensusowym; (3) normalizacja, kategoryzacja i deduplikacja wyodrębnionych IOC na zasadach reguł; (4) etykietowanie komponentów IOC jako do zachowania (capture-group) lub do wyrzucenia (non-capture-group) przy użyciu grafu; oraz (5) iteracyjne generowanie regex z diagnostyczną weryfikacją wobec oryginalnych ciągów IOC. Aby ocenić użyteczność, przepływ pracy zastosowano do 3156 raportów CTI, a wynikowe regexy oceniono na podstawie ponad 2400 niezależnie zebranych ciągów rzeczywistych z dziesięciu scenariuszy oceny MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK), dając średnią wartość trafień 99,1% i średnią wartość niedopasowania między IOC na poziomie 0,8%. Protokół dokumentuje zatem powtarzalną implementację przekładu IOC na regex i wyraźnie określa jego obecny zakres, założenia operacyjne i znane przypadki awarii.

Wprowadzenie

Cyberprzestępczość nadal nakłada znaczne obciążenia operacyjne i finansowe na organizacje w sektorach publicznym i prywatnym. W 2023 roku zgłoszone straty z powodu cyberprzestępczości w Stanach Zjednoczonych przekroczyły 12,5 miliarda dolarów¹, podkreślając skalę i uporczywość złośliwej działalności. W tym kontekście, Centra Operacji Bezpieczeństwa (SOC) służą jako główne jednostki operacyjne odpowiedzialne za wykrywanie, analizę i reagowanie na zagrożenia w czasie rzeczywistym.
Logika wykrywania w wielu procesach SOC jest wdrażana poprzez mechanizmy oparte na regułach w platformach zarządzania informacjami i zdarzeniami bezpieczeństwa (SIEM), które są szeroko stosowane, ponieważ są interpretowalne, deterministyczne i kompatybilne z istniejącymi procesami SOC. Wśród różnych typów reguł, reguły SIEM oparte na korelację są szczególnie ważne dla identyfikacji zachowań ataku, które obejmują wiele zdarzeń, hostów i okien czasowych. W ramach tych reguł, wyrażenia regularne (regex) funkcjonują jako wielokrotnie używalny pierwotny element wyszukiwania: analitycy osadzają je w szerszych regułach wykrywania, które dodają ograniczenia pól, filtry specyficzne dla platformy i logikę korelację zdarzeń, zamiast wdrażać je jako samodzielne detektory.

W praktyce, analitycy SOC często rozpoczynają opracowywanie reguł od wskaźników kompromitacyjnych (IOC) pochodzących z raportów inteligencji cyberzagrożeń (CTI) publikowanych przez dostawców zabezpieczeń, niezależnych badaczy lub publiczne bazy wiedzy, takie jak MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK)². Te ciągi IOC mogą zawierać ścieżki plików, fragmenty wiersza poleceń, klucze rejestru lub inne strukturalne artefakty obserwowane podczas ataków³. Przekładanie takich ciągów na wzorce regex odpowiednie dla reguł korelację SIEM jest powtarzającym się zadaniem w procesie autorstwa reguł.

Ten krok translacji jest praktycznym operacyjnym węzłem szyjkowym. Opracowywanie wzorców regex, które są ogólne, aby uchwycić znaczącą wariację, ale precyzyjne, aby uniknąć niezamierzonych dopasowań, wymaga specjalistycznej ekspertyzy; małe błędy składniowe lub niewłaściwe decyzje dotyczące komponentów do zachowania lub uogólnienia mogą uniemożliwić wdrożenie użytecznej reguły wykrywania. Ponieważ ta praca jest manualna, powtarzalna i szczegółowa, może opóźnić wdrażanie wykrywania nowych zagrożeń, wymagać przeglądu przez bardziej doświadczonych analityków i przyczyniać się do obciążenia analityków w operacyjnych ustawieniach SOC^4,5.

Centralnym wyzwaniem w translacji IOC na regex jest decyzja, które części IOC kodują stabilne, istotne dla atakującego zachowanie i powinny zatem zostać zachowane, a które odzwierciedlają wariację specyficzną dla środowiska lub hosta i powinny zostać uogólnione. Na przykład kanoniczne korzenie rejestru takie jak HKEY_CLASSES_ROOT\CLSID, katalogi systemowe takie jak System32 i znane nazwy wykonywalne takie jak rundll32.exe zazwyczaj muszą pozostać wyraźne, podczas gdy ścieżki profili użytkowników, host-specyficzne identyfikatory zabezpieczeń (SIDs) i globalne unikalne identyfikatory (GUIDs) powinny być zwykle abstrahowane. Robienie tego spójnie na różnorodne typy IOC sprawia, że zadanie translacji nie jest trywialne. W całym tym protokole odnosimy się do pierwszego jako składników zachowanych lub grup chwytających, a drugiego jako abstrakcyjnych lub nieskładników chwytających.

Poprzednie prace badały zautomatyzowane wyodrębnianie inteligencji zagrożeń z nieustrukturyzowanego tekstu przy użyciu przetwarzania języka naturalnego i technik ekstrakcji encji^6,7. Bardziej niedawno kilka badań zbadano bezpośrednie generowanie reguł wykrywania z raportów CTI za pomocą dużych modeli językowych (LLM)⁸. Te podejścia pokazują, że część procesu autorstwa reguł może być wspomagana przez modele językowe, ale zwykle nie koncentrują się na konkretnym problemie operacyjnym generowania wzorców regex, które zachowują semantyki grup chwytających i pozostają odpowiednie do późniejszego wdrożenia SIEM. Uzupełniające kierunki pracy strukturyzowały zawartość CTI dla dalszego użytku na różne sposoby, w tym reprezentacje oparte na grafie wiedzy, takie jak TINKER⁹ oraz generowanie kwerend szukania logów napędzanych przez CTI, takich jak ThreatRaptor¹⁰, które konwertują nieustrukturyzowaną CTI na zstrukturyzowaną wiedzę lub języki zapytań specyficznych dla domeny, a nie na wzorce regex przeznaczone do osadzania w regułach korelację SIEM.

Równolegle, wcześniejsze badania eksplorowały zautomatyzowane syntezę regex przy użyciu metod opartych na przykładach, tłumaczenia neuronowego i podejść generują-i-napraw^{11,12,13,14,15,16}. Jednak te metody są ogólnie zaprojektowane dla ustawień, które polegają na dużych zestawach reprezentatywnych przykład

Protokół

Use the following five-stage workflow to transform a CTI report into validated regex patterns with traceable intermediate outputs (see Rysunek 1 for an overview).

1. System setup

1. Install prerequisites.
   1. Install Python 3.8 lub nowsze, wszystkie zależności Pythona wymienione w requirements.txt oraz bazę danych grafową Neo4j.
      1. Potwierdź dostęp do jednego lub więcej interfejsów programowania aplikacji (API) dla wybranych dużych modeli językowych i sprawdź, czy usługa Neo4j działa i jest dostępna z lokalnego komputera.
   2. Potwierdź, że tabela materiałów jest kompletna.
      1. Upewnij się, że wymienione są zależności uruchomieniowe, w tym wersja interpretera Pythona, zależności potoku, wersja Neo4j i tył wyodrębniania tekstu z formatu Portable Document Format (PDF).
      2. Upewnij się, że wymienione są opcje konfiguracji LLM, w tym dostawców LLM, nazwy i wersje modeli, temperaturę, opcje wysiłku rozumowania i ustawienia głosowania zespołowego.
      3. Upewnij się, że wymienione są formaty wejściowe i wyjściowe, w tym obsługiwane formaty plików wejściowych i obsługiwane formaty eksportu.
2. Uruchom interfejs użytkownika sieci web (UI).
   1. Otwórz terminal, przejdź do głównego katalogu referencyjnej implementacji i uruchom aplikację za pomocą udokumentowanego polecenia uruchamiającego (w referencyjnej implementacji: cd langchain_pipeline po którym następuje streamlit run app_v2.py).
   2. Upewnij się, że aplikacja ładuje się pod adresem http://localhost:8501 i że panel konfiguracji bocznego paska jest widoczny.
3. Skonfiguruj dostawcę LLM.
   1. W sekcji Konfiguracja LLM bocznego paska wybierz dostawcę LLM, wprowadź nazwę modelu i podaj prawidłowy klucz interfejsu programowania aplikacji (API).
   2. Zapisz dostawcę, nazwę modelu, wersję modelu, temperaturę, opcje wysiłku rozumowania oraz datę dostępu dla tabeli materiałów.
      ​UWAGA. W referencyjnej implementacji, pojedyncze wyodrębnianie IOC domyślnie dotyczy głównego komercyjnego LLM wymienionego w tabeli materiałów z temperaturą = 0,0; generowanie regex domyślnie ma temperaturę = 0,3.
4. Włącz głosowanie zespołowe (opcjonalnie, ale zalecane dla wyników powtarzalnych).
   1. Włącz opcję Głosowanie zespołowe w bocznym pasku, aby zatrzymać tylko IOC, które spełniają minimalny próg głosowania (Min Votes ≥ 2 zalecane).
   2. Dodaj dodatkowe wystąpienia LLM, określając dostawcę, nazwę modelu, klucz API i liczbę powtórzeń wykonania na model.
      1. Zapisz liczbę powtórzeń każdego dostawcy i wybrany próg minimalnego głosu.
         UWAGA. Głosowanie zespołowe jest opcjonalne. Gdy jest wyłączone, potok wykonuje pojedyncze wyodrębnianie LLM, a filtr konsensusu jest pomijany. Domyślne ustawienia zespołowe to powtórzenia = 1 na skonfigurowany model i min_votes = 2.
5. Połącz się z Neo4j.
   1. W sekcji Połączenie Neo4j bocznego paska wprowadź identyfikator URI połączenia (na przykład bolt://localhost:7687), nazwę użytkownika i hasło.
   2. Potwierdź, że interfejs zgłasza pomyślne połączenie. Nie należy kontynuować bez aktywnego połączenia.
6. Zabezpiecz wszystkie poświadczenia.
   1. Traktuj klucze API LLM i hasło Neo4j jako poufne poświadczenia. Przechowuj je w zmiennych środowiskowych lub menedżerze wpisów tajnych, a nie w plikach źródłowych, eksportowanych raportach lub zrzutach ekranu, i szybko zmień dowolny klucz, jeśli podejrzewasz wyciek.
      UWAGA. Ten protokół oprogramowania nie wymaga kaptura chemicznego, szafy biobezpieczeństwa ani innego sprzętu do izolacji; traktuj poufne raporty CTI i poświadczenia zgodnie z instytucjonalnymi zasadami bezpieczeństwa danych.

2. Etap 1: parsowanie dokumentu

1. Procedura.
   1. Przejdź do zakładki Przetwarzanie w głównym interfejsie.
   2. Przekaż raport CTI w obsługiwanym formacie (.pdf,.docx,.md,.txt lub.html).
   3. Kliknij „Uruchom następny etap”, aby wykonać Etap 1, lub „Uruchom wszystkie etapy”, aby wykonać pełny potok sekwencyjnie.
2. Potwierdź punkt kontrolny Etap 1.
   1. Potwierdź, że podgląd Markdown dokumentu wejściowego jest wyświetlany.
   2. Sprawdź, czy ścieżki plików, klucze rejestru, fragmenty wiersza poleceń i granice sekcji pozostają nietknięte w podglądzie.
   3. Jeśli ciągi techniczne są obcięte lub formatowanie jest usuwane, popraw plik źródłowy lub przetworz dokument z zewnętrznym konwerterem przed ponownym przekazaniem.

3. Etap 2: wyodrębnianie IOC

1. Procedura.
   1. Potwierdź konfigurację LLM (oraz głosowanie

Wyniki

Niniejsza sekcja przedstawia reprezentatywne wyniki uzyskane dzięki protokołowi IOC-to-regex oraz podsumowuje ewaluację referencyjną służącą do oceny jego przydatności operacyjnej. W ramach ewaluacji referencyjnej przetworzono 3 156 raportów CTI powiązanych z technikami MITRE ATT&CK, przeanalizowano ponad 230 000 zdań, wyekstrahowano ponad 63 000 kandydatów na IOC oraz oceniono wygenerowane wyrażenia regularne (regex) w zestawieniu z ponad 2 400 niezależnie zebranymi ciągami znaków prawdy obiektywnej (ground-truth) z...

Dyskusja

Przekształcanie niezstrukturyzowanych raportów CTI w wykonywalną logikę wykrywania pozostaje czasochłonną i podatną na błędy czynnością w procesach bezpieczeństwa operacyjnego. Podczas gdy wcześniejsze wysiłki koncentrowały się na automatyzacji na poziomie ekstrakcji IOC lub generowania reguł na wysokim poziomie, praktycy nadal stoją wobec znacznych wyzwań w konwertowaniu wyciągniętych ciągów IOC na wyrażenia regularne, które są strukturalnie poprawne, semantycznie precyzyjne i nadające się do dalszego użytku w SIEM. Prz...

Materiały

Lista materiałów użytych w tym artykule

Nazwa	Firma	Numer katalogowy	Komentarze
Komputer (CPU)	—	≥ 4 rdzenie zalecane	Brak GPU
LangChain	LangChain	≥ 0.1.x	Framework orkiestracji LLM
LLM (ekstrakcja IOC, pojedynczy model)	OpenAI	gpt-5.1	Używane do ekstrakcji IOC (Etap 2), gdy głosowanie zespołowe jest wyłączone. temperatura = 0.0; max_workers = 5. Dostęp: 2025-12-15.
LLM (Generacja regex)	OpenAI	gpt-5.1	Używane do generowania regex (Etap 5). temperatura = 0.3 przed walidacją w dół. Dostęp: 2025-12-15.
LLM (Charakterystyka skalowalności)	OpenAI	gpt-5.1	Używane do 6 000-IOC uruchomienia skalowalności zgłoszonego w Reprezentatywnych Wynikach. Dostęp: 2025-12-15.
Pamięć (RAM)	—	≥ 16 GB zalecane	Wymagane do przetwarzania dokumentów
Neo4j	Neo4j, Inc.	≥ 5.x	Baza danych grafowych do normalizacji IOC
Neo4j Python Driver	Neo4j, Inc.	≥ 5.x	Interfejs Python do Neo4j
System operacyjny	Microsoft / Apple / Linux	Windows, macOS lub Linux	Obsługa wieloplatformowa
Analizowanie PDF — podstawowe środowisko	Microsoft	MarkItDown ≥ 0.0.x	Backend Etap 1; konwertuje PDF/DOCX/HTML/TXT wejścia na Markdown. Analityczny wynik pogrupowano na 4 000 znaków przed przetwarzaniem LLM. Dostęp: 2025-12-15. https://github.com/microsoft/markitdown
Konfiguracja potoku (Etap 2 — ekstrakcja IOC)	—	Domyślne referencyjne	Tryb pojedynczego LLM: temperatura = 0.0, max_workers = 5. Wartości domyślne trybu głosowania zespołowego: powtórzenia = 1 na skonfigurowany model, min_votes = 2.
Konfiguracja potoku (Etap 5 — generacja regex)	—	Domyślne referencyjne	Temperatura generowania = 0.3. Walidacja: overgen_random_tests = 5 losowych negatywnych próbek na IOC. Granice iteracji: max_iterations = 10, debug_loop_cap = 5, discard_validation_cap = 5.
Python	Python Software Foundation	≥ 3.8	Wymagane środowisko uruchomieniowe
Silnik regex	Python Standard Library	moduł re	Używane do walidacji i testowania regex
Streamlit	Streamlit Inc.	≥ 1.25	Interfejs użytkownika oparty na sieci
Kod źródłowy referencyjnej implementacji	Autorzy / GitHub | Repozytorium GitHub		Kod źródłowy dla interfejsu Streamlit, potoku LangChain, normalizacji wspomaganej przez Neo4j, generowania regex, narzędzi do walidacji i przykładowych plików konfiguracyjnych. Dostępny na https://github.com/SOCautomatic/cti-ioc-regex-pipeline. Dostęp: 11 czerwca 2026.