Siber Tehdit Zehbaratını Hesaplanabilir Tespit Kalıplarına Dönüştürmek İçin Yapılandırılmış Bir İş Akışı

Özet

Burada, büyük dil modelleri (LLM'ler) ve grafik destekli bileşen etiketlemeleri kullanarak güvenlik bilgisi ve olay yönetimi (SIEM) tespit kuralları için güvenlik bilgisi ve olay yönetimi (SIEM) tespit kuralları için güvenlik bilgisi ve olay yönetimi (SIEM) tespit kuralları için tehlike göstergelerini tehlike göstergelerine dönüştüren bir protokol sunuyoruz.

Özet

Güvenlik Operasyon Merkezleri (SOC'lar), siber tehdit istihbaratı (CTI) raporlarını rutin olarak operasyonel tespit içeriğine dönüştürür. Bu iş akışındaki kalıcı bir darboğaz, özellikle dosya yolları, kayıt anahtarları ve komut satırı dizileri gibi çıkarılmış uzlaşma göstergelerinin (IOC) güvenlik bilgisi ve olay yönetimi (SIEM) korelasyon kurallarına gömmeye uygun dağıtılabilir düzenli ifadelere (regex) çevrilmesidir. Önceki çalışmalar otomatik uzlaşma göstergesi (IOC) çıkarımı geliştirmiş olsa da, çıkarılan dizileri doğrulanmış regex desenlerine dönüştürmek büyük ölçüde manuel olarak kalır, uzman uzmanlık gerektirir ve hatalara açıktır. Bu protokolün amacı, IOC'den regex'e dönüşüm için standartlaştırılmış ve tekrarlanabilir bir prosedür sağlamaktır. İş akışı beş aşamadan oluşur: (1) heterojen CTI raporlarını birleşik bir Markdown temsiline ayrıştırmak; (2) IOC çıkarımı çoklu büyük dil modeli (LLM) kullanılarak uzlaşma oylaması; (3) çıkarılan IOC'lerin kural temelli normalizasyonu, kategorize edilmesi ve deduplication; (4) IOC bileşenlerinin grafik destekli etiketlenmesi; tutma (yakalama grubu) veya atma (ele geçirme grubu olmayan) olarak etiketlenmesi; ve (5) orijinal IOC dizileri karşısında tanı doğrulama ile yinelemeli regex üretimi. Faydayı değerlendirmek için iş akışı 3.156 CTI raporuna uygulandı ve ortaya çıkan regexler, on MITRE Karşı Taktik, Teknikler ve Ortak Bilgi (ATT&CK) Değerlendirme senaryosundan 2.400'den fazla bağımsız toplanmış gerçek dizisi ile karşılaştırıldığında ortalama isabet oranı %99,1 ve ortalama çapraz IOC uyumsuzluk oranı %0,8 oldu. Bu nedenle protokol, IOC'den regex'e çevirisi için tekrarlanabilir bir uygulamayı belgeler ve mevcut kapsamını, operasyonel varsayımlarını ve bilinen arıza durumlarını açıkça belirtir.

Giriş

Siber suçlar, kamu ve özel sektördeki kuruluşlar üzerinde önemli operasyonel ve finansal yükler getirmeye devam etmektedir. 2023 yılında, Amerika Birleşik Devletleri'nde siber suç nedeniyle bildirilen kayıplar 12,5 milyar^{doları aştı ve} bu da kötü niyetli faaliyetlerin ölçeğini ve sürekliliğini vurguladı. Bu alanda, Güvenlik Operasyon Merkezleri (SOC'lar), tehditleri gerçek zamanlı olarak tespit etmek, analiz etmek ve yanıt vermekten sorumlu birincil operasyonel birimler olarak hizmet vermektedir.
Birçok SOC iş akışında tespit mantığı, Güvenlik Bilgisi ve Olay Yönetimi (SIEM) platformlarındaki kural tabanlı mekanizmalarla uygulanır; bu mekanizmalar, yorumlanabilir, deterministik ve mevcut SOC iş akışlarıyla uyumlu oldukları için yaygın olarak kullanılır. Farklı kural türleri arasında, korelasyon tabanlı SIEM kuralları, birden fazla olay, ana bilgisayar ve zaman aralığını kapsayan saldırı davranışlarını tanımlamak için özellikle önemlidir. Bu kurallar içinde, düzenli ifadeler (regexler) yeniden kullanılabilir bir arama ilkesi olarak işlev görür: analistler, onları alan kısıtlamaları, platforma özgü filtreler ve olay-korelasyon mantığı ekleyen daha geniş tespit kurallarına gömer; bunları kendi içinde yetiştirilen dedektörler olarak kullanmak yerine.

Pratikte, SOC analistleri kural geliştirmeye genellikle güvenlik tedarikçileri, bağımsız araştırmacılar veya MITRE Karşı Taktikler, Teknikler ve Ortak Bilgi (ATT&CK) gibi kamu bilgi tabanları tarafından yayımlanan siber tehdit istihbaratı (CTI) raporlarından türetilen uzlaşma göstergeleriyle (IOC) ^başlarlar. Bu IOC dizileri dosya yolları, komut satırı parçaları, kayıt kaydı anahtarları veya saldırılar sırasında gözlemlenen diğer yapılandırılmış artefaktları^{içerebilir 3}. Bu tür dizeleri SIEM korelasyon kurallarına uygun regex kalıplarına çevirmek, kural yazarlık iş akışında tekrar eden bir görevdir.

Bu çeviri adımı pratik bir operasyonel darboğazdır. Anlamlı varyasyonları yakalayacak kadar genel ama istenmeyen eşleşmeleri önleyecek kadar hassas regex kalıpları oluşturmak özel uzmanlık gerektirir; Küçük sözdizimi hataları veya hangi bileşenlerin korunması veya genelleştirilmesi gerektiği konusunda yanlış kararlar, aksi takdirde faydalı olan bir tespit kuralını etkisiz hale getirebilir. Bu çalışma manuel, tekrarlayıcı ve detay odaklı olduğundan, ortaya çıkan tehditlerin tespit edilmesini geciktirebilir, daha deneyimli analistler tarafından inceleme gerektirebilir ve operasyonel SOC^{ayarlarında analist iş yüküne katkıda bulunabilir 4,5}.

IOC'den regex'e çevirisindeki temel zorluk, IOC'nin hangi bölümlerinin kararlı, saldırganla ilgili davranışı kodladığını ve bu nedenle korunması gerektiğini, hangi kısımların ise çevre veya ana koluya özgü varyasyonları yansıttığını ve genelleştirilmesi gerektiğini belirlemektir. Örneğin, HKEY_CLASSES_ROOT\CLSID gibi kanonik kayıt kökleri, System32 gibi sistem dizinleri ve rundll32.exe gibi bilinen çalıştırılabilir adlar genellikle açık kalmalıdır; oysa kullanıcı profili yolları, ana bilgisayara özgü Güvenlik Tanımlayıcıları (SID) ve Küresel Benzersiz Tanımlayıcılar (GUID) genellikle soyutlanmalıdır. Bunu heterojen IOC tipleri arasında tutarlı şekilde yapmak, çeviri görevini basit hale getirmektir. Bu protokol boyunca, ilkini korunan veya yakalama grubu bileşenleri, ikincisini ise soyut veya yakalanma grubu olmayan bileşenler olarak adlandırırız.

Önceki çalışmalar, doğal dil işleme ve varlık çıkarma teknikleri kullanılarak yapılandırılmamış metinden tehdit istihbaratının otomatik çıkarımını^{araştırmıştır 6,7}. Daha yakın zamanda, CTI raporlarından doğrudan tespit kurallarının oluşturulmasını büyük dil modelleri (LLM'ler) kullanarak ^{incelemiştir8}. Bu yaklaşımlar, kural yazarlığı iş akışının bazı bölümlerinin dil modelleri tarafından desteklenebileceğini gösterir, ancak genellikle yakalama grubu semantiklerini koruyan ve aşağı akım SIEM dağıtımı için uygun kalan regex desenleri oluşturma özel operasyonel sorununa odaklanmazlar. Tamamlayıcı çalışma alanları, TINKER⁹ gibi bilgi grafiği tabanlı temsiller ve ThreatRaptor¹⁰ gibi CTI tabanlı log-arama sorgularının CTI tabanlı üretimi gibi farklı şekillerde yapılandırılmıştır; bu sorgular yapılandırılmamış CTI'yi SIEM korelasyon kurallarına gömmek üzere regex kalıplarına dönüştürmek yerine yapılandırılmış bilgi veya alana özgü sorgu dillerine dönüştürür.

Paralel olarak, önceki çalışmalar örnek tabanlı yöntemler, sinir çevirisi ve üret-onarım^{yaklaşımları} 11,12,13,14,15,16 kullanarak otomatik regex sentezini araştırmıştır. Ancak, bu yöntemler genellikle IOC kaynaklı tespit bağlamları yerine büyük temsilci örnekler veya doğal dil açıklamalarına dayanan ortamlar için tasarlanmıştır. SOC iş akışlarında, IOC dizileri genellikle seyrek, yapısal olarak heterojen ve operasyonel semantikle yakından bağlantılıdır. Bu uyumsuzluk, mevcut regex üretim yöntemlerinin genel olarak yetersiz olduğu iddiasından ziyade, IOC'den regex'e çeviriye uyarlanmış bir iş akışını motive eder.

Burada sunulan protokol, özellikle SOC tespit iş akışının IOC'den regex'e çeviri aşamasına odaklanır. IOC çıkarımı, manuel analizden, otomatik araçlardan veya her ikisinin birleşiminden kaynaklanabilecek bir üst akış girdi olarak ele alınır; protokol tam SIEM kuralları oluşturmaya çalışmaz. Bunun yerine, IOC dizelerini sözdizimsel olarak geçerli, anlamsal olarak yorumlanabilir ve operasyonel dağıtıma uygun regex desenlerine dönüştürmek için sistematik bir prosedür sunar. Mevcut IOC kapsamı kasıtlıdır: dosya yolları, kayıt anahtarları ve komut satırı göstergeleri regex genellemesinden faydalanan hem kararlı hem de değişken yapısal bileşenler içerirken, IP adresleri, alan adları ve hash'ler gibi atomik göstergeler ise tam eşleşme koşulları veya itibar tarzı araştırmalarla daha doğal bir şekilde operasyonel hale getirilir ve bu nedenle birincil kapsamın dışında kalırlar. Bu sınırlar içinde, protokol, benzer girdi formatları ve araç ön koşullarını paylaşan SOC ortamları arasında taşınabilir olması amaçlanmıştır.

Protokol

Aşağıdaki beş aşamalı iş akışını kullanarak bir CTI raporunu izlenebilir ara çıktılara sahip doğrulanmış regex desenlerine dönüştürün (genel bakış için Şekil 1'e bakınız).

1. Sistem kurulumu

1. Ön koşulları kur.
   1. Python 3.8 veya daha yenisini, requirements.txt'da listelenen tüm Python bağımlılıklarını ve bir Neo4j grafik veritabanını kurun.
      1. Seçilen büyük dil modelleri için bir veya daha fazla uygulama programlama arayüzüne (API) erişimi onaylayın ve Neo4j servisinin çalıştığını ve yerel makineden erişilebildiğini doğrulayın.
   2. Malzemeler Tablosunun tamamlandığını doğrulayın.
      1. Python yorumlayıcı sürümü, pipeline bağımlılıkları, Neo4j sürümü ve Portable Document Format (PDF) metin çıkarma arka uçu dahil olmak üzere çalışma zamanı bağımlılıklarının listelendiğini doğrulayın.
      2. LLM yapılandırma seçeneklerinin listelendiğini doğrulayın; bunlar arasında LLM sağlayıcıları, model isimleri ve sürümleri, sıcaklık, akıl yürütme çabası seçenekleri ve toplu-oy ayarları yer alır.
      3. Desteklenen giriş ve çıkış formatlarının, desteklenen giriş dosya formatları ve desteklenen dışa aktarma formatları dahil olmak üzere listelendiğinden emin olun.
2. Web kullanıcı arayüzünü (UI) başlatın.
   1. Bir terminal açın, referans-uygulama kök dizinine gidin ve belgelenmiş başlatma komutunu kullanarak uygulamayı başlatın (referans uygulamada: cd langchain_pipeline ardından streamlit run app_v2.py).
   2. Uygulamanın http://localhost:8501 hızında yüklendiğini ve yan panel yapılandırma panelinin göründüğünü doğrulayın.
3. LLM sağlayıcısını yapılandırın.
   1. Yan panelin LLM Yapılandırma bölümünde bir LLM sağlayıcısı seçin, model adını girin ve geçerli bir uygulama programlama arayüzü (API) anahtarı ekleyin.
   2. Tedarikçisini, model adı, model versiyonunu, sıcaklığı, akıl yürütme ve çaba seçeneklerini ve Malzemeler Tablosu için erişim tarihini kaydedin.
      NOT. Referans uygulamada, tek-LLM IOC çıkarımı, Malzemeler Tablosu'nda belirtilen birincil ticari LLM'ye varsayılan olarak sıcaklık = 0.0 olur; regex üretimi varsayılan olarak sıcaklık = 0.3 olur.
4. Topluluk oylamayı etkinleştirin (isteğe bağlı ancak tekrarlanabilir sonuçlar için önerilir).
   1. Kenar çubuğundaki Topluluk Oylama seçeneğini etkinleştirerek yalnızca minimum oy eşiğini karşılayan IOC'ları (En Düşük Oy ≥ 2 önerilen) tutun.
   2. Sağlayıcı, model adı, API anahtarı ve model başına uygulama tekrarı sayısını belirterek ek LLM örnekleri ekleyin.
      1. Her sağlayıcının tekrar sayısını ve seçilen asgari oy eşiğini kaydedin.
         NOT. Topluluk oylaması isteğe bağlıdır. Devre dışı bırakıldığında, boru hattı tekli LLM çıkarımı gerçekleştirir ve konsensus filtresi atlanır. Varsayılan topluluk ayarları tekrarlar = her yapılandırılmış model başına 1 ve min_votes = 2 olmasıdır.
5. Neo4j'ye bağlanın.
   1. Yan çubuğunun Neo4j Bağlantı bölümünde bağlantı URI'sini (örneğin bolt://localhost:7687), kullanıcı adını ve şifreyi girin.
   2. Arayüzün başarılı bir bağlantı raporu verdiğini doğrulayın. Aktif bağlantı olmadan devam etmeyin.
6. Tüm kimlik bilgilerini güvence altına alın.
   1. LLM API anahtarlarını ve Neo4j şifresini hassas kimlik bilgileri olarak kabul edin. Bunları kaynak dosyalarda, dışa aktarılan raporlarda veya ekran görüntülerinde değil, ortam değişkenlerinde veya sır yöneticisinde saklayın ve sızıntı şüphesi varsa herhangi bir anahtarı hemen döndürün.
      NOT. Bu yazılım protokolü, kimyasal bir duman davlumucu, biyogüvenlik kabini veya diğer fiziksel muhafaza ekipmanı gerektirmez; Kurumsal veri güvenliği politikalarına uygun olarak gizli CTI raporlarını ve kimlik bilgilerini yönetin.

2. Aşama 1: Belge ayrıştırma

1. Prosedür.
   1. Ana arayüzdeki İşleme sekmesine gidin.
   2. Desteklenen bir formatta (.pdf, .docx, .md, .txt veya .html) bir CTI raporu yükleyin.
   3. Stage 1'i çalıştırmak için "Run Next Stage" tuşuna tıklayın veya tam pipeline'ı ardışık çalıştırmak için "Run All Stages" seçeneğine tıklayın.
2. 1. aşama kontrol noktasını onaylayın.
   1. Giriş belgesinin Markdown önizlemesinin görüntülendiğini doğrulayın.
   2. Dosya yollarının, kayıt kaydı anahtarlarının, komut satırı parçalarının ve bölüm sınırlarının önizlemede korunduğunu doğrulayın.
   3. Teknik dizileri kısaltılırsa veya biçimlendirme bırakılırsa, kaynak dosyayı düzeltin veya belgeyi harici bir dönüştürücüyle ön işleyerek yeniden yüklemenizi yapın.

3. Aşama 2: IOC çıkarımı

1. Prosedür.
   1. LLM yapılandırmasını (ve etkinse topluluk oylamayı) onaylayın.
   2. Aşama 2'yi çalıştırmak için "Sonraki Aşamayı Çalıştır" tuşuna tıklayın.
2. Aşama 2 kontrol noktasını onaylayın.
   1. Arayüzün, üç üst seviye anahtarla (Dosya Yolları, Komut Satırları ve Kayıt Anahtarları) içeren bir IOC koleksiyonunu JavaScript Nesne Gösterimi (JSON) formatında gösterdiğini doğrulayın.
   2. Topluluk oylama etkinleştirildiğinde, her tutulan IOC için oy sayımlarının ve katkı modeli meta verilerinin kaydedildiğini doğrulayın.
      NOT. Kelimesi kelimesine Aşama 2 sistemi ve insan istemleri, Aşama 5 oluşturma ve optimizasyon istemleriyle birlikte, Ek Dosya 1 (Supplemental_File_1_Prompts.txt) olarak yayımlanır.

4. Aşama 3: IOC analizi ve sınıflandırması

1. Prosedür.
   1. Aşama 3'ü çalıştırmak için "Bir Sonraki Aşamayı Çalıştır" tuşuna tıklayın.
2. Aşama 3 kontrol noktasını onaylayın.
   1. Her tutulan IOC'nin standart bir kategori, bir kaynak etiketi ve mevcut olduğunda orijinal çıkarma anahtarıyla listelendiğini doğrulayın.

5. Evre 4: Neo4j destekli IOC normalizasyonu

1. Prosedür.
   1. Neo4j bağlantısının aktif olduğunu doğrulayın.
   2. 4. Aşamayı çalıştırmak için "Bir Sonraki Aşamayı Çalıştır" tuşuna tıklayın.
   3. IOC başına normalizasyon çıktısını inceleyin ve yol ve komut satırı bileşenleri için saklama/atma etiketlerinin üretildiğini ve kayıt anahtarlarının bitişik kanonik bir alt dizim oluşturduğunu doğrulayın.
2. 4. aşama kontrol noktasını onaylayın.
   1. Her IOC tipi için normalize IOC tablolarının üretildiğini doğrulayın (dosya yolları, kayıt anahtarları, komut satırı göstergeleri).
   2. Her girişin orijinal değeri, normalleştirilmiş değeri ve 'sakla' veya 'at' etiketli element/durum çiftlerinden oluşan bir bileşen listesini içerdiğinden emin olun.
      NOT. Ayrıntılı Neo4j şeması, Cypher sorguları, karar kuralları ve kayıt anahtarı normalizasyon prosedürü Ek Dosya 2'de listelenmiştir; Örnek bir örnek Temsilci Sonuçlar'da verilmiştir.

6. 5. Aşama: regex üretimi ve puanlama

1. Prosedür.
   1. 5. Aşamayı çalıştırmak için "Sonraki Aşamayı Çalıştır" tuşuna tıklayın. Her normalize edilmiş IOC ve yasaklı token listesinin regex üretimi ve deterministik doğrulama için gönderildiğini doğrulayın.
   2. Bir aday doğrulamada başarısız olursa, uyumlu bir aday üretilene veya yineleme sınırına ulaşana kadar optimizasyon döngüsünün regex'i geliştirmesine izin verin.
   3. Son regexi uyumlu olandan en yüksek puanlı kısmi eşleşmeye (used_fallback = Doğru olarak kaydedilen) herhangi bir IOC için tanı çıktısını, optimizasyon geçmişini ve yineleme sayılarını inceleyin.
2. 5. Aşama kontrol noktasını onaylayın.
   1. Her tutulan IOC için nihai bir regex hazırlandığını doğrulayın.
   2. Aday puanlarının, optimizasyon geçmişlerinin, sorun listelerinin ve yineleme sayılarının kaydedildiğini doğrulayın.
   3. Tahmini token kullanımı ve gecikme dahil olmak üzere IOC başına telemetrinin kaydedildiğini doğrulayın.
      NOT. Ayrıntılı regex doğrulama kuralları, puanlama formülü ve yineleme-kontrol parametreleri Ek Dosya 2'de listelenmiştir.

7. Analitik ve doğrulama

1. IOC dağılımlarını, toplu-oy sonuçlarını (etkinleştirildiğinde), regex kalitesinde özetleri ve optimizasyon istatistiklerini incelemek için Analytics sekmesini açın. Bu özetleri, çıkarma dengesizliği veya tekrarlanan optimizasyon hataları gibi anormalileri tespit etmek için kullanın.

8. Sonuçları ihracat et

1. Export sekmesinde dışa aktarma formatını (düz metin, JSON veya YAML) seçin ve regex setini indirin. İxracat edilen regexlerin ilgili puanları ve kategorize meta verilerini içerdiğini doğrulayın.
2. Ayrıştırılmış belgeler, çıkarılmış İOk'lar, normalize temsiller, aday regexler ve nihai çıktıları içeren tam JSON raporunu oluşturun ve indirin. Bu raporu tekrarlanabilirlik kaydı olarak koruyun.

9. Sorun Giderme

1. Eğer Aşama 1 kısaltılmış veya boş PDF içeriği dönerse, belgeyi yeniden yüklemeden önce harici bir dönüştürücü veya optik karakter tanıma aracıyla ön işleyin ve teknik artefaktların Markdown önizlemesinde görünür kaldığını doğrulayın.
2. Eğer 2. Aşama çok az konuz birliği IOC dönerse, eşik değiştirmeden önce sağlayıcı, model, API anahtarı, tekrar sayım ve en az oy ayarlarını doğrulayın. Dışlanan adayları aşırı katı oy kullanmaktan ayırt etmek için dışlanmış adayları inceleyin.
3. Eğer 4. Aşama tüm bileşenleri atılmış olarak işaretlerse, Neo4j bağlantısını doğrulayın ve grafiğin analiz edilen IOC türü için ilgili Yol, Kayıt veya komut satırı arayüzü (CLI) kelime dağarcığını içerdiğini doğrulayın.
4. Eğer 5. Aşama derlenen ancak eşleşmede başarısız olan veya aşırı genelleştiren bir regex üretirse, adayı yeniden oluşturmadan önce optimizasyon geçmişi, tanı hata pozisyonu ve aşırı genelleme kontrollerini inceleyin.

10. Son protokol çıktılarını onaylayın.

1. Dışlanmış Markdown dosyasının, IOC kümesinin (toplu oylama etkinleştirildiğinde konsensusla doğrulanan, devre dışı bırakıldığında tek model), kategorize edilmiş IOC tablosunun ve grafik ile normalize edilmiş IOC temsillerinin hepsinin mevcut olduğunu doğrulayın.
2. SIEM uyumlu regex setinin, analitik özetlerin ve tam JSON raporunun hepsinin mevcut olduğunu doğrulayın ve JSON raporunu tekrarlanabilirlik kaydı olarak arşivleyin.

Sonuçlar

Bu bölüm, IOC'den regex'e protokol tarafından üretilen temsilli sonuçları sunar ve operasyonel uygulanabilirliğini değerlendirmek için kullanılan referans değerlendirmesini özetler. Referans değerlendirmesi, MITRE ATT&CK teknikleriyle ilişkili 3.156 CTI raporunu işledi, 230.000'den fazla cümleyi analiz etti, 63.000'den fazla IOC adayını çıkardı ve oluşturulan regexleri on MITRE ATT&CK Değerlendirme senaryosundan 2.400'den fazla bağımsız toplanmış yeraltı gerçeklik dizisiyle karşılaştırdı. Bu gerçek dizileri, MITRE ATT&CK Değerlendirme çalışmaları sırasında siber güvenlik tedarikçileri tarafından bağımsız olarak raporlanan uzmanlar tarafından hazırlanmış saldırı eserleridir ve bu nedenle insan analistler ve satıcıların uygulamada belgelediği yapısal kalıpları yansıtır. Aşağıdaki sonuçlar, iş akışı davranışı, yapısal doğruluk ve operasyonel log analizi ile tespit iş akışlarıyla ilgili değerlendirme sonuçlarına odaklanmaktadır.

Uçtan uca boru hattının genel bir özeti, temsil eden sonuçların geri kalanını çerçeveleyen yakalama grubu bulgusu ve regex üretim aşamalarını özetleyen Şekil 1'de sunulmaktadır.

Aşama 1: Belge Ayrıştırma Çıktısı

Şekil 2, giriş CTI raporunun birleşik bir Markdown temsiline dönüştürüldüğü Aşama 1'in çıktısını gösterir. Başarılı bir şekilde çalıştırıldığında, arayüz belgenin yapılandırılmış bir önizlemesini, bölüm sınırları ve alaka göstergelerini gösterir.

Doğru yürütme, tutarlı paragraf segmentasyonu ve dosya yolları, kayıt anahtarları ve komut satırı parçaları gibi teknik artefaktların korunmasıyla gösterilir. Bu aşamada aşırı kesinti veya biçimlendirme kaybı sonraki analizi etkileyebilir ve ilerlemeden önce ele alınmalıdır.

Aşama 2: Uzlaşmaya Dayalı IOC Çıkarımı

Şekil 3 , aday IOC'ların çoklu LLM toplu oylama kullanılarak çıkarıldığı Aşama 2'nin çıktısını göstermektedir. Ortaya çıkan arayüz, oy sayımları ve katkı modelleriyle notlandırılmış JSON formatlı bir IOC koleksiyonu sunar.

Yalnızca yapılandırılmış minimum uzlaşma eşiğini karşılayan IOC'ler korunur. Bu aşamada hariç tutulan Günlük Atlar genellikle modele özgü halüsinasyonları veya belirsiz metin parçalarını yansıtır. Dışlanmaları beklenen ve arzu edilen bir sonuçtur ve topluluk oylamanın doğru işlediğini gösterir.

Aşama 3: IOC Analizi ve Sınıflandırması

Tablo 2 , her protokol aşaması için beklenen çıktı, otomatik doğrulama adımları ve analistlerle yüzlü kalite kontrol kontrollerini özetler.

Şekil 4 , Aşama 2'de toplu oylama sırasında uzlaşma eşiğini karşılamayan IOC adaylarını ve arayüzün analist incelemesi için ortaya çıktığını göstermektedir. Bu tür adaylar genellikle modele özgü halüsinasyonlar veya belirsiz metin parçalarını yansıtır. Bu nedenle , Şekil 4 ve Şekil 5 , aynı Aşama 3 sürecinin alternatif görüşlerinden ziyade, Aşama 2'den atılmış set ve Aşama 3'ten tutulan set — farklı aşama çıktılarına karşılık gelir.

Şekil 5 , JSON ayrıştırma, kural tabanlı kategorize etme ve IOC duplikaliasyonu sonrası Aşama 3 tarafından üretilen tutulan IOC tablosunu sunmaktadır. Her tutulan IOC için, aşama standart bir kategori, kaynak etiketi ve mevcut olduğunda orijinal çıkarma anahtarını kaydeder, ardından IOC'yu aşağı akış normalizasyonuna geçirir.

Aşama 4: IOC Tipleri Arasında Grafik Destekli IOC Normalizasyonu

Şekil 6, Şekil 7 ve Şekil 8 , mevcut çalışmada ele alınan üç IOC kategorisi için temsil edici normalizasyon sonuçlarını göstermektedir: dosya yolları, kayıt anahtarları ve komut satırı göstergeleri. Her kategori için, figürler CTI raporundan çıkarılan orijinal IOC'yi, grafik destekli analiz kullanılarak üretilen normalize temsille karşılaştırır.

Tüm IOC türlerinde, protokol her IOC'yi anlamsal bileşenlere ayırır ve grafik veritabanında kodlanmış yapılandırılmış bilgi kullanarak hiyerarşik ilişkileri çözer. Mevcut uygulamada, Neo4j normalize Path, Registry ve CLI düğümlerini saklar ve bileşenlerin tanınan zincirlere ait olup olmadığını test etmek için bitişik ilişkiler kullanır. Bu rol, algılama^{mühendisliği 2} sırasında yapılandırılmış ATT&CK bilgisinin kullanımına benzer.

Önemli olarak, bu normalleştirme adımı, IOC bileşenleri için açıkça anlamsal rolleri kaydeder; bunları analiz kaydından sessizce çıkarmak yerine saklama veya atma olarak etiketler. Normalize edilmiş dizi esas olarak keep bileşenlerinden yeniden oluşturulurken, atma bileşenleri aşağı akış regex üretimi ve doğrulaması için meta veri olarak kullanılabilir kalır.

Bu aşamanın doğru yürütülmesi, anlamlı yapısal bağlamı koruyan ve farklı IOC tipleri arasında tutarlı yakalama-grup etiketlemesi sergileyen normalize edilmiş IOC'larla gösterilir. Orijinal ve normalleştirilmiş temsiller arasındaki görsel karşılaştırma, yakalama grubu çözünürlüğünün tutarlı ve istenmeyen bilgi kaybı olmadan uygulandığını doğrulamak için pratik bir kalite kontrol mekanizması sağlar.

5. Aşama: Yardımcı Kısıtlama Temelli Seçim ile Düzenli İfade Üretimi

Şekil 9 , protokolün normalize edilmiş İok'lardan yapısal olarak uyumlu düzenli ifadeleri iteratif doğrulama iş akışı aracılığıyla oluşturduğu Aşama 5'in çıktısını göstermektedir. Uygulama, ilk nesil istemi, bir aday IOC ile eşleşmediğinde tanı yeniden sorma, atma farkında doğrulama ve sınırlı yeniden deneme döngülerini birleştirir.

Normalize edilmiş bir IOC ve ona bağlı sakla/atma bileşeni spesifikasyonu verildiğinde, iş akışı önce bir regex adayı oluşturur. Aday daha sonra IOC ile test edilir, eşleşme başarısız olduğunda tanı yoluyla yeniden sorulur, yasak atılan tokenlar kontrol edilir ve rastgele negatif dizilerle aşırı genelleme açısından değerlendirilir.

Birden fazla aday temel doğrulama kontrollerini sağladığında, protokol temsilci bir regex'i aşağı akış kullanımı için korumak amacıyla yardımcı kısıtlama tabanlı bir seçim mekanizması uygular. Mevcut uygulama, adayları 'Puan = n_cg - n_wc' ile puanlar; burada 'n_cg' temsil edilen kalın bileşenlerinin sayısı, 'n_wc' ise regex'te bulunan atılmış veya eşlenmemiş token sayısıdır.

Seçim fonksiyonu şu şekilde tanımlanır:

Puan = n_cg − n_wc

Bu, daha genel form olan Score = α·n_cg − β·n_wc şeklinin eşit ağırlıklı uzmanlaşmasıdır (α = β = 1). Burada, n_cg temsil edilen keep bileşenlerinin sayısını, n_wc ise regex tarafından yeniden eklenen atılan bileşenler veya eşlenmemiş ekstra tokenların sayısını gösterir. Uygulama ayrıca her IOC için yineleme sayılarını, issue listlerini, tahmini token tüketimini, önbellek kullanımını ve gecikme telemetrisini kaydeder. Eşit ağırlık ayarı, referans uygulaması için basit bir deterministik varsayılan olarak kullanıldı; Eksik bir tutma bileşeni ile yeniden tanıtılan atma bileşenini eşit derecede istenmeyen olarak kabul ettiği için, yanlış negatif ve yanlış pozitiflerin farklı operasyonel maliyetler taşıdığı dağıtım bağlamlarında başka ağırlıklar tercih edilebilir.

Son regex, bu kısıtlamaları en iyi karşılayan aday olarak seçilir. Gerekli yakalama grubu bileşenlerini isteğe bağlı yapıların içine yerleştiren regexler, örneğin ( ... )?, anlamsal tutarlılığı zayıflattıkları için seçilmeden çıkarılır. Bu seçim adımı, üretim sürecine yardımcı niteliktir ve bağımsız bir kalite ölçütü olarak hizmet etmeyi amaçlamamıştır.

CTI İşlemesinin Analitik Genel Bakış

Şekil 10 , işlenen tüm belgeler boyunca CTI analiz sonuçlarına genel bir bakış sunar. Referans değerlendirmesinde, IOC çıkarımı 3.156 CTI raporu üzerinde 63.000'den fazla ADAY üretti; bunlar arasında 12.195 dosya yolu, 2.302 kayıt anahtarı ve 10.286 komut satırı göstergesi bulunmakta, kalan adaylar ise regex hedef olmayan IOC tiplerine aittir.

Bu sayımlar, çıkarılan göstergelerin mevcut protokolün hedeflediği üç IOC kategorisinde yoğunlaştığını yüksek düzeyde doğrularken, birçok çıkarılan artefaktın regex üretim kapsamı dışında kaldığını da gösterir. İş akışını yeniden oluştururken, işlenen CTI raporlarının tam sayısını, toplam IOC adaylarını, kategori bazında sayımları ve çıkarma sırasında kullanılan sağlayıcı, model, model versiyonu, sıcaklık, tekrar sayısı ve uzlaşma eşiğini raporlayın.

Referans değerlendirmesinde, oluşturulan regexler, on MITRE ATT&CK Değerlendirme senaryosundan 2.400'den fazla bağımsız toplanmış yeraltı gerçeklik dizisi karşılaştırıldığında değerlendirilmiş ve ortalama %99,1 isabet oranı ile %0,8 oranı çapraz IOC uyumsuzluk oranı elde edilmiştir. Bu makalede, uyumsuzluk oranı anlamsal özgüllük ölçüsü olarak kullanılır: uyumsuzluk, bir IOC için oluşturulan bir regex'in aynı zamanda farklı bir IOC ile ilişkili bir ground-truth dizisine de uyduğunda oluşur. Bu miktar, uçtan uca operasyonel uyarı yanlış pozitif oranı olarak yorumlanmamalıdır; bu oran da aşağı akış kural mantığı ve dağıtım bağlamına bağlıdır.

Bu dağılım, CTI korpusunun yapısal bileşimini yansıtır ve kullanıcıların çıkarılan göstergelerin beklenen IOC tipleriyle örtüştüğünü doğrulamalarını sağlar. Beklenen oranlardan büyük sapmalar, yukarı akış ayrıştırma veya çıkarma sorunlarını gösterebilir ve aşağı akış normalizasyonu ve regex üretimine geçmeden önce incelenmelidir.

Regex Optimizasyon İşlemlerinin Analizi

Şekil 11 , düzenli ifade üretimi ve iyileştirme sırasında gerçekleştirilen eylemleri özetlemektedir. Dağılım, üç tür eylem içerir: başlangıç regex üretimi, LLM tabanlı optimizasyon adımları ve yeniden deneme tabanlı yenileme.

LLM tabanlı optimizasyon, gözlemlenen tüm eylemlerin %51,7'sini oluşturuyor. Bu yaygınlık, yalnızca ilk üretimin genellikle yakalama grubu kısıtlamalarını ve dışlama gereksinimlerini karşılayan regexler üretmek için yeterli olmadığını gösterir. Bunun yerine, aday regexleri geliştirmek için yinelemeli optimizasyon aktif ve tekrar tekrar uygulanır.

Bu dağılım, verimsizliği yansıtmak yerine, optimizasyon iş akışının karmaşık IOC girdilerinden yapısal olarak uyumlu regexler üretirken protokolün gerekli ve ayrılmaz bir bileşeni olduğunu gösterir.

Ölçeklenebilirlik testi LLM ile oluşturulan rastgele 6.000 IOC örnekleminde ayrı bir ölçeklenebilirlik karakterizasyonu (bkz. Materyal Tablosu), IOC başına medyan gecikme 2,95 saniye ve ortalama 23,18 saniye olarak bildirilmiştir. Aynı karakterizasyonda, sözdizimi geçerli regex derlemesi %99,56'ya ulaştı, genel üretim başarısı %99,4'e ulaştı, ortalama tahmini token kullanımı IOC başına yaklaşık 3.986 token idi ve iş akışı ortalama olarak her IOC başına yaklaşık 7,89 LLM çağrısı gerektirdi. İlk geçiş başarı oranları eşleşme-hata ayıklama döngüsü için %56,46 ve yakalama dışı grup doğrulama döngüsü için %72,92 idi. Bu ölçümler, toplu kullanım için hesaplama maliyeti ve operasyonel verimliliği karakterize etmeye yardımcı olur.

Mevcut referans karakterizasyonunda model yeniden eğitimi için örneklenmiş çıktı alt kümesinin uzman incelemesi kullanılmamıştır; Bildirilen sonuçlar, otomatik boru hattı yürütmesini ve yukarıda açıklanan aşağı akış değerlendirme veri setlerini yansıtır.

Operasyonel kanıtlar ve arıza yönetimi. Şekil 12, protokol tarafından üretilen dışa aktarılan SIEM regex dosyasının yapısını ve temsilci dosya yolu, kayıt anahtarı ve komut satırı desenleri için kural düzeyinde doğrulama kanıtlarını göstermektedir. Şekil 13 , tüm aşama çıktılarını (çıkarılan, analiz edilen ve normalize edilmiş IOC'ler, oluşturulan regex desenleri ve her IOC doğrulama bayraklarıyla birlikte) ortaya çıkaran ve aletlerin tükettiği birincil artefaktı olan tam JSON raporunu gösterir. Şekil 14, protokolün gürültülü bir CTI girdisini nasıl ele aldığını gösterir: analiz aşamasında defingasyonlu, boşluk bozmuş bir dosya yolu işaretlenir, düzeltilir, kanonik %TEMP% şablonuna normalleştirilir ve ardından derleyici, eşleşen bir regex'e dönüştürülür. Bu çalışılmış örnek, Şekil 12 ve Şekil 13'teki operasyonel kanıtları, ham IOC metni kanonik biçimden ayrıldığında protokolün nasıl davrandığını belgeleyerek tamamlamaktadır.

Şekil 1: IOC'den regex'e protokolün genel mimarisi. Şekil, uçtan uca boru hattını özetlemektedir. Yukarı akış IOC çıkarıcısı tarafından üretilen aday IOC dizeleri, Windows dokümantasyonundan doldurulmuş bir Neo4j grafikindeki referans düğümleriyle (adım 1) karşılaştırılır; bu grafik bilinen yol, kayıt defteri ve komut satırı bileşenlerini (adım 2) alır. Değişken veya çevreye özgü parçalar, atılmış olarak etiketlenir ve normalleştirilmiş yeniden yapılandırmadan dışlanır, bileşen meta verilerinde korunur; böylece bileşen düzeyinde saklama ve atma etiketleriyle normalleştirilmiş bir IOC elde edilir (adım 3). Bu normalleştirilmiş OK'lar, daha sonra LLM tabanlı regex üretim aşamasına (4. adım) geçirilir; bu aşamada aday düzenli ifadeler üretilir; bu ifadeler puanlanır ve yakalama grubu kısıtlamalarına ve atılmış token kurallarına (5. adım) göre yineleme olarak optimize edilir, ardından nihai regex seçilir (adım 6). Bu figürün daha büyük bir versiyonunu görmek için lütfen buraya tıklayın.

Şekil 2: Aşama 1 belge ayrıştırma çıktısı. Orijinal CTI raporu ile ayrıştırılmış belge önizlemesinin yan yana karşılaştırılması. Sol panelde orijinal CTI raporu PDF formatında gösterilirken, sağ panel ayrıştırıcı tarafından oluşturulan birleşik Markdown temsili gösterilir. Bu figürün daha büyük bir versiyonunu görmek için lütfen buraya tıklayın.

Şekil 3: Multi-LLM topluluk oylaması kullanılarak uzlaşmaya dayalı IOC çıkarımı. Arayüz, topluluk tabanlı IOC çıkarma sürecini ve ara sonuçlarını göstermektedir. Kırmızı kutu, IOC çıkarımına katılan yapılandırılmış LLM örneklerini, seçilen sağlayıcıları ve her model için yapılan tekrarlanan çıkarma çalışmalarını vurgular. Mavi kutu, bir IOC'nin korunması için gereken minimum karşılaşma sayısını belirten kullanıcı tarafından tanımlanan uzlaşma eşiğini gösterir. Tüm modeller ve tekrarlar boyunca çıkarma sonuçları toplandıktan sonra, eşik değerinden daha az kez görünen aday IOC'ler atılır. Turuncu kutu, uzlaşma kriterini karşılayan ve sonraki analiz aşamalarına aktarılan son tutulan IOC setini gösterir. Bu figürün daha büyük bir versiyonunu görmek için lütfen buraya tıklayın.

Şekil 4: 2. Aşamada toplu oylamayla elenmiş IOC'lar. Toplu oy verme sırasında yapılandırılmış minimum oy eşiğini karşılamayan ve analist incelemesi için sunulan IOC adaylarının yan yana görünümü. Atılan adaylar genellikle modele özgü halüsinasyonlar veya belirsiz metin parçalarını yansıtır ve 3. aşama kategorilendirme aşamasına geçmez. Bu figürün daha büyük bir versiyonunu görmek için lütfen buraya tıklayın.

Şekil 5: Standartlaştırılmış sınıflandırmaya sahip Tutulan IOC seti. Aşama 3 işleminden sonra tutulan IOC adayları, standartlaştırılmış kategorileri, kaynak etiketleri ve mevcut olduğunda orijinal çıkarma anahtarlarıyla birlikte gösterilir. Bu tablo, normalizasyon aşamasında kullanılan yapılandırılmış IOC girdisini sağlar. Bu figürün daha büyük bir versiyonunu görmek için lütfen buraya tıklayın.

Şekil 6: Grafik destekli analiz kullanarak dosya yolu IOC normalizasyonu. Orijinal dosya yolu ioc'u ile normalleştirilmiş temsilinin yan yana karşılaştırılması. Grafik tabanlı geçiş, bilinen Yol bileşenlerini normalleştirilmiş adla sorgular ve her bileşeni keep or at olarak etiketler. Sürücü tanımlayıcıları ve değişken dosya adı parçaları, bileşen kaydında 'at' olarak işaretlenebilirken, normalleştirilmiş form esas olarak aşağı akış desen yapımında gerekli olan yapısal segmentlerden yeniden oluşturulur. Bu figürün daha büyük bir versiyonunu görmek için lütfen buraya tıklayın.

Şekil 7: Graf destekli analiz kullanarak kayıt anahtarı IOC normalizasyonu. Hiyerarşik kayıt yapılarının grafik destekli çözümlemesiyle bir kayıt anahtarı ioc'nin normalleştirilmesi. Kısaltılmış kök anahtarlar, kanonik kayıt kovanlarına genişletilir ve analizör, ana yer tutucuları, SID benzeri değerler ve GUID benzeri tokenları atlarken en uzun bitişik bilinen kayıt alt dizisini çıkarır. Çıktı, her tutulan bileşen için etiketleri tutar/atlar ve sonraki işlem için kanonik bir kayıt yolu oluşturur. Bu figürün daha büyük bir versiyonunu görmek için lütfen buraya tıklayın.

Şekil 8: Grafik destekli analiz kullanarak komut satırı OC normalizasyonu. Orijinal komut satırı IOC ile normalleştirilmiş temsilinin karşılaştırılması. Protokol, alıntılanan dizileri koruyarak komut satırını tokenize eder, mümkün olduğunda öncü komut belirtecesini Neo4j aramasıyla normalleştirir ve gömülü yol benzeri veya kayıt defterine benzer parçaları özyinelemeli olarak analiz eder. Kararlı komutla ilgili bileşenler keep olarak etiketlenir, değişken argümanları discard olarak etiketlenir ve nihai kanonik komut yapısı saklanan öğelerden yeniden oluşturulur. Bu figürün daha büyük bir versiyonunu görmek için lütfen buraya tıklayın.

Şekil 9: Düzenli ifade adaylarının kısıtlama tabanlı seçimi. Her normalize IOC için birden fazla regex adayı üretilir ve yinelemeli doğrulama iş akışı kullanılır. Belirlenmiş yakalama grubu bileşenlerini koruyan ve istenmeyen değişken alt dizileri sınırlayan nihai regex seçmek için kısıtlama odaklı puanlama mekanizması uygulanır. Bu figürün daha büyük bir versiyonunu görmek için lütfen buraya tıklayın.

Şekil 10: Çıkarılan IOC'ların CTI raporları arasında dağılışı. CTI raporlarından tanımlanan toplam gösterge sayısını ve dosya yolları, kayıt anahtarları ve komut satırı göstergeleri arasındaki dağılımlarını gösteren IOC çıkarma sonuçlarının özeti. Bu görüş, CTI içerik kapsamı ve çıkarma davranışının üst düzey doğruluğunu sağlar. Bu figürün daha büyük bir versiyonunu görmek için lütfen buraya tıklayın.

Şekil 11: Düzenli ifade üretimi sırasında optimizasyon eylemlerinin dağılımı. Regex üretimi sırasında gerçekleştirilen eylemlerin dağılımı; başlangıç üretimi, LLM tabanlı optimizasyon ve yeniden deneme tabanlı yenileme dahil. LLM odaklı optimizasyon, tüm eylemlerin %51,7'sini oluşturur ve bu da yinelemeli iyileştirmenin, yakalama grubu kısıtlamalarını karşılayan regexler üretmek için protokolün temel bir bileşeni olduğunu gösterir. Bu figürün daha büyük bir versiyonunu görmek için lütfen buraya tıklayın.

Şekil 12: Temsilci dışa aktarılan regex dosyası. Protokol tarafından oluşturulan SIEM regex ihracat (siem_rules.txt) örnek içerikleri. Her giriş, kaynak IOC'yi, çıkarılan kategoriyi (dosya yolu, kayıt anahtarı veya komut satırı) ve doğrulanmış regex desenini içerir. Eşlik eden doğrulama tablosu, beklenen davranışı ve her kural türü için doğruluğu doğrulamak için kullanılan sistem kanıtlarını özetler. Bu figürün daha büyük bir versiyonunu görmek için lütfen buraya tıklayın.

Şekil 13: Temsilci tam JSON raporu. Beş protokol aşamasının tamamını temsil eden bir CTI raporunda çalıştırdıktan sonra uçtan uca boru hattı çıktısı üretilir. JSON belgesi, kaynak dosyayı, ayrıştırılmış bölüm sayısını, kategoriye göre gruplanmış çıkarılmış IOC'leri, kaynak etiketli 3. aşama kategorize edilmiş kayıtları, 4. aşama normalizasyon farkını ve her bir OC doğrulama bayraklarıyla 5. aşama regex desenlerini kaydeder. Rapor ayrıca, kısmi arızaları tespit etmesini sağlayan üst düzey başarı ve hata meta verilerini ortaya koyuyor. Bu figürün daha büyük bir versiyonunu görmek için lütfen buraya tıklayın.

Şekil 14: Başarısız veya gürültülü giriş: tanımlama ve düzeltme. Protokolün gürültülü bir IOC'yi nasıl tanımlayıp kurtardığına dair çalışılmış bir örnek. Ham giriş %T E M P%\malware[.]EXE, ortam değişkeni belirteçesinde eklenmiş boşluklar içerdiği ve dosya uzantısı definj edildiği için işaretlenmiştir. Düzeltme adımı, eklenen boşlukları kaldırır ve kelime noktasını geri getirir; 4. aşama normalizasyonu %TEMP%'yi kanonik Windows Temp dizin şablonuna genişletir; ve Aşama 5, düzeltilmiş normalize edilmiş IOC'yi derleyen ve eşleştiren bir regex oluşturur. Bu örnek, Tartışmada tartışılan gürültülü giriş yönetimi sürecini göstermektedir. Bu figürün daha büyük bir versiyonunu görmek için lütfen buraya tıklayın.

Element	Tip	Değer / Şema	Örnek	Notlar
Düğüm etiketi	Plak Şirketi	:P ath	Windows, System32, cmd.exe	Windows dosya yolu bileşenlerini saklar
Düğüm etiketi	Plak Şirketi	:Kayıt	SOFTWARE, Microsoft, Windows NT	Kayıt anahtarı bileşenlerini kök kovanların altında saklar
Düğüm etiketi	Plak Şirketi	:CLI	powershell.exe, -ExecutionPolicy, Bypass	Komut tokenlarını ve parametreleri saklar
Düğüm özelliği	String	İsim	cmd.exe	Orijinal kılıf; normalleştirilmiş çıktıda görüntüleme için kullanılır
Düğüm özelliği	String	name_lower	cmd.exe	Küçük harfler; tüm MATCH sorguları için arama anahtarı olarak kullanıldı
İlişki	Yönlendirilmiş kenar	(a)-[:NEXT]->(b)	(Windows)-[:NEXT]->(System32)	Her iki uç nokta da aynı etiketi paylaşır; Windows sistemlerinde yerel bitişikliği kodlar
Kısıtlama	Benzersizlik	n.name_lower etiket başına UNIQUE	-	:P ath, :Registry, :CLI'ye uygulandı
Veri kaynağı	Kapsama	Windows 8, 10, 11	-	İstemci işletim sistemi grafik olarak doldurulmuş
Veri kaynağı	Kapsama	Windows Server 2012, 2016, 2019, 2022	-	Sunucu işletim sistemi grafik olarak doldurulmuş

Tablo 1: IOC normalizasyonu için kullanılan Neo4j grafik şeması (Aşama 4). Üç düğüm etiketini (Path, Registry, CLI), paylaşılan özellik şemasını (isim, name_lower), yerel sıralama kenarları için kullanılan yönlendirilmiş bitişik ilişkisini, benzersizlik kısıtlamalarını ve grafiği dolduran Windows istemci ve sunucu sürümlerini listeler.

Sahne	Beklenen çıktı	Otomatik doğrulama	Analistle görüşme kalite kontrolü
Aşama 1: Belge ayrıştırma	Birleşik Markdown metni, LLM işlemeden önce 4.000 karakter halinde parçalanmış.	—	Markdown önizlemesinin görsel olarak kontrol edilmesi; dosya yollarının, kayıt anahtarlarının, komut satırı parçalarının ve bölüm sınırlarının ayrıştırmaya dayanıp dayanıklı olup olmadığını doğrulamak; Teknik dizileri kestiriyorsa arka uçu değiştirin.
Aşama 2: IOC çıkarımı	Üç üst seviye anahtara sahip JSON (Dosya Yolları, Komut Satırları, Kayıt Anahtarları); IOC başına oy sayımları ve toplu oy kullanma etkinleştirildiğinde katkı modeli meta verileri.	Konsensus eşik filtresi (min_votes), oy sayısı ayarlanmış eşik altında olan IOC'leri hariç tutar.	Dışlanan adayların aşırı katı oy kullanmaktan halüsinasyonları ayırt etmek için incelemesi min_votes ayarlanır.
Aşama 3: IOC analizi ve sınıflandırması	Kategorize edilmiş IOC listesi: her IOC standartlaştırılmış bir kategori, kaynak etiketi ve mevcut olduğunda orijinal çıkarma anahtarı ile eşleştirilir.	Regex tabanlı kurallar ve IOC desen sezgileri yoluyla standartlaştırılmış kategori eşleme; (IOC, kategori) çift dedlikalisiyon.	Belirsiz veya gürültülü adaylar için kategorize edilmiş çıktıların nokta kontrolü (Şekil 4A).
Evre 4: Neo4j destekli normalizasyon	Bileşen düzeyinde saklama/at etiketleriyle IOC başına normalize edilmiş form.	Cypher, Windows referans grafiği üzerinden (i)-(iii) sorgular; Neo4j mevcut olmadığında deterministik ön işleme yedek geri dönüşü yapar.	Grafik kapsama boşluklarını belirlemek için tüm çöplerin gözden geçirilmesi; Gerekirse grafik verilerinin tedarikçi veya ortama özgü referanslarla genişletilmesi.
5. Aşama: Regex üretimi ve puanlama	IOC başına nihai regex, aday puanları, optimizasyon geçmişi, yineleme sayıları ve IOC başına telemetri.	Eşleşme testi, statik kalite kontrolleri, sınır farkında yasaklı token kontrolü, 5 deterministik negatif örnekle aşırı genelleme testi; en yüksek skorlu kısmi maça (used_fallback bayrağı) geri dönüş.	Yedek regexler için optimizasyon geçmişi incelemesi; Yeniden oluşturulmadan önce her IOC arıza pozisyonu tanı incelemesi.

Tablo 2: Aşama çıktısı ve doğrulama özeti. Her protokol aşamasını (1–5) beklenen artefaktına, pipeline tarafından üretilen otomatik doğrulama kanıtlarına (regex derleme durumu, isabet oranı, IOC arası uyumsuzluk oranı, optimizasyon yineleme sayıları) ve ilgili analist tarafından hazırlanan kalite kontrol kontrolüne (görsel karşılaştırma, atılan adayların incelenmesi ve kategori incelemesi) eşler.

Ek Dosya 1: Kelimesi kelimesine LLM uyarıları. Aşama 2 IOC çıkarımı ve 5. Aşama regex üretimi ve optimizasyonu için kullanılan kelimesi kelimesine sistem ve insan istemleri. Bu dosyayı indirmek için lütfen buraya tıklayın.

Ek Dosya 2: 4. ve 5. Aşamalar için uygulama detayları. Aşama 4 grafik destekli IOC normalizasyonunu ve 5. Aşama regex doğrulama, puanlama ve yineleme kontrolünü destekleyen algoritmik ve uygulama detayları. Bu dosyayı indirmek için lütfen buraya tıklayın.

Tartışma

Yapılandırılmamış CTI raporlarını yürütülebilir algılama mantığına çevirmek, operasyonel güvenlik iş akışlarında zaman alıcı ve hata riski taşıyan bir görev olmaya devam etmektedir. Önceki çalışmalar, IOC çıkarımı veya yüksek seviyeli kural oluşturma düzeyinde otomasyonu araştırmış olsa da, uygulayıcılar çıkarılan IOC dizilerini yapısal olarak doğru, anlamsal olarak hassas ve sonraki SIEM kullanımı için uygun regexlere dönüştürmede hâlâ önemli zorluklarla karşı karşıyadır. Burada sunulan protokol, her aşamanın iyi tanımlanmış ara eser oluşturduğu ve sonuçları bir sonraki aşamaya geçirmeden önce açık doğrulama uyguladığı aşamalı bir iş akışı aracılığıyla bu boşluğu kapatır. Şekil 14 , defingen, boşluk bozmuş bir dosya yolunun tanımlandığı, düzeltildiği, normalleştirildiği ve derleme regexine dönüştürüldüğü bir durumu belgeler; Protokolün gürültülü giriş yönetimi ve mevcut kapsamı, aşağıda listelenen sınırlamalarla birlikte tartışılır.

Bu protokolün temel katkılarından biri, iş akışının incelenebilir ara çıktılarla aşamalara açıkça ayrılmasıdır. Uygulama artık somut şekilde tanımlanmıştır: belge ayrıştırma, LLM işleme için Markdown ve parçalanmış metin üretir; IOC çıkarımı, dosya yolları, kayıt kaydı anahtarları ve komut satırı göstergeleri için yapılandırılmış JSON yayar; kural tabanlı IOC analizi, çıkarılan değerleri standartlaştırır ve deduplicate eder; Neo4j destekli normalizasyon, her IOC bileşenini sakla veya atma olarak etiketler; Regex üretimi, aday seçiminden önce eşleşme hata ayıklama, iptal doğrulama ve aşırı genelleme kontrolleri uygular.

Protokol, düzenli ifade üretimini tek bir tahmin problemi olarak değil, yinelemeli bir yapı görevi olarak ele alır. Uygulama, yapısal olarak önemli IOC öğelerini korumak için ilk nesil promptu, otomatik eşleşme teşhisi, sınırlı iyileştirme döngüleri ve bileşen tabanlı puanlama fonksiyonu kullanarak yapısal olarak önemli olan IOC öğelerini koruyor, atılmış veya haritalanmamış alt dizileri cezalandırır. Bu yinelemeli tasarım, her adımda uygulanan deterministik validatörlerle birlikte, büyük ve heterojen bir değerlendirme seti boyunca yapısal olarak sadık kalan regex desenlerinin üretilmesini destekler. Referans değerlendirmesinde, bu iş akışı 3.156 CTI raporuna uygulandı ve 2.400'den fazla bağımsız gerçek dizisine karşı değerlendirildi; ortalama isabet oranı %99,1 ve ortalama çapraz IOC uyumsuzluk oranı %0,8 oldu. Bu gerçek dizileri, MITRE ATT&CK Değerlendirme çalışmaları sırasında siber güvenlik tedarikçileri tarafından raporlanan uzmanlar tarafından oluşturulmuş eserler olduğundan, bu değerlendirme protokolün çıktısını otomatik olarak oluşturulan desenlerle değil, insan analistler tarafından belgelenen YOK desenleriyle örtük olarak karşılaştırır.

Temsilci sonuçlarda gösterildiği gibi, iş akışı iç içe dosya yolları veya uzun komut satırı dizileri gibi karmaşık IOC yapılarını işlediğinde yinelemeli optimizasyon özellikle önemlidir. Referans değerlendirme sonuçları ayrıca, en yaygın eşleşmeyen vakaların, saldırganların grafik veritabanında temsil edilmeyen veya kaynak CTI raporlarında açıkça belgelenmemiş özel yürütülebilir dosyalar veya parametreler kullandıklarında meydana geldiğini gösterir. Operasyonel kullanımda, bu arıza modları sessiz hatalar yerine beklenen sınır koşulları olarak ele alınmalı ve grafik kapsamının, kaynak-raporun tamlığının ve regex-hata hata ayıklama telemetrisinin gözden geçirilmesini tetiklemelidir.

Protokol, üç alternatif yöntem ailesiyle karşılaştırılabilir. İlk olarak, TransRegex¹¹ ve Regex+¹² gibi örnek tabanlı regex sentezi yöntemleri, pozitif ve negatif dizi örneklerinden seçilmiş regeks setlerinden öğrenir. Bu yöntemler, temsil örnek setleri mevcut olduğunda iyi performans gösterir ancak CTI'da bildirilen her IOC genellikle tek bir temsilci dizi olarak görünür ve gerekli genelleştirme sınırı örnek kapsamı yerine operasyonel anlam sistemiyle belirlenir. İkinci olarak, Bartoli ve ^ark.13,14 tarafından tanıtılan genetik programlama yaklaşımları, regexlerin uzayını evrimsel operatörler aracılığıyla arar ve genellikle eşleşen ve eşleşmeyen dizilerle etiketlenmiş bir korpus gerektirir; çıkarma desenlerinin toplu oluşturulması için oldukça uygundurlar ancak doğrudan yapılandırılmamış CTI anlatılarını tüketmezler. Üçüncüsü, son zamanlarda sinirsel ve LLM tabanlı^{yaklaşımlar 15,16} doğal dil tanımlarını doğrudan regex dizilerine çevirir; bu yöntemler iyi belirlenmiş istemler için güçlüdür ancak tek atış kullanımında, sözdizimsel olarak geçerli olan ancak gerekli yakalama grubu bileşenlerini kaçıran veya ilişkisiz IOC varyantları arasında aşırı genelleştirici regexler üretebilir. Mevcut protokol, bu yönertmeleri (i) seçilmiş örnek setleri veya doğal dil sorguları yerine yapılandırılmamış CTI raporlarını girdi olarak alarak, (ii) herhangi bir regex oluşturulmadan önce her IOC'yu grafik destekli normalizasyon yoluyla keep ve dist bileşenlerine ayırarak ve (iii) her aday regex'i deterministik eşleşme, atma ve aşırı genelleştirme kontrolleriyle sınırlı bir yineleme döngüsü içinde doğrulayarak tamamlamaktadır. Amaç, kendi kıyaslamalarında önceki yöntemleri geride bırakmak değil, ara kararlarının SOC analistleri tarafından denetlenebilir ve denetlenebilir bir şekilde tekrarlanabilir bir IOC'den regex'e boru hattı sağlamaktır.

Protokol, giriş CTI raporlarının kalitesi hakkında çeşitli varsayımlarda bulunur. (i) IOC dizileri belge ayrıştırmadan sonra kurtarılabilir metin biçiminde göründüğünü, yani dosya yolları, kayıt anahtarları ve komut satırı göstergelerinin yalnızca görsellere, ekran görüntülerine veya gizlenmiş kodlamalara gömülü olmadığını varsayar; (ii) CTI'da bildirilen IOC parçaları, yapısal çapaklarını koruyacak kadar eksiktir (örneğin, kayıt anahtarları hive öneklerini korur, dosya yolları Windows dokümantasyon grafiğine göre tanınabilir en az bir dizin ankrajını korur ve komut satırları çağrılan çalıştırılabilir dosyayı veya bilinen bir modül referansını korur); ve (iii) bildirilen IOC'ler, protokolün dayandığı yakalama grubu bileşenlerini kaldıracak şekilde kısaltılmamış, sansürlenmemiş veya yeniden yazılmamıştır. Bu varsayımları karşılayan CTI raporları arasında çoğu MITRE ATT&CK teknik tanımı, tedarikçi tavsiyeleri, olay-yanıt yazıları ve iyi biçimlendirilmiş tehdit bültenleri bulunur. Öncelikle ekran görüntülerine dayanan, çevresindeki bağlamdan yoksun çok kısaltılmış IOC listeleri veya açık IOC dizileri olmayan serbest metin paraphrase'leri amaçlanan işletim zafının dışında kalır ve daha az çıkarma hatırlaması ve daha az sadık normalleştirme üretmesi beklenmelidir; Bu tür raporlar, pipeline girmeden önce yukarı akış görüntü-metne ön işleme veya analist incelemesinden fayda görebilir.

Bu protokol uygulanırken birkaç sınırlama göz önünde bulundurulmalıdır. İlk olarak, mevcut uygulama dosya yolları, kayıt defteri anahtarları ve komut satırı göstergelerine odaklanıyor; daha geniş IOC kategorileri gibi alan adları, e-posta eserleri, kullanıcı-ajanı dizileri veya davranışsal dizileri gibi konulara değil. Bu, kasıtlı bir kapsam seçimidir, çünkü atomik göstergeler genellikle tam eşleşme iş akışlarıyla iyi hizmet verir ve mevcut protokol, regex genellemesinden faydalanan değişken yapılı IOC'leri hedeflemektedir; yine de, grafikte şu anda temsil edilmeyen IOC türlerine uygulanabilirliği sınırlar. İkinci olarak, mevcut arıza senaryoları üç ana kategoriye ayrılır: işletim sistemi grafiğinde olmayan yerel olmayan yollar veya komut satırı argümanları, ilgili yardımcı araçlar veya yapılar için eksik grafik kapsamı ve önemli komut parçaları veya cmdlet'ler hiç bildirilmediğinde CTI kaynağında eksiklik. Üçüncüsü, referans değerlendirmesinde kullanılan çapraz IOC uyumsuzluk metriği, konuşlandırılmış SIEM mantığı altında uçtan uca uyarı yanlış pozitifleri yerine üretilen regexlerin anlamsal özgüllüğünü ölçer.

LLM değişkenliği ve versiyonlama altında tekrarlanabilirlik. IOC çıkarma ve regex üretim aşamaları ticari LLM uç noktalarına bağlı olduğundan, tekrarlanabilirliği etkileyen iki değişkenlik kaynağı: sağlayıcı tarafı model güncellemeleri zamanla ve çağrı başına örnekleme stoklastikası. İlkini azaltmak için, Malzemeler Tablosu'ndaki tüm LLM ile ilgili alanlar referans değerlendirmesinde kullanılan model tanımlayıcılarını ve erişim tarihini kaydeder ve protokol, sağlayıcı bir model anlık görüntüsü açıkladığında sabitlenmesini önerir. İkincisini hafifletmek için, referans uygulama IOC-çıkarma sıcaklığını 0.0'da sabitler ve sıfır olmayan sıcaklığı yalnızca regex üretim aşamasında kullanır; burada 2. ve 5. Aşamalardaki topluluk oylama ve deterministik validatörler kalıntı varyasyonu emer. Bu sonuçları tekrarlarken, kullanıcılar tam model versiyonunu, erişim tarihini, sıcaklığını ve kullanılan toplu oy eşiğini kaydetmelidir; Bu eksenlerin herhangi birinde önemli sapmaların isabet oranı ve uyumsuzluk metriklerini değiştirmesi beklenmelidir.

Birkaç kurtarılabilir arıza modu, bunları üreten aşamanın seviyesinde ele alınabilir. Aşama 1 ayrıştırma hataları (örneğin, taranmış PDF'lerin boş veya bozuk Markdown üretmesi): girişi optik karakter tanıma veya harici bir dönüştürücü ile önceden işleyerek yeniden yükleme; Devam etmeden önce ayrıştırılmış bölüm sayısının ve toplam karakter sayısının sıfır olmadığını doğrulayın. Aşama 2 çıkarma başarısızlıkları (IOC geri dönmemesi veya halüsinasyon girişleri): topluluk oy eşiğini artırmak (Minimum Oy 2≥ artırın), ek model örneklerini etkinleştirin veya LLM sıcaklığını düşürün; API bağlantısını ve yapılandırılmış modelin JSON formatlı çıktıyı kabul ettiğini doğrulayın. Tüm atma etiketleriyle 4. aşama normalizasyonu (her IOC bileşeni atma olarak etiketlenir): Neo4j referans grafiğini tedarikçi veya çevreye özgü yol bileşenleri ve kayıt kökleriyle genişletmek; Cypher içe aktarma betikleri ve saklama/atma kararı kuralı Ek Dosya 2'de listelenmiştir. 5. aşama regex hataları (used_fallback = doğru, veya tekrarlanan atma-doğrulama reddedilmeleri): başarısız doğrulayıcıyı belirlemek için IOC başına optimizasyon geçmişi alanını inceleyin; IOC gerçekten stabil tutma bileşenlerinden yoksunsa, o IOC için manuel regex yazmayı veya otomatik kural oluşturmadan çıkarıp analist incelemesi için kategorize edilmiş IOC tablosunda tutmayı düşünün.

Yukarıdaki sınırlamalarla tutarlı olarak, üretilen regexler, kendi kendine yeten dedektörler olarak değil, daha geniş SOC tespit içeriğinde yeniden kullanılabilir arama ilkeleri olarak ele alınmalıdır. Operasyonel ortamlarda, analistler bunları platforma özgü alan mantığı, beyaz listeler, kaynak kontrolleri veya korelasyon koşullarıyla birleştirerek alışılmadık ama kötü niyetli olmayan yollardan kaynaklanan zararlı eşleşmeleri bastırabilirler.

Gelecekteki çalışmalar, insan tarafından yazılmış regexlerle sistematik karşılaştırma, ek IOC kategorilerinde daha geniş değerlendirme, yapılandırılmış analist-geri bildirim çalışmaları, saldırgan tarafından oluşturulan yardımcı programlar ve komutlar için genişletilmiş grafik kapsamı ve dağıtım ayarlarında uçtan uca gecikme ve maliyetin daha kapsamlı raporlanmasını içerebilir. Buna rağmen, mevcut protokol, IOC'den regex'e çevirisi için hem güçlü yönlerini hem de mevcut sınırlarını belgeleyen tekrarlanabilir ve operasyonel olarak yorumlanabilir bir çerçeve sağlar.

Malzemeler

Bu makalede kullanılan malzemelerin listesi

Ad	Şirket	Katalog numarası	Yorumlar
Computer (CPU)	—	≥ 4 çekirdek önerilir	GPU gerekmez
LangChain	LangChain	≥ 0.1.x	LLM orkestrasyon çerçevesi
LLM (IOC çıkarma, tek model)	OpenAI	gpt-5.1	Ensemble oylaması devre dışı bırakıldığında IOC çıkarma (Aşama 2) için kullanılır. temperature = 0.0; max_workers = 5. Erişim: 2025-12-15.
LLM (Regex oluşturma)	OpenAI	gpt-5.1	Regex oluşturma (Aşama 5) için kullanılır. Aşağı yönlü doğrulama öncesi temperature = 0.3. Erişim: 2025-12-15.
LLM (Ölçeklenebilirlik karakterizasyonu)	OpenAI	gpt-5.1	Temsili Sonuçlarda bildirilen 6.000-IOC ölçeklenebilirlik çalıştırması için kullanılır. Erişim: 2025-12-15.
Bellek (RAM)	—	≥ 16 GB önerilir	Belge işleme için gerekli
Neo4j	Neo4j, Inc.	≥ 5.x	IOC normalizasyonu için grafik veritabanı
Neo4j Python Sürücüsü	Neo4j, Inc.	≥ 5.x	Neo4j için Python arayüzü
İşletim Sistemi	Microsoft / Apple / Linux	Windows, macOS veya Linux	Çoklu platform desteği
PDF ayrıştırma — birincil arka uç	Microsoft	MarkItDown ≥ 0.0.x	Aşama 1 arka ucu; PDF/DOCX/HTML/TXT girdilerini Markdown'a dönüştürür. LLM işlemeden önce 4.000 karakterde parçalanmış çıktı. Erişim: 2025-12-15. https://github.com/microsoft/markitdown
Boru hattı yapılandırması (Aşama 2 — IOC çıkarma)	—	Referans varsayılanları	Tek-LLM modu: temperature = 0.0, max_workers = 5. Ensemble oylama modu varsayılanları: yapılandırılmış model başına tekrarlar = 1, min_votes = 2.
Boru hattı yapılandırması (Aşama 5 — regex oluşturma)	—	Referans varsayılanları	Oluşturma sıcaklığı = 0.3. Doğrulama: IOC başına overgen_random_tests = 5 belirlenmiş olumsuz örnek. Döngü sınırları: max_iterations = 10, debug_loop_cap = 5, discard_validation_cap = 5.
Python	Python Software Foundation	≥ 3.8	Gerekli çalışma zamanı ortamı
Regex Motoru	Python Standart Kütüphanesi	re modülü	Regex doğrulama ve test için kullanılır
Streamlit	Streamlit Inc.	≥ 1.25	Web tabanlı kullanıcı arayüzü
Referans uygulama kaynak kodu	Yazarlar / GitHub | GitHub deposu		Streamlit arayüzü, LangChain boru hattı, Neo4j destekli normalizasyon, regex oluşturma, doğrulama yardımcı programları ve örnek yapılandırma dosyaları için kaynak kod. Erişim: 11 Haziran 2026.