Related Articles

Kubescape Nedir? Açık Kaynak Kubernetes Güvenlik Platformu Rehberi

5 gün ago

Kartla Ödeme Nasıl Çalışır? “Ödeme Başarılı” Mesajının Arkasında Ne Var?

5 gün ago

Grype Nedir? Container ve SBOM Zafiyet Tarama Rehberi

2 hafta ago

Her SIEM farklıdır.

Splunk farklı sorgu dili kullanır.
Microsoft Sentinel KQL kullanır.
QRadar AQL kullanır.
Elastic/OpenSearch farklı query yapılarıyla çalışır.
Graylog, Chronicle, Datadog, Humio veya diğer platformlarda da alan adları ve sorgu mantığı değişebilir.

Fakat güvenlik ekiplerinin tespit etmek istediği davranış çoğu zaman aynıdır:

Şüpheli PowerShell çalıştırıldı mı?
Yeni local admin oluşturuldu mu?
LSASS erişimi var mı?
Suspicious process chain oluştu mu?
RDP brute-force denemesi var mı?
Credential dumping belirtisi görüldü mü?

İşte Sigma, bu problemi çözmek için geliştirilmiş açık, okunabilir ve taşınabilir bir detection rule standardıdır.

Kısa ifade:

YARA dosyalar için neyse,
Sigma loglar için odur.

---

🔍 Sigma Nedir?

Sigma, log verileri üzerinde şüpheli veya zararlı davranışları tespit etmek için kullanılan açık kaynaklı ve vendor-agnostic bir detection rule formatıdır.

Sigma kuralları genellikle YAML formatında yazılır.

Amaç şudur:

Tespit mantığını SIEM’den bağımsız yaz.
Sonra ihtiyaca göre Splunk, Elastic, Sentinel, QRadar veya başka platformlara dönüştür.

Yani Sigma doğrudan bir SIEM değildir.
Log toplama sistemi değildir.
EDR değildir.
Alarm motoru değildir.

Sigma, detection engineering için ortak bir kural dilidir.

---

Sigma Neden Önemlidir?

Bir SOC ekibi aynı tespit mantığını farklı platformlarda tekrar tekrar yazmak zorunda kalabilir.

Örneğin:

PowerShell -enc kullanımı tespit edilecek.

Bu mantık Splunk’ta farklı, Sentinel’de farklı, Elastic’te farklı, QRadar’da farklı yazılır.

Sigma burada ortak bir ara format sağlar:

Detection logic → Sigma YAML
Sigma YAML → SIEM query format

Bu sayede detection rule’lar daha taşınabilir, okunabilir ve versiyonlanabilir hale gelir.

---

🛠️ Sigma Neler Sunar?

1️⃣ Kolay Okunabilir YAML Formatı

Sigma kuralları insan tarafından okunabilir YAML formatında yazılır.

Basit bir Sigma kuralı şu bölümlerden oluşur:

title
id
status
description
references
author
date
tags
logsource
detection
falsepositives
level

Bu yapı sayesinde hem analistler hem detection engineer’lar kural mantığını kolayca okuyabilir.

---

2️⃣ SIEM Bağımsız Detection Mantığı

Sigma’nın en büyük gücü vendor bağımsız olmasıdır.

Aynı detection mantığı farklı SIEM platformlarına dönüştürülebilir:

• Splunk
• Elastic / OpenSearch
• Microsoft Sentinel
• QRadar
• Graylog
• Chronicle
• Datadog
• Humio
• Loki
• Diğer backend’ler

Burada kritik nokta şudur:

Sigma kuralı evrensel detection mantığını tanımlar.
Backend/converter bunu hedef SIEM diline çevirir.

---

3️⃣ pySigma ve sigma-cli ile Dönüştürme

Eskiden Sigma dönüşüm süreçlerinde sigmac sık kullanılıyordu. Ancak güncel ekosistemde pySigma ve sigma-cli daha doğru yaklaşımdır.

Modern kullanım mantığı:

Sigma Rule
→ pySigma parser
→ processing pipeline
→ backend converter
→ SIEM query

Örnek konsept:

sigma convert -t splunk suspicious_powershell.yml
sigma convert -t lucene suspicious_powershell.yml
sigma convert -t sentinel suspicious_powershell.yml

Hedef SIEM’e göre backend ve pipeline seçimi gerekir. Alan adları, log kaynağı ve data model farkları doğru eşlenmezse kural teknik olarak dönüşse bile beklenen alarmı üretmeyebilir.

---

4️⃣ Rule-as-Code Yaklaşımı

Sigma, detection kurallarını kod gibi yönetmeye uygundur.

Bu ne sağlar?

• Git üzerinde versiyonlama
• Pull request ile kural inceleme
• CI/CD ile kural doğrulama
• Otomatik test
• Ortamlar arası deployment
• Değişiklik geçmişi
• Kural kalitesi kontrolü

Bu yaklaşım modern detection engineering süreçlerinde çok değerlidir.

---

5️⃣ MITRE ATT&CK Etiketleme

Sigma kuralları MITRE ATT&CK teknikleriyle etiketlenebilir.

Örnek:

tags:
  - attack.execution
  - attack.t1059.001

Bu sayede kurallar taktik/teknik bazlı sınıflandırılabilir.

Kullanım avantajları:

• Detection coverage analizi
• ATT&CK heatmap üretimi
• Eksik tekniklerin görülmesi
• SOC use-case önceliklendirme
• Threat hunting planlama

---

📌 Basit Sigma Kuralı Örneği

Aşağıdaki örnek, encoded PowerShell kullanımını tespit etmeye yönelik basit bir Sigma kuralıdır.

title: Suspicious Encoded PowerShell Execution
id: 8f1b4c5e-1d2a-4d7a-9a2d-111111111111
status: test
description: Detects possible encoded PowerShell command execution.
author: SOC Team
date: 2026/06/16
logsource:
  product: windows
  category: process_creation
detection:
  selection_img:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
  selection_cmd:
    CommandLine|contains:
      - '-enc'
      - '-encodedcommand'
      - '-EncodedCommand'
  condition: selection_img and selection_cmd
falsepositives:
  - Administrative scripts
  - Software deployment tools
level: medium
tags:
  - attack.execution
  - attack.t1059.001

Bu kuralın mantığı şudur:

Windows process creation loglarına bak.
Process powershell.exe veya pwsh.exe ise kontrol et.
CommandLine içinde encoded command parametresi varsa eşleşme üret.

---

Sigma Kuralının Temel Bölümleri

title

Kuralın kısa ve anlaşılır adıdır.

title: Suspicious Encoded PowerShell Execution

logsource

Kuralın hangi log kaynağına uygulanacağını belirtir.

Örnek:

logsource:
  product: windows
  category: process_creation

Bu alan çok kritiktir. Çünkü aynı detection mantığı farklı log kaynaklarında farklı field isimleriyle gelebilir.

detection

Asıl eşleşme mantığının yazıldığı bölümdür.

Örnek:

detection:
  selection:
    CommandLine|contains: '-enc'
  condition: selection

condition

Hangi selection bloklarının birlikte değerlendirileceğini belirtir.

Örnek:

condition: selection_img and selection_cmd

falsepositives

Kuralın hangi meşru durumlarda tetiklenebileceğini belirtir.

level

Alarmın önem seviyesini gösterir.

Yaygın seviyeler:

informational
low
medium
high
critical

tags

MITRE ATT&CK veya kurumsal etiketleme için kullanılır.

---

🎯 Sigma Nerelerde Kullanılır?

🕵️ SOC ve MSSP Ekipleri

SOC ekipleri Sigma ile SIEM’den bağımsız detection rule geliştirebilir.

Faydaları:

• Ortak kural dili
• Daha hızlı use-case geliştirme
• Farklı müşterilere/platformlara uyarlama
• MSSP ortamlarında standartlaştırma
• Rule library yönetimi

---

🧠 Threat Hunting

Sigma sadece alarm üretimi için değil, threat hunting için de kullanılabilir.

Örnek hunting soruları:

Son 7 günde encoded PowerShell kullanımı var mı?
Kimler suspicious parent-child process chain oluşturdu?
Hangi hostlarda credential dumping belirtisi var?
Hangi kullanıcılar beklenmeyen servis oluşturdu?

Sigma kuralı hunting sorgusuna dönüştürülerek platform üzerinde geçmiş loglarda çalıştırılabilir.

---

🔄 Platformlar Arası Kural Taşınabilirliği

Bir kuralı tek formatta yazıp farklı SIEM platformlarına dönüştürmek mümkündür.

Örnek akış:

Sigma YAML
→ Splunk SPL
→ Microsoft Sentinel KQL
→ Elastic Query
→ QRadar AQL

Ancak burada önemli bir gerçek vardır:

Kural dönüşebilir.
Ama her ortamda doğrudan kusursuz çalışmayabilir.

Çünkü field mapping, log normalization, Sysmon/Event ID kullanımı, EDR log şeması ve data model farklılıkları sonucu etkiler.

---

🧪 Detection Engineering

Sigma, detection engineering süreçlerinde standart bir geliştirme formatı olarak kullanılabilir.

Süreç örneği:

Threat intelligence gelir
→ Davranış çıkarılır
→ Sigma kuralı yazılır
→ Test loglarıyla doğrulanır
→ SIEM formatına dönüştürülür
→ False-positive analizi yapılır
→ Production’a alınır
→ Git üzerinde versiyonlanır

---

⚡ Vendor-Agnostic Threat Detection

Sigma’nın en güçlü tarafı vendor bağımsız yaklaşımıdır.

Bir güvenlik ekibi SIEM değiştirirse tüm detection mantığını sıfırdan yazmak zorunda kalmaz. Sigma kuralları yeni hedef platforma dönüştürülebilir.

Bu da kurumlara şu avantajları sağlar:

• SIEM bağımlılığını azaltma
• Detection bilgisini platformdan bağımsız saklama
• Daha kolay migration
• Ortak kural standardı
• Daha iyi kural paylaşımı

---

Sigma, YARA ve Suricata Arasındaki Fark

Araç / Format	Odak Alanı	Kullanım
YARA	Dosya / malware pattern	Dosya içeriği, string, binary pattern
Sigma	Log tabanlı tespit	SIEM, EDR logları, Windows/Linux event
Suricata	Ağ trafiği	IDS/IPS network traffic detection
Zeek	Ağ olayları / metadata	Network security monitoring

Kısa ifade:

YARA → Dosyada iz arar.
Suricata → Ağ trafiğinde alarm üretir.
Zeek → Ağ olaylarını anlamlandırır.
Sigma → Loglarda davranış tespit eder.

---

✅ Sigma Kullanırken En İyi Uygulamalar

1️⃣ Logsource Alanını Doğru Yazın

Yanlış logsource, yanlış dönüşüm ve yanlış alarm anlamına gelir.

Örnek:

logsource:
  product: windows
  category: process_creation

Bu, process creation loglarını hedefler. Eğer ortamda Sysmon Event ID 1 yoksa veya Windows Security 4688 farklı alanlarla geliyorsa mapping yapılmalıdır.

---

2️⃣ Field Mapping’i Kontrol Edin

Sigma’daki Image, CommandLine, ParentImage, User, TargetFilename gibi alanlar SIEM tarafında farklı isimlerle tutulabilir.

Örnek:

Sigma: CommandLine
Splunk CIM: Processes.process
Elastic ECS: process.command_line
Sentinel: ProcessCommandLine

Bu nedenle converter pipeline ve SIEM data model doğru eşlenmelidir.

---

3️⃣ False Positive Alanını Boş Bırakmayın

Her detection kuralı operasyonel gerçeklikle birlikte değerlendirilmelidir.

Örnek false-positive kaynakları:

• Admin scriptleri
• Software deployment araçları
• Backup agent
• Monitoring agent
• IT automation işleri
• Developer test komutları

---

4️⃣ MITRE ATT&CK Tag Ekleyin

Kuralı sadece teknik değil, taktiksel olarak da sınıflandırın.

Örnek:

tags:
  - attack.execution
  - attack.t1059.001

---

5️⃣ Kuralı Production’a Almadan Test Edin

Sigma kuralı yazmak tek başına yeterli değildir.

Test adımları:

Syntax kontrolü
Converter çıktısı kontrolü
Test log üzerinde çalıştırma
False-positive ölçümü
Field mapping doğrulama
Zaman aralığı testi
Production dry-run

---

⚠️ Sık Yapılan Hatalar

1️⃣ Sigma’yı SIEM Sanmak

Sigma bir SIEM değildir. Bir detection rule formatıdır.

2️⃣ Converter Çıktısını Kör Şekilde Kullanmak

Dönüştürülen sorgu mutlaka hedef SIEM üzerinde test edilmelidir.

3️⃣ Log Kaynağı Olmadan Kural Yazmak

Ortamda ilgili log yoksa kural çalışmaz.

Örnek:

Process creation logları toplanmıyorsa PowerShell process kuralı alarm üretmez.

4️⃣ Alan Adlarını Varsaymak

Her SIEM aynı field isimlerini kullanmaz. Data normalization kontrol edilmelidir.

5️⃣ Çok Geniş Kural Yazmak

Aşırı geniş kurallar false-positive üretir ve SOC yorgunluğuna yol açar.

6️⃣ Kural Seviyesini Yanlış Belirlemek

Her PowerShell kullanımı critical değildir. Severity, bağlama göre belirlenmelidir.

---

48s Mini-PoC Planı

1. SigmaHQ kural deposundan basit bir Windows process creation kuralı seçin.
2. Kuralın logsource, detection, condition alanlarını inceleyin.
3. Ortamınızdaki SIEM field mapping karşılığını çıkarın.
4. sigma-cli veya pySigma backend ile hedef SIEM sorgusuna dönüştürün.
5. Dönüştürülen sorguyu test logları üzerinde çalıştırın.
6. False-positive üreten sistemleri not alın.
7. Gerekirse allowlist veya filtre ekleyin.
8. Kuralı Git üzerinde versiyonlayın.
9. MITRE ATT&CK tag’leriyle coverage takibi yapın.
10. Production’a almadan önce SOC runbook hazırlayın.

---

Örnek Sigma Rule Lifecycle

Threat report okundu
→ Davranış çıkarıldı
→ Sigma kuralı yazıldı
→ Syntax kontrol edildi
→ SIEM query’ye dönüştürüldü
→ Test loglarıyla doğrulandı
→ False-positive analizi yapıldı
→ Production deployment yapıldı
→ Alarm kalitesi takip edildi
→ Kural iyileştirildi

Bu yaklaşım detection engineering olgunluğunu artırır.

---

Sonuç

Sigma, log tabanlı tehdit tespiti için açık, okunabilir ve taşınabilir bir kural standardıdır.

Kurallar YAML ile yazılır, Git üzerinde yönetilebilir, MITRE ATT&CK ile etiketlenebilir ve farklı SIEM platformlarına dönüştürülebilir.

Ancak en önemli nokta şudur:

Sigma kuralı yazmak başlangıçtır.
Gerçek değer; doğru log kaynağı, doğru field mapping, doğru test ve doğru tuning ile ortaya çıkar.

Doğru kullanıldığında Sigma, SOC ve threat hunting ekiplerine SIEM bağımsız, sürdürülebilir ve otomasyona hazır bir detection engineering altyapısı sağlar.

Kurallarınızı bir kez yazın, doğru pipeline ile birçok platformda kullanın.