Microsoft Sentinel ile Güvenlik Olayı İzleme ve Yönetimi

Yazar:komut.io ekibi
0 Yorum

Güvenlik ekibinin gece 2’de panikle seni araması, logların her yerde dağınık olması, hangi olayın gerçek tehdit olduğunu anlayamamak… Bunları yaşadıysan Microsoft Sentinel’in neden bu kadar popüler olduğunu anlarsın. Sentinel, Microsoft’un bulut tabanlı SIEM (Security Information and Event Management) ve SOAR (Security Orchestration, Automated Response) çözümü. Doğru yapılandırıldığında hem log toplayıcısı hem tehdit dedektörü hem de otomatik müdahale aracı olarak çalışıyor. Bu yazıda sıfırdan Sentinel kurulumundan gerçek dünya senaryolarına kadar her şeyi ele alacağız.

Microsoft Sentinel Nedir ve Neden Önemli?

Geleneksel SIEM çözümleri (IBM QRadar, Splunk gibi) on-premise altyapı gerektiriyordu. Lisans maliyetleri, donanım yatırımları ve bakım yükü küçük-orta ölçekli ekipleri zorluyordu. Sentinel ise Azure üzerinde çalışıyor, kullandığın kadar ödersin modeliyle devreye giriyor ve Azure’un ölçeklenebilirliğinden faydalanıyor.

Sentinel’in temel bileşenleri şunlar:

  • Log Analytics Workspace: Tüm log verilerinin toplandığı merkezi depo
  • Data Connectors: Farklı kaynaklardan log çeken bağlayıcılar
  • Analytics Rules: Tehditleri tespit eden kural motoru
  • Incidents: Oluşturulan güvenlik olayları
  • Playbooks: Logic Apps tabanlı otomatik müdahale senaryoları
  • Workbooks: Görsel dashboard’lar
  • Threat Intelligence: IOC ve TTP entegrasyonları

Sentinel Workspace Kurulumu

Önce Azure üzerinde Log Analytics Workspace oluşturman gerekiyor. Azure CLI ile bunu hızlıca yapabilirsin:

# Azure'a giriş yap
az login

# Resource group oluştur
az group create 
  --name rg-sentinel-prod 
  --location eastus

# Log Analytics Workspace oluştur
az monitor log-analytics workspace create 
  --resource-group rg-sentinel-prod 
  --workspace-name law-sentinel-prod 
  --location eastus 
  --sku PerGB2018 
  --retention-time 90

# Microsoft Sentinel'i workspace'e ekle
az sentinel onboarding-state create 
  --resource-group rg-sentinel-prod 
  --workspace-name law-sentinel-prod 
  --name default

Retention süresini 90 gün olarak ayarladım. Compliance gereksinimlerine göre 30’dan 730 güne kadar uzatabilirsin, ancak maliyet artacaktır. Ücretsiz tier 31 GB/gün’e kadar veri alımını kapsıyor, sonrası ücretli.

Data Connector Yapılandırması

Sentinel’in değer üretmesi için log kaynaklarını bağlaman gerekiyor. En kritik connectorlar şunlar:

  • Microsoft Defender for Endpoint: Endpoint telemetrisi
  • Azure Active Directory: Sign-in logları ve audit logları
  • Office 365: Exchange, SharePoint, Teams aktiviteleri
  • Azure Activity: Azure kaynak değişiklikleri
  • Windows Security Events: Domain controller ve üye sunucu logları
  • Syslog: Linux sunucu logları
  • CEF (Common Event Format): Firewall ve ağ cihazı logları

Windows güvenlik olaylarını toplamak için Azure Monitor Agent’ı Windows Server’lara deploy etmen gerekiyor:

# Azure Arc ile on-premise Windows sunucuyu kaydet
# Önce Arc agent'ı indir ve kur (Windows Server'da PowerShell ile)
# Sonra Data Collection Rule oluştur

az monitor data-collection rule create 
  --resource-group rg-sentinel-prod 
  --location eastus 
  --name dcr-windows-security-events 
  --data-flows '[{
    "streams": ["Microsoft-SecurityEvent"],
    "destinations": ["law-sentinel-prod"]
  }]' 
  --data-sources '{
    "windowsEventLogs": [{
      "name": "windowsSecurityEvents",
      "streams": ["Microsoft-SecurityEvent"],
      "xPathQueries": [
        "Security!*[System[(EventID=4624)]]",
        "Security!*[System[(EventID=4625)]]",
        "Security!*[System[(EventID=4648)]]",
        "Security!*[System[(EventID=4688)]]",
        "Security!*[System[(EventID=4698)]]",
        "Security!*[System[(EventID=4720)]]",
        "Security!*[System[(EventID=4726)]]"
      ]
    }]
  }'

Buradaki EventID’lere dikkat et. 4624 başarılı oturum açma, 4625 başarısız oturum açma, 4648 farklı kimlik bilgileriyle oturum açma girişimi, 4688 yeni process oluşturma, 4698 scheduled task oluşturma anlamına geliyor. Bunlar saldırı zincirinin en kritik izleme noktaları.

KQL ile Log Sorgulama

Sentinel, Kusto Query Language (KQL) kullanıyor. KQL’i öğrenmek başta zor gelebilir ama birkaç temel sorguyu kavradıktan sonra çok güçlü analizler yapabiliyorsun.

Brute Force Tespiti

Kısa sürede çok sayıda başarısız giriş denemesi klasik bir brute force göstergesi:

# KQL - Son 1 saatte 10'dan fazla başarısız giriş denemesi
SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID == 4625
| where AccountType == "User"
| summarize FailedAttempts = count(), 
            TargetAccounts = make_set(TargetUserName),
            FirstAttempt = min(TimeGenerated),
            LastAttempt = max(TimeGenerated)
    by IpAddress
| where FailedAttempts > 10
| order by FailedAttempts desc

Impossible Travel Tespiti

Bir kullanıcının coğrafi olarak imkansız iki farklı konumdan giriş yapması hesap ele geçirme belirtisi olabilir:

# KQL - Aynı kullanıcının 1 saat içinde farklı ülkelerden girişi
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, 
          Location, IPAddress,
          CountryOrRegion = LocationDetails.countryOrRegion
| sort by UserPrincipalName, TimeGenerated asc
| extend PrevCountry = prev(CountryOrRegion, 1),
         PrevUser = prev(UserPrincipalName, 1),
         PrevTime = prev(TimeGenerated, 1)
| where UserPrincipalName == PrevUser
| where CountryOrRegion != PrevCountry
| where datetime_diff('minute', TimeGenerated, PrevTime) < 60
| project TimeGenerated, UserPrincipalName, 
          FromCountry = PrevCountry, 
          ToCountry = CountryOrRegion,
          IPAddress

Yetkisiz Scheduled Task Tespiti

Saldırganlar persistence için scheduled task kullanır. EventID 4698 bu aktiviteyi yakalar:

# KQL - İş saatleri dışında oluşturulan scheduled task'lar
SecurityEvent
| where EventID == 4698
| extend TaskName = tostring(EventData.TaskName),
         TaskContent = tostring(EventData.TaskContent),
         SubjectUserName = tostring(EventData.SubjectUserName)
| where hourofday(TimeGenerated) < 8 or hourofday(TimeGenerated) > 18
| where dayofweek(TimeGenerated) !in (6, 7)
| project TimeGenerated, Computer, SubjectUserName, TaskName
| order by TimeGenerated desc

Analytics Rules Oluşturma

KQL sorgularını Scheduled Analytics Rules’a dönüştürmek Sentinel’in kalbi. Portaldan da yapabilirsin ama ARM template ile kod olarak yönetmek çok daha iyi bir pratik:

# Azure CLI ile analytics rule oluşturma örneği
# Önce rule template JSON hazırla, sonra deploy et

az sentinel alert-rule create 
  --resource-group rg-sentinel-prod 
  --workspace-name law-sentinel-prod 
  --rule-id "brute-force-detection-001" 
  --rule-name "Brute Force Saldırı Tespiti" 
  --rule-type Scheduled 
  --enabled true 
  --severity High 
  --query "SecurityEvent | where EventID == 4625 | summarize count() by IpAddress | where count_ > 10" 
  --query-frequency PT1H 
  --query-period PT1H 
  --trigger-operator GreaterThan 
  --trigger-threshold 0 
  --tactics "CredentialAccess" 
  --techniques "T1110"

Rule’lara MITRE ATT&CK taktiklerini (--tactics) ve tekniklerini (--techniques) etiketlemek önemli. Bu, olayların otomatik olarak saldırı çerçevesine göre sınıflandırılmasını sağlıyor ve SOC analistlerinin önceliklendirme yapmasını kolaylaştırıyor.

Gerçek Dünya Senaryosu: Ransomware İndikatörlerini İzleme

Geçen yıl bir müşteriyle yaşadığım gerçek bir senaryoyu paylaşayım. Finans sektöründen bir şirkette, hafta sonu gece 3’te bir sunucuda olağandışı dosya erişim örüntüsü başladı. Saldırgan sistemde zaten 2 gündür sessizce keşif yapıyordu. Sentinel olmasaydı bunu ancak zararın boyutu ortaya çıktıktan sonra anlardık.

Ransomware aktivitesini önceden yakalamak için şu sorgular hayat kurtarır:

# KQL - Toplu dosya silme veya şifreleme girişimi tespiti
// Kısa sürede yüksek sayıda dosya erişimi (olası ransomware)
DeviceFileEvents
| where TimeGenerated > ago(1h)
| where ActionType in ("FileCreated", "FileModified", "FileRenamed")
| where FileName endswith ".encrypted" 
    or FileName endswith ".locked"
    or FileName endswith ".crypto"
    or FolderPath contains "\AppData\"
| summarize FileCount = count(), 
            UniqueExtensions = dcount(FileName),
            FilePaths = make_set(FolderPath, 10)
    by DeviceName, InitiatingProcessFileName, 
       InitiatingProcessAccountName
| where FileCount > 100
| project TimeGenerated = now(), DeviceName, 
          InitiatingProcessFileName,
          InitiatingProcessAccountName,
          FileCount, FilePaths

// Aynı anda shadow copy silme girişimi
SecurityEvent
| where EventID == 4688
| where CommandLine has "vssadmin" and CommandLine has "delete"
    or CommandLine has "wbadmin" and CommandLine has "delete"
    or CommandLine has "bcdedit" and CommandLine has "recoveryenabled No"
| project TimeGenerated, Computer, Account, CommandLine
| order by TimeGenerated desc

Bu sorguların ikincisi özellikle kritik. Ransomware’lerin neredeyse tamamı sistemi şifrelemeden önce shadow copy’leri siliyor. Bu komutu gördüğün anda zaten geç kalmış olabilirsin ama Sentinel ile bunu tetikleyici olarak kullanıp otomatik müdahale başlatabilirsin.

Playbook ile Otomatik Müdahale

Bir incident oluştuğunda elle müdahale yerine Logic Apps tabanlı Playbook’lar devreye girebilir. Şüpheli IP adresini otomatik olarak firewall’a ekleme, kullanıcı hesabını devre dışı bırakma, SOC ekibine Teams mesajı gönderme gibi aksiyonlar dakikalar içinde gerçekleşebilir.

# Playbook tetikleme için Sentinel Automation Rule oluşturma
az sentinel automation-rule create 
  --resource-group rg-sentinel-prod 
  --workspace-name law-sentinel-prod 
  --automation-rule-name "auto-respond-brute-force" 
  --display-name "Brute Force Otomatik Müdahale" 
  --order 1 
  --triggering-logic '{
    "isEnabled": true,
    "triggersOn": "Incidents",
    "triggersWhen": "Created",
    "conditions": [
      {
        "conditionType": "Property",
        "conditionProperties": {
          "propertyName": "IncidentTactics",
          "operator": "Contains",
          "propertyValues": ["CredentialAccess"]
        }
      },
      {
        "conditionType": "Property",
        "conditionProperties": {
          "propertyName": "IncidentSeverity",
          "operator": "Contains",
          "propertyValues": ["High"]
        }
      }
    ]
  }' 
  --actions '[{
    "order": 1,
    "actionType": "RunPlaybook",
    "actionConfiguration": {
      "triggerBy": "Incident",
      "logicAppResourceId": "/subscriptions/SUB_ID/resourceGroups/rg-sentinel-prod/providers/Microsoft.Logic/workflows/playbook-block-ip"
    }
  }]'

Watchlist ile Bağlam Zenginleştirme

Sentinel’in en az konuşulan ama en değerli özelliklerinden biri Watchlist. Kendi verilerini (VIP kullanıcı listesi, kritik sunucu IP’leri, bilinen kötü IP’ler, izin verilen ülkeler) Sentinel’e yükleyip sorgularda kullanabilirsin.

# CSV formatında watchlist yükleme
az sentinel watchlist create 
  --resource-group rg-sentinel-prod 
  --workspace-name law-sentinel-prod 
  --watchlist-alias "vip-users" 
  --display-name "VIP Kullanıcılar" 
  --provider "Microsoft" 
  --source "Local File" 
  --items-search-key "UserPrincipalName" 
  --raw-content "$(base64 -w 0 vip-users.csv)"

# KQL'de watchlist kullanımı
# VIP kullanıcıların başarısız girişlerini yüksek öncelikli izle
let VIPUsers = _GetWatchlist('vip-users') | project UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != 0
| where UserPrincipalName in (VIPUsers)
| project TimeGenerated, UserPrincipalName, 
          IPAddress, ResultDescription,
          LocationDetails
| order by TimeGenerated desc

Maliyet Optimizasyonu

Sentinel maliyetleri log hacmiyle doğrudan ilişkili. Yanlış yapılandırılmış bir connector ile aylık binlerce dolar fatura yiyebilirsin. Birkaç kritik öneri:

  • Verbose logları filtrele: Tüm Windows Event loglarını değil, sadece güvenlik açısından kritik EventID’leri topla
  • Commitment Tier kullan: Günlük 100 GB üzeri hacimde commitment tier PAYG’den %60’a kadar ucuz
  • Data tier’ı doğru seç: Her logun Sentinel’e gitmesi gerekmez, bazı veriler sadece Log Analytics’te tutulabilir
  • Retention’ı optimize et: Compliance gerektirmiyorsa 90 gün yeterli, 2 yıl tutmak gereksiz maliyet
  • Tekilleştirme yap: Aynı logu hem Defender hem de Sentinel’e göndermek gereksiz
# Hangi tablo ne kadar veri tüketiyor?
# Bu sorguyu Sentinel'de çalıştır
Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize TotalGB = sum(Quantity) / 1000
    by DataType
| order by TotalGB desc
| take 20

Bu sorgu sana en fazla maliyet yaratan log kaynaklarını gösterir. Genellikle ilk 3-5 tablo toplam maliyetin %70-80’ini oluşturur.

Incident Management ve SOC İş Akışı

Sentinel’de bir incident oluştuğunda SOC analistinin izlemesi gereken standart bir süreç olmalı. Her ekibin kendi playbook’u farklıdır ama genel akış şu şekilde işliyor:

  • Triage: Incident’ın gerçek tehdit mi yoksa false positive mi olduğunu belirle
  • Severity assessment: Etkilenen varlıkların kritikliğine göre öncelik ver
  • Scope determination: Lateral movement var mı, başka sistemler etkilenmiş mi?
  • Containment: Tehdit kaynağını izole et (IP bloklama, hesap devre dışı bırakma)
  • Evidence collection: Logları ve artifact’ları kayıt altına al
  • Eradication: Kötü amaçlı dosyaları temizle, backdoor’ları kapat
  • Recovery: Sistemleri güvenli duruma getir
  • Post-incident review: Nasıl daha iyi yapılabilirdi?

Sentinel’in “Investigation Graph” özelliği lateral movement analizi için son derece değerli. Tek bir incident’ın etkilediği kullanıcıları, cihazları ve IP adreslerini görsel olarak haritalar.

UEBA ile İçeriden Tehdit Tespiti

User and Entity Behavior Analytics (UEBA), Sentinel’in yapay zeka tabanlı anomali tespit motorudur. Her kullanıcı ve cihaz için normal davranış profili oluşturur, sapmalar olduğunda puanlama yapar.

UEBA’yı etkinleştirmek için:

  • Azure AD identity provider olarak yapılandırılmış olmalı
  • En az 7 gün boyunca davranışsal baseline oluşturmalı
  • Anomaly detection modelleri aktif olmalı

UEBA’nın tespit ettiği anomali tipleri:

  • Unusual sign-in activity: Alışılmadık saat, konum, cihaz kombinasyonu
  • Unusual data access: Normalden çok daha fazla dosya erişimi
  • Unusual resource access: Daha önce hiç erişmediği kaynaklara erişim
  • Peer group anomaly: Aynı departmandaki diğer kullanıcılara göre sapma

Tehdit İstihbaratı Entegrasyonu

Threat Intelligence Platforms (TIP) ile Sentinel’i entegre etmek IOC (Indicator of Compromise) tabanlı tespiti güçlendirir. MISP, Anomali ThreatStream veya direkt STIX/TAXII feed’leri bağlayabilirsin.

# TAXII server bağlantısı oluşturma
az sentinel threat-intelligence-indicator create 
  --resource-group rg-sentinel-prod 
  --workspace-name law-sentinel-prod 
  --indicator-name "malicious-ip-feed" 
  --kind "ipv4-addr" 
  --pattern "[ipv4-addr:value = '185.220.101.0/24']" 
  --pattern-type "stix" 
  --source "Custom TI Feed" 
  --valid-from "2024-01-01T00:00:00Z" 
  --confidence 85 
  --threat-types "malicious-activity"

Threat Intelligence’ı aktif hale getirince, log’larınızdaki IP, domain ve hash değerleri otomatik olarak bilinen kötü amaçlı göstergelerle eşleştiriliyor. Bu tamamen manuel süreçleri ortadan kaldırıyor.

Sonuç

Microsoft Sentinel, doğru yapılandırıldığında bir SOC ekibinin görüş alanını dramatik biçimde genişletiyor. Salt log toplayıcısı olmaktan çıkıp korelasyon motoru, anomali dedektörü ve otomatik müdahale platformuna dönüşüyor.

Başlangıç için şu sırayı takip etmeni öneririm: Önce kritik kaynaklardan log toplamayı başlat (AD, endpoint, firewall). Sonra temel analytics rule’ları devreye al. UEBA baseline oluşması için birkaç hafta bekle. İlk playbook’ları basit tutarak başla, giderek karmaşıklaştır. Maliyet takibini asla ihmal etme.

Sentinel bir araç, onu değerli kılan ise arkasındaki süreçler ve insanlar. En iyi SIEM bile kötü yapılandırılmış, süreçsiz ortamda gürültü üretir. Ama iyi tasarlanmış bir Sentinel ortamında gece 2’deki telefon yerine sabah 8’de detaylı bir incident raporu seni karşılıyor. Ve bu fark, gerçekten her şeyi değiştiriyor.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir