1. IoC tipleri ve eşleştirme stratejisi

IoC (Indicator of Compromise); bir uzlaşmanın gözlemlenmiş teknik izidir. SiberAnaliz beslemesinde dört temel IoC tipi yer alır: IPv4/IPv6, domain, URL ve dolaylı olarak gösterge bağlamında zikredilen hash değerleri. Her bir tip, log akışında farklı bir alanla eşleşir; korelasyon mühendisliği bu eşleştirmenin disiplinidir.

IP Firewall, proxy, NetFlow, EDR network telemetry, web sunucu erişim logları — src_ip, dst_ip, client_ip, remote_addr alanlarında aranır.
DM DNS query logları, proxy, TLS SNI, mail gateway — query, tls_sni, host alanlarında aranır.
URL Web proxy, WAF, mail gateway link tarayıcı — url, request, referer alanlarında aranır.
HSH EDR proses oluşturma olayları, AV tarama, indirme logları — sha256, md5, imphash alanlarında aranır.

Genel desen: bir lookup tablosu (SiberAnaliz beslemesi) ile bir olay akışı (log) arasında, IoC alanı üzerinden join. Bu join SIEM motoruna göre farklı sözdizimi alır; mantığı aynıdır.

2. Sigma kural formatı

Sigma; log korelasyon kuralları için fiili (de facto) açık standarttır. Bir kez yazılır, sigmac derleyicisi ile platform-spesifik (Splunk, Elastic, Sentinel, QRadar) çıktıya dönüştürülür. Threat intel beslemesinin platform bağımsız taşınmasında kritiktir.

title: SiberAnaliz Tehdit IP'sine Outbound Bağlantı
id: 4f1d2c7e-9b3a-4e8b-9c0d-1a2b3c4d5e6f
status: experimental
description: |
  Bir iç istemciden SiberAnaliz beslemesinde yer alan zararlı bir
  IP adresine doğru outbound TCP/UDP bağlantı tespit eder.
references:
  - https://siberanaliz.com/rehber/siem-kurali
author: SOC Team
date: 2026/05/27
logsource:
  category: firewall
  product: any
detection:
  selection:
    action: 'allow'
    direction: 'outbound'
    dst_ip|expand: '%SiberAnalizIPList%'
  filter_internal:
    dst_ip|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: selection and not filter_internal
fields:
  - src_ip
  - dst_ip
  - dst_port
  - app
falsepositives:
  - Güvenlik testleri (kırmızı takım tatbikatları)
  - Yanlış geo-ip etiketlenmiş kurumsal SaaS
level: high
tags:
  - attack.command_and_control
  - attack.t1071

dst_ip|expand: '%SiberAnalizIPList%' notasyonu, derleyici tarafında ilgili platforma uygun bir lookup join'e dönüşür. Sigma'nın değer ekleri (value modifiers) |cidr, |contains, |startswith ifadeleri eşleştirme mantığını ince ayar yapmaya izin verir.

3. Splunk SPL örneği

Splunk'ta strateji şudur: SiberAnaliz CSV'si bir lookup table olarak kaydedilir (sb_threat_ip.csv), ardından log akışı bu lookup ile inputlookup veya doğrudan lookup ile zenginleştirilir.

# 1) Lookup tanımı: $SPLUNK_HOME/etc/apps/threat_intel/local/transforms.conf
[siberanaliz_ip_lookup]
filename = sb_threat_ip.csv
case_sensitive_match = false

# 2) Lookup tablosunu indirip Splunk'a deploy eden cron:
curl -fsSL "https://siberanaliz.com/export.csv?type=ip" \
  | awk -F',' 'NR>1 {gsub(/"/, "", $2); print $2}' \
  | grep -E '^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$' \
  | awk 'BEGIN{print "ip,source,added"} {print $1",siberanaliz,"strftime("%Y-%m-%d",systime())}' \
  > "$SPLUNK_HOME/etc/apps/threat_intel/lookups/sb_threat_ip.csv"

# 3) Korelasyon araması (saved search olarak kaydedilir):
index=firewall action=allow direction=outbound
| lookup siberanaliz_ip_lookup ip AS dst_ip OUTPUT source AS sib_source
| where isnotnull(sib_source)
| where NOT cidrmatch("10.0.0.0/8", dst_ip)
  AND NOT cidrmatch("172.16.0.0/12", dst_ip)
  AND NOT cidrmatch("192.168.0.0/16", dst_ip)
| stats count, values(src_ip) AS src_ips, values(app) AS apps by dst_ip
| eval severity="high", source="SiberAnaliz"

Bu arama Splunk Enterprise Security'de bir correlation search olarak tanımlanır; eşleşme bir Notable Event üretir ve SOAR'a düşer.

4. Elastic EQL örneği

Elastic Security tarafında strateji benzer: SiberAnaliz beslemesi Indicator Index'e yüklenir (ör. threat-intel-siberanaliz), ardından Indicator Match Rule bu indeksi olay indeksi ile join eder.

// Indicator match rule (Kibana Detection Engine)
{
  "name": "Outbound to SiberAnaliz Threat IP",
  "type": "threat_match",
  "language": "kuery",
  "query": "destination.ip:* and network.direction:outbound",
  "index": ["logs-firewall-*", "logs-network-*"],
  "threat_index": ["threat-intel-siberanaliz-*"],
  "threat_query": "threat.indicator.type:\"ipv4-addr\"",
  "threat_mapping": [
    {
      "entries": [{
        "field": "destination.ip",
        "type": "mapping",
        "value": "threat.indicator.ip"
      }]
    }
  ],
  "severity": "high",
  "risk_score": 73,
  "from": "now-10m",
  "interval": "5m"
}

# EQL (Event Query Language) eşdeğeri (ad-hoc avlamak için):
sequence by host.id with maxspan=5m
  [ network where destination.ip in ("203.0.113.10", "198.51.100.42") ]
  [ process where event.action == "network_connection" ]

Indicator Match kuralı sürekli arka planda çalışır ve eşleşmede Alert üretir. SOAR entegrasyonu için kibana.alert.workflow_status alanı kullanılır.

5. Microsoft Sentinel KQL

Microsoft Sentinel'de strateji üç biçim alır: (a) doğrudan externaldata() ile uzaktan CSV'yi anlık okuma; (b) Watchlist nesnesi yükleme; (c) TI bağlayıcı üzerinden ThreatIntelligenceIndicator tablosuna akıtma. Aşağıda en yaygın iki yöntem örneklenmiştir.

// (a) externaldata() ile inline lookup
let SiberAnalizIPs =
    externaldata(ip: string)
    [@"https://siberanaliz.com/export.csv?type=ip"]
    with(format="csv", ignoreFirstRecord=true)
    | project ip = trim('"', ip);

CommonSecurityLog
| where DeviceVendor in ("Fortinet", "Palo Alto Networks", "Cisco")
| where CommunicationDirection == "Outbound"
| where DestinationIP in (SiberAnalizIPs)
| where not(ipv4_is_private(DestinationIP))
| project TimeGenerated, SourceIP, DestinationIP, DestinationPort, DeviceVendor, Activity
| summarize hits = count(), src_count = dcount(SourceIP) by DestinationIP
| where hits > 0

// (b) Watchlist tabanlı (üretim için tercih edilen)
let WL = _GetWatchlist("siberanaliz_ip") | project SearchKey;
DnsEvents
| where SubType == "LookupQuery"
| where Name in (WL)
| project TimeGenerated, ClientIP, Name, ComputerName, ResultCode

Sentinel Analytics Rule'lar bu sorguyu 5 dakikada bir çalıştırır; eşleşme bir Incident üretir. Entity mapping bölümünde SourceIP ve DestinationIP entity olarak işaretlenir.

6. ESET Endpoint custom IoC

ESET PROTECT ve ESET Inspect (EDR) üzerinde custom IoC dosya hash'i, URL ve registry kalıbı olarak tanımlanabilir. Network göstergeleri (IP/domain) doğrudan policy'ye bağlanmak yerine Detection kuralı olarak yazılır.

# ESET Inspect Detection Rule (özet — XML formatı kısaltılmış)
<rule name="SiberAnaliz - Outbound to threat domain">
  <event type="NetworkConnection">
    <condition>
      <operator name="OR">
        <operator name="EQUALS" field="TargetHostname" value="ornek-phish-domeni.tld"/>
        <operator name="EQUALS" field="TargetHostname" value="malware-c2.example"/>
      </operator>
    </condition>
    <severity>High</severity>
    <tags>siberanaliz, c2</tags>
  </event>
</rule>

Yöntem; SiberAnaliz domain göstergelerini bir sürede bir ESET PROTECT API'sine push eden cron script ile beslenir. Detection rule'lar tek tek dosya değil, ESET Inspect'in liste-tabanlı policy'leri üzerinden yönetilir.

7. CrowdStrike Falcon IoC import

CrowdStrike Falcon, IoC Management API üzerinden IP, domain, URL ve hash değerlerini indicator nesneleri olarak alır ve detect, prevent veya allow aksiyonlarına bağlar.

# Falcon IoC API v1 — bulk indicator yükleme
curl -fsSL -X POST \
  -H "Authorization: Bearer $FALCON_TOKEN" \
  -H "Content-Type: application/json" \
  "https://api.crowdstrike.com/iocs/entities/indicators/v1" \
  -d '{
    "indicators": [
      {
        "type": "ipv4",
        "value": "203.0.113.10",
        "action": "detect",
        "severity": "high",
        "platforms": ["windows","mac","linux"],
        "source": "SiberAnaliz",
        "description": "USOM doğrulanmış tehdit IP"
      },
      {
        "type": "domain",
        "value": "ornek-phish-domeni.tld",
        "action": "prevent",
        "severity": "high",
        "platforms": ["windows"],
        "source": "SiberAnaliz"
      }
    ]
  }'

Falcon tarafında action: prevent network bağlantılarını engeller; action: detect yalnızca alert üretir. Üretime alımda önce detect ile 1–2 hafta gözlem yapılır, false positive oranı ölçüldükten sonra prevent'e geçilir.

8. Yara opsiyonel kullanımı

Yara; dosya içeriği desen eşleştirme dilidir. SiberAnaliz beslemesi doğrudan dosya hash'leri sunmasa da, tehdit göstergesi kullanılan dosya kalıntılarını yakalamak için Yara kuralları yazılabilir.

rule SiberAnaliz_Embedded_C2_Domain
{
    meta:
        author      = "SOC Team"
        date        = "2026-05-27"
        reference   = "https://siberanaliz.com/rehber/siem-kurali"
        severity    = "high"

    strings:
        $d1 = "ornek-phish-domeni.tld" ascii wide nocase
        $d2 = "malware-c2.example"    ascii wide nocase
        $u1 = "http://203.0.113.10/"  ascii nocase
        $u2 = "https://198.51.100.42" ascii nocase

    condition:
        any of them
}

Kural EDR (CrowdStrike, ESET Inspect) içinde custom Yara olarak veya VirusTotal Hunting, Velociraptor, osquery ile birlikte çalıştırılabilir. SiberAnaliz domain ve URL beslemesinden script ile strings bloğu otomatik üretilebilir.

9. False positive yönetimi

IoC eşleştirme kurallarının en büyük gerçek dünya sorunu, analist yorgunluğuna yol açan yanlış pozitiflerdir. Üç temel disiplin gerekir:

1 Exclusion listesi: Kurumsal proxy, AV güncelleme, Windows Update, sandbox ve test ortamı IP'leri her kurala özel olarak eklenmelidir.
2 Kritiklik haritalaması: SiberAnaliz 1–10 ham kritiklik puanı yayınlar (1–3 Kritik, 4–5 Yüksek, 6–7 Orta, 8–10 Düşük). SIEM tarafında alert severity bu bant haritasına eşleştirilmelidir; aksi halde her IoC eşleşmesi aynı önem dereceyi alır ve triage çöker.
3 Bağlam zenginleştirme: Alert payload'ı içine kategori kodu (PH/MD/BP), bağlantı tipi (APT C&C, Phishing), son senkron zamanı; analist tek bakışta karar verebilsin.

Korelasyon kuralı yazımı — pratik kalıplar

Tek bir IoC eşleşmesi, yüksek sinyal değeri taşımakla birlikte, çoğu zaman tek başına bir incident üretimine yetmez. Tespit mühendisliği literatüründe kabul edilen pratik, IoC eşleşmesini ikincil bir gözlemle katmanlamaktır. Örneğin "SiberAnaliz domain'ine sorgu" tek başına orta seviyeli bir alert iken, "aynı kaynaktan beş dakika içinde bir DLL yan yüklemesi veya WMI etkinliği" eklendiğinde Kritik seviyeye yükseltilir. Sigma kurallarında condition bloğu selection1 and selection2 biçiminde yazılarak bu katmanlama ifade edilir.

Bir başka yaygın kalıp zamansal tekilleştirmedir (deduplication). Aynı istemci kısa bir süre içinde aynı IoC'ye birden çok kez vurabilir; bu durumda her gözlem ayrı bir alert üretmek yerine, bir zaman penceresi içinde tek bir alert oluşturulup tekrarlar sayım olarak eklenir. Splunk'ta dedup ve bucket _time span=10m, Sentinel'de summarize, Elastic'te alert threshold bölümü bu işlevi karşılar.

Üretim kalitesi için her IoC kuralının üç ek alanı taşıması beklenir: (a) MITRE ATT&CK tekniği (örn. T1071 — Application Layer Protocol), (b) kaynak feed bilgisi (SiberAnaliz / USOM), (c) kritiklik haritalaması. Bu üç alan SOC'un raporlama, KPI takibi ve denetim (audit) süreçlerinin temel girdileridir.

Telemetri kalitesi ve eksik veri

En iyi IoC eşleşme kuralı bile beslendiği log akışından daha kaliteli değildir. Pratikte üç tipik telemetri açığı görülür. Birincisi şifreli trafik görünmezliği: TLS şifreli outbound bağlantılarda yalnızca destination IP ve SNI görünür; URL veya hash gözlemi mümkün değildir. Bu nedenle URL feed'lerinden beslenen kurallar yalnızca HTTP ya da TLS-MITM yapılmış akışlarda anlamlıdır.

İkinci açık DNS log yokluğudur. Sysmon Event ID 22 veya kurumsal DNS query log akışı yoksa, domain feed'lerinden beslenen kurallar hiçbir kaynak bulamaz. Bu, modern saldırı zincirlerinin neredeyse tamamının domain düzeyinde başladığı düşünüldüğünde kritik bir eksikliktir. Sysmon konfigürasyonunun bu event'i mutlaka yakalaması gerekir.

Üçüncü açık NAT/proxy görünmezliğidir: kurumsal proxy arkasından geçen istemci kaynak IP bilgisi proxy IP olarak gözükür. Bu durumda korelasyon x-forwarded-for veya proxy access log üzerinden istemci IP'sine doğru zenginleştirilmelidir; aksi halde tüm alert'ler tek bir proxy IP üzerinde yoğunlaşır ve triage imkansız hale gelir.

Kontrol Listesi

1 IoC tipleri (IP/Domain/URL/Hash) için ayrı korelasyon hatları kuruldu.
2 SiberAnaliz lookup/watchlist saatlik cron ile güncellenir; hata bildirimi aktif.
3 Sigma kuralı yazıldı; Splunk/Elastic/Sentinel için derlenmiş çıktılar repoda.
4 Kural seviyesinde exclusion listesi tanımlandı; kurumsal proxy ve AV trafikleri filtreleniyor.
5 Kritiklik bandı SIEM severity'sine maplenmiş; Kritik → P1, Yüksek → P2.
6 Detect → Prevent geçişi için 1–2 hafta gözlem dönemi planlandı.
7 Alert payload'ı kaynak (SiberAnaliz), kategori ve son senkron zamanı içeriyor.

SiberAnaliz Verisi ile Hızlı Başlangıç

SiberAnaliz /export.csv ve /export.json uç noktaları Splunk lookup, Elastic indicator index ve Sentinel watchlist için doğrudan kullanılabilir; /api/addresses ise sayfalı çekim için uygundur.

Tüm göstergeler (JSON) IPv4 (CSV) Domain (CSV) REST API Göstergeleri gezin