Sigma kuralını sorguya çevirmek

SPL bir kuralı yalnız Splunk'ta çalıştırır, KQL yalnız Microsoft ürünlerinde. Altay Kargo'nun SOC ekibi iki aracı birlikte kullanıyor. Merkez ofisin sunucu kayıtları Splunk'ta, bulut kimlik kayıtları Sentinel'de duruyor. Her kuralı iki dilde ayrı ayrı yazmak hem zaman kaybettirir hem de iki sürümün zamanla ayrışmasına yol açar.

Sigma bu sorunu çözer. Sigma, aracı belirtmeyen ve YAML dosyası olarak yazılan bir kural biçimidir; sonradan istenen sorgu diline çevrilir. Bu derste önce bir Sigma kuralını okuyacaksın. Sonra onu sigma-cli ile iki dile çevirecek, alan eşleme hatasını bulacak ve kuralı canlıya almadan önce nasıl sınayacağını göreceksin.

Bir Sigma kuralı birkaç temel alan taşır. title kuralın adıdır, id ise değişmeyen ve benzersiz bir UUID'dir. status kuralın olgunluğunu söyler.

logsource verinin nereden geldiğini tarif eder. detection aranan koşulu taşır. falsepositives bilinen yanlış pozitif nedenlerini listeler, level ise önem derecesidir.

tags alanına attack.t1110 gibi MITRE ATT&CK etiketleri yazılır. Ekip bu etiketlerden hangi tekniği kapsadığını, hangisinin boş kaldığını çıkarır. logsource üç alt alanla yazılır: category, product ve service. Örneğin product: windows ve service: security birlikte Windows Security günlüğünü işaret eder.

title: Windows Hesabında Başarısız Oturum Açma
id: 8f2a1e40-889b-4b7a-9d2e-2f7c9a410099
status: experimental
description: Windows Security günlüğündeki başarısız oturum açma olaylarını yakalar
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4625
  condition: selection
falsepositives:
  - Parolasını unutan kullanıcının art arda hatalı girişi
tags:
  - attack.t1110
level: medium

Kuralı yukarıdan aşağı oku. logsource Windows Security günlüğünü seçer. detection altındaki selection, EventID değeri 4625 olan olayları tarif eder.

4625, Windows'un başarısız oturum açma olayıdır. condition: selection kararı verir: seçim sağlanıyorsa kural eşleşir. falsepositives satırı, analiste bu kuralın en sık nerede yanılacağını önceden söyler.

status: experimental, kuralın sahada henüz yeterince sınanmadığını belirtir. Bu kural tek başına hiçbir sorguyu çalıştırmaz. Yalnız aranan koşulu tarif eder; çalışan bir sorgu için çeviri gerekir.

Kuralın üst bilgisi de önemlidir. description kuralın neyi neden aradığını bir iki cümleyle anlatır. references kuralın dayandığı raporu ya da teknik yazıyı gösterir.

author ve date kimin, ne zaman yazdığını, modified ise son değişikliği tutar. level beş değer alır: informational, low, medium, high ve critical. Bu değer, alarmın kuyruğa hangi öncelikle gireceğini belirler.

4625 gibi gürültülü bir olayı tek başına arayan kural medium ya da daha düşük kalmalıdır. Kesin bir saldırı izini arayan kural ise high ya da critical olabilir. Seviyeyi şişirmek, analistin gerçek alarmı gürültüden ayırmasını zorlaştırır.

Çeviriyi pySigma kütüphanesi yapar, sigma-cli ise onun komut satırı arayüzüdür. Çeviri üç aşamadan geçer. Önce kural okunur ve doğrulanır. Sonra işlem hattı (pipeline) devreye girer.

İşlem hattı alan adlarını hedef ortama göre değiştirir ve logsource'u gerçek bir kaynağa ya da tabloya bağlar. En sonda backend, dönüşmüş kuralı hedef dilin söz dizimiyle yazar. Splunk backend'i SPL, Kusto backend'i KQL üretir.

Backend'ler ve işlem hatları eklenti olarak kurulur. sigma plugin list kurulabilir eklentileri gösterir. sigma plugin install splunk ise Splunk backend'ini kurar.

Hedef ve hat adlarını ezberleme, listeden seç. sigma list targets kurulu backend'leri, sigma list pipelines kurulu işlem hatlarını gösterir. Hat adları eklenti sürümüyle değişebilir; listeye bakmak seni eski bir yazıdaki yanlış addan korur.

Çeviri komutu sabit bir sırayla kurulur. Önce alt komut convert gelir. -t ile hedef dil, -p ile işlem hattı verilir, en sona kural dosyası ya da dizini yazılır.

Splunk backend'i işlem hattı ister. -p verilmezse araç durur ve sigma list pipelines splunk komutunu önerir. Kuralı çevirmeden önce sigma check kural.yml ile söz dizimini ve zorunlu alanları denetlersin.

$ sigma convert -t splunk -p splunk_windows kurallar/kaba-kuvvet.yml
source="WinEventLog:Security" EventCode=4625

$ sigma convert -t kusto -p azure_monitor kurallar/kaba-kuvvet.yml
SecurityEvent
| where EventID == 4625

İki çıktıyı yan yana karşılaştır. Splunk hattı logsource'u source="WinEventLog:Security" koşuluna çevirdi. Kuraldaki EventID alanı da EventCode oldu, çünkü Splunk'ın Windows eklentisi bu alanı o adla çıkarır.

Kusto tarafında azure_monitor hattı olay kodunu tanıdı ve sorguyu SecurityEvent tablosuna bağladı. Alan adı değişmedi, çünkü o tabloda sütunun adı zaten EventID'dir. Kusto backend'i metin değerlerini =~ ile, sayıları == ile karşılaştırır.

Sigma değerleri varsayılan olarak harfe duyarsız sayar ve backend bu anlamı korur. Microsoft tarafında başka hatlar da vardır; Defender XDR ve ASIM için ayrı hatlar bulunur. Adlarını sigma list pipelines kusto gösterir.

detection alanı iki parçadan oluşur. Seçimler aranan alan-değer çiftlerini listeler. condition ise seçimlerin hangi mantıkla birleşeceğini söyler.

En yalın hâli condition: selection'dır. Birden çok seçim tanımlayıp selection and not filter gibi bir mantık da kurabilirsin. Aynı seçimin altında alt alta yazılan alanlar AND ile bağlanır.

Bir alanın altındaki liste değerleri ise OR ile bağlanır. Değiştiriciler alan adına dikey çizgiyle eklenir. |contains değerin metnin içinde geçmesini, |startswith başta, |endswith sonda olmasını arar. |all eki ise listedeki bütün değerlerin aynı anda geçmesini ister.

SigmaHQ deposundaki kurallar dışlama seçimlerine anlamlı adlar verir. filter_main_ ile başlayan seçimler, her ortamda geçerli olan bilinen iyi durumları dışlar. filter_optional_ ile başlayan seçimler ise yalnız bazı ortamlarda görülen yazılımları dışlar. condition satırı çoğu zaman şöyle görünür: selection and not 1 of filter_main_* and not 1 of filter_optional_*.

Yıldızlı ad, o önekle başlayan bütün seçimleri kapsar. Bu adlandırma, kuralı kendi ortamına uyarlarken hangi dışlamayı silip hangisini koruyacağını açık eder. Depoda binlerce hazır kural vardır. Ekip sıfırdan yazmadan önce orada arar, sonra kuralı kendi ortamına uyarlar.

Çevrilmiş bir kural hata vermeden çalışıp hiç sonuç döndürmeyebilir. En yaygın neden, alan adının hedefte farklı olmasıdır. Sigma'nın process_creation kategorisi Sysmon'un alan adlarını kullanır. Sysmon'da başlatılan programın yolu Image, başlatan programın yolu ParentImage alanındadır.

Windows'un kendi 4688 olayında aynı bilgiler NewProcessName ve ParentProcessName adlarını taşır. Altay Kargo'nun sunucularında Sysmon yok, yalnız 4688 toplanıyor. Ekip aşağıdaki kuralı yalnız Splunk hattıyla çevirdi ve bir hafta boyunca hiç alarm görmedi.

title: Office Uygulamasından PowerShell Başlatılması
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
    Image|endswith: '\powershell.exe'
  condition: selection
level: high

$ sigma convert -t splunk -p splunk_windows kurallar/office-powershell.yml
ParentImage IN ("*\\winword.exe", "*\\excel.exe") Image="*\\powershell.exe"

$ sigma convert -t splunk -p windows-audit -p splunk_windows kurallar/office-powershell.yml
source="WinEventLog:Security" EventCode=4688 ParentProcessName IN ("*\\winword.exe", "*\\excel.exe") NewProcessName="*\\powershell.exe"

İlk çeviri söz dizimi olarak kusursuzdur, ama ParentImage ve Image alanlarını arar. 4688 olaylarında bu alanlar hiç yoktur ve sorgu boş döner. Hata mesajı da çıkmaz; kural sessizce kör kalır.

İkinci komut iki hattı zincirler. windows-audit hattı önce process_creation kategorisini 4688 olayına çevirir. Image alanını NewProcessName, ParentImage alanını ParentProcessName yapar. Ardından splunk_windows hattı Security kaynağını ve EventCode adını ekler.

Hatların hangi sırayla çalışacağını her hattın kendi öncelik değeri belirler. windows-audit hattı sigma plugin install windows ile gelir. Çeviriden sonra sorguyu, kuralın yakalaması gereken bir olayın bulunduğu bilinen bir zaman aralığında çalıştır. Hiç sonuç gelmiyorsa kural canlıya alınmaz.

Tek bir 4625 olayı saldırı değildir; parolasını yanlış yazan bir çalışan da aynı olayı üretir. Kaba kuvvette asıl sinyal sayıdır. Sigma'nın 2.0 belirtimi bunun için korelasyon kurallarını getirdi. Korelasyon kuralı başka kurallara adıyla başvurur ve üstlerine bir sayım koyar.

type: event_count, timespan: 5m, group-by: TargetUserName ve condition: gte: 10 birlikte şunu söyler: aynı hesap için beş dakikada en az on başarısız giriş. value_count farklı değerleri sayar. temporal ise farklı olayların aynı pencerede birlikte görülmesini arar.

Her backend korelasyonu desteklemez. Splunk backend'i korelasyonu stats ile çevirir. Desteklenmeyen bir hedefte aynı mantığı summarize ile elle yazarsın.

Kuralı SIEM'e koymadan önce elindeki örnek kayıtlarla sınarsın. Chainsaw ve Hayabusa, Windows EVTX dosyalarını Sigma kurallarıyla doğrudan tarar. chainsaw hunt komutu bir EVTX dizinini, -s ile verilen Sigma kurallarını ve --mapping ile verilen alan eşleme dosyasını alır. Hayabusa da aynı işi yapar ve Sigma'nın korelasyon kurallarını destekler.

Hayabusa 4.0 sürümünde csv-timeline ve json-timeline komutlarını tek bir dfir-timeline komutunda birleştirdi. Çıktı biçimini artık -t seçeneği belirler. Örnek veriyi kendi lab makinende ürettiğin bir saldırı simülasyonundan alırsın.

Kural bu veride eşleşmiyorsa canlıda da eşleşmez. Uncoder gibi web araçları farklı dillere hızlı çeviri karşılaştırması sunar. Gerçek kayıtları ve iç kuralları bu tür üçüncü taraf hizmetlere yapıştırmazsın.

# 1. Söz dizimi ve zorunlu alanlar
sigma check kurallar/

# 2. Her hedefe çeviri; hata çıkarsa süreç durur
sigma convert -t splunk -p windows-audit -p splunk_windows -o cikti/splunk.spl kurallar/
sigma convert -t kusto -p azure_monitor -o cikti/sentinel.kql kurallar/

# 3. Örnek EVTX kayıtlarında beklenen eşleşme
chainsaw hunt test-verisi/ -s kurallar/ --mapping mappings/sigma-event-logs-all.yml --json

Olgun ekipler kuralları kod gibi yönetir. Kurallar bir Git deposunda durur ve her değişiklik bir çekme isteğiyle gelir.

Sürekli entegrasyon adımı önce sigma check ile söz dizimini denetler. Sonra kuralları hedef dillere çevirir ve çeviri hatasında süreci durdurur. Ardından test verisi üstünde kuralı çalıştırır; beklenen eşleşme gelmezse değişiklik birleştirilmez.

Testi geçen kural SIEM'e dağıtılır. Git geçmişi kimin, neyi, neden değiştirdiğini kayıt altında tutar. Bir kural gürültü üretmeye başladığında önceki sürüme dönmek tek bir komutla olur.