Kısa yanıt
- TDR = tehdit tespiti ve müdahale (Threat Detection and Response). Bir ürün değil, bir yetenek tanımı.
- Önleme katmanı geçerli kimlikle gelen erişimi görmez; TDR tam olarak bu boşluğu kapatır.
- XDR araç, MDR hizmet, SIEM kayıt ve alarm altyapısı; TDR ise hepsini birleştiren süreçtir.
- Başarı üç süreyle ölçülür: tespit, ilk müdahale ve kapatma süresi.
TDR nedir?
TDR, tehdit tespiti ve müdahale (Threat Detection and Response) kelimelerinin kısaltması. İki işi tek bir çatı altında tanımlıyor: ortamda olup biteni sürekli izleyip tehdit olabilecek davranışı bulmak ve bulunan şeye tanımlı adımlarla karşılık vermek.
Burada iki yarı birbirini tamamlıyor. Tespit yarısı; uç nokta, kimlik, ağ, e-posta ve bulut kayıtlarını toplar, bunları analiz eder ve tehdit istihbaratıyla anlamlandırır. Müdahale yarısı ise tespit edilen olayı sınırlar, kaynağını temizler, etkilenen sistemleri geri döndürür ve olayı kayda geçirir.
Dolayısıyla TDR bir ürün adı değil, bir yetenek tanımı. Aynı işi yapan araçlar değişse de sorulan sorular aynı kalır: hangi kayıtlara bakıyoruz, hangi davranışı şüpheli sayıyoruz, alarm geldiğinde ilk yarım saatte kim ne yapıyor?
Tespit olmadan müdahale tahmine, müdahale olmadan tespit bir rapora dönüşür. TDR bu iki yarıyı aynı süreçte birleştirdiğinde anlam kazanır.
Neden önleme tek başına yetmiyor?
Kurumların güvenlik bütçesinin büyük bölümü hâlâ önlemeye gidiyor: güvenlik duvarı, uç nokta koruması, e-posta filtresi, farkındalık eğitimi. Bunlar gerekli, ama hiçbiri tek başına "buradan saldırgan geçemez" garantisi vermiyor. Böyle bir garanti zaten yok.
Saldırıların önemli bölümü artık teknik bir açıktan değil, geçerli bir kimlik bilgisinden ilerliyor. Oltalama ile ele geçirilmiş bir hesap, satın alınmış bir oturum veya yanlış yapılandırılmış bir bulut izni; hepsi meşru görünen bir erişim üretiyor. Kimlik doğrulaması başarılı olduğu için önleme katmanı burada bir şey işaretlemiyor.
Önlemenin tek başına kapatamadığı boşluklar:
- Geçerli kimlikle gelen erişim: saldırgan yeni bir hesap açmıyor, var olan hesabı kullanıyor. Yetki sorgusu geçiyor, davranış sorgusu geçmiyor.
- İzin verilmiş araçların kötüye kullanımı: uzak yönetim araçları, betik yorumlayıcıları ve dosya paylaşım sistemleri kurumda zaten var. Kötüye kullanıldıklarında engellenecek bir "yabancı" yazılım da yok.
- Tedarik zinciri: güvenilen bir üreticiden gelen güncelleme veya eklenti, kendi altyapınızdaki bir açıktan daha kolay içeri giriyor.
- Yapılandırma hatası: açık bırakılmış bir yönetim arayüzü ya da fazla yetkili bir servis hesabı bir açık değil, bir tasarım tercihi. Yama yönetimi bunları görmez.
"Kaç saldırı engelledik" iyi bir gösterge değil. Daha dürüst soru şu: içeri giren bir saldırıyı kaç saatte fark ederiz?
Tespitten müdahaleye: süreç nasıl işler?
İyi kurulmuş bir TDR süreci tek bir kahramana değil, sıralı adımlara dayanır. Adımların her birinin bir çıktısı ve o çıktının yazıldığı bir yer olmalı.
- Telemetri: uç nokta, kimlik sağlayıcı, ağ, e-posta ve bulut kayıtlarının toplanması. Kaydı tutulmayan sistem, tespit kapsamının da dışında kalır.
- Tespit: imza ve kural eşleşmesi, davranış analitiği ve tehdit istihbaratının birlikte çalışması. Bilinen saldırılar kuralla, bilinmeyenler sapmayla yakalanır.
- Önceliklendirme: alarmın varlık kritikliği, hesabın yetkisi ve zamanlamayla birlikte puanlanması. Her alarm aynı sıraya konmaz.
- Araştırma: olayın kapsamının belirlenmesi: hangi hesaplar, hangi cihazlar, hangi veriler ve ne kadarı etkilendi.
- Sınırlama: yayılmayı durduracak geri alınabilir adımlar. Oturum kapatma, erişim kısıtı, cihazın ağdan ayrılması.
- Temizleme ve kurtarma: kalıntının kaldırılması, düzeltmenin uygulanması ve sistemin kontrollü biçimde devreye alınması.
- Kapanış ve ders: ne olduğunun, ne yapıldığının ve neyin değişmesi gerektiğinin kayda geçirilmesi.
Bu sürecin yönetimi ölçümle mümkün. Aşağıdaki üç süre, TDR'nin gerçekten çalışıp çalışmadığını gösteren en temel göstergeler:
| Ölçüm | Neyi anlatır? | Zayıfsa işaret |
|---|---|---|
| Tespit süresi | Olayın başlamasıyla fark edilmesi arasındaki zaman. | Kayıt kapsamı eksik ya da tespit kuralları seyrek. |
| İlk müdahale süresi | Alarmın çıkmasıyla ilgilenilmeye başlanması arasındaki zaman. | Alarm hacmi yüksek, sahiplik tanımlı değil. |
| Kapatma süresi | Olayın sınırlanması ve kapanması arasındaki zaman. | Yetki, erişim veya karar onayı tıkanıyor. |
Bu üç süre bir arada okunmalı. Yalnızca kapatma süresini kısaltmak, fark edilmeyen bir olayı daha hızlı kapatmak anlamına gelmez; tespit süresi uzunsa toplam etki değişmez.
XDR, MDR ve SIEM ile farkı
TDR şemsiye bir kavram. Piyasada duyduğunuz kısaltmalar ise bu şemsiyenin altındaki araçları ve hizmet modellerini anlatıyor. Karışıklık genellikle buradan çıkıyor.
| Ne yapar? | Kim yürütür? | |
|---|---|---|
| SIEM | Kayıtları toplar, ilişkilendirir ve alarm üretir. | Kurumun kendi ekibi. |
| EDR | Uç noktada davranışı izler, şüpheli süreci durdurur. | Kurumun kendi ekibi. |
| XDR | Uç nokta, kimlik, e-posta ve bulut sinyallerini tek yerde birleştirir. | Kurumun kendi ekibi. |
| MDR | Aynı izleme ve müdahale işini dışarıdan yürütür. | Hizmet sağlayıcı, kurum adına. |
| TDR | Tespit ve müdahaleyi uçtan uca tanımlayan süreç. | Kim yürütürse yürütsün, sorumluluk kurumda. |
Bu ayrımın pratik karşılığı şu: bir araç satın almak TDR kurmak anlamına gelmiyor. Araç, sürecin hangi adımını hızlandırdığı ölçüde değerli. Alarmı üreten araç var ama alarmı ele alacak tanımlı adım yoksa kurum yalnızca daha hızlı bilgi sahibi oluyor, daha hızlı müdahale etmiyor.
Aynı çizgide iki yazımız daha var: SOAR yazısında alarm üretmekle alarmı ele almanın ayrı işler olduğunu, UEBA yazısında ise geçerli bir hesabın olağandışı davranışının nasıl görünür kılındığını anlatmıştık.
MDR, izlemeyi devreder; sorumluluğu devretmez. Veri ihlali bildirimi gibi yükümlülükler her durumda kurumun üzerinde kalır.
Nereden başlamalı?
- Kayıt envanteri çıkarın. Hangi sistem kayıt tutuyor, ne kadar süre saklıyor ve merkezî olarak okunabiliyor mu? TDR'nin sınırı bu envanterin sınırıdır.
- Kritik varlıklarla başlayın. Yönetim yetkisi olan hesaplar, kimlik sağlayıcı, finans ve üretim sistemleri. Herkesi aynı anda izlemek alarm hacmini yönetilemez kılar.
- Üç senaryo için akış yazın. Oltalama bildirimi, olağandışı oturum açma ve kritik sunucuda şüpheli süreç. Bu üçünün adımları yazılıysa geri kalanı benzer biçimde kurulur.
- Süreleri bugünden ölçmeye başlayın. Tespit, ilk müdahale ve kapatma sürelerini haftalık izleyin. Ölçülmeyen iyileşme gösterilemez.
- Geri alınabilir adımları otomatikleştirin. Zenginleştirme, ön kontrol ve geçici erişim kısıtı otomasyona uygun. Kalıcı yetki değişikliği ve hukuki bildirim insan onayında kalmalı.
- Planı test edin. Yılda bir yapılan masa başı tatbikat, kriz anında ilk aranan belge olur. Test edilmemiş bir müdahale planı, var olduğu varsayılan bir plana benzer.
TDR'nin başarısı kaç alarm ürettiğiyle değil, gerçek bir olayı ne kadar sürede sınırladığıyla ölçülür.
Son olarak: araç seçimi ikinci adım. Önce hangi kaydı tuttuğunuzu, hangi davranışı şüpheli saydığınızı ve alarm geldiğinde kimin ne yapacağını yazmak gerekir.