01 - Tespit Mühendisliği: Disiplinden Senaryoya ve Boru Hattına
Sürekli gelişen bir siber tehdit ortamında, tespit etmek Önemli bir hasara yol açmadan önce kötü niyetli etkinlik, arasındaki gerçek farkı temsil eder. dayanıklı ve savunmasız bir organizasyon. Onlarca yıldır tehdit tespiti yapılıyor SOC analistlerinin özel yazılı kurallarına, antivirüs imzalarına ve bireysel sezgilerine emanet edilmiştir. Bugün, bu zanaatkar yaklaşım artık sürdürülebilir değil: kütüklerin hacmi, karmaşıklığı Bulutta yerel altyapılar ve saldırganların karmaşıklığı bir yaklaşım gerektirir mühendislik ve sistematik.
İşte böyle doğdu Tespit Mühendisliği: ilkeleri uygulayan bir disiplin yazılım mühendisliğinin yazılımı oluşturma, test etme, dağıtma ve sürdürme sürecine kadar algılama kuralları. Artık mesele bir SIEM'de izole edilmiş sorgular yazmak değil, mesele otomatik boru hatları, tespitleri kod olarak sürümlendirin, verilerle test edin bunları simüle edin ve objektif ölçümlerle ölçün.
Bu Makalede Neler Öğreneceksiniz?
- Tespit Mühendisliği nedir ve neden özerk bir disiplin haline geldi?
- Tespit için geçici komut dosyalarından CI/CD ardışık düzenlerine geçiş
- Bir algılamanın tüm yaşam döngüsü: hipotez, geliştirme, test, dağıtım, ayarlama
- Ana tespit türleri: imza tabanlı, davranışsal, anormallik tabanlı
- Kalite metrikleri: Doğru Pozitif Oranı, Yanlış Pozitif Oranı, MTTD, MTTR
- SIEM/SOAR ekosistemi ve temel veri kaynakları
- Güvenlik kuralları için Kod Olarak Algılama ve CI/CD ardışık düzenleri kavramı
- Sigma kuralları, Python komut dosyaları ve YAML yapılandırmalarıyla pratik örnekler
Tespit Mühendisliği Nedir?
La Tespit Mühendisliği ve sistematik tasarım, geliştirme süreci, telemetri içindeki kötü amaçlı etkinliği tanımlayan mantığın test edilmesi ve bakımı bir organizasyonun. Bu telemetri, uç noktalardan, bulut altyapısından, kimlik sağlayıcıları, web uygulamaları, ağ sistemleri ve çok daha fazlası.
Bir SOC analistinin SIEM'e sorgu yazdığı geleneksel yaklaşımın aksine Belirli bir olaya yanıt olarak Tespit Mühendisliği, iş akışı yapılandırılmış modern yazılım geliştirmeyi anımsatan: kod versiyonlama, kod inceleme, üretimde otomatik test, sürekli dağıtım ve performans izleme.
"Yazılım Mühendisliği kodlamada ne ise, Tespit Mühendisliği de SOC için odur: geçici, reaktif aktiviteyi sistematik, ölçülebilir ve sürekli gelişen bir disipline dönüştürmek."
- SANS Enstitüsü, 2025 Tespit Mühendisliği Araştırması
Tespit Mühendisliğinin Üç Temeli
Disiplin, olgunluğunu tanımlayan birbiriyle bağlantılı üç temele dayanmaktadır:
- Tehdit İstihbaratı - Rakiplerin kim olduğunu, hangi teknikleri kullandıklarını anlayın (MITRE ATT&CK) ve kuruluşun hangi varlıklarının risk altında olduğu. Anlamadan Tehditlerin derinliği nedeniyle tespitler genel olacak ve çok etkili olmayacaktır.
- Veri Mühendisliği - Gerekli günlüklerin toplandığından ve normalleştirildiğinden emin olun ve analiz için kullanılabilir. Üzerinde çalıştığı veriler doğru değilse mükemmel ve işe yaramaz bir tespit mevcut veya kalitesiz.
- Yazılım Mühendisliği - Yazılım geliştirmenin en iyi uygulamalarını uygulayın: sürüm kontrolü, test etme, CI/CD, dokümantasyon, ölçümler. Tespitler tedavi edilmeli üretim kodu olarak.
Evrim: Özel Senaryolardan Mühendislik Disiplinine
Modern Tespit Mühendisliğine giden yol dört bölüme ayrılabilir: Her biri artan bir olgunluk ve otomasyon düzeyiyle karakterize edilen farklı aşamalar.
Aşama 1: İmzalar Çağı (1990-2005)
Erken tespit biçimleri şunlara dayanıyordu: statik imzalar: bilinen kalıplar kötü amaçlı yazılım, kötü amaçlı dosyaların karmaları, ağ yüklerindeki belirli dizeler. Her antivirüs ve IDS (Saldırı Tespit Sistemi), periyodik olarak güncellenen bir imza veritabanını tuttu. Yaklaşım bilinen tehditlerle oldukça iyi çalıştı ancak yüzleri tamamen kör ediyordu yeni varyasyonlara veya özelleştirilmiş saldırılara.
Aşama 2: SIEM Komut Dosyalarının Çağı (2005-2015)
Öncekinin yaygınlaşmasıyla SIEM (Güvenlik Bilgileri ve Olay Yönetimi), analistler özel sorgular ve korelasyonlar yazmaya başladı. Her analistin sahip olduğu kendi yaklaşımı, kendi senaryoları, kendi adlandırma kuralları. Kurallar oluşturuldu doğrudan SIEM web arayüzünde, sürüm oluşturmadan, test etmeden, belgelendirmeye gerek kalmadan standartlaştırılmış. Bir analist kuruluştan ayrıldığında, tespitleri sıklıkla ardılları için anlaşılmaz.
Aşama 3: Tespit Mühendisliğinin Doğuşu (2015-2022)
2015 ve 2022 yılları arasında güvenlik topluluğu, daha yapılandırılmış bir yaklaşım. Standart formatlar aşağıdaki gibi doğar: Sigma (2017) için tespit kuralları, çerçeve GÖNYE ATT&CK referans haline gelir rakiplerin tekniklerini haritalamak için evrensel ve ilk özel Tespit ekipleri Mühendislik daha olgun organizasyonlarda görülür.
Aşama 4: Kod Olarak Algılama ve CI/CD Ardışık Düzeni (2022'den günümüze)
Günümüzde en gelişmiş kuruluşlar, tespitleri tam olarak yazılım kodu gibi ele almaktadır. Kurallar bildirimsel formatlarda (Sigma, YAML) yazılmıştır ve Git depolarında versiyonlanmıştır. simüle edilmiş verilerle otomatik olarak test edildi, CI/CD hattı aracılığıyla dağıtıldı ve izlendi özel kontrol panelleri ile. göre SANS 2025 Tespit Mühendisliği Araştırması, Kuruluşların %60'ı özel Tespit Mühendisliği ekiplerine sahiptir; %70'i Halihazırda yapılandırılmış ekipler kurmuş olan, 5.000'den fazla çalışanı olan işletmelerin sayısı.
| Faz | Dönem | Yaklaşmak | Aletler | Sınırlar |
|---|---|---|---|---|
| Statik imzalar | 1990-2005 | Bilinen imzalarda desen eşleştirme | Antivirüs, IDS (Snort) | Görünmez sıfır gün, yüksek gecikme |
| SIEM komut dosyaları | 2005-2015 | SIEM'de özel amaçlı sorgular | Splunk, ArcSight, QRadar | Sürümlenmemiş, test edilmemiş, bilgi silolarına yerleştirilmiş |
| Tespit Mühendisliği | 2015-2022 | Standartlarla yapılandırılmış iş akışı | Sigma, ATT&CK, ELK | Hala birçok manuel işlem var |
| Kod Olarak Algılama | 2022-günümüz | CI/CD ardışık düzeni, tüm versiyonları mevcut | Git, CI/CD, Sigma, SOAR | Organizasyonel olgunluk gerektirir |
Bir Tespitin Yaşam Döngüsü
Her tespit, kaliteyi, etkililiği ve verimliliği garanti eden iyi tanımlanmış bir yaşam döngüsünü takip eder. zaman içinde sürdürülebilirlik. Döngü altı temel aşamadan oluşur; her biri teslimatlar ve özel kalite kriterleri.
1. Hipotez (Hipotez)
Her şey bir tanesiyle başlar tehdit hipotezi. Analist veya tespit mühendisi belirli bir saldırı tekniğini tanımlar (örneğin, "Bir saldırganın kullanabileceği Kötü amaçlı yükleri indirmek ve yürütmek için PowerShell") ve nasıl olduğuna dair bir hipotez formüle edin bu etkinlik mevcut günlüklerde kendini gösterecektir. Hipotezlerin kaynakları şunları içerir:
- Tehdit İstihbaratı - Aktif kampanyalar ve gözlemlenen TTP'ler hakkında rapor
- GÖNYE ATT&CK - Belirli taktiklerle eşlenen teknikler
- Ölüm sonrası kaza - Önceki olaylardan alınan dersler
- Kırmızı Takım bulguları - Sızma testleri ve mor ekipleme sonuçları
- Boşluk analizi - Tespit kapsamı olmayan ATT&CK teknikleri
2. Kalkınma (Gelişme)
Tanımlanan hipotez ile tespit mühendisi tespit kuralını yazar. Bu format seçimini (Sigma, SIEM yerel sorgusu, Python betiği), tanımı içerir gerekli kaynak günlüklerinin, seçim ve filtreleme mantığının ve meta veriler (yazar, önem derecesi, ATT&CK eşlemesi, bilinen yanlış pozitifler).
3. Test Etme ve Doğrulama (Test Etme)
Dağıtımdan önce algılamanın gerçek ve simüle edilmiş verilere göre doğrulanması gerekir. Test şunları içerir: gerçek pozitif test (kural simüle edilmiş saldırıyı algılıyor mu?), yanlış pozitif test (kural meşru faaliyetlerle ilgili uyarılar üretiyor mu?), e performans testi (kural hacimler üzerinde yeterince etkilidir üretim günlüğü?).
4. Dağıtım
Dağıtım, kuralı formata dönüştüren otomatik işlem hatları aracılığıyla gerçekleşir hedef SIEM'e özgü, onu üretim ortamına dağıtın ve doğruluğunu doğrulayın Operasyon. Olgun ortamlarda bu süreç CI/CD aracılığıyla tamamen otomatikleştirilir.
5. İzleme ve Ölçümler
Üretime girdikten sonra tespit sürekli olarak izlenir. Temel ölçümler oluşturulan uyarıların hacmini, doğru/yanlış pozitif oranını, ortalama süreyi içerir algılama (MTTD) ve SOC analist yükü üzerindeki etkisi.
6. Ayarlama ve Bakım
Üretimde toplanan verilere dayanarak algılama sürekli olarak geliştirilir. ayarlama, yinelenen yanlış pozitifler için istisnalar eklemeyi, kapsamı genişletmeyi içerebilir tekniğin varyasyonlarını kapsayacak mantık veya daha fazla değilse kuralın kullanımdan kaldırılması İlgili.
En İyi Uygulama: Mor Takım Oluşturma
Il mor takım oluşturma geri bildirim döngüsünü önemli ölçüde hızlandırır algılama yaşam döngüsü. Kırmızı Takım'ın hücum becerilerini savunma becerileriyle birleştirmek Mavi Takım'ın gerçek saldırı tekniklerini simüle etmesi ve tespitleri doğrulaması mümkün. gerçek zamanlı olup, hipotez ile doğrulanmış tespit arasındaki süreyi haftalardan saatlere indirir.
Tespit Türleri: IOC'den Davranışa
Algılamalar, kullanılan algılama mantığına göre sınıflandırılabilir. Her türün belirli avantajları ve sınırlamaları vardır ve olgun bir tespit programı bunları birleştirir hepsi katmanlı bir şekilde.
1. İmza Tabanlı Tespit
İmza tabanlı tespit aramaları kesin desenler verilerde: dosya karması komutlardaki, IP adreslerindeki veya bilinen kötü amaçlı alanlardaki bilinen, belirli dizeler (IOC - Göstergeler Uzlaşma). Çok düşük yanlış pozitif oranına sahip en basit ve en hızlı türdür, ancak yeni veya değişken tehditlere karşı tamamen etkisizdir.
title: Emotet Loader Hash Detection
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: stable
description: Detects known Emotet loader by file hash
author: Detection Engineering Team
date: 2025/10/15
references:
- https://attack.mitre.org/software/S0367/
logsource:
category: file_event
product: windows
detection:
selection:
Hashes|contains:
- 'SHA256=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'
- 'SHA256=a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a'
- 'MD5=d41d8cd98f00b204e9800998ecf8427e'
condition: selection
falsepositives:
- Unlikely, known malicious hashes
level: critical
tags:
- attack.execution
- attack.t1204.0022. Davranışsal Tespit
Davranışsal tespitler aranıyor eylem dizileri veya deseni Belirli IOC'lerden bağımsız olarak şüpheli aktiviteyi gösteren davranışlar. Örneğin, Mimikatz'ın belirli bir karmasını aramak yerine, davranışsal bir tespit Kimlik bilgilerini çıkarmak için LSASS belleğine erişen herhangi bir işlemi arayabilir. Bu yaklaşım kaçmaya karşı çok daha dayanıklıdır çünkü saldırganlar değişebilir kendi araçları vardır ancak altta yatan tekniği pek değiştiremezler.
title: Suspicious LSASS Process Access - Credential Dumping
id: b2c3d4e5-f6a7-8901-bcde-f12345678901
status: experimental
description: |
Detects process access to LSASS memory, a common technique
for credential dumping (T1003.001). Focuses on behavior
rather than specific tool signatures.
author: Federico Calo
date: 2025/11/20
references:
- https://attack.mitre.org/techniques/T1003/001/
logsource:
category: process_access
product: windows
detection:
selection:
TargetImage|endswith: '\lsass.exe'
GrantedAccess|contains:
- '0x1010' # PROCESS_QUERY_LIMITED_INFORMATION + PROCESS_VM_READ
- '0x1038' # Read memory access
- '0x1FFFFF' # PROCESS_ALL_ACCESS
filter_legitimate:
SourceImage|endswith:
- '\MsMpEng.exe' # Windows Defender
- '\csrss.exe' # Client Server Runtime
- '\wmiprvse.exe' # WMI Provider
- '\svchost.exe' # Service Host
filter_system:
SourceUser|contains: 'SYSTEM'
SourceImage|startswith: 'C:\Windows\System32\'
condition: selection and not filter_legitimate and not filter_system
falsepositives:
- Legitimate security tools performing memory scanning
- EDR solutions with high-privilege access
level: high
tags:
- attack.credential_access
- attack.t1003.0013. Anomaliye Dayalı Tespit
Anomaliye dayalı tespitler, normalliğin temeli e Önemli sapmaları rapor edin. Örneğin, bir kullanıcı genellikle bir İtalya'da mesai saatleri içinde bulunuyorsanız, Çin'den sabah 3'te giriş yapmak bir anormallik. Bu yaklaşım, tamamen bilinmeyen (sıfır gün) tehditleri tespit edebilir, ancak özellikle dinamik ortamlarda daha fazla hatalı pozitif sonuç üretme eğilimindedir.
4. Tehdit Avcılığı
Tehdit avcılığı bir süreçtir proaktif ve hipotez odaklı hangisinde analistler otomatik tespitten kaçmış olabilecek tehditleri aktif olarak ararlar. Otomatik tespitin aksine, tehdit avcılığı keşif amaçlıdır ve sıklıkla daha sonra kodlanan ve otomatikleştirilen yeni tespitler.
| Algılama türü | Kesinlik | Sıfır Gün Kapsamı | Yanlış Pozitifler | Bakım | Örnek |
|---|---|---|---|---|---|
| İmza Tabanlı | Çok yüksek | Hiçbiri | Çok düşük | Yüksek (IOC'yi güncelleyin) | Hash dosyaları, kötü amaçlı IP'ler |
| Davranışsal | Yüksek | İyi | Orta | Ortalama | LSASS erişimi, yanal hareket |
| Anomali Tabanlı | Değişken | Harika | Yüksek | Yüksek (temel ayar) | Anormal giriş, olağandışı trafik |
| Tehdit Avcılığı | Çok yüksek | Harika | Minimum (manuel) | Yüksek (analist gerektirir) | Keşifsel analiz, hipotezler |
Algılamalara ilişkin kalite ölçümleri
Bir tespit, eğer değilse, faydalı değildir. ölçülebilir. Kalite ölçümleri tespit kurallarının etkinliğini değerlendirmenize olanak tanır, süreci yönlendirir Tespit Mühendisliği programına yapılan yatırımların ayarlanması ve gerekçelendirilmesi.
Temel Operasyonel Metrikler
| Metrik | Tanım | Hedef | Nasıl Geliştirilir |
|---|---|---|---|
| MTTD (Ortalama Tespit Süresi) | Kötü amaçlı etkinlik anından uyarının oluşturulmasına kadar geçen ortalama süre | < 4 saat (en iyi takım: < 30 dakika) | Daha iyi günlük kapsamı, gerçek zamanlı algılama |
| MTTR (Ortalama Yanıt Süresi) | Tespitten kontrol altına alma/çözünmeye kadar geçen ortalama süre | < 4 saat | SOAR otomasyonu, tanımlanmış taktik kitapları |
| Gerçek Pozitif Oran (TPR) | Gerçek tehditlere karşılık gelen uyarıların yüzdesi | Kritik için >%80, yüksek için >%60 | Sürekli ayarlama, gelişmiş filtreleme |
| Yanlış Pozitif Oranı (FPR) | Meşru faaliyetler için oluşturulan uyarıların yüzdesi | Kritik için < %25 | Beyaz liste, zenginleştirilmiş bağlam, korelasyon |
| Yanlış Negatif Oranı (FNR) | Tespit edilemeyen gerçek tehditlerin yüzdesi | < %1 | Mor ekip oluşturma, tehdit avcılığı |
| ATT&CK Kapsamı | En az bir tespitin kapsadığı MITRE ATT&CK tekniklerinin yüzdesi | > İlgili tekniklerin %70'i | Düzenli boşluk analizi, önceliklendirme |
Tespit Puanının Hesaplanması
Tespit programının genel kalitesini değerlendirmek için pratik bir yaklaşım ve Tespit Olgunluk Puanıçeşitli ölçümleri tek bir puanda birleştiren normalleştirildi. İşte Python'da örnek bir hesaplama:
from dataclasses import dataclass
from typing import List
@dataclass(frozen=True)
class DetectionMetrics:
"""Immutable snapshot of detection performance metrics."""
rule_id: str
true_positives: int
false_positives: int
false_negatives: int
total_alerts: int
avg_detection_time_minutes: float # MTTD
avg_response_time_minutes: float # MTTR
@property
def precision(self) -> float:
"""TP / (TP + FP) - How many alerts are real threats."""
denominator = self.true_positives + self.false_positives
return self.true_positives / denominator if denominator > 0 else 0.0
@property
def recall(self) -> float:
"""TP / (TP + FN) - How many real threats are caught."""
denominator = self.true_positives + self.false_negatives
return self.true_positives / denominator if denominator > 0 else 0.0
@property
def f1_score(self) -> float:
"""Harmonic mean of precision and recall."""
p, r = self.precision, self.recall
return 2 * (p * r) / (p + r) if (p + r) > 0 else 0.0
def calculate_maturity_score(metrics_list: List[DetectionMetrics]) -> dict:
"""Calculate overall detection program maturity score.
Returns an immutable dict with aggregated metrics.
"""
if not metrics_list:
return {"score": 0, "grade": "F", "details": {}}
avg_precision = sum(m.precision for m in metrics_list) / len(metrics_list)
avg_recall = sum(m.recall for m in metrics_list) / len(metrics_list)
avg_f1 = sum(m.f1_score for m in metrics_list) / len(metrics_list)
avg_mttd = sum(m.avg_detection_time_minutes for m in metrics_list) / len(metrics_list)
avg_mttr = sum(m.avg_response_time_minutes for m in metrics_list) / len(metrics_list)
# Weighted maturity score (0-100)
precision_score = avg_precision * 25 # 25% weight
recall_score = avg_recall * 25 # 25% weight
f1_component = avg_f1 * 20 # 20% weight
mttd_score = max(0, (240 - avg_mttd) / 240) * 15 # 15% weight (240min = 4h target)
mttr_score = max(0, (240 - avg_mttr) / 240) * 15 # 15% weight
total_score = (precision_score + recall_score + f1_component
+ mttd_score + mttr_score) * 100
grade_thresholds = [
(90, "A"), (80, "B"), (70, "C"), (60, "D")
]
grade = next(
(g for threshold, g in grade_thresholds if total_score >= threshold),
"F"
)
return {
"score": round(total_score, 1),
"grade": grade,
"details": {
"avg_precision": round(avg_precision, 3),
"avg_recall": round(avg_recall, 3),
"avg_f1": round(avg_f1, 3),
"avg_mttd_minutes": round(avg_mttd, 1),
"avg_mttr_minutes": round(avg_mttr, 1),
"total_rules_evaluated": len(metrics_list),
},
}
# Esempio di utilizzo
sample_metrics = [
DetectionMetrics("SIGMA-001", 45, 5, 2, 50, 15.0, 35.0),
DetectionMetrics("SIGMA-002", 120, 30, 8, 150, 8.5, 22.0),
DetectionMetrics("SIGMA-003", 200, 15, 5, 215, 3.2, 12.0),
]
result = calculate_maturity_score(sample_metrics)
print(f"Detection Maturity Score: {result['score']} ({result['grade']})")
print(f"Details: {result['details']}")Dikkat: Gösteriş Metrikleri
Tespit programınızın başarısını ölçmekten kaçının. toplam sayı kuralların veya oluşturulan uyarıların sayısı. Bunlar metriklerdir ciddi sorunları maskeleyebilecek gösterişli ölçümler. 50 kişilik bir kuruluş yüksek doğrulukta algılama ve 5.000 kurala sahip olanlardan çok daha güvenli binlerce yanlış pozitif, analistler arasında alarm yorgunluğuna neden oluyor.
SIEM/SOAR Ekosistemi
Il SIEM (Güvenlik Bilgileri ve Olay Yönetimi) ve kalp Tespit Mühendisliği altyapısı. Ve toplayan, normalleştiren platform, Kuruluştaki tüm kaynaklardan gelen günlükleri ilişkilendirir ve analiz eder. YÜKSEL (Güvenlik Düzenleme, Otomasyon ve Yanıt) SIEM'i tamamlar önceden tanımlanmış taktik kitaplar aracılığıyla uyarılara verilen yanıtların otomatikleştirilmesi.
Ana SIEM Platformlarına Genel Bakış
| platformu | Tip | Sorgu dili | Güçlü yönler | İdeal Kullanım Durumu |
|---|---|---|---|---|
| Splunk Kurumsal | Şirket İçi / Bulut | SPL | Olgunluk, uygulama ekosistemi, esneklik | Karmaşık işletmeler, olgun SOC'ler |
| Elastik SIEM | Açık Kaynak / Bulut | KQL / EQL / ES|QL | Açık kaynak, ölçeklenebilirlik, maliyet | Düşük bütçeli, bulutta yerel ekipler |
| Microsoft Sentinel | Bulut (Azure) | KQL | Azure/M365 entegrasyonu, yerleşik yapay zeka | Microsoft merkezli kuruluşlar |
| Google SecOps (Günlük) | Bulut (GCP) | YARA-L | Sınırsız saklama, hız | Büyük hacimli veriler, GCP |
| CrowdStrike Falcon LogScale | Bulut | LogScale Sorgusu | Hızlı alım, sıkıştırma | CrowdStrike Organizasyonları |
| Sumo Mantığı | Bulut | Sumo Mantık Sorgusu | Yerel SaaS, kullanım kolaylığı | Bulut öncelikli, SaaS ağırlıklı |
Temel Veri Kaynakları
Tespitlerin kalitesi doğrudan verilerin kalitesine ve eksiksizliğine bağlıdır mevcut. Etkili bir tespit programı için temel veri kaynakları şunlardır:
- Uç Nokta Telemetrisi - İşlem günlükleri, dosya sistemi olayları, kayıt defteri değişiklikleri, ağ bağlantıları. Kaynaklar: EDR (CrowdStrike, SentinelOne, Microsoft Defender), Sysmon
- Ağ Telemetrisi - NetFlow, DNS sorguları, HTTP/TLS meta verileri, PCAP seçici. Kaynaklar: güvenlik duvarı, IDS/IPS, proxy, DNS çözümleyici
- Kimlik ve Erişim - Kimlik doğrulama olayları, ayrıcalık yükseltme, grup üyeliği değişiklikleri. Kaynaklar: Active Directory, Entra ID, Okta, CyberArk
- Bulut Denetim Günlükleri - API çağrıları, konfigürasyon değişiklikleri, kaynak oluşturma. Kaynaklar: AWS CloudTrail, Azure Etkinlik Günlüğü, GCP Denetim Günlükleri
- Uygulama Günlükleri - Web sunucusu erişim kayıtları, uygulama hataları, WAF olayları. Kaynaklar: Nginx, Apache, CloudFront, özel uygulamalar
- E-posta Güvenliği - Kimlik avı girişimleri, kötü amaçlı ekler, BEC tespiti. Kaynaklar: O365 için Microsoft Defender, Proofpoint, Mimecast
Veri Normalleştirme: Görünmez Temel
Olmadan veri normalleştirme, tespitler hassastır ve taşınabilir değildir.
Her SIEM ve her kaynak aynı kavramlar için farklı formatlar kullanır: "oturum açma hatası"
şöyle görünebilir EventID 4625 Windows'ta, sshd: Failed password
Linux'ta veya {"eventType": "user.session.start", "outcome": "FAILURE"}
Okta'da. Aşağıdaki gibi bir normalleştirme şemasını benimseyin: ECS (Elastik Ortak Şema),
OCSF (Açık Siber Güvenlik Şeması Çerçevesi) veya Sigma'nın veri modeli şunları sağlar:
algılamayı yalnızca bir kez yazmak ve herhangi bir kaynağa uygulamak.
Kod Olarak Algılama: Modern Paradigma
Kod Olarak Algılama (DaC) ve geliştirme uygulamalarını uygulayan yaklaşım Algılama kurallarını yönetmek için yazılım. Kural oluşturmak ve değiştirmek yerine SIEM grafik arayüzü aracılığıyla tespitler kod olarak yazılır, versiyonlanır Git depolarında, çekme istekleri aracılığıyla kod incelemesine tabi tutulur, otomatik olarak test edilir ve CI/CD boru hatları aracılığıyla teslim edilir.
Kod Olarak Algılamanın Avantajları
Geleneksel Yaklaşımla Karşılaştırıldığında
- Sürüm oluşturma - Her değişiklik geri alma olasılığıyla birlikte Git'te izlenir
- Kod İncelemesi - Algılamalar dağıtımdan önce akran incelemesine tabi tutulur
- Otomatik Testler - Pozitif ve negatif verilerle otomatik doğrulama
- Tekrarlanabilirlik - Tespitlerin tüm durumu depodan yeniden oluşturulabilir
Operasyonel Faydalar
- Hız - Tespitler günler değil dakikalar içinde üretime giriyor
- Tutarlılık - Kalite standartları eşit şekilde uygulanır
- Denetim İzi - Uyumluluk için tam izlenebilirlik
- İşbirliği - Aynı depoya birden fazla ekip katkıda bulunabilir
Kod Olarak Algılama Havuzunun Yapısı
detections/
rules/
credential_access/
lsass_memory_access.yml
brute_force_login.yml
kerberoasting.yml
execution/
powershell_encoded_command.yml
suspicious_wmi_execution.yml
lateral_movement/
psexec_usage.yml
rdp_from_unusual_source.yml
persistence/
scheduled_task_creation.yml
registry_run_key.yml
tests/
credential_access/
lsass_memory_access_test.json
brute_force_login_test.json
execution/
powershell_encoded_command_test.json
config/
sigma_config.yml
siem_mappings.yml
exclusions.yml
pipelines/
ci.yml
cd.yml
docs/
CONTRIBUTING.md
STYLE_GUIDE.md
REVIEW_CHECKLIST.md
README.mdTespitler için CI/CD İşlem Hattı
CI/CD algılama ardışık düzeni, taahhütten üretime kadar tüm süreci otomatikleştirir. GitHub Eylemleri için örnek bir yapılandırma aşağıda verilmiştir:
name: Detection CI/CD Pipeline
on:
pull_request:
paths: ['rules/**', 'tests/**']
push:
branches: [main]
paths: ['rules/**']
jobs:
validate:
name: Validate Sigma Rules
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install sigma-cli
run: pip install sigma-cli pySigma-backend-splunk pySigma-backend-elasticsearch
- name: Lint Sigma Rules
run: |
sigma check rules/ --validation-config config/sigma_config.yml
echo "All rules pass validation"
- name: Verify ATT&CK Mapping
run: |
python scripts/verify_attack_tags.py rules/
echo "All rules have valid ATT&CK mappings"
test:
name: Test Detection Logic
needs: validate
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run True Positive Tests
run: |
python scripts/run_tests.py \
--rules-dir rules/ \
--tests-dir tests/ \
--test-type true_positive
- name: Run False Positive Tests
run: |
python scripts/run_tests.py \
--rules-dir rules/ \
--tests-dir tests/ \
--test-type false_positive
- name: Generate Coverage Report
run: python scripts/coverage_report.py --output reports/coverage.json
deploy:
name: Deploy to SIEM
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v4
- name: Convert Sigma to Splunk SPL
run: |
sigma convert \
--target splunk \
--pipeline splunk_windows \
rules/ \
--output converted/splunk/
- name: Deploy to Splunk via API
env:
SPLUNK_TOKEN: ${{ secrets.SPLUNK_API_TOKEN }}
SPLUNK_URL: ${{ secrets.SPLUNK_URL }}
run: |
python scripts/deploy_splunk.py \
--rules-dir converted/splunk/ \
--splunk-url "$SPLUNK_URL" \
--token "$SPLUNK_TOKEN"
- name: Update ATT&CK Coverage Map
run: python scripts/update_attack_coverage.pyKod Olarak Eksiksiz Algılama Akışı
- Algılama mühendisi Git şubesinde yeni bir Sigma kuralı oluşturur
- Kural ve ilgili testlerle birlikte bir Çekme İsteği açar
- CI hattı sözdizimsel doğrulama, TP/FP testi ve ATT&CK eşleme doğrulamasını gerçekleştirir
- Bir hakem, mantığı, dokümantasyonu ve kapsamı kontrol ettikten sonra PR'yi onaylar.
- Ana ile birleştirme, kuralı dönüştüren ve SIEM'e dağıtan CD hattını etkinleştirir
- İzleme kontrol panelleri üretimdeki algılama performansını izler
Etkili Tespitler Yazmak: İlkeler ve Kalıplar
Vasat bir tespit ile mükemmel bir tespit arasındaki fark, tespitin derinliğinde yatmaktadır Yanlış pozitif filtreleme kalitesinde saldırı tekniğinin anlaşılması ve belgelerin eksiksizliği. İşte temel ilkeler.
İlke 1: Araçla Değil, Tekniğe Başlayın
"Mimikatz" için bir tespit yazmayın - "Mimikatz" için bir tespit yazın. teknik di LSASS hafıza erişimi yoluyla kimlik bilgisi dökümü (T1003.001). Bu yaklaşım onu kapsar olanlar da dahil olmak üzere aynı tekniği uygulayan tüm araçlar otomatik olarak gelecekleri henüz bilinmiyor.
İlke 2: Katman Algılamaları (Algılama Piramidi)
Aynı teknik için çok düzeyli algılamayı uygulayın. Hash tabanlı tespit (önemsiz bir şekilde kaçınılabilir) tecrübesiz saldırganları hâlâ yakalayabilirken, Davranış tespiti daha gelişmiş olanları yakalar. Bu katmanlı yaklaşım ve olarak bilinir Derinlikte Tespit.
Prensip 3: Her Zaman İçeriği Belgeleyin
Her tespit şunları içermelidir: motivasyon (neden bu tespit mevcut), ATT&CK haritalaması (hangi tekniği kapsıyor), i yanlış bilinen pozitifler (hangi meşru faaliyetlerin kuralı tetikleyebileceği) ve yanıt başucu kitabı (tespit tetiklendiğinde analistin yapması gereken şey).
Tam Örnek: Günlük Analizi Python ile Tespit
"""
Brute Force Detection Module
MITRE ATT&CK: T1110.001 - Brute Force: Password Guessing
Detects multiple failed login attempts followed by a success.
"""
from dataclasses import dataclass, field
from datetime import datetime, timedelta
from collections import defaultdict
from typing import Optional
@dataclass(frozen=True)
class LoginEvent:
"""Immutable representation of a login event."""
timestamp: datetime
username: str
source_ip: str
success: bool
service: str # 'ssh', 'rdp', 'web', 'vpn'
@dataclass(frozen=True)
class BruteForceAlert:
"""Immutable alert generated by the detector."""
username: str
source_ip: str
failed_count: int
time_window_minutes: int
first_attempt: datetime
last_attempt: datetime
successful_login: bool
severity: str # 'medium', 'high', 'critical'
mitre_technique: str = "T1110.001"
@dataclass(frozen=True)
class DetectionConfig:
"""Immutable configuration for brute force detection."""
failed_threshold: int = 5
time_window_minutes: int = 10
lockout_threshold: int = 20
whitelist_ips: tuple = ()
monitored_services: tuple = ('ssh', 'rdp', 'web', 'vpn')
class BruteForceDetector:
"""Stateless brute force detection engine.
Analyzes login events and produces alerts when
brute force patterns are detected.
"""
def __init__(self, config: Optional[DetectionConfig] = None):
self._config = config or DetectionConfig()
def analyze(self, events: list[LoginEvent]) -> list[BruteForceAlert]:
"""Analyze a batch of login events for brute force patterns.
Returns a new list of alerts (no mutation of input).
"""
# Group events by (source_ip, username)
grouped = defaultdict(list)
for event in events:
if (event.service in self._config.monitored_services
and event.source_ip not in self._config.whitelist_ips):
key = (event.source_ip, event.username)
grouped[key].append(event)
alerts = []
for (source_ip, username), user_events in grouped.items():
sorted_events = sorted(user_events, key=lambda e: e.timestamp)
alert = self._check_brute_force(source_ip, username, sorted_events)
if alert is not None:
alerts.append(alert)
return alerts
def _check_brute_force(
self, source_ip: str, username: str, events: list[LoginEvent]
) -> Optional[BruteForceAlert]:
"""Check if events match a brute force pattern."""
window = timedelta(minutes=self._config.time_window_minutes)
failed_events = [e for e in events if not e.success]
if len(failed_events) < self._config.failed_threshold:
return None
# Check if failures cluster within the time window
for i, start_event in enumerate(failed_events):
window_end = start_event.timestamp + window
window_failures = [
e for e in failed_events[i:]
if e.timestamp <= window_end
]
if len(window_failures) >= self._config.failed_threshold:
# Check for subsequent successful login
success_after = any(
e.success and e.timestamp >= start_event.timestamp
for e in events
)
severity = self._calculate_severity(
len(window_failures), success_after
)
return BruteForceAlert(
username=username,
source_ip=source_ip,
failed_count=len(window_failures),
time_window_minutes=self._config.time_window_minutes,
first_attempt=window_failures[0].timestamp,
last_attempt=window_failures[-1].timestamp,
successful_login=success_after,
severity=severity,
)
return None
def _calculate_severity(self, failed_count: int, success: bool) -> str:
"""Determine alert severity based on pattern characteristics."""
if success and failed_count >= self._config.lockout_threshold:
return "critical" # Many failures + success = likely compromised
if success:
return "high" # Fewer failures + success = suspicious
if failed_count >= self._config.lockout_threshold:
return "high" # Many failures = active attack
return "medium" # Moderate failures = possible attackMITRE ATT&CK: Referans Çerçevesi
çerçeve GÖNYE ATT&CK (Düşman Taktikleri, Teknikleri ve Ortak Bilgi) ve rakiplerin tekniklerini haritalamak ve sınıflandırmak için evrensel referans. ATT&CK, Tespit Mühendisliği için tanımlamak için ortak bir dil sağlar. Ne ölçmek için bir matris arıyoruz kapsama bizimki tespit.
Tespit Mühendisliği için ATT&CK Nasıl Kullanılır?
- Önceliklendirme - Tüm ATT&CK teknikleri eşit yaratılmamıştır kuruluşunuzla alakalı. Rakipler tarafından en çok kullanılan teknikleri belirleyin kendi sektörünüzde (tehdit istihbaratı) ve kaynakları bunlara yoğunlaştırın.
- Boşluk Analizi - Mevcut tespitleri ATT&CK teknikleriyle eşleştirin kaplanmamış alanları görüntülemek için. Şunu kullanın: ATT&CK Navigatörü için Geçerli kapsama alanını gösteren ısı haritaları oluşturun.
-
Etiketleme - Her Sigma ve tespit kuralı ATT&CK etiketlerini içermelidir
karşılık gelen (örn.
attack.t1003.001). Bu, verileri toplamanızı sağlar teknik ve taktik için ölçümler. - Ölçüm - Her taktik için kapsanan tekniklerin yüzdesini takip edin (İlk Erişim, Yürütme, Kalıcılık vb.) ve gerçekçi kapsam hedeflerini tanımlayın.
| Taktikler | Örnek teknikler | Temel Veri Kaynakları | Zorluk Tespiti |
|---|---|---|---|
| İlk Erişim | T1566 Kimlik Avı, T1190 Herkese Açık Uygulamadan Yararlanma | E-posta, WAF, proxy | Ortalama |
| Uygulamak | T1059 Komut Satırı, T1204 Kullanıcı Yürütme | Sysmon, EDR, işlem günlükleri | Düşük-Orta |
| Kalıcılık | T1053 Zamanlanmış Görev, T1547 Önyükleme Otomatik Başlatma | Kayıt defteri, dosya sistemi, EDR | Ortalama |
| Ayrıcalık Yükseltmesi | T1068 Suistimal, T1078 Geçerli Hesaplar | EDR, AD günlükleri, bulut denetimi | Yüksek |
| Savunmadan Kaçınma | T1070 Göstergesinin Kaldırılması, T1027 Gizleme | EDR, Sysmon, AMSI | Çok Yüksek |
| Kimlik Bilgisi Erişimi | T1003 İşletim Sistemi Kimlik Bilgilerinin Boşaltılması, T1110 Kaba Kuvvet | EDR, AD günlükleri, kimlik doğrulama günlükleri | Ortalama |
| Yanal Hareket | T1021 Uzaktan Hizmetler, T1570 Yanal Takım Transferi | Ağ, AD günlükleri, EDR | Yüksek |
| Sızma | T1048 Alt Protokolü Üzerinden Sızma, T1567 Web Hizmeti | DLP, proxy, DNS, NetFlow | Çok Yüksek |
Ekip Yapısı ve Rolleri
Etkili bir Tespit Mühendisliği programı, becerilerin bir kombinasyonunu gerektirir nadiren tek bir kişide bulunur. Ekip yapısı duruma göre değişir Kuruluşun büyüklüğü, ancak kilit roller iyi tanımlanmıştır.
Anahtar Roller
- Tespit Mühendisi - Merkezi rol. Kuralları yazar, test eder ve korur tespit etme. Tehdit istihbaratı, SIEM sorgu dilleri ve komut dosyası oluşturma konularında beceriler gerektirir (Python) ve hedef platform günlüklerine aşinalık. SANS Anketi 2025'e göre, Kuruluşların %60'ında en az bir özel tespit mühendisi vardır.
- Tehdit İstihbaratı Analisti - Tehditlerle ilgili bağlam sağlar: hangileri APT grupları aktif, hangi teknikleri kullanıyorlar, hangi göstergeleri arayacaklar. Onları besliyor eyleme geçirilebilir zeka ile tespit hipotezi.
- Veri Mühendisi / Günlük Mimarı - Kalite ve kullanılabilirlik ile ilgili fırsatlar veri: yeni günlük kaynaklarının eklenmesi, normalleştirme, ayrıştırma ve yönetim toplama altyapısına sahiptir.
- SOC Analisti - Tespitlerin son kullanıcısı. Geri bildirim sağlar Uyarıların kalitesi açısından temel nokta: çok fazla yanlış pozitif mi var? Uyarı uygulanamaz mı? İçerik bilgisi mi eksik?
- Kırmızı Takım / Mor Takım - Doğrulamak için rakiplerin tekniklerini simüle edin tespitler. Kırmızı takım geri bildirimi iyileştirmenin en etkili mekanizmasıdır kapsam ve kurallara bağlılık.
Küçük Ekipler Organizasyonu
Her kuruluşun özel bir Tespit Mühendisliği ekibini karşılayabilmesi mümkün değildir. Daha küçük güvenlik ekipleri (3-5 kişi) için önerilen yaklaşım şudur:
- Ata Zamanın %20-30'u Detection Engineering'deki SOC analistlerinin oranı
- Evlat edinmek Sigma topluluk kuralları temel olarak (SigmaHQ deposu)
- Bir uygulama yapılandırılmış geri bildirim süreci uyarı triyajından
- Kullanmak Kod Olarak Algılama basit işlem hatlarıyla bile (Git + dağıtım komut dosyası)
- Odaklan En alakalı 10-15 ATT&CK tekniği sektörünüz için
Gerçek Durum: Kazadan Tespit Boru Hattına
Tartışılan kavramları somut hale getirmek için gerçekçi bir örnek görelim. üretimde bir boşluğun keşfedilmesinden tespit edilmesine kadar olan tüm yol.
Senaryo: PowerShell Kodlanmış Komutu Aracılığıyla Güvenlik Güvenliğinin Aşılması
Mor bir ekip çalışması sırasında Kırmızı Takım, kötü niyetli bir veri yüklemeyi başarır
PowerShell'i Base64 kodlu bir komutla kullanma (-EncodedCommand).
Saldırı, yalnızca arama yaptığı için mevcut tespitlerle tespit edilemiyor
genel kodlama deseni değil, bilinen PowerShell komutlarının belirli dizeleri.
Adım 1: Hipotez ve Analiz
Tespit mühendisi hipotezi formüle eder: "PowerShell'in herhangi bir kullanımı
-Kurumsal bir ortamda EncodedCommand şüpheli olarak değerlendirilmelidir çünkü
Yasal yazılımın nadiren komutlarını kodlaması gerekir." Analiz
Son 30 güne ait günlüklerin sonuçları şunu doğruluyor: 50.000 PowerShell yürütmesinden yalnızca 12'si kullanıldı
-EncodedCommandve tümü bilinen bir BT otomasyon komut dosyasına atfedilebilir.
Adım 2: Sigma Kuralı
title: Suspicious PowerShell Encoded Command Execution
id: f4a3b2c1-d5e6-7890-abcd-ef0123456789
status: test
description: |
Detects execution of PowerShell with encoded commands (-enc,
-EncodedCommand). Legitimate use is rare in enterprise environments.
Attackers commonly use this to obfuscate malicious payloads.
author: Federico Calo
date: 2025/12/01
modified: 2025/12/15
references:
- https://attack.mitre.org/techniques/T1059/001/
- https://attack.mitre.org/techniques/T1027/010/
logsource:
category: process_creation
product: windows
detection:
selection_powershell:
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
selection_encoded:
CommandLine|contains:
- '-enc '
- '-EncodedCommand'
- '-encodedcommand'
- '-ec '
filter_known_automation:
ParentImage|endswith: '\sccm_agent.exe'
User|contains: 'SVC_AUTOMATION'
condition: selection_powershell and selection_encoded and not filter_known_automation
falsepositives:
- SCCM automation scripts (filtered)
- Custom IT automation using encoded commands (add to filter)
level: high
tags:
- attack.execution
- attack.t1059.001
- attack.defense_evasion
- attack.t1027.0103. Adım: Test Etme, Dağıtım ve Sonuçlar
Kural, 5 gerçek pozitif senaryo (kodlanmış komutun varyantları) ve 20 gerçek pozitif senaryo ile test edilmiştir. yanlış negatif senaryolar (meşru PowerShell yürütmeleri). Boru hattı yoluyla dağıtımdan sonra CI/CD, ilk 30 günde tespit 8 uyarı oluşturur: 6 gerçek pozitif (şüpheli komut dosyaları) analiz edilecek), 1 hatalı pozitif (filtreye eklenecek yeni otomasyon komut dosyası) ve yetkisiz erişimin tespit edilmesine yol açan 1 kritik gerçek pozitif.
Ölçülebilir Sonuçlar
- Kesinlik: %87,5 (toplam 8 uyarıdan 7 TP)
- MTTD: "algılanmadı"dan 4,2 dakikaya düşürüldü (ortalama uyarı oluşturma süresi)
- ATT&CK kapsamı: Haritaya +2 teknik (T1059.001, T1027.010) eklendi
- Gerçek etki: 45 dakika içinde keşfedilen ve kontrol altına alınan 1 aktif bozukluk
Sonuçlar ve Sonraki Adımlar
Tespit Mühendisliği güvenlikte temel bir paradigma değişimini temsil ediyor operasyonel. Bu sadece SIEM'de daha iyi kurallar yazmakla ilgili değil, aynı zamanda bir komple mühendislik süreci tüm yaşam döngüsünü kapsayan Tespitlerin sayısı: Tehdit hipotezinden üretimdeki doğrulamaya kadar.
Hatırlanması gereken önemli noktalar:
- Kalite miktarı yener - 50 yüksek doğruluklu algılama sonsuzdur Uyarı gürültüsü üreten 5.000 kuraldan daha kullanışlıdır.
- Algılamaları kod olarak ele alın - Sürüm oluşturma, kod incelemesi, otomatik testler ve CI/CD işlem hatları isteğe bağlı değil, temeldir.
- Her şeyi ölçün - MTTD, MTTR, hassasiyet, geri çağırma, ATT&CK kapsamı. olmadan ölçütlere göre sürekli iyileştirme imkansızdır.
- Teknikten başlayın - Tespitleri MITRE ATT&CK ile eşleyin ve konsantre olun Kuruluşunuzla en alakalı tekniklerle ilgili kaynaklar.
- Veri kalitesine yatırım yapın - Onsuz mükemmel ve işe yaramaz bir tespit üzerinde çalışılacak veriler. Günlük kaynaklarının normalleştirilmesi ve eklenmesi, tüm programın görünmez temeli.
Bir sonraki makalede
Serinin bir sonraki makalesinde bunları daha derinlemesine inceleyeceğiz. Sigma kuralları: Taşınabilir tespitlerin yazılması için standart format. Sözdiziminin tamamını göreceğiz, büyük SIEM'ler için gelişmiş değiştiriciler, dönüşüm arka uçları ve biz bunları derleyeceğiz En kritik ATT&CK teknikleri için eksiksiz bir kurallar dizisi.