Veri İhlalini Ne Kadar Hızlı Tespit Edersiniz? MTTD Rehberi

Yarın şirketinizin verisi çalınırsa, ne kadar sürede farkına varırsınız? Benim ortamımda tek bir gerçeğe göre plan yapıyorum: küresel ortalama dwell time hâlâ haftalar veya aylarla ölçülüyor, saatlerle değil. İhlal ile tespit arasındaki o boşluk, asıl zararın yaşandığı yerdir. Saldırganlar her şeyi ilk dakikada kapıp götürmezler. Keşfederler, yetki yükseltirler ve zamanla sessizce veri sızdırırlar. Endpoint'lerinize, kimlik loglarınıza ve ağ akışlarınıza dair görünürlüğünüz yoksa, üçüncü bir taraf size söyleyene kadar onları yakalayamazsınız. Ortalama tespit süresini (MTTD) düşürmek, yapabileceğiniz en yüksek ROI'ye sahip güvenlik çalışmasıdır.

Ortalama Tespit Süresi Neden Önlemekten Daha Önemli

Hiçbir savunma mükemmel değildir. Yönettiğim her ortamda bunu kabul ettim. Firewall'lar, EDR ve yama yönetimi önemli, kararlı saldırganlar sonunda phishing, açık hizmetler veya ele geçirilmiş kimlik bilgileri yoluyla içeri girmenin bir yolunu bulur. Soru, bir olayın yaşanıp yaşamayacağı değil. Olayı ne kadar hızlı tespit ettiğinizdir.

MTTD, saldırganın ilk erişimi ile sizin ilk tespitiniz arasındaki süreyi ölçer. Kısa MTTD, veri ağınızdan çıkmadan önce tehditi kontrol altına alabileceğiniz anlamına gelir. Uzun MTTD, haftlar sonra bir haber makalesinde okuduğunuz anlamına gelir. Ben sabah 2'de bir uyarı almayı, bir saldırganın 90 gün boyunca sunucularımda gezindiğini keşfetmeye tercih ederim.

Daha önce az bilinen güvenlik araçları hakkındaki yazımda (https://furkanikkan.com/urun/guvenlik-uzemlarinin-gercekte-kullandigi-az-bilinen-siber-guvenlik-araclari-55) belirttiğim gibi, görünürlük araçları bir parlak panodan çok daha önemlidir.

Veri Sızdırmayı Gizleyen Yaygın Kör Noktalar

Gördüğüm çoğu ekibin tespiti neredeyse imkansız kılan boşlukları var. Saldırganların gizlendiği yerler şunlar:

• DNS tüneli: Veri, saldırgan kontrollü alan adlarına DNS sorguları üzerinden gönderilir. DNS loglamıyorsanız, en yaygın sızdırma kanallarından birine karşı körsünüz.
• Bulut depolama bucket'ları: Yanlış yapılandırılmış S3 veya Azure Blob container'larına sessizce erişilir. Bucket erişim loglaması açık değilse, okumaları asla göremezsiniz.
• Geniş erişime sahip servis hesapları: Bu hesaplarda nadiren MFA vardır ve neredeyse asla denetlenmez. Veri hırsızlığı için mükemmeldir.
• 443 portundaki giden trafik: Her şey normal HTTPS gibi görünür. TLS incelemesi veya davranışsal taban çizgisi olmadan, toplu sızdırma doğrudan içine karışır.
• Devre dışı veya yapılandırılmamış EDR ajanları: Bozuk sensörü olan bir endpoint, saldırganların hemen istismar ettiği bir boşluktur.

Ben her zaman tek bir soru sorarak başlarım: gerçekten hangi logları topluyorum ve bunlara kim bakıyor? Cevap "çok topluyoruz ama kimse incelemiyor" ise, bu hiç toplamamaktan daha kötüdür. Sahte bir güvenlik yaratır.

Gerçekten Çalışan Bir Tespit Stratejisi Kurmak

Tespit, tek bir araç satın almakla ilgili değildir. Doğru yüzeyler boyunca görünürlüğü katmanlandırmakla ilgilidir. Ortamlarımda önceliklendirdiğim şeyler şunlar:

1. Aktif uyarı ile merkezi loglama — Windows Event Log'larını, Syslog'u ve bulut denetim log'larını bir SIEM'e veya basit bir Elastic stack'e gönderin. Ama sadece depolamayın. Uyarı tetikleyen tespit kuralları yazın.

1. Endpoint görünürlüğü — Linux sunucuları dahil her endpoint'e EDR deploy edin. Ortama göre Wazuh ve CrowdStrike gibi araçlar kullanıyorum. Ajan sağlığını günlük kontrol edin.

1. Kimlik izleme — Çoğu saldırı kimlik üzerinden geçer. İmkansız seyahat, yeni MFA cihazı kayıtları ve normal saatler dışındaki servis hesabı kullanımını izleyin.

1. Ağ akış analizi — Normal trafiği taban çizmek için NetFlow veya sFlow kullanın. Giden veride ani sıçramalar otomatik olarak uyarı tetiklemelidir.

1. Bulut kontrol düzlemi logları — CloudTrail, Azure Activity Logs ve GCP Audit Logs'u etkinleştirin. Tek bir API çağrısı tüm bir bucket'ı ortaya çıkarabilir.

Olağandışı giden veri hacmini tespit etmek için basit bir Wazuh kuralı şuna benzer:

<rule id="100050" level="10">
  <if_group>network</if_group>
  <field name="dst_port">^443$</field>
  <description>High outbound data volume on HTTPS - possible exfiltration</description>
  <group>exfiltration,detection,</group>
</rule>

Bu karmaşık değil ama çalışıyor. Kaç ekibin bu seviyede tespit bile olmadığına şaşarsınız.

Tespit Yeteneğinizi Saldırganlardan Önce Test Etmek

Tespitinizin çalışmadığını öğrenmek için gerçek bir olayı beklemeyin. Ben her çeyrekte purple team egzersizleri yapıyorum. Yaklaşımım şöyle:

Önce, saldırıyı simüle ediyorum. Ortamıma karşı bilinen teknikleri çalıştırmak için Atomic Red Team gibi araçlar kullanıyorum:

Invoke-AtomicTest T1048.002 -ExecutionMode

Bu teknik, alternatif bir protokol üzerinden sızdırmayı simüle eder. SIEM'im birkaç dakika içinde uyarı vermezse, düzeltmem gereken bir boşluğum var.

İkinci olarak, logları manuel inceliyorum. EDR davranışı yakaladı mı? Firewall olağandışı bağlantımı logladı? SIEM endpoint ve ağ olaylarını ilişkilendirdi mi? Her boşluk bir bilet ve bir düzeltme alır.

Üçüncü olarak, tespit süresini ölçüyorum. 30 dakika sürüyorsa, fena değildir. Üç gün sürüyorsa, yapacak işim var. Hedef sürekli iyileştirme, mükemmellik değil.

Görünürlük İçin Gerçekte Kullandığım Araçlar

Stack'imi pratik tutuyorum. Vendor lock-in yok, sihirli vaatler yok:

• Wazuh host tabanlı tespit ve log toplama için
• Elastic Stack SIEM ve log arama için
• Suricata IDS/IPS için edge gateway'lerde
• Zeek derin inceleme gerektiğinde ağ trafiği analizi için
• Sysmon her Windows endpoint'te ayrıntılı süreç loglaması için
• Bulut yerel denetim logları — CloudTrail, Azure Activity Log, GCP Audit Logs

Sağlam bir yapılandırma dosyasıyla Sysmon deploy etmek size süreç oluşturma, ağ bağlantıları ve dosya oluşturma olaylarını verir. Minimal bir Sysmon config girdisi:

<RuleGroup name="Network" groupRelation="or">
  <NetworkConnect onmatch="include">
    <DestinationPort name="Suspicious Port">4444</DestinationPort>
  </NetworkConnect>
</RuleGroup>

Bu, yaygın saldırgan portlarında klasik C2 beaconing'i yakalar. Basit, etkili ve çalışıyor.

Dwell Time'ı Düşürmek Dürüst Değerlendirmeyle Başlar

Mevcut tespit yetenekleriniz hakkında dürüst olun. "Veri ağımızdan çıkıyor olsa ne kadar hızlı bilirdik?" sorusuna spesifik bir sayıyla cevap veremiyorsanız, yapacak işiniz var. Cevabın "FBI arayana kadar bilmezdik" olduğu ortamlar gördüm. İçinde bulunmak isteyeceğiniz bir pozisyon değil.

Küçük başlayın. Endpoint loglamasını çalışır hale getirin. Bulut denetim loglarını etkinleştirin. Beş yüksek doğrulukta tespit kuralı yazın. Test edin. Sonra beş tane daha ekleyin. Tespit, zamanla geliştirdiğiniz bir kasdır, satın aldığınız bir ürün değil.

Saldırganlar zaten hızlı hareket ediyor. Sizin tespitinizin daha hızlı olması gerekiyor.

Kapak görseli: ₡ґǘșϯγ Ɗᶏ Ⱪᶅṏⱳդ · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/148598741@N02/53541654993