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 zweryfikowano wygenerowane wyrażenia regularne (regex) w odniesieniu do ponad 2 400 niezależnie zebranych ciągów znaków prawdy obiektywnej (ground-truth) z dziesięciu scenariuszy MITRE ATT&CK Evaluation. Ciągi znaków prawdy obiektywnej stanowią wyselekcjonowane przez ekspertów artefakty ataków, raportowane niezależnie przez dostawców rozwiązań cyberbezpieczeństwa podczas ćwiczeń MITRE ATT&CK Evaluation, a zatem odzwierciedlają wzorce strukturalne, które analitycy i dostawcy dokumentują w praktyce. Poniższe wyniki koncentrują się na zachowaniu przepływu pracy, poprawności strukturalnej oraz efektach ewaluacji istotnych dla operacyjnej analizy logów i przepływów detekcyjnych.

Przegląd całego procesu przedstawiono na Rysunku 1, który podsumowuje etapy wyszukiwania grup przechwytywania i generowania wyrażeń regularnych, stanowiące ramy dla pozostałych reprezentatywnych wyników.

Etap 1: Wynik analizy dokumentu

Rycina 2 przedstawia wynik Etapu 1, w którym wejściowy raport CTI jest analizowany i przekształcany w ujednoliconą reprezentację Markdown. Po pomyślnym wykonaniu interfejs wyświetla ustrukturyzowany podgląd dokumentu, zawierający granice sekcji oraz wskaźniki istotności.

Prawidłowe wykonanie objawia się spójną segmentacją akapitów oraz zachowaniem artefaktów technicznych, takich jak ścieżki do plików, klucze rejestru i fragmenty wiersza poleceń. Nadmierne ucięcie treści lub utrata formatowania na tym etapie mogą wpłynąć na późniejszą analizę i powinny zostać naprawione przed kontynuowaniem prac.

Etap 2: Ekstrakcja IOC w oparciu o konsensus

Rysunek 3 ilustruje wynik etapu 2, w którym kandydaci na IOC są wyodrębniani przy użyciu głosowania zespołowego wielu modeli LLM. Powstały interfejs prezentuje kolekcję IOC w formacie JSON, opatrzoną adnotacjami dotyczącymi liczby głosów oraz modeli, które do nich przyczyniły się.

Zachowane zostają jedynie te IOC, które spełniają skonfigurowany minimalny próg konsensusu. IOC wykluczone na tym etapie zazwyczaj odzwierciedlają halucynacje specyficzne dla danego modelu lub niejednoznaczne fragmenty tekstu. Ich wykluczenie jest oczekiwanym i pożądanym wynikiem, wskazującym na prawidłowe funkcjonowanie głosowania zespołowego.

Etap 3: Analiza i klasyfikacja IOC

Tabela 2 podsumowuje oczekiwane wyniki, automatyczne kroki walidacji oraz kontrole jakości przeznaczone dla analityka na każdym etapie protokołu.

Rysunek 4 przedstawia kandydatów na IOC, którzy nie osiągnęli progu konsensusu podczas głosowania zespołowego w Etapie 2, a których interfejsy powierzchniowe są udostępniane do inspekcji analityka. Takie kandydatury zazwyczaj odzwierciedlają halucynacje specyficzne dla modelu lub niejednoznaczne fragmenty tekstu. Rysunek 4 i Rysunek 5 odpowiadają zatem wynikom różnych etapów — zestawowi odrzuconemu w Etapie 2 oraz zestawowi zatrzymanemu w Etapie 3 — a nie alternatywnym widokom tego samego procesu w Etapie 3.

Rysunek 5 przedstawia tabelę zachowanych IOC wygenerowaną w Etapie 3 po parsowaniu JSON, kategoryzacji opartej na regułach oraz deduplikacji IOC. Dla każdego zachowanego IOC etap ten rejestruje zestandaryzowaną kategorię, tag źródła oraz oryginalny klucz ekstrakcji, jeśli jest dostępny, przed przekazaniem IOC do dalszej normalizacji.

Etap 4: Normalizacja IOC z wykorzystaniem grafów dla różnych typów IOC

Rycina 6, Rycina 7 oraz Rycina 8 przedstawiają reprezentatywne wyniki normalizacji dla trzech kategorii IOC omówionych w niniejszym badaniu: ścieżek do plików, kluczy rejestru i wskaźników wiersza poleceń. Dla każdej kategorii ryciny porównują oryginalny IOC wyodrębniony z raportu CTI z reprezentacją znormalizowaną, uzyskaną za pomocą analizy wspomaganej grafem.

W przypadku wszystkich typów IOC, protokół rozkłada każdy IOC na komponenty semantyczne i rozstrzyga relacje hierarchiczne, wykorzystując ustrukturyzowaną wiedzę zakodowaną w grafowej bazie danych. W obecnej implementacji baza Neo4j przechowuje znormalizowane węzły Ścieżki, Rejestru i CLI oraz wykorzystuje relacje sąsiedztwa do sprawdzenia, czy komponenty należą do rozpoznanych łańcuchów. Rola ta jest analogiczna do wykorzystania ustrukturyzowanej wiedzy ATT&CK podczas projektowania mechanizmów detekcji².

Co istotne, ten etap normalizacji rejestruje jawne role semantyczne dla komponentów IOC, oznaczając je jako „zachowaj” (keep) lub „usuń” (discard), zamiast po cichu usuwać je z rekordu analizy. Znormalizowany ciąg znaków jest rekonstruowany głównie z komponentów oznaczonych jako zachowaj, podczas gdy komponenty do usunięcia pozostają dostępne jako metadane dla późniejszego generowania i walidacji wyrażeń regularnych (regex).

O prawidłowym wykonaniu tego etapu świadczą znormalizowane IOC, które zachowują istotny kontekst strukturalny i wykazują spójne etykietowanie grup przechwytywania w różnych typach IOC. Porównanie wizualne reprezentacji oryginalnych i znormalizowanych stanowi praktyczny mechanizm kontroli jakości, pozwalający zweryfikować, czy rozdzielczość grup przechwytywania została zastosowana w sposób spójny i bez niezamierzonej utraty informacji.

Etap 5: Generowanie wyrażeń regularnych z pomocniczym wyborem opartym na ograniczeniach

Rysunek 9 przedstawia wynik Etapu 5, w którym protokół generuje strukturalnie zgodne wyrażenia regularne z znormalizowanych IOC za pomocą iteracyjnego procesu walidacji. Implementacja łączy początkowy prompt generujący, diagnostyczne ponawianie zapytań w przypadku braku dopasowania kandydata do IOC, walidację z uwzględnieniem odrzucań oraz pętle ponowień z określonym limitem.

Biorąc pod uwagę znormalizowany IOC oraz powiązaną z nim specyfikację komponentów do zachowania/odrzucenia, przepływ pracy najpierw generuje wstępnego kandydata na wyrażenie regularne (regex). Następnie kandydat jest testowany względem IOC, w przypadku niepowodzenia dopasowania następuje ponowne wywołanie diagnostyczne, sprawdzane jest występowanie zakazanych odrzuconych tokenów, a następnie oceniana jest nadmierna generalizacja przy użyciu losowych ciągów negatywnych.

W przypadku, gdy wielu kandydatów spełnia podstawowe kryteria walidacji, protokół stosuje pomocniczy mechanizm selekcji oparty na ograniczeniach, aby zachować reprezentatywny regex do dalszego wykorzystania. Obecna implementacja ocenia kandydatów według wzoru `Score = n_cg - n_wc`, gdzie `n_cg` to liczba reprezentowanych komponentów zachowanych, a `n_wc` to liczba odrzuconych lub niezmapowanych tokenów obecnych w regexie.

Funkcję selekcji definiuje się jako:

Wynik = n_cg − n_wc

Jest to specjalizacja o równych wagach (α = β = 1) bardziej ogólnej postaci Score = α·n_cg − β·n_wc. Tutaj n_cg oznacza liczbę reprezentowanych komponentów zachowanych, a n_wc oznacza liczbę komponentów odrzuconych lub nieprzypisanych dodatkowych tokenów wprowadzonych ponownie przez wyrażenie regularne. Implementacja rejestruje również liczbę iteracji, listy błędów, szacowane zużycie tokenów, wykorzystanie pamięci podręcznej oraz telemetrię opóźnień dla każdego IOC. Ustawienie równych wag zostało zastosowane jako prosty, deterministyczny domyślny parametr dla implementacji referencyjnej; ponieważ traktuje ono brakujący komponent zachowany i ponownie wprowadzony komponent odrzucony jako równie niepożądane, w kontekstach wdrożeniowych, w których wyniki fałszywie ujemne i fałszywie dodatnie niosą ze sobą różne koszty operacyjne, preferowane mogą być inne wagi.

Jako kandydat najlepiej spełniający te ograniczenia wybierany jest końcowy regex. Wyklucza się wybór wyrażeń regularnych, które umieszczają wymagane komponenty grup przechwytujących wewnątrz konstrukcji opcjonalnych, np. ( ... )?, ponieważ osłabia to spójność semantyczną. Ten etap selekcji jest pomocniczy względem procesu generowania i nie ma służyć jako samodzielna metryka jakości.

Przegląd analityczny przetwarzania CTI

Rysunek 10 przedstawia przegląd wyników analizy CTI we wszystkich przetworzonych dokumentach. W ocenie referencyjnej ekstrakcja IOC z 3 156 raportów CTI dostarczyła ponad 63 000 kandydatów na IOC, w tym 12 195 ścieżek do plików, 2 302 kluczy rejestru oraz 10 286 wskaźników wiersza poleceń, przy czym pozostałe kandydaty należały do typów IOC niebędących celami wyrażeń regularnych.

Liczby te stanowią wysokopoziomową walidację potwierdzającą, że wyodrębnione wskaźniki koncentrują się w trzech kategoriach IOC objętych obecnym protokołem, wykazując jednocześnie, że wiele wyodrębnionych artefaktów pozostaje poza zakresem generowania wyrażeń regularnych. Podczas reprodukcji przepływu pracy należy podać dokładną liczbę przetworzonych raportów CTI, całkowitą liczbę kandydatów na IOC, liczby w podziale na kategorie oraz dostawcę, model, wersję modelu, temperaturę, liczbę powtórzeń i próg konsensusu zastosowane podczas ekstrakcji.

W ewaluacji referencyjnej wygenerowane wyrażenia regularne (regexy) oceniono w odniesieniu do ponad 2 400 niezależnie zebranych ciągów znaków prawdy obiektywnej (ground-truth) z dziesięciu scenariuszy MITRE ATT&CK Evaluation, osiągając średni wskaźnik trafień 99,1 % oraz średni wskaźnik niedopasowania między różnymi IOC na poziomie 0,8 %. W niniejszym manuskrypcie wskaźnik niedopasowania jest wykorzystywany jako miara specyficzności semantycznej: niedopasowanie występuje, gdy wyrażenie regularne wygenerowane dla jednego IOC pasuje również do ciągu znaków prawdy obiektywnej powiązanego z innym IOC. Wartość ta nie powinna być interpretowana jako końcowy operacyjny wskaźnik fałszywych alarmów, który zależy również od logiki reguł w dalszych etapach analizy oraz kontekstu wdrożenia.

Rozkład ten odzwierciedla strukturę korpusu CTI i pozwala użytkownikom zweryfikować, czy wyekstrahowane wskaźniki są zgodne z oczekiwanymi typami IOC. Znaczne odchylenia od oczekiwanych proporcji mogą wskazywać na problemy z analizą składniową lub ekstrakcją w górnym strumieniu danych i powinny zostać zbadane przed przejściem do normalizacji i generowania wyrażeń regularnych w dolnym strumieniu.

Analiza działań optymalizacji wyrażeń regularnych

Rysunek 11 podsumowuje działania wykonane podczas generowania i doprecyzowania wyrażeń regularnych. Rozkład obejmuje trzy rodzaje działań: wstępne generowanie wyrażeń regularnych, kroki optymalizacji sterowane przez LLM oraz regenerację w oparciu o ponowne próby.

Optymalizacja sterowana przez LLM odpowiada za 51,7 % wszystkich zaobserwowanych działań. Ta częstotliwość wskazuje, że sama wstępna generacja jest często niewystarczająca do stworzenia wyrażeń regularnych spełniających ograniczenia grup przechwytujących i wymagania wykluczania. Zamiast tego, w celu doprecyzowania kandydujących wyrażeń regularnych, aktywnie i wielokrotnie stosowana jest optymalizacja iteracyjna.

Zamiast odzwierciedlać nieefektywność, rozkład ten wykazuje, że proces optymalizacji jest niezbędnym i integralnym elementem protokołu podczas generowania zgodnych strukturalnie wyrażeń regularnych z złożonych danych wejściowych IOC.

Osobna charakterystyka skalowalności przeprowadzona na losowej próbie 6 000 IOC wygenerowanych za pomocą LLM do testów skalowalności (patrz Tabela Materiałów) wykazała medianę opóźnienia wynoszącą 2,95 s na IOC oraz średnie opóźnienie na poziomie 23,18 s. W tej samej charakterystyce odsetek poprawności składniowej kompilacji wyrażeń regularnych wyniósł 99,56 %, ogólna skuteczność generowania osiągnęła 99,4 %, średnie szacowane zużycie tokenów wyniosło około 3 986 tokenów na IOC, a przepływ pracy wymagał średnio około 7,89 wywołań LLM na IOC. Wskaźniki sukcesu w pierwszej próbie wyniosły 56,46 % dla pętli dopasowania i debugowania (match-debug loop) oraz 72,92 % dla pętli walidacji grup nieprzechwytywanych (non-capture-group validation loop). Pomiary te pomagają określić koszt obliczeniowy oraz przepustowość operacyjną w przypadku przetwarzania wsadowego.

W bieżącej charakterystyce referencyjnej do ponownego trenowania modelu nie wykorzystano eksperckiej weryfikacji podzbioru pobranych wyników; raportowane rezultaty odzwierciedlają automatyczne wykonanie potoku oraz opisane powyżej zestawy danych do ewaluacji końcowej.

Dowody operacyjne i obsługa błędów. Rysunek 12 przedstawia strukturę wyeksportowanego pliku regex SIEM wygenerowanego przez protokół, wraz z dowodami walidacji na poziomie reguł dla reprezentatywnych wzorców ścieżek plików, kluczy rejestru i wiersza poleceń. Rysunek 13 przedstawia odpowiadający mu pełny raport JSON, który ujawnia wszystkie wyniki poszczególnych etapów (wyekstrahowane, przeanalizowane i znormalizowane IOC wraz z wygenerowanymi wzorcami regex i flagami walidacji dla każdego IOC) i stanowi główny artefakt wykorzystywany przez narzędzia w dalszej części procesu. Rysunek 14 ilustruje sposób obsługi przez protokół zaszumionych danych wejściowych CTI: ścieżka pliku z neutralizacją znaków specjalnych (defanged) i zaburzonymi odstępami zostaje oznaczona na etapie analizy, skorygowana, znormalizowana do kanonicznego szablonu %TEMP%, a następnie przekonwertowana na kompilujący się i dopasowujący wyrażenie regularne. Ten przykład praktyczny uzupełnia dowody operacyjne przedstawione na Rysunku 12 oraz Rysunku 13, dokumentując zachowanie protokołu w sytuacji, gdy surowy tekst IOC odbiega od formy kanonicznej.

Rysunek 1: Ogólna architektura protokołu konwersji IOC na wyrażenia regularne (regex). Rysunek przedstawia kompletny przebieg procesu. Kandydujące ciągi IOC wygenerowane przez nadrzędny ekstraktor IOC są dekomponowane i porównywane z węzłami referencyjnymi w grafie Neo4j zasilanym dokumentacją systemu Windows (krok 1), co pozwala na odzyskanie znanych komponentów ścieżek, rejestru oraz wiersza poleceń (krok 2). Fragmenty zmienne lub specyficzne dla środowiska są oznaczane jako do odrzucenia i wykluczane z znormalizowanej rekonstrukcji, przy jednoczesnym zachowaniu ich w metadanych komponentów, co daje znormalizowane IOC z etykietami zachowania lub odrzucenia na poziomie komponentów (krok 3). Znormalizowane IOC są następnie przekazywane do etapu generowania wyrażeń regularnych opartego na LLM (krok 4), który tworzy kandydackie wyrażenia regularne, które są punktowane i iteracyjnie optymalizowane pod kątem ograniczeń grup przechwytujących oraz reguł tokenów odrzuconych (krok 5), aż do wyboru ostatecznego wyrażenia regularnego (krok 6). Kliknij tutaj, aby wyświetlić powiększoną wersję tego rysunku.

Rysunek 2: Wynik analizy dokumentu w Etapie 1. Porównanie oryginalnego raportu CTI z podglądem przeanalizowanego dokumentu. Lewy panel przedstawia oryginalny raport CTI w formacie PDF, natomiast prawy panel wyświetla ujednoliconą reprezentację w formacie Markdown wygenerowaną przez parser. Kliknij tutaj, aby wyświetlić powiększoną wersję tego rysunku.

Rysunek 3: Ekstrakcja IOC oparta na konsensusie z wykorzystaniem głosowania zespołu multi-LLM. Interfejs przedstawia proces ekstrakcji IOC oparty na zespole oraz jego wyniki pośrednie. Czerwona ramka wyróżnia skonfigurowane instancje LLM uczestniczące w ekstrakcji IOC, w tym wybranych dostawców oraz liczbę powtórzeń procesu ekstrakcji wykonanych dla każdego modelu. Niebieska ramka wskazuje zdefiniowany przez użytkownika próg konsensusu, który określa minimalną liczbę wystąpień wymaganą do zachowania danego IOC. Po zagregowaniu wyników ekstrakcji ze wszystkich modeli i powtórzeń, kandydaci na IOC, którzy pojawiają się rzadziej niż wynosi próg, są odrzucani. Pomarańczowa ramka pokazuje końcowy zestaw zachowanych IOC, które spełniają kryterium konsensusu i są przekazywane do kolejnych etapów analizy. Kliknij tutaj, aby wyświetlić większą wersję tego rysunku.

Rycina 4: IOC odrzucone w drodze głosowania zespołowego na etapie 2. Widok zestawiony kandydatów na IOC, którzy nie spełnili skonfigurowanego progu minimalnej liczby głosów podczas głosowania zespołowego i zostali wyświetleni do wglądu analityka. Odrzucone kandydatury zazwyczaj odzwierciedlają halucynacje specyficzne dla modelu lub niejednoznaczne fragmenty tekstu i nie są przekazywane do kroku kategoryzacji na etapie 3. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.

Rycina 5: Zestaw zachowanych IOC ze zstandaryzowaną klasyfikacją. Kandydaci na IOC zachowani po przetwarzaniu w Etapie 3 są przedstawieni wraz ze swoimi zstandaryzowanymi kategoriami, tagami źródłowymi oraz oryginalnymi kluczami ekstrakcji, jeśli były dostępne. Tabela ta przedstawia ustrukturyzowane dane wejściowe IOC wykorzystywane w etapie normalizacji. Aby wyświetlić powiększoną wersję tej ryciny, kliknij tutaj.

Rysunek 6: Normalizacja IOC ścieżki pliku przy użyciu analizy wspomaganej grafem. Porównanie oryginalnego IOC ścieżki pliku z jego znormalizowaną reprezentacją. Przeszukiwanie oparte na grafie odpytuje znane komponenty ścieżki według znormalizowanej nazwy i oznacza każdy komponent jako „zachowaj” (keep) lub „odrzuć” (discard). Identyfikatory dysków oraz zmienne fragmenty nazw plików mogą zostać oznaczone jako „odrzuć” w rekordzie komponentu, podczas gdy forma znormalizowana jest rekonstruowana głównie z zachowanych segmentów strukturalnych, wymaganych do późniejszego konstruowania wzorców. Kliknij tutaj, aby wyświetlić większą wersję tego rysunku.

Rysunek 7: Normalizacja wskaźników IOC kluczy rejestru za pomocą analizy wspomaganej grafem. Normalizacja wskaźnika IOC klucza rejestru poprzez rozstrzyganie hierarchicznych struktur rejestru wspomagane grafem. Skrócone klucze główne są rozwijane do kanonicznych uli rejestru, a analizator wyodrębnia najdłuższy ciągły znany podciąg rejestru, pomijając placeholdery hostów, wartości przypominające SID oraz tokeny przypominające GUID. Wynikowe rekordy zawierają etykiety zachowania/odrzucenia dla każdego zachowanego komponentu i generują kanoniczną ścieżkę rejestru do dalszego przetwarzania. Kliknij tutaj, aby wyświetlić powiększoną wersję tego rysunku.

Rysunek 8: Normalizacja IOC w wierszu poleceń z wykorzystaniem analizy wspomaganej grafami. Porównanie oryginalnego IOC z wiersza poleceń oraz jego znormalizowanej reprezentacji. Protokół tokenizuje wiersz poleceń z zachowaniem ciągów znaków w cudzysłowie, normalizuje początkowy token polecenia poprzez wyszukiwanie w Neo4j (jeśli jest to możliwe) i rekurencyjnie analizuje osadzone fragmenty przypominające ścieżki lub klucze rejestru. Stabilne komponenty powiązane z poleceniem są oznaczane jako keep (zachowaj), zmienne argumenty jako discard (odrzuć), a końcowa kanoniczna struktura polecenia jest rekonstruowana z elementów zachowanych. Kliknij tutaj, aby wyświetlić powiększoną wersję tego rysunku.

Rycina 9: Selekcja kandydatów wyrażeń regularnych w oparciu o ograniczenia. Dla każdego znormalizowanego IOC generowanych jest wiele kandydatów wyrażeń regularnych (regex) przy użyciu iteracyjnego procesu walidacji. Zastosowano mechanizm punktacji oparty na ograniczeniach w celu wyboru końcowego wyrażenia regularnego, które zachowuje wyznaczone komponenty grup przechwytujących, ograniczając jednocześnie niepożądane zmienne podciągi. Kliknij tutaj, aby wyświetlić większą wersję tej ryciny.

Rysunek 10: Rozkład wyekstrahowanych IOC w raportach CTI. Podsumowanie wyników ekstrakcji IOC przedstawiające całkowitą liczbę wskaźników zidentyfikowanych w raportach CTI oraz ich rozkład w obrębie ścieżek do plików, kluczy rejestru i wskaźników wiersza poleceń. Widok ten zapewnia wysokopoziomową walidację zakresu treści CTI oraz przebiegu procesu ekstrakcji. Kliknij tutaj, aby wyświetlić powiększoną wersję tego rysunku.

Rycina 11: Rozkład działań optymalizacyjnych podczas generowania wyrażeń regularnych. Podział działań wykonywanych podczas generowania wyrażeń regularnych, w tym generowania wstępnego, optymalizacji sterowanej przez LLM oraz regenerowania w oparciu o ponowienie próby. Optymalizacja sterowana przez LLM stanowi 51.7 % wszystkich działań, co pokazuje, że iteracyjne ulepszanie jest niezbędnym elementem protokołu tworzenia wyrażeń regularnych spełniających ograniczenia grup przechwytujących. Kliknij tutaj, aby wyświetlić powiększoną wersję tej ryciny.

Rysunek 12: Reprezentatywny wyeksportowany plik regex. Przykładowa zawartość eksportu regex SIEM (siem_rules.txt) wygenerowanego zgodnie z protokołem. Każdy wpis zawiera źródłowy wskaźnik IOC, przypisaną kategorię (ścieżka pliku, klucz rejestru lub wiersz polecenia) oraz zwalidowany wzorzec regex. Dołączona tabela walidacji podsumowuje oczekiwane zachowanie oraz dowody systemowe wykorzystane do potwierdzenia poprawności każdego typu reguły. Kliknij tutaj, aby wyświetlić powiększoną wersję tego rysunku.

Rycina 13: Reprezentatywny pełny raport JSON. Wynik końcowy potoku (pipeline) wygenerowany po uruchomieniu wszystkich pięciu etapów protokołu na reprezentatywnym raporcie CTI. Dokument JSON rejestruje plik źródłowy, liczbę przeanalizowanych sekcji, wyodrębnione IOC zgrupowane według kategorii, zrekategoryzowane rekordy z etapu 3 z tagami źródłowymi, różnice normalizacji z etapu 4 oraz wzorce regex z etapu 5 z flagami walidacji dla każdego IOC. Raport zawiera również metadane sukcesu i błędów na najwyższym poziomie, które umożliwiają narzędziom w dalszych etapach wykrycie częściowych awarii. Kliknij tutaj, aby wyświetlić większą wersję tej ryciny.

Rycina 14: Błędne lub zaszumione dane wejściowe: identyfikacja i korekta. Przykład praktyczny pokazujący, w jaki sposób protokół identyfikuje zaszumiony IOC i naprawia go. Surowe dane wejściowe %T E M P%\malware[.]exe zostają oznaczone, ponieważ token zmiennej środowiskowej zawiera wstawione spacje, a rozszerzenie pliku zostało zneutralizowane (defanged). Krok korekty usuwa wstawione znaki białych znaków i przywraca dosłowną kropkę; normalizacja w etapie 4 rozszerza %TEMP% do kanonicznego szablonu katalogu Temp systemu Windows; a etap 5 generuje wyrażenie regularne, które kompiluje się i dopasowuje do poprawionego, znormalizowanego IOC. Przykład ten ilustruje sposób obsługi zaszumionych danych wejściowych omówiony w sekcji Dyskusja. Kliknij tutaj, aby zobaczyć powiększoną wersję tej ryciny.

Element	Typ	Wartość / Schemat	Przykład	Uwagi
Etykieta węzła	Label	:Path	Windows, System32, cmd.exe	Przechowuje komponenty ścieżki plików systemu Windows
Etykieta węzła	Label	:Registry	SOFTWARE, Microsoft, Windows NT	Przechowuje komponenty kluczy rejestru poniżej głównych uli (root hives)
Etykieta węzła	Label	:CLI	powershell.exe, -ExecutionPolicy, Bypass	Przechowuje tokeny poleceń i parametry
Właściwość węzła	String	name	cmd.exe	Oryginalna wielkość liter; używana do wyświetlania w znormalizowanym wyniku
Właściwość węzła	String	name_lower	cmd.exe	Forma małymi literami; używana jako klucz wyszukiwania dla wszystkich zapytań MATCH
Relacja	Krawędź skierowana	(a)-[:NEXT]->(b)	(Windows)-[:NEXT]->(System32)	Oba punkty końcowe mają tę samą etykietę; koduje natywną sąsiedniość w systemach Windows
Ograniczenie	Unikalność	n.name_lower UNIQUE na etykietę	-	Zastosowane do :Path, :Registry, :CLI
Źródło danych	Zakres	Windows 8, 10, 11	-	Systemy operacyjne klientów wprowadzone do grafu
Źródło danych	Zakres	Windows Server 2012, 2016, 2019, 2022	-	Systemy operacyjne serwerów wprowadzone do grafu

Tabela 1: Schemat grafu Neo4j wykorzystany do normalizacji IOC (Etap 4). Przedstawia trzy etykiety węzłów (Path, Registry, CLI), ich wspólny schemat właściwości (name, name_lower), skierowaną relację sąsiedztwa wykorzystywaną do krawędzi porządkowania natywnego, ograniczenia unikalności oraz wersje klienta i serwera Windows, które zasilają graf.

Etap	Oczekiwany wynik	Zautomatyzowana walidacja	Kontrola jakości skierowana do analityka
Etap 1: Analiza dokumentu	Zunifikowany tekst Markdown, podzielony na fragmenty po 4000 znaków przed przetwarzaniem przez model LLM.	—	Wizualna kontrola podglądu Markdown w celu potwierdzenia, że ścieżki do plików, klucze rejestru, fragmenty wiersza poleceń i granice sekcji nie zostały naruszone podczas parsowania; zmiana backendu w przypadku ucięcia ciągów technicznych.
Etap 2: Ekstrakcja IOC	Plik JSON z trzema kluczami najwyższego poziomu (File Paths, Command Lines, Registry Keys); w przypadku włączenia głosowania zespołowego – liczba głosów dla każdego IOC oraz metadane dotyczące modeli wnoszących wkład.	Filtr progu konsensusu (min_votes) wyklucza wskaźniki kompromitacji (IOC), których liczba głosów jest niższa od skonfigurowanego progu.	Analiza odrzuconych kandydatów w celu odróżnienia halucynacji od zbyt rygorystycznego głosowania przed dostosowaniem parametru min_votes.
Etap 3: Analiza i klasyfikacja wskaźników kompromitacji (IOC)	Kategoryzowana lista wskaźników kompromitacji (IOC): każdy wskaźnik IOC sparowany ze znormalizowaną kategorią, tagiem źródłowym oraz oryginalnym kluczem ekstrakcji, jeśli jest dostępny.	Mapowanie na standaryzowane kategorie za pomocą reguł opartych na wyrażeniach regularnych i heurystyk wzorców IOC; usuwanie duplikatów par (IOC, kategoria).	Kontrolna weryfikacja skategoryzowanych wyników pod kątem kandydatów niejednoznacznych lub zaszumionych (Rysunek 4A).
Etap 4: Normalizacja z wykorzystaniem Neo4j	Forma znormalizowana per-IOC z etykietami zachowania/odrzucenia na poziomie komponentów.	Zapytania Cypher (i)-(iii) w odniesieniu do grafu referencyjnego Windows; deterministyczne przetwarzanie wstępne jako rozwiązanie zapasowe w przypadku braku dostępności Neo4j.	Analiza wszystkich przypadków całkowitego odrzucenia w celu zidentyfikowania luk w pokryciu grafu; rozszerzenie danych grafu o referencje specyficzne dla dostawcy lub środowiska w razie potrzeby.
Etap 5: Generowanie i punktowanie wyrażeń regularnych	Ostateczny regex dla każdego IOC wraz z wynikiem kandydata, historią optymalizacji, liczbą iteracji oraz telemetrią dla każdego IOC.	Test dopasowania, statyczne kontrole jakości, kontrola tokenów zabronionych z uwzględnieniem granic, test nadmiernej generalizacji na 5 deterministycznych próbkach negatywnych; przejście do dopasowania częściowego z najwyższą punktacjąą (flaga used_fallback).	Przegląd historii optymalizacji dla zapasowych wyrażeń regularnych; diagnostyczna inspekcja pozycji błędu zgodnie z IOC przed regeneracją.

Tabela 2: Podsumowanie wyników etapów i walidacji. Przypisuje każdy etap protokołu (1–5) do oczekiwanego artefaktu, dowodu automatycznej walidacji wygenerowanego przez potok (status kompilacji wyrażeń regularnych, współczynnik trafień, współczynnik niezgodności krzyżowych wskaźników IOC, liczba iteracji optymalizacji) oraz odpowiadającej im kontroli jakości przeprowadzanej przez analityka (porównanie wizualne, inspekcja odrzuconych kandydatów oraz przegląd kategorii).

Plik uzupełniający 1: Dosłowne prompty LLM. Dosłowne prompty systemowe i ludzkie wykorzystane do ekstrakcji IOC w etapie 2 oraz generowania i optymalizacji wyrażeń regularnych w etapie 5.Kliknij tutaj, aby pobrać ten plik.

Plik uzupełniający 2: Szczegóły implementacji dla etapów 4 i 5. Szczegóły algorytmiczne i implementacyjne wspierające normalizację IOC wspomaganą grafem w etapie 4 oraz walidację za pomocą wyrażeń regularnych, punktację i kontrolę iteracji w etapie 5. Kliknij tutaj, aby pobrać ten plik.

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. Przedstawiony tutaj protokół radzi sobie z tym problemem poprzez wieloetapowy przepływ pracy, w którym każda faza generuje dobrze zdefiniowany pośredni artefakt i stosuje wyraźną weryfikację przed przekazaniem wyników do kolejnego etapu. Rysunek 14 dokumentuje jeden taki przypadek, w którym zidentyfikowany, uszkodzony i zakłócony ścieżką plików jest poprawiany, normalizowany i przekształcany w kompilujące wyrażenie regularne; obsługa zakłóceń wejściowych protokołu i jego obecny zakres są omówione razem z ograniczeniami wymienionymi poniżej.

Centralnym wkładem tego protokołu jest jego wyraźne rozłożenie przepływu pracy na etapy z kontrolowalnymi pośrednimi wynikami. Implementacja jest teraz opisana konkretnie: parsowanie dokumentu produkuje Markdown i pofragmentowany tekst do przetwarzania przez LLM; ekstrakcja IOC emituje strukturalne JSON dla ścieżek plików, kluczy rejestru i wskaźników wiersza poleceń; analiza IOC oparta na regułach standaryzuje i usuwa duplikaty wyciągniętych wartości; normalizacja wspierana przez Neo4j oznacza każdy składnik IOC jako zachowaj lub odrzuć; a generacja wyrażeń regularnych stosuje debugowanie dopasowań, weryfikację odrzucenia i sprawdzanie nadmiernej generalizacji przed wyborem kandydatów.

Protokół traktuje generowanie wyrażeń regularnych jako iteracyjne zadanie konstrukcyjne, a nie jednorazowy problem predykcyjny. Implementacja korzysta z początkowego sugestu generacji, zautomatyzowanych diagnostyków dopasowania, ograniczonych pętli rafiniacji i funkcji punktacji opartej na komponentach, aby zachować strukturalnie ważne elementy IOC, karząc jednocześnie odrzucone lub niezmapowane podciągi. Ta iteracyjna konstrukcja, wraz z deterministycznymi walidatorami stosowanymi na każdym kroku, wspiera produkcję wzorców regex, które pozostają strukturalnie wiernymi na dużym i heterogenicznym zbiorze ewaluacji. W referencyjnej ewaluacji, ten przepływ pracy został zastosowany do 3156 raportów CTI i oceniany w odniesieniu do ponad 2400 niezależnych niezależnych ciągów rzeczywistych, dając średni współczynnik trafień 99,1% i średnią niezgodność między IOC na poziomie 0,8%. Ponieważ te rzeczywiste ciągi są ekspercko kurowanymi artefaktami zgłaszanymi przez dostawców cyberbezpieczeństwa podczas ćwiczeń ewaluacji MITRE ATT&CK, ta ocena zawiera porównanie wyniku protokołu z wzorami IOC udokumentowanymi przez analityków ludzkich, a nie z wygenerowanymi automatycznie.

Jak pokazano w reprezentatywnych wynikach, iteracyjna optymalizacja jest szczególnie ważna, gdy przepływ pracy obsługuje złożone struktury IOC, takie jak zagnieżdżone ścieżki plików lub długie ciągi wiersza poleceń. Wyniki referencyjnej ewaluacji wskazują również, że najczęściej niedopasowane przypadki występują, gdy atakujący używają niestandardowych wykonywalnych plików lub parametrów, które nie są reprezentowane w bazie danych graficznej lub nie są wyraźnie udokumentowane w źródłowych raportach CTI. W użytku operacyjnym te tryby awarii powinny być traktowane jako oczekiwane warunki graniczne, a nie cicha błędy, i powinny wywoływać przegląd pokrycia grafu, kompletności źródłowych raportów i telemetrii debugowania regex.

Protokół można porównać do trzech rodzin alternatywnych metod. Po pierwsze, metody syntezy wyrażeń regularnych opartych na przykładach, takie jak TransRegex¹¹ i Regex+¹², uczą się wyrażeń regularnych z kurowanych zestawów przykładów ciągów dodatnich i ujemnych. Te metody radzą sobie dobrze, gdy dostępne są reprezentatywne zestawy przykładów, ale są mniej bezpośrednio stosowalne w kontekstach SOC, gdzie każdy IOC zgłoszony w CTI pojawia się zazwyczaj jako pojedynczy reprezentatywny ciąg, a wymagana granica generalizacji jest napędzana przez semantyki operacyjne, a nie przez zasięg przykładów. Po drugie, podejścia do programowania genetycznego, takie jak te wprowadzone przez Bartoli i in.^13,14, przeszukują przestrzeń wyrażeń regularnych za pomocą operatorów ewolucyjnych i zazwyczaj wymagają oznaczonego korpusu ciągów pasujących i niepasujących; są one dobrze dostosowane do wsadowe konstruowania wzorców ekstrakcji, ale nie zużywają niezstrukturyzowanych narracji CTI. Po trzecie, ostatnie podejścia oparte na sieciach neuronowych i LLM^15,16 przekładają opisy w języku naturalnym bezpośrednio na ciągi wyrażeń regularnych; metody te są potężne dla dobrze określonych sugestii, ale w jednorazowym użytku mogą produkować wyrażenia regularne, które są składniowo poprawne, ale przegapiają wymagane komponenty grupy uchwytów lub nadmiernie generalizują wśród niepowiązanych wariantów IOC. Obecny protokół uzupełnia te kierunki poprzez (i) przyjm

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.