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ı...

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...

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.