False positive alarmlar için filtre üretimi: algoritmadan LLM’e

Kaspersky, false positive güvenlik alarmları için filtre üretimi sürecini otomatikleştiren üç yaklaşımı karşılaştırdı. Saf algoritmayla başlayan çalışma, tek system prompt’lu bir LLM’e ve dört agent’lı bir zincire kadar uzandı. İki LLM yaklaşımı neredeyse aynı sonucu verince ekip daha basit ve hızlı olan tek prompt’lu modeli seçti. Şirkete göre false positive’ler yüzde 99 azaldı, günlük üretilen filtre sayısı yüzde 28 arttı.

Filtre üretimi neden elle yorucu

Bir false positive için doğru filtre yazmak birkaç adım ister. Logu okursunuz, aktivitenin kaynağını bulursunuz, sınırı çizersiniz, kuralı yazarsınız. Sonra filtrenin dayanıklı olup olmadığını kontrol edersiniz. Olay başına ortalama 400 civarı alan varken bu iş analistin gününü yiyor.

Yazının en işe yarar kısmı “geçerli filtre” tanımı. Kuralın tetiklenen parçası belli bir olay kümesini yakalar; yazı buna bağlam diyor. İyi filtre bu bağlamı mümkünse tamamen kapsar, dışına taşmaz. Yalnızca PowerShell’e bakan filtre çok geniş kalır. Tek bir olay ID’sine bakan filtre ise bir daha görülmeyecek tek bir olayı susturur.

Bir tuzak daha var. Filtre tespit kuralının sorgusunu birebir kopyalarsa kuralı fiilen kapatır. Çözüm, filtrede kuralın kullandığı alanları dışarıda bırakmak ya da dosya yolunun kuralın bakmadığı bir parçasını kullanmak.

Algoritmik yol: FP-Growth ve bağlam

İlk sürümde jeneratör alarmı ve onu tetikleyen kuralı alıyor, bağlamı çıkarıyor, gereksiz alanları eliyor, string’leri normalize ediyor. Kombinasyonları FP-Growth (frequent pattern growth) ile üretiyor. Algoritma yeterince sık görülmeyen öğeleri ağaçtan atıyor, böylece denenecek kombinasyon sayısı düşüyor. Analiste en iyi üç aday gidiyor.

Bu yolun artısı deterministik olması: aynı alarm hep aynı sonucu verir. Bir alanın neden aday listesine girmediğini görebilirsiniz. Dış bağımlılık ya da model yok, yani izole bir ağa da kurulabiliyor.

Zayıf noktası bağlam. Kural ilk kez tetiklendiyse elde benzer olay yok, filtre de çıkmıyor. Normalizasyon kuralları da her dosya yolu varyasyonunu yakalamıyor. Bazı istisnalar birbiriyle çeliştiği için kural olarak hiç yazılamıyor.

LLM’e geçince kaybolan adım: doğrulama

LLM ile filtre üretimi bağlam ihtiyacını ortadan kaldırıyor. Model kombinasyon taramıyor; olayı, seçilen alanları ve kuralı okuyup doğrudan aday yazıyor. Normalizasyonda da daha esnek. Ekip alan seçimini yine algoritmaya bırakmış, çünkü o adım hatasız çalışıyordu. Taşınabilir ders şu: deterministik çalışan bir adımı modele vermenin getirisi yok, yalnızca tutarsızlık ekler.

Bedel de yazıda açıkça geçiyor. Tek istekli modelde çıktı doğrulaması yok, filtreler sözdizimi kontrolünden geçmeden geliyor. Bütün işi tek bir system prompt taşıdığı için bir yerdeki küçük düzeltme başka bir yerin mantığını bozabiliyor.

Örneklere bakın. İki yöntemde de üç adaydan biri fazla genişti. LLM’in önerdiği filecmdline: "kafka*" tek başına adında kafka geçen her komutu susturur. Bu tasarımda son kararı analist veriyor; filtreler otomatik uygulanmıyor.

Agent zinciri neden seçilmedi

Dört agent’lı sürüm (Selector, Generator, Validator, Commentator) tam bu eksiği kapatıyor. Validator geçersiz filtreyi Generator’a geri gönderiyor, alanlar yanlışsa seçimi baştan başlatıyor. Ama LLM çağrısı arttığı için sistem yavaşlıyor ve modele erişim şart. Metriklerde tek prompt’lu LLM ile neredeyse aynı çıkınca ekip basit olanı seçmiş.

Kendi SOC’unuzda nereden başlanır

• Kapatılan false positive alarmları kural bazında sayın. Bağlamı birikmiş kurallar algoritmik yaklaşım için hazır aday.
• String normalizasyonunu modelden bağımsız yazın. Sürücü harfini ve kullanıcı klasörünü ortam değişkenine çevirmek, yolu tek harf büyüklüğüne indirmek ucuz ve tekrarlanabilir bir iş.
• Kuralın kullandığı alanları filtreden otomatik çıkaran bir kontrol ekleyin. Kuralı kör eden filtreler bu kontrolde takılır.
• LLM kullanacaksanız tek prompt ile başlayın. Çıktıyı SIEM (Security Information and Event Management) sorgu ayrıştırıcınızdan geçirmeden analiste göstermeyin. Validator agent’ının işinin bir kısmını bu ucuz kontrol görür.
• Otomatik filtre üretimi çıktısını kod gibi yönetin: sürüm kontrolünde tutun, onaylayanı ve gerekçeyi kaydedin. LLM’in ürettiği açıklama bu kayda doğrudan girebilir.
• Model erişimi olmayan izole ortamda algoritmik yolda kalın. Yazıya göre bu yol vakaların üçte ikisinde analisti tatmin eden filtre üretiyor.

Rakamları okurken

Ölçüm iki metrikle yapılıyor: onay oranı ve false positive düşüşü (FP drop). Onay oranı, üç adaydan en az biri seçildiyse üretimi başarılı sayıyor. Yani diğer iki aday kötü olsa da sonuç başarılı görünür.

FP drop ise ancak zaman içinde ölçülebiliyor. Filtre devreye girmeden önceki ve sonraki eşit süreler karşılaştırılıyor. Yüzde 99’luk düşüşün hangi alarm kümesi ve hangi süre üzerinde ölçüldüğü metinde yazmıyor.

Kendi ortamınızda bu sayıyı kural bazında, eşit zaman pencereleriyle hesaplayın. Filtrelenen olaylardan düzenli örnek çekip içine gerçek bir olayın sızıp sızmadığına bakın. FP drop bu sızıntıyı göstermez.