Beş veri ihlali, beş tespit yolu: Sizinkini hangisi ortaya çıkarır?

Beş veri ihlali, beş tespit yolu: Sizinkini hangisi ortaya çıkarır?

‍

Son güncelleme: 26 Ekim 2026

Bir güvenlik izleme uyarısı. Kurumsal hesaptan olağan dışı hacimde gönderilen e-postalar. Sunucu ekranındaki fidye notu. Veri işleyenden gelen bildirim. USOM'dan gelen uyarı.

Kamuya açık beş veri ihlali duyurusu, ihlallerin beş farklı yoldan fark edildiğini gösteriyor. Kurucu, operasyon yöneticisi veya güvenlik sorumlusu için soru şu: İşletmenizdeki bir ihlali hangi yol ortaya çıkarır ve kim harekete geçer?

Bu karşılaştırma, tespiti tek bir güvenlik ürününden çok, farklı sinyallerin birlikte değerlendirildiği bir süreç olarak görmeye yardımcı oluyor. Teknik izleme kadar çalışan gözlemleri ve kurum dışından gelen bildirimler de önem taşıyor. Her yolun sağladığı görünürlük ve sınırları farklı.

‍

Beş tespit yolu ve her birinin sınırları

Aşağıdaki olay bilgileri ilgili duyurulardan alınmıştır. Karşılaştırmadan çıkardığımız operasyonel öneriler, bu kuruluşlarda hangi kontrollerin bulunduğuna veya bulunmadığına dair bir tespit değildir.

1. Choice Hotels: güvenlik izleme uyarısı

Doğrulanan tespit yolu: Güvenlik izleme kontrollerinin ürettiği uyarı.
Bildirilen tespit tarihi: 5 Haziran 2026.
İnceleme durumu: Yayımlanan duyuruya göre inceleme devam ediyor.

Choice Hotels International, Inc., bir çalışanın ağ hesabına sosyal mühendislik yoluyla yetkisiz erişim sağlandığını bildirdi. İhlal, güvenlik izleme kontrollerinin ürettiği uyarıyla tespit edildi.

Duyuru, ihlalin başlangıcını ve tespitini 5 Haziran, bitişini 6 Haziran olarak veriyor. Kullanılan izleme ürününü, uyarının hangi koşulda üretildiğini veya tespitin tam saatini belirtmiyor.

Bu yol neyi gösterebilir? İzlenen faaliyetler içinde uyarı koşulunu karşılayan ve araştırılması gereken bir olayı.

Tek başına neyi ortaya koyamaz? Erişimin tüm kapsamını, etkilenen bütün verileri veya ilgili sistemlerin tamamının izlendiğini. Aynı gün tespit edilmiş olması da müdahalenin hemen tamamlandığı anlamına gelmez.

İlgili bir uyarının inceleme yapabilecek kişiye ulaştığını gösteren yakın tarihli ve güvenli bir test isteyin.

2. İzmir Büyükşehir Belediyesi: olağan dışı e-posta gönderim hacmi

Doğrulanan tespit yolu: Kurumsal bir hesaptan olağan dışı hacimde e-posta gönderildiğinin fark edilmesi.
Bildirilen tespit tarihi: 30 Eylül 2026.
İnceleme durumu: İnceleme devam ediyor; etkilenen kişi sayısı tam olarak belirlenmemiş.

Belediye, hesaba önceden ele geçirilmiş bir parola kullanılarak erişildiğini bildirdi. Duyuru, bunu e-posta sunucusundaki bir güvenlik açığının istismarından ayırıyor.

Bildirilen bulgular arasında iki hesabın posta kutusu içeriklerinin kurum dışına aktarılması, gelen iletileri silen kurallar, toplu spam gönderimi ve e-posta imzasına dolandırıcılık içerikli metin eklenmesi var. Olağan dışı hacmi ilk olarak otomatik bir kontrolün mü yoksa bir kişinin mi fark ettiği belirtilmiyor.

Bu yol neyi gösterebilir? Bir hesabın kullanım biçimindeki değişimi.

Neyi kaçırabilir? Gönderim hacminde sıçrama yaratmayan faaliyetleri. Posta kutusu incelemesinde şüpheli yönlendirme ve silme kuralları ile değiştirilen hesap ayarları da değerlendirilmeli.

“Çok sayıda spam gönderilirse fark ederiz” bir başlangıç olabilir. Daha sessiz hesap kötüye kullanımını neyin göstereceğini de sorun.

3. DNC Sağlık: fidye notu ve erişilemeyen veri tabanı dosyaları

Doğrulanan tespit yolu: Bilişim personelinin sunucu ekranında fidye notunu görmesi ve veri tabanı dosyalarına erişilemediğini fark etmesi.
Bildirilen tespit tarihi: Görüntülenen duyuruda tam ve tereddütsüz bir tarih bulunmuyor.
İnceleme durumu: İnceleme devam ediyor; kişi ve kayıt sayıları ilk aşamada kesinleştirilememiş.

DNC Sağlık Hizmetleri AŞ, sağlık verileri de dahil olmak üzere kişisel veriler içeren bir sunucunun şifrelendiğini bildirdi. Şifreleme, ilk aşamada kaç kişi ve kaydın etkilendiğinin belirlenmesini de güçleştirdi.

Bu yol neyi gösterebilir? Acil teknik inceleme ve operasyonel karar gerektiren görünür bir olayı.

Tek başına neyi ortaya koyamaz? Yetkisiz erişimin ne zaman başladığını, saldırganın nasıl girdiğini veya şifrelemeden önce bilgilerin kopyalanıp kopyalanmadığını. Dosyalara erişilememesi, verilerin kurum dışına çıkmadığının kanıtı değildir.

Çalışanların olay bildirmesini kolaylaştırın; bunun yanında uç nokta uyarıları ve olağan dışı ağ faaliyeti gibi daha erken sinyalleri test edin. Fidye notu, kesinti belirgin hâle geldikten sonraki bir tespit yoludur.

4. Güllüoğlu Gıda: veri işleyenden gelen bildirim

Doğrulanan tespit yolu: Veri işleyenin veri sorumlusuna bildirim yapması.
Bildirilen tespit tarihi: 8 Ekim 2026.
İnceleme durumu: Yayımlanan duyuruya göre inceleme devam ediyor.

Güllüoğlu Gıda San. ve Tic. AŞ, veri işleyenin sistemlerindeki bir sunucuya, kullanılan üçüncü taraf yazılım kütüphanesindeki güvenlik açığı istismar edilerek yetkisiz erişim sağlandığını bildirdi.

Etkilendiği belirtilen bilgiler arasında müşterilerin bilgileri ve saklanan şifre değerleri ile satıcı paneli hesapları ve bunların saklanan şifre değerleri bulunuyor. Duyuru veri işleyenin adını veya veri işleyenin olayı ilk nasıl keşfettiğini açıklamıyor.

Bu yol neyi gösterebilir? Başka bir kuruluşun işlettiği altyapıdaki bir olayı.

Tek başına neyi ortaya koyamaz? Olayın tüm zaman çizelgesini veya etki kapsamını. Veri sorumlusunun bildirimle haberdar olduğu tarih, veri işleyenin ilk tespit tarihi olmak zorunda değil.

Acil sağlayıcı bildirimlerini kimin aldığını ve bu kişinin kanıtları nasıl temin ettiğini belirleyin. Veri işleyen riski incelememizdeki soruları bu görüşmede kullanabilirsiniz.

5. Ondokuz Mayıs Üniversitesi: USOM bildirimi

Doğrulanan tespit yolu: USOM'dan gelen bildirim.
Bildirilen tespit tarihi: 14 Ekim 2026.
İnceleme durumu: İnceleme devam ediyor; etkilenen ilgili kişi grupları henüz bilinmiyor.

Ondokuz Mayıs Üniversitesi, kullandığı bir yazılımdaki güvenlik açığından yararlanılarak yetkisiz erişim sağlandığını ve 109 kişinin kişisel verilerinin ele geçirildiğini bildirdi.

Duyuru, tespit yolunu USOM bildirimi olarak belirtiyor. USOM'un bilgiyi nasıl edindiğini veya yazılım ile güvenlik açığının ayrıntılarını açıklamıyor.

Bu yol neyi gösterebilir? Kurum içinde incelemeyi başlatan dış kaynaklı bilgiyi.

Neyi garanti edemez? Dışarıdaki bir kurumun sizin olayınızı keşfedeceğini veya zarar doğmadan önce size ulaşacağını.

Genel iletişim kanalına gelenler dahil, güvenilir dış uyarıların olay sorumlusuna ulaşabildiğini kontrol edin.

Yönetimin yanıtlaması gereken üç soru

Bu yollar örtüşebilir: olağan dışı e-posta trafiği teknik bir uyarı üretebilir; bir sağlayıcı da dışarıdan uyarı alabilir. Bu karşılaştırmayı kapsama alanını ve sorumlular arasındaki aktarımı sınamak için kullanın.

1. Hangi kurum içi sinyaller bize ulaşır?

Teknik sorumludan izlenen sistemleri, uyarı koşullarını ve bunları kimin değerlendirdiğini belirtmesini isteyin. İşletmeniz için ilgili e-posta, kimlik, uç nokta ve bulut hizmetlerini dahil edin. Uyarının iletilmesini ve alındığının teyidini gösteren güvenli bir testin kanıtını isteyin.

Var olan fakat hiç incelenmeyen günlükler, etkin bir tespit süreciyle aynı kabiliyeti sağlamaz.

2. Kurum dışından biri sorunu bildirebilir mi?

Sağlayıcıların, müşterilerin ve güvenlik araştırmacılarının ulaşabileceği, takip edilen bir bildirim kanalı olup olmadığını kontrol edin. Acil sağlayıcı iletişim bilgilerini ve olağan muhatap erişilemiyorsa kullanılacak yedek yolu doğrulayın.

Türkiye'de hizmet veren yabancı bir SaaS işletmesinde, küresel güvenlik ekibi, yerel iş irtibatı ve gizlilik sorumlusu arasındaki aktarımı test edin. Türkçe gelen bildirimlerin nasıl anlaşılacağını ve yönlendirileceğini kararlaştırın.

3. Olayın üst makamlara taşınmasından kim sorumlu?

Bir olay lideri ve yedeği belirleyin. Sınırlama önlemlerini kimin onaylayacağını, kanıtları kimin koruyacağını, sağlayıcılarla kimin iletişim kuracağını ve gizlilik veya hukuk değerlendirmesini kimin koordine edeceğini yazın.

Şirket e-postasının kullanılamadığı veya ele geçirildiği bir senaryoyu test edin. Eskalasyon planında kullanılabilir bir alternatif iletişim kanalı bulunmalı.

İlk adım: beklediğiniz ilk üç sinyali adlandırın

Olay sorumlusuna şu soruyu sorun:

“E-posta hesabının ele geçirilmesi, fidye yazılımı ve bulut verilerinin açıkta kalması için beklediğimiz ilk üç sinyal nedir, nerede görünür ve kim harekete geçer?”

“İlk”, ekibinizin en erken fark etmeyi beklediği sinyalleri anlatır; garanti edilen bir sıralamayı değil. Aşağıdaki örnekler kendi ortamınız için düşünme aracıdır; beş duyurudan çıkarılmış ek olgular değildir.

Ele geçirilen e-posta hesabı

  1. İncelenmesi gereken bir kimlik veya oturum açma uyarısı.
  2. Şüpheli yeni bir yönlendirme veya gelen kutusu kuralı.
  3. Olağan dışı gönderim faaliyeti ya da hesap sahibinin göndermediği iletileri bildiren bir alıcı.

Fidye yazılımı

  1. Şüpheli çalıştırma faaliyetine ilişkin uç nokta uyarısı.
  2. Sistemler arası olağan dışı hareket veya dışarıya doğru alışılmadık veri trafiği.
  3. Erişilemeyen dosyaları veya fidye notunu bildiren bir çalışan.

Üçüncü sinyal, ciddi kesintiden sonra gelebilir. Çalışmada önceki sinyallerin üretilip izlenip izlenmediğini sorgulayın.

Açıkta kalan bulut verileri

  1. Depolama izinlerinin amaçlanmayan herkese açık veya kurum dışı erişime izin verdiğini gösteren bulgu.
  2. İlgili erişim günlüklerinde görülen olağan dışı nesne okuma veya indirme işlemleri.
  3. Açıkta kalan bilgiyi işaret eden dış bildirim.

Verinin erişime açık olmasını fiilen erişilmiş olmasından ayırın. Herkese açık erişim bulgusu izinleri gösterir; tek başına kişisel verilerin indirildiğini kanıtlamaz. Öte yandan, ilgili günlükleme hiç etkinleştirilmemişse kayıtlarda indirme görülmemesi de güçlü bir güvence değildir.

Örneğin Amazon S3 için erişim analizi, herkese açık veya hesaplar arası erişimi tespit edebilir. Nesne okuma gibi CloudTrail veri olaylarının kaydı uygun yapılandırma gerektirir; izler bunları varsayılan olarak kaydetmez. Kendi platformunuzdaki eşdeğer ayarları kontrol edin.

Önerdiğiniz her sinyal için kaynağı, alıcıyı, izleme saatlerini ve son test tarihini yazın. Eksikleri belirleyip sorumlu ve gerçekçi bir tamamlanma tarihi atayın. Bir ürünün neyi tespit ettiğini ve uyarısının ekibe nasıl ulaştığını açıklayamıyorsanız boş kutuya yalnızca ürün adını yazmayın.

Uyarının müdahaleye nasıl dönüşeceğini bilin

Bu beş duyuru, hangi tespit yönteminin en iyi performansı gösterdiğini söyleyemez. Bunlar güvenlik araçlarının kontrollü karşılaştırması değil, ayrı olayların özetleridir.

Buna karşılık yararlı bir yönetim testi sunarlar: Kuruluşunuz farklı yönlerden gelen uyarıları fark edip bunlara karşı harekete geçecek kişiyi belirleyebiliyor mu?

Üç senaryolu çalışmayla başlayın. Ekip bir sinyali sorumlu kişiye kadar izleyemiyorsa giderilecek somut bir boşluk bulmuşsunuz demektir.

Kooch'un sürekli uyum desteği, üzerinde anlaşılmış kanıt incelemelerini ve olay koordinasyonunu kapsar. Teknik ekip, sağlayıcılar ve gizlilik işlevi arasındaki sorumlulukları ve eskalasyon yollarını belgelemek için Kooch ile iletişime geçin.

Kaynaklar / Referanslar

Resmî duyuruların metni ve erişilebilirliği 26 Ekim 2026 tarihinde yeniden kontrol edildi. Yukarıdaki olay açıklamaları her duyuruda bildirilenlerle sınırlıdır. “İnceleme devam ediyor” ifadesi, yayımlanan duyurudaki durumu aktarır; mevcut usul aşamasının bağımsız teyidi değildir.

  1. KVKK veri ihlali bildirimleri dizini — beş duyuru 21 Ekim 2026 altında listeleniyor.
  2. Choice Hotels International, Inc. — izleme uyarısı; 2026/2288.
  3. İzmir Büyükşehir Belediyesi — olağan dışı e-posta hacmi; 2026/2271.
  4. DNC Sağlık Hizmetleri AŞ — bilişim personelinin gözlemi ve ilk sayım sınırları; 2026/2282. Duyurudaki tespit tarihi eksik.
  5. Güllüoğlu Gıda San. ve Tic. AŞ — veri işleyen bildirimi; 2026/2281.
  6. Ondokuz Mayıs Üniversitesi — USOM bildirimi; 2026/2290.
  7. NIST SP 800-61 Rev. 3 — izleme, dış bildirimler ve olay sorumlulukları için teknik rehber; Türk hukuku yükümlülüğü olarak sunulmuyor.
  8. Microsoft: Compromised cloud email account — posta kutusu kuralları ve yönlendirme kontrolleri.
  9. CISA #StopRansomware Guide — izleme, inceleme ve alternatif iletişim.
  10. AWS IAM Access Analyzer for S3 — herkese açık ve hesaplar arası izinler.
  11. AWS CloudTrail logging for S3 — nesne düzeyinde veri olayları ve varsayılan kayıt ayarları.
Masoud Salmani